[Select Repost] Scaling — What's it all about?

Jim York argues, in this blog post, that scaling Agile requires starting with the simple and progressing through practice to mastery. Here he offers basic steps to go from small to larger scale Agile.

 


 

Recent discussions around scaling agile remind me of the applicability of the shu ha ri model in martial art to success in agile. The path to mastery is not found in a cookbook or by taking a pill. As in the martial arts, scaling agile requires starting with the simple and progressing through practice to mastery.

Scaling agile requires starting with the simple and progressing through practice to mastery.

Getting started is simple

The first step in scaling agile is easy — well, relatively easy compared to later steps. Before you contemplate scaling, first make sure you can create a single effective agile team. At a minimum, to create a single effective agile team you must start by giving the team what it needs to be successful, then listen for their emerging needs, and fulfill those needs quickly. Given the right ingredients and the right support, accomplishing this first step is almost a given barring major organizational culture issues.

But it gets harder

Step 2 gets a bit more complicated. On the surface it's pretty straightforward. Simply repeat whatever you did to create that first effective agile team. Be prepared though. It might not be so easy the second time around. Here’s why:

To achieve the first effective agile team, most organizations do things like dedicate staffing to the team; establish a team room; allocate tools, equipment, environments, and so forth to that team's exclusive use... in other words, remove all of the impediments that might otherwise get it the team's way of being an effective agile team. Then, if anything was missed and the team discovers a new impediment, swoop in and get the impediment out of the team's way.

Removing impediments for the agile team usually has the side effect of further constraining the rest of the organization.

The problem lies in that removing impediments for the agile team usually has the side effect of further constraining the rest of the organization. For example, pulling staff to work on just one initiative, without reducing the total number of initiatives in progress, increases the workload for the remaining staff. Likewise, reserving a conference room for the exclusive use of an agile team as their "team room" takes formerly shared space out of the pool of available shared space for the rest of the organization.

So, while achieving the first team was relatively easy, getting a the second team to the same level is progressively harder. And…

We’re not done yet

Once you’ve proven that you can create a single agile team and then that you can do it again with a second team, you are still not ready to scale. You must now be able to repeat the process that you used to create your first 2 effective agile teams until you have enough teams to meet the demands of the initiative you wish to tackle.

And here is where the wheels might fall off the bus. Unless something is done to balance the needs of the agile teams with the constraints of the environment in which they operate, the teams will cease to be effective agile teams — and you can’t scale effectively without the building blocks of these effective agile teams.

Scaling agile changes the organization

The organization’s capacity to make and absorb change limits the rate at which it can create effective agile teams.

The bottom line is that scaling agile requires significant organizational change. The ripple effect of the changes realized by the act of creating a single agile team grows with each additional effective agile team. The cumulative effect of these ripples gives rise to massive waves of change that can overwhelm an unprepared organization. The organization’s capacity to make and absorb change limits the rate at which it can create effective agile teams. Increasing that capacity is ultimately what agile is all about.