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.

Reference: Use Scrum even if you don’t want to be Agile from our NCG partner Johannes Brodwall at the Thinking Inside a Bigger Box blog.