Use Scrum even if you don't want to be Agile
An “Agile” project is one that actively seeks to incorporate changes as the project progresses, rather than assuming that the plans from the beginning of the project will work for the whole project duration. Not all organizations want to adopt “agile” as their project metaphor. And some organizations that do adopt methods such as Scrum do it without becoming as “agile” as Scrum promises. Instead of criticizing these organizations of “agile heresy”, I would instead like to offer some useful experience from Scrum, even if the word “agile” doesn’t appeal to you.
Track your progress with small, well-defined milestones: The Product backlog of Scrum is essentially an ordered list of work items. Good backlog elements are either completed or not completed. Partially completed milestones are not counted. A more Agile project will let the product backlog change throughout the project, while a more rigid project may set down the whole backlog at the beginning of the project. Using a product backlog that is complete ‘up front’ makes your project less agile, but using a product backlog lets you track progress better than most traditional project plans. Demonstrate progress to stakeholders: The earlier a project gets feedback on the work it has completed, the better it is able to anticipate and deal with misunderstandings. The expectations of stakeholders is often misunderstood until everyone can actually see what is being constructed. Scrum requires Sprint reviews at regular intervals of a couple of weeks to demonstrate progress. A project with less communication with the stakeholders may have fewer and less regular reviews, but every review you do have will reduce your risk. Communicate daily within the team: Just as there will be misunderstanding between the project and the stakeholders about the proper outcomes, there will be misunderstandings within the team about the proper strategies to complete the project. Scrum requires a daily standup meeting to enforce communication within the team. Other teams may be geographically distributed, dislike the ritual of the standing meeting or work on non-overlapping tasks and decide that they need less communication. Regardless of the form or frequency of communication within the team, the project should evaluate whether they are making repeated mistakes because of lack of shared knowledge and awareness. And whether their rituals waste or preserve the time of the team. Make decision making explicit: In Scrum, the decisions about what the team should work on rests with a single individual: The Project owner. Many organizations cannot invest the authority that this role implies with a single individual, or cannot find an individual with both the business understanding and the technical knowledge to make confident evaluations. Regardless of whether the authority rests with a single individual, a project needs to make decisions about what it should create and in what order. Identifying who needs to be involved in these decisions will make the project run more smoothly.
You don’t need to “drink the Agile cool aid” to benefit from the experience of Scrum over the last 20 years. And many projects that profess being Agile just be using the rituals from Scrum within an old mindset. You will not get the same benefits from Scrum as a truly agile team, but that doesn’t mean it’s not right for you.
Comments:
[Jan Erik Carlsen] - May 30, 2012
I fully agree that this is useful for anyone running an IT-related project, agile or not. I don’t think everyone is aware of the great impact that these techniques have on the motivation of the team members and the productivity of the team.  Some of these aspects were also mentioned in my talk at Smidig2010: http://vimeo.com/30574961
[Jeroen Mengerink] - May 29, 2012
Good post, your statements are very clear! Too bad that most organizations just want to say “Look how Agile we are” while they use Scrum in the less Agile way you described.Â
Geir Amsjø - May 29, 2012
You are being very constructive here Johannes, and this may be a good way to bring peace to the IT-business:-) But - there is a big but(t) here - too many settle for the small benefits while they could have had the big one. I will advise almost all IT-oriented organisations to aim for the big one.
So I agree that it can be an OK approach to start with an “un-agile Scrum” first, and then gradually become more and more agile.
Johannes Brodwall - May 29, 2012
Thank you both, @google-5d544533084e4fb035ba47d2144088dc:disqus and @twitter-18375388:disqus for nice comments. The most important idea in all of this is to separate Scrum and Agile in people’s mindsets. Scrum doesn’t automatically make you Agile.
Jordan - Jun 11, 2012
So it really is a one size fits all methodology then? Jordan
Johannes Brodwall - Jun 11, 2012
Or “one size fits none” except with adapting it to the circumstance. :-)
Johannes Brodwall - Jun 4, 2012
Your philosophy in the talk is very much the same as mine. The statement “we have to do this, otherwise we’re not agile” is not helpful. I like your approach of showing some things people can do even if they don’t want to discuss “agile” yet.