Scrum Is Not a Serious Tool
I have been an Agile proponent for several years now. When I first started looking at Scrum as a solution for our company, I dismissed it outright. “This is light-weight project management.” “My boss will never take something serious that calls people ‘pigs’ and ‘chickens’” and most importantly “Where are the project plans and documentation!” This was designed for DotComs – not real companies!
Eventually, Scrum became pivotal to the success of some very aggressive and high-profile projects.
In retrospect, I realized:
- This is not lightweight project management, it’s just different. If anything its collaborative project management – which is far more likely to be successful.
- I think the ‘pig’ and ‘chicken’ thing is kind of silly – but I am sort of a serious guy. Apparently, this is the one thing that most people remembered when going to Scrum training. Especially the non-IT people. Go figure.
- Lack of formal documentation is a problem only because of the big mental leaps people must make to substitute the formal idea of a big stack of papers in a three ring binder with post-it notes or tracking systems.
Learning From Others
A couple years into my first, remarkably successful Scrum implementation of four Scrum teams I was having lunch discussing Scrum with someone from another company. He was in the first few months of implanting Scrum in his company.
This newly minted Scrum Master confidently explained to me the amazing application they were using to track their projects. He described the customization and workflows that they were using to manage the teams. He talked about how their system tracked all the tasks down to them minute, which fed data to charts and management reports, and ultimately populating the overall portfolio management system. He spoke with pride of all the improvements they made to the process. Then he explained, because of the importance of the project they needed to have weekly project status reports and meeting to review these reports.
I sat in horror listening to this bastardization of Scrum. In fact, the only thing ‘Scrum’ about it was that he called himself the Scrum Master. I didn’t know what to say. He was so proud of it – I didn’t want to be the one tell him his “baby was ugly.”
Later, I was talking this over with another Scrum Master friend. I concluded that I just didn’t think their process would work. My suspicions were confirmed the following year, when I ran into him again, and was told that they had abandoned Scrum because “it just didn’t work.”
Since then, I have had this conversation a half a dozen times with different companies about how they tried Scrum but it just doesn’t work in their company. But when I dig into what they did and how they did it, I always discover the same thing. They weren’t doing Scrum. At best they were doing waterfall with iterations, a.k.a. Scrummerfall.
In corporate I.T. management that all ails can be cured by more planning, documentation, tracking, measurement, and reports. However, there is a also the assumption that when you start a project that the project scope is locked down, and the budget won’t change. There is the competing expectation that if “the company” wants a “small change” to the project, it’s no big deal.
The Gratuitous Analogy
What would a great lecture be without a great analogy… enjoy!
- Scrum is like whitewater rafting. The rafting team members each have a job, they know how to perform it, and they know the team’s short term goals very well – “get beyond the first rapids.” They vaguely understand the approximate long term goal – “Get to the end of the river.” And, they know they have to work together, and help each other succeed. Finally, they know that everything else is pretty much going to change. The rocks aren’t always in the same plae, the rapids are moving faster, a log is floating alongside the boat. The team has to pull their strengths to get through, and make collective changes along the way.
- Waterfall project teams are military ships with a crew, a captain, a detailed set of orders, and an admiral relaying changes from command.
- Scrummerfall is taking that rafting team, with a captain, the orders, and the admiral relaying changes. This is a recipe for failure.
Scrum is fantastic for companies because it allows them to be agile (that’s why they call it agile). It is about being able to change directions quickly in response to the environment without sinking the raft.
Why Companies Fail
As I have said, I have talked to many people who have told me how “Scrum didn’t work in my company.”
The reasons companies fail at Scrum is they don’t really adopt Scrum. They try to make Scrum work in the framework of all the old baggage, and try to make it ‘Scrummier’. To some extent it is possible; As Mike Cohn (Scrum Pioneer, Author, and all around great consultant) told me, “It’s not about being Agile… it’s about becoming more Agile.”
However, you can’t be Agile by spending months doing detailed project plans and trying to stick to them. You can’t burden your Scrum teams down by having them to use their [expensive] development time updating tracking software and attending status meetings.
In order to have a chance at succeeding in Agile, companies have to allow teams to start fresh. They have to be allowed to try new methods of planning and budgeting. They need to be given the latitude to self-manage, and most importantly they need to be allowed to incrementally make changes to their process without interference from ‘traditional management’. Finally, the Scrum Master must remember his role is to serve the team, coach in Scrum dogma, and help remove impediments to progress – never to lead or dictate things to the team.
In a nutshell, Scrum generally fails because companies aren’t comfortable changing to allow it to