In The Scrum Guide Ken and Jeff write that Scrum is simple to understand, but extremely difficult to master. The entire guide is only 16 pages long, including the title and acknowledgements pages. This speaks to its simplicity. The difficulty comes from implementing it in a changing world. What works today may not work tomorrow. What worked with one team, may not work with another. Using Scrum is a constant battle with change; being, well, agile.

When discussing the question of how to best to implement Scrum across the enterprise, I like to use Scrum itself as a guide. The ubiquitous Stacey chart tells us that a project for which there is a high amount of agreement on the end goal, and a lot of certainty regarding the solution, might best be accomplished with a waterfall approach. It is really projects that fall in the complex band that are prime candidates for Scrum.

Likewise, if there is a high degree of agreement regarding what the enterprise will look like, post roll-out, and a lot of agreement regarding how to get there, then an all-in approach, in which the entire enterprise adopts Scrum on a given date, could very well be the best option.

However, if agreement and/or certainty are not close and the enterprise finds themselves in the Complex band, it makes much more sense to do an incremental, agile, roll-out. In this case, I suggest the following approach.

Step 1—Prepare

Gather a list of your likely Sprint team members, remembering to include developers, user experience people, QA/QC, DBAs, etc…

Step 2—Rate

Rate each person on Scrum knowledge and Scrum experience.

Step 3—Implement

Use the information from Step 2 to determine how many Scrum projects you can start at one time. You should plan on having two to four people experienced with Scrum on each team. Include Scrum training for the entire team before the project officially starts.

Step 4—Rinse and repeat

At the end of each project, try to divide the team up so two to four experienced Scrum people can go to work on another project. This will let you start two to four new Scrum teams for each Scrum project that ends. Continue to repeat the process until everyone has been trained and is working on a Scrum team.

Scrum is designed to be simple. Sometimes we forget this and complicate things by trying to insert old, management thinking into the process. So make things easy on yourself and let Scrum do the heavy lifting for your next enterprise roll out.

See you next time…