A theme of scaling Agile, or Lean for that matter, is all hot these days. You will hear it all sorts of contexts: as broad as Agile and as specific as one of the methods we use. No wonder. It sells.
You can tell that looking at tracks at Agile or Lean conferences. You can tell that looking at a rise of approaches that specifically aim at the big scale as their main target (SAFe, anyone?)
The interesting part of the whole dispute is how rarely we question scaling up strategy. I mean it seems to be some sort of unquestionable paradigm and when you decide to go against that everyone looks at you as you were an alien. I sometimes feel like rolling out a huge program to introduce Agile or Lean in the whole organization was the only thing there was for big companies.
How does it work for us so far? Not so well. We don’t have lots of success stories and those few that are available seem to be share at pretty much every Agile or Lean event there is. This tells a story about our success rates with scaling agile too.
Unscaling strategies are almost never mentioned in the dispute. It is so despite the fact that we actually know at least a couple of different approaches we can use there.
One is skunk works. The basic idea is to create a group within a company that operates pretty independently on the rest of the organization. This creates an opportunity to try out a lot of stuff that would be hard to implement in a broader context. At the same it creates an environment of much smaller scale.
Applying Lean Startup within a big organization goes along the same lines. On the top of a product development strategy we create a context of work that is autonomous and that operates in small scale.
Quite a different approach is when an organization decides to find a partner to outsource some of their work to. With such a situation one thing that is easily done is scaling the context down. A difficult part is to find a partner that would live be the right values and employ the right practices. But then again, it may be used as a viable unscaling strategy too.
Interestingly enough, such approaches are rare. One exception may be outsourcing. However, outsourcing done in a common way has nothing to do with scaling down and very frequently criteria used to choose an outsourcing partner only make the whole situation worse. Believe me, I’m actually in this business on a receiving end so I’ve heard all the motivations for sending the work near-shore or off-shore.
If you wonder why unscaling is so unpopular you aren’t going to be surprised with the answers. Either of these scenarios means losing control and that is something that management is generally allergic to. Also to make it work you need trust as high autonomy is one of key parts of the setup. Finally, there’s a risk of doing something not exactly in a standardized way which may produce unpredictable outcomes.
Have I just said between the lines that one of the main drivers of scaling up Agile and Lean is complacency? Oh well…
Anyway, unscaling strategy not only makes it much easier to adopt Lean or Agile but at the same time it enables fresh ideas as many constraints are typically relieved. Not to mention that it goes along the lines of autonomy, mastery and purpose which drives individual motivation.
So the next time you hear about scaling Agile why not consider unscaling it?
Subscribe RSS feed
Follow on Twitter
Subscribe by email
9 comments… add one
Could you define “unscaling”?
@Peter – Pretty much any scenario that creates a smaller, independent context. Whenever we are talking about scaling up Agile we almost never are in the context of one huge product that everyone works on. And yet we expect unified process for everyone.
The idea of unscaling is built in opposition to this scenario. It assumes that more often than not scaling up is neither needed nor helpful and some organizational changes can create context where scaling up scenario isn’t even relevant.
Hi Pawel – your points for unscaling sound similar to what we hear from the scrum / large scale scrum camp which basically says the way to scale is to use decoupled units – or in amazon terms two pizza teams.
That makes a lot of sense if your architecture allows it. In many cases though it is not where the organization is. Telling it to fix the architecture in order to achieve scale is nice but not a very evolutionary/practical approach in most cases…
SAFe is one way to deal with the difficulty/complexity temporarily. I relate to the concerns that it doesn’t make the fact it is a temporary kludgy fix to the coupling/dependencies clear enough – kind of creating the beast that lives upon the complexity. It will be hard to expect a release train engineer to be the one inspired to decouple the train and drive towards smaller mini delivery pipelines.
Kanban service oriented delivery is another way to deal with the dependencies temporarily. Seeing dependencies delay flow will create a force for streamlining and decoupling but I’m not sure whether that force will be strong enough.
I think a change management “architectural runway” activity looking at bigger issues that need to be dealt with in order to enable a big change towards an unscaled organization might be required.
@Yuval – I’ve never mentioned two-pizza team, and on purpose. If you look at origins of skunk works they are doing huge things, like multi-role fighters. At the same time this still creates a context that is way smaller than the whole organization.
Over the years in software business I’ve repeatedly had one sad observation. The huge part of dependencies are not hidden. In fact they were put there on purpose and are consciously being cultivated. Typically, before we hit the first surprising dependencies we are so far into untangling process that it doesn’t take much of work to get rid out of these either.
The problem that we first need to address is a cultural one. Either unscaling scenario, no matter whether we mention a two-pizza team or Boeing skunk works, requires trust. This is something organizations are short of.
Obviously we can discuss how different methods help to facilitate building trust. Bits like transparency or predictability are definitely helpful. At the same time, and I agree here with you, they’re rarely helpful enough to trigger reconsidering the organization’s architecture.
This brings us back to the point where the only viable scenario seems to be scaling up. Well, it’s most definitely not the only viable scenario and that’s my point. In fact, as you point, these scenarios feed on complexity often resulting in petrifying the existing structures.
Interestingly enough you can easily scale alternative approaches so you have risks under control. No one expects to have the whole company turned into hundreds of Lean Startups. You can with one small team and keep your options open.
The big change that is needed, and this is where we differ, is in my opinion leap of faith that management has to take to launch such experiments.
@Pawel – we agree regarding the leap of faith that managements needs to take.
I’m just saying that leap of faith will not reap results immediately – which is why I mentioned architectural runway.
Let’s discuss further when we meet…
@Yuval – Looking forward to this discussion.
PS. I didn’t want to leave an impression that results are instant. I have to learn to be more explicit.
The problem of scaling usually comes up in established organizations, which have been building & maintaining applications over years, and now want to apply Agile methodologies to their processes.
As we know from Conway’s law, system architectures are constrained to mimic communication structures of organizations that produce them. Often organizations, that grew organically and followed some sort of waterfall development model, have a monolithic code base, that cannot be discarded without affecting business. These organizations have a lot of dependencies between teams, and developing new features requires good synchronization.
“Unscaling” for these organizations is certainly the simple, reasonable way to go, but it’s far from easy. It requires gradually changing the architecture of these monolithic systems into separate modules with well-defined interfaces. Then and only then can their teams effectively work in small scale environments.
Because changing the architectures is costly and time consuming, should these organizations delay adopting Agile methodologies?
@Michal – There two bit I’d discuss. One is that I think you seem to assume that the style of working on projects or with code base are the source of how interactions in these organizations work. I’d say that the dependency is the opposite direction.
The other bit I’d discuss is that you point reorganizing existing hierarchies as the main challenge of unscaling. In my experience, once there’s decision to do that, the existing structure is rarely any sort of a challenge. The big issue happens earlier–when there’s a decision to be made. The decision that relieves a number of command and control mechanisms and thus scares the crap out of the top managers across the companies.
Now, the question you ask at the end, whether such organizations should delay adopting Agile is I believe one that has already been answered. If they didn’t want to go with the adoption we wouldn’t be discussing Agile at scale every other day in this or that context.
In fact, changes that need to happen to go that path are valuable even if go beyond Agile or Lean context. At least as long as we discuss trust, autonomy or mastery.
This post reminds me of the debates that followed #ALE13 conference, as many models were presented, people started to ask what is a correct model definition. Among the ideas that emerged, that of testing a model with scale-up and scale-down was one that I agree with.
I think that it is good for the environment, to first think about how things will scale-up and down, and to consider this, because not always the shortest path to an exit is forward. (see the airplane, where the nearest exit might be right behind you..).