Agile@Scale

How can a supertanker (read large enterprise) be as fast and flexible as small motorboats?

Unfortunately it can’t.

Being agile at scale is hard. And most companies are trying to do it the wrong way.

The right way is:

  • Use small motorboats and give them freedom to deliver to customers whenever this is possible
  • Improve navigation, steering, speed and everything else that is needed on the supertanker when small motorboats aren’t feasible
  • Aim to make small motorboats a feasible options in more scenarios over time

What this means in practice is that whenever possible you should allow small teams to deliver value to customers in a very agile way. If you don’t NEED to do agile at scale why should you? This might require changes in mindset, corporate controls and sometimes even in leadership, but it is clearly better than imposing a scaled approach when it is not necessary.

So what are most companies doing wrong? Here are a couple of common mistakes:

  • Imposing a scaled approach top down
  • Forcing all teams to use the imposed approach
  • Focus on consistency and control rather than agility and value to customer

When introducing agile@scale we should think really hard on why we need to scale it and if we can avoid it.

The only proper reason that I am familiar with for doing agile@scale is to handle dependencies. The most common dependencies are:

  • Technical dependencies (teams are dependent on solutions that are being managed by other teams)
  • Business dependencies (the solution that has been sold to customer involves several solutions managed by different teams)
  • User experience dependencies (the solution used by Users involve user interfaces that are managed by different teams)

If a team doesn’t have any large dependencies (small dependencies can often be handled ad-hoc) why should you use a scaled approach? A scaled approach will by nature make the team slower, less responsive to customer needs and less fun to work in.

If teams have dependencies, but dependencies can be removed by reorganizing, then this is often the best choice.

If teams have dependencies and they can’t for some reason be removed right now – think about what needs to happen so they can be removed or reduced later on and start working towards that.

If you only have a handful of teams that need to coordinate their efforts, most of the time informal coordination of backlog items together with Scrum-of-Scrums are fully sufficient in my experience.

If you have more teams – let’s say more than 6, you might need more mechanisms to coordinate. Then SAFe can be an interesting framework to look at for inspiration.

If you are looking to implement SAFe, here are some key ideas:

  • Start with as little as possible, too much change will overwhelm the organization
  • Only use things that improve your current ways of working, based on your current needs. Implementing the entire SAFe framework would be totally crazy in most contexts.
  • Allow teams to work outside of SAFe framework if they don’t have strong dependencies to other teams (small motorboats)
  • Make Release Trains as small as possible – the goal is one team. It can in my experience be MUCH better to have two Release Trains with some dependencies than one huge release train that is not homogeneous (planning will be much harder, follow-up much harder, motivation lower, continuous improvements borderline impossible).