Feb 05

Scaling Agile, steep mountains have slippery slopes

7699228408_e7805285c5_kA lot of IT companies are trying to work with Agile. And most of them are having some sort of success. But the bigger the company the more difficult it gets. Getting Scrum to work with development teams works in most cases but surrounding management and connecting departments have a hard time to adapt.

To accommodate this we see a new trend. Scaling. Scaling Agile to help larger companies to make the change and gain the benefits of agile frameworks like Scrum or Kanban. But this comes with a price and to my believe might in most cases not even work. When a company starts to work with Agile, often Scrum, a change is set in motion. Communication and interaction start to work differently and the focus moves from budget driven to value driven. As I said, most often the development teams can work with Scrum but the interaction between these teams and the rest of the company becomes blurry. So systems like SAFe, LeSS, Scaling Agile, Blowing up Scrum or whatever the name, are brought in. Sometime because someone read an article or a coach is challenged to come up with something that fills in the blanks. I have heard from companies who start directly with these larger systems without even trying to get the basics like Scrum to work.

Why doesn’t it work? Keep in mind that the idea of scaling comes from the fact that there is a feeling that Scrum does not accommodate the larger picture.  Scrum doesn’t say anything about architecture or design. It doesn’t say anything about DevOps. So smart people start to invent large scale scrum solution that accommodate the bigger picture, but in doing so they forget two very important things. The first one is that the Agile mindset is about people and bringing value. Frameworks like Scrum are designed to help people to communicate and work on value. And they are horizontally throughout the company. They feed on what customers want. Traditional process management on the other hand is budget driven and feeds management and sometimes shareholders. You can read about this in an article from Forbes. Large scale Agile systems are to keep this vertical system in place and in most cases go against everything that Agile stands for. The idea of using Scrum is so everything becomes visible. The good things but also the bad and painful stuff. Agile as an mindset can then help to make the change.

The second thing is that often examples from other companies are used for these Scale Scrum Systems. Spotify is a good example. At Spotify they started small and with Scrum. When they became larger, they adapted Scrum so it worked in their larger system. They started to use Tribes and Chapters. And it is very cool, but keep in mind that this is something that Spotify worked out by themselves. They knew the potential of Agile and got it to work and designed their own Spotify system. This does not guarantee that this will work for other companies. What is good for one might hurt another. So when a company works with Scrum and finds that is does not completely work throughout the entire system. A click and play scaling Scrum system will not work. Each company will have to start working on their own Scaling. Every company has it’s own unique DNA and even though they all might develop software, the people doing this have a unique mind. You cannot upload a system into that mind and hope everything will scale. You have to build it from the inside out and using the companies own building blocks.

We often say that frameworks like Scrum are easy to understand but are very hard to get to work. There is no plug and play solution. We often try to adapt systems or frameworks to the needs of the company. Most companies have grown so large that it is nearly impossible to control. So we try to fit something over the mountain. But when are companies going to learn that maybe they have grown too big and made thing to complex. Maybe it is not about Scaling up. Maybe it is better to start sizing down. To go back to the basics and look at what is really needed and what will bring value.  I know of companies who work with around 250 developers and 5000 surrounding managers and supporting functions. What went wrong there? Together they try to control a large software landscape where most of the functionality isn’t even used anymore. But nobody dares to touch it, change it or throw it away.

So the question is not if you need to scale? The question is if you can reduce. And if this is somehow not an option, don’t just pick a ready to install Agile Scaling system, because they don’t work like that, but start to change from within the DNA of the company. Use Scrum as the tool to make the path visible and apply Agile as you navigation. That’s the way to scale the mountain. And I can provide a lot of metaphors hear about slippery and danger. But I think you can figure it out by yourself. So don’t just use an “instant” scaling system but device your own.

Permanent link to this article: http://agilethings.nl/scaling-agile-steep-mountains-slippery-slopes/