Adopting Agile in Large Organisations

Enterprises that I’ve interacted and read about often tackle Agile Transformations in the same way — they build small teams, assign them responsibilities over a part of the technical system, and then tell them to get things done. They’ve latched on to the notion that Agile teams are meant to be small.

Unfortunately, the crucial part of agile teams isn’t size, it’s cross-functionality. Everybody that needs to be involved in moving something from being a customer’s idea to being in a customer’s hand all need to be in the same team. Dependency meetings across team boundaries are inadequate.

What this means is that your first agile teams, if they have to cope with existing architectural systems, will be too large to be truly agile. However, they’ll be able to get things done, and they will be able to work on improving how their work gets done.

This new, too-big-team, has 3 responsibilities:
1. Deliver things that satisfy people’s needs
2. Share skills and knowledge so the team can shrink to a more reasonable size. The people who are no longer needed can be used to seed a new team, eventually spreading agile thinking through the entire organisation.
3. Make the technical systems simpler, so less expertise is required in order for a team to be functional.

Don’t start with small teams and expect to become an agile shop. Your architecture and organisational habits just aren’t there, yet.

(NB: I’m not suggesting you do a reorg around very large teams. Make it informal. You’re going to get it wrong the first few times, so the less stress you create, and money you sink into it, the less you’ll feel like it has to succeed at all costs. Whichever people you need, to ensure a full, end-to-end, capability, should be begged, borrowed, stolen, or hired. A reorg can wait until you’ve got it figured out.)