Scaling Agile appears to be a common topic these days. Of course there are good advices and bad advices on how to do that. But how do you know which is which? A few weeks back I came up with the idea of an anti-maturity model. If you have dealt with a few maturity models in the past, these usually run from level 1 to level 5, where level 5 means more mature. My anti-maturity model runs differently, with level 0 indicating that you are probably on the right track, and level MAX_INT that you are probably not doing to well. Why does this scale run differently? As part of my work, I realized there is always someone out there who can come up with an even worse way of doing things than that other guy that I thought was worst.

Level 5 – The Brooks

You realize that the constraint of 3-9 team members is artificial. Since you are a large organization, you need to have adaptations, and that includes team sizes of 100 team members. They already work this way for decades. Changing a working team is going interrupt their productivity. That’s not something you want to put at risk just by going to another methodology.

Level 4 – The Blue-printers

Scaling Agile is easy at this level. All you need to do is to use Scrum since almost everyone uses it. Then you run your Sprints starting with Sprint 1 – Requirements, Sprint 2 is on Architecture. Sprint 3 is on Design, Sprint 4-5 is on Programming, and Sprint 6 is to find the one to blame. Since you waste a lot of your time doing that, you won’t ship any software at all.

Of course, you can run the sprints in parallel, since you will stick with your requirements department, enterprise architects, and designers.

Level 3 – The Conways

Some of your IT teams are using agile. The larger organization though uses proven methods like project plans to adhere to that. Your teams are not cross-functional. Instead, you still have a department in place for all the testing, and you are going to stick with that, since you can’t release the crap the teams build, anyways.

Your architecture in the software maps directly to the organizational structure. You make sure to stick to those structure by introducing additional roles, like a technical counterpart for the business-facing ProductOwner that gives out architecture stories to your teams.

Level 2 – The C3POs

You realize that you have a lot of people involved. The concept of Scrum of Scrums is too limited for you to work. Since you have 42 management levels involved, you should go for a Scrum of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums of Scrums, so that all your important people can serve as a ProductOwner of a ProductOwner of a ProductOwner of a ProductOwner of a ProductOwner, and so on. The technical term for that model is Chief ProductOwner, and your most senior one is afterwards called the CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCPO. You have the same structure in your ScrumMaster organization. The top-most person there is called the Master of Desaster.

Level 1 – The Downstreamers

You have tiny little teams which work together – your database team creates the database first, so that in the second sprint your business domain team can code the business domain, and your UI guys will be dealing with the user interface in sprint 3. Your ProductOwners are self-organizing, and driven by their own project managers. Your product is driven by three customers, and your ProductOwners deal with the necessary re-prioritzation for that – each on their own.

Level 0 – Emergent Scaling

You realize that scaling agile is a complex problem. That means that you need emergent practices, and can’t work from a blue-print or project plan. You realize that you should probe the underlying organization for the changes necessary, and see what happens as you incorporate little experiments while maybe scaling the organization to use Agile all over the place – including accounting, marketing, and sales.

You don’t focus on one agile methodologies or framework, but make local adaptations as necessary to provide the biggest customer benefits all the way through. Your teams deliver business value from end to end, and each of the teams works as their own start-up in the larger organization. Since you have decoupled the whole organization, you don’t need many people while still being able to ship products every second of the day.

Conclusion

If you have read thus far, congratulations. If you find there is still something you want to add, please feel free to do so.

In case you want to outline this model to your management, I also came up with a name, an abbreviation for it: ScAAMM.