Scaling agile

I've had some conversations regarding "scaling agile" recently, with people from other countries than Sweden. I promised them to put together blog posts on how I teach and coach agility in an organization that spans many departments, many teams, and many components. For their sake I try to do it English which is my second language, so bear with me.

Scaling

The descriptions of the agile methods such as Scrum often focus on the convenient small scale: the whole client organization may be represented by a single Product Owner, the whole IT-department by the cross-functional team (max 9 persons) that actually has the competence to create a full feature end-to-end in the few objects that they need to manage, etc.

As soon as the reality is more complex than this (many objects, many teams, many departments, complex platform, different technologies etc) you will need to scale. Scaling can be done in many dimensions, depending on where you actually have the increased complexity; and when we do, we must be sure that we keep our focus on maintaining our agility

Agility

First: remember what it is we want to achieve when we use "agile" methods. Remember that the "agile" methods aren't agile at all, but that they help us - if the methods are properly applied - to become more agile in our collaborations. There is this constant need for any organization that develops new software and IT-based services to change direction quickly, since development is all about discovering new things:

Aha, the reference user group didn't understand the proposed user interface! Let's change it! Ooops, we found hidden complexity in the organization's view on what actually constitutes a customer! Integration to System Gizmo is problematic since it shows that Gizmo cannot handle UTF-8 data as it said it could!

The inherent inability to plan ahead development calls for a more flexible way of controlling the value creation in a collaborations focused on developing things, than what project models that rely on extensive planning can do. Hence the rise of the "agile" methods, and a manifesto that says that it is more important to be able to respond to changes, than be able to follow a plan.

Inspect & Adapt

The thing that actually makes us agile, our ability to change quickly in respond to new circumstances, comes from an increased ability for all of us to actually see the current situation as it is; and an increased ability to change accordingly. In agile circles this is called "inspect & adapt", and it is an observation that the frequency of our inspect & adapt-events will determine our agility. Faster feed-back loops means better steering ability.

All the practises that make up the different agile methods (a method is basically a bunch of practises thrown together in a bag), aims at increasing either the ability to inspect, or the ability to adapt, or both. In particular, they aim to increase the transparency of our work (you cannot inspect if things aren't visible), and they want to increase the power (=ability to steer) on all levels by shifting mandate around and make sure the ability to govern follows the right to govern.

This can be seen in such practises like the self-organized team (increased ability to adapt by delegating mandate to the level where the expertise is), a visible backlog showing the status of both all items and their actual prioritization (increased ability to inspect by letting everyone see what is going on and what limited organizational resources we actually compete for).

No matter what practise: it will affect either the ability to inspect or the ability to adapt or both, and you can tell if you applied correctly if this actually had that effect in your collaboration.

Transparency

So when we scale agile, we must understand that it is the ability to inspect and adapt we actually try to scale. And since the ability to adapt actually comes from our ability to inspect (a blind driver is a bad driver) we must understand that the primary focus must be to increase the ability to inspect. In a big organization it is important to increase the transparency even more. Here are some tricks we've used in different organizations:

Use a single backlog! Put all items for all project and all teams in a single backlog. In all lean implementations (and doing agile is a lean implementation) one of the top priorities is to visualize the value-chain; and in a development organization the backlog is the value-chain. I will explain the extended backlog in a later post, since this is a crucial tool.

All teams on the same wall! If you can: put the teams (with images of the team members) on the same wall. Maybe their boards as well, but at least a team presentation poster (of the individuals and of the team's responsibilities) together with the team's goals for this and the coming sprints (or what you call your planning horizons).

Big visible calendar! One tricky part of scaling is the synchronization issue. You see your team mates, but seldom put that in the larger context; or here the drum beat / see the conductor. But actually the whole organization share common goals, and those goals will be realized through specific events. In order to increase the visibility and synchronize between teams: have a common visible calendar with all the releases, all sprint demos, and all other events that are important to them all.

These are just some of the simple tricks that you can use to increase transparency among many teams. There are more to scaling than this and I will cover them in more blog posts, but now it is sunny weather and I need to prepare for my son's birthday reception.