You probably won’t be surprised by the fact that quite many people in the quite many organisations think that if they adopted a daily standup—they nailed Scrum methodology. Oh, wait, and “we use story points, too!”. What those people have come up with for sure—the endless list of excuses, such as “But we’re in a startup, we can’t afford to dedicate more than 45 minutes for the estimation meeting!” or “I as a CEO am too busy to attend the scrum of scrums meeting”. But why it happens?
Of course, each case is different, as well as the process change for an organisation is difficult, and may fail for a number of reasons.
The Story of a Failure in the Agile Tranformation
ACME Company has a product that requires software development. As the company matured and grew, Business people began to complain about many problems perceived to come from the development shop. The CFO and other C-level execs complained that lots of projects got initiated, few finished, and there was no sense of value being delivered. WE NEED A SOLUTION!!!
So a Director, Manager or perhaps a VP mentioned this “agile” process that is catching on, and how “I hear that lots of companies are having success with it.” So they call in some sales guy who pitches their training and coaching and tells them a pipe dream of how they can develop twice as much code in the same amount of time.
They spend a lot of money to train their developers, QA and a few other roles how to run Scrum. The PMs, who have a traditional background, are assumed to make natural Scrum Masters. Its’ still project management, right? They even call them PMs still. Agile PMs. There you go; a change in title is all you need.
People who have a full time job managing parts of the product are given part time responsibility to become Product Owners. They don’t have the time to do their jobs properly, and are not very well coached in their role–remember, the old waterfall PMs are now the SMs and don’t have the experience to teach them how to do their job well.
And to top everything off: The VP level on up believes they don’t have to learn anything or change in any way. Nor do they understand that Business, Sales and other departments need to make changes for this to work.
The really funny part is that very often the PMO itself doesn’t change. The Director of the PMO could be 100% waterfall and not even understand how his or her lack of knowledge about Agile will poison the process. The PMO continues to think that the solution for everything entails MORE GOVERNANCE, MORE DOCUMENTATION, and MORE GATES.
Often, this situation is called an IMPLEMENTATION because they simply outlined a bunch of new processes and implemented the changes. But no thought was given to changing how people think.
When the organization changes its thinking process, this is a TRANSFORMATION.
Lack of Top-Down Support
Being agile is not just following some book or enforcing some scrum ceremonies. It should be coming from the inside. Or, in case of an organisation, from top to bottom, too. Quite often, unfortunately, the whole initiative ends up where it started—in the same department (usually IT).
When I look back at those situations, I recall the moments when a simple facilitation from an executive could really help to bring it further.
Blindly Following a Scrum Book
There is a false belief that adopting a few “scrum-ish” processes will bring changes to the teams and will magically transform the whole organisation. But in reality, agile requires a cultural change, a mind-shift sort to speak. In the most of the cases however, companies simply tend to adopt a few scrum ceremonies without understanding that there is a false sense of expectation that the teams will now start “delivering” with the triple speed.
Due to this the company hangs in between agile and waterfall. Kind of not there yet, but not so far away from the beginning too. This leads to a hybrid implementation (aka “scrumban”) which leads to the final statement that “agile does not fit our organisation”.
- No change to organizational structures. Projects are running up and teams are shuffled together to work on the project.
In agile, however, teams should be formed and projects should be given to teams.
“Bring work to the people, not people to the work.”
- No change to a personal commitment.
Individuals do not “team up” and continue being same individuals who are more extrinsic-driven and don’t really care what happens to their team.
- Ignoring the boundaries
A stakeholder ignores the defined processes and simply asks his “favorite” developer “when this thing is going to be ready?”, thus breaking the feeling of sprint isolation.
- Ignoring the processes
A team member works on what he wants to, when he wants to, and doesn’t care about the team performance as a single unit.
- Ignoring cross-functional opportunity
A team member (say, a programmer) refuses to help with testing because he is a developer, not a tester!
Although Scrum is not a doctrine but rather a framework, the real scrum transformation requires more than just everyone’s buy-in. It requires the whole change of culture, the development of habits, constant facilitation of ceremonies, transparency. Build this and you’ll get trust, responsibility, commitment and improved delivery.