What is your favorite agile scaling model?
Well, I wouldn’t say that we have a favorite agile scaling model. You know, there are a lot of scaling models that are out there. There’s one that is called “Vertical Slicing,” there’s one that is called “LeSS,” there’s one that is called “SAFe,” there’s one that’s called “Scrum at Scale,” there’s one that’s called “Nexus,” — there’s a lot that’s out there. The industry has sort of moved to this scaling movement as we’ve gone into enterprise organizations.
We don’t particularly have a favorite. We’ve used all of them–all of them have things that we like, all of them also have things that we don’t like. One thing to keep in mind though, is the absolute best way for an organization to scale, is to NOT. When an organization brings us in and says, “Hey Mark, we want you to help us scale our projects,” the first thing we say is, “What are the dependencies that you have between your teams that we can break, so that you don’t have to scale?”
Scaling is never more efficient–scaling is always going to be less efficient, and it’s also fundamentally somewhat anti-agile. When you think about agile as a concept, agile as a concept is: you take very large initiatives and you break them down into small digestible chunks that people can execute against. Scaling is: you take a lot of small modules and you integrate them into a large enterprise type of system. And so, at its core it’s somewhat anti-agile.
Having said that there are a few things that we’re looking for:
1. Is this a scaling model that is empowering the people who are actually doing the work itself (the development teams)?
2. Is it allowing for a feedback loop that allows these teams to inspect and adapt?
3. Is it somewhat self-correcting?
If you’re meeting those models, we’re more likely to be comfortable with them. Is there a favorite scaling model? The answer is no, other than my favorite scaling model is to break the dependencies so that we don’t have to scale.