Starting agile adoption

Imagine that you have some interest in Agile. Perhaps you read a book, and talked with a friend who is doing agile at his firm.

Then you take a Scrum course.

Now what do you do?

Let’s take a middle of the road case, where you have a software development group of 80 or so, and business people for another 20 people. You are one of the 80.  You’ve come into the office on Friday morning. You want to do something with Scrum, but you are unclear where to start.

Here are some ideas.

1. Take a deep breath.

You are a beginner. You won’t do everything in one day, and there is no need to do everything in one day.

It will be a long, up-and-down climb. The adoption process can take you every day for a bunch of days.  Just to get started.  (It is worth it.)  Get ready.

2. Convince some people to do a pilot.

Talk to some people who seem interested. Get them more interested.  Ask if they would like to try it.

Talk to a boss, and ask if he would be Ok to try it. Maybe 6 Sprints (2 weeks each).  One Team.  Possibly the first MVP would would be longer than 6 sprints, but you ask him to commit to at least 6 sprints as a fair trial.

3. Do the pilot

One team, 7 volunteers.  Get people who want to try it.

Work hard to make it successful.  Get some important impediments removed!

Almost surely, by 6 sprints the Team will be clearly better than what you all used to do.

4. Tell good stories of success

You have to tell the stories of success. The how and why it was better.  About some happy people. About some good numbers.  Depends partly on your culture.

5. Continue the first pilot and start a 2nd pilot

Make these a success.  Again, get volunteers.

6. Consider an Open Space event

About now, you may have some momentum.  Also a sense that some things must change to make this new thing (agile) work better around here.  Use the Open Space event to identify and attack those key impediments.

Both impediments to the 2 existing teams and impediments to a broader agile adoption.

7. Deepen the existing 2 Teams

By deeper we mean: doing agile better.  (Another option is doing things more widely but thinner.  Not really recommended – yet.)

The deeper and stronger they become, the more they become hardened ships that can cut through the deepest arctic icebergs.

Build their stories of success till the stories start to tell themselves.

8. Widen the teams.

Add another 2 teams. Do not widen too fast.  Take care of these teams. Remember that they are new.  They need more help.  The culture is now feeling a threat, and is starting to resist.  The volunteers are not quite as gung-ho.  The overall complexity is mounting.

Do not widen the agile too fast. Give yourself (and those you have gathered) enough bandwidth to support these new teams properly. And still support the 2 original teams.

9. Start a management IRT

IRT stands for ‘impediment removal team.’  This Team (and it may be part-time) takes as its backlog some of the impediments from the 4 existing teams. The managers in this team must deliver, sprint by sprint, solutions to impediments.  Implemented solutions to reasonably sized impediments. One each sprint.

It keeps the managers off the streets. (A Yogi Berra in-joke. I like managers. Really.)  Gets them actively supporting agile.

10. Rinse and repeat.

Well, there are many more things that could be said.

Continuing to do these same things, as the adoption widens, is not a bad idea.

And it allows me to close this blog post for today.

 

« « The ScrumButt Test (4): You know who the Product Owner is || What does the Scrum framework do? » »