First rule of scaling agile - DON'T!


2020-02-07, 14:37 Posted by: Andreas Rowell

What's the first rule of scaling agile?

DON'T!

Yep, that's right. The first rule of scaling agile is… don't do it! Or rather, try to avoid it for as long as you possibly can.

You might have expected a certified SAFe SPC consultant to give a slightly different answer. But let me explain myself.

As you most certainly have noticed, scaling agile seems to be on the agenda pretty much everywhere these days. Agile is no longer an esoteric underground movement, but rather the new industry standard for software development – regardless if you are a small start-up or a big enterprise.

We all have anecdotal evidence that agile methods produce better results than traditional project methods and the statistics tell the same story. According to the 2018 CHAOS report, agile projects enjoy a 60% greater chance of success than non-agile projects. The report also states that waterfall projects are three times more likely to fail than agile projects.

 

Enterprises are going agile

The track record of agile makes big organizations converting to agile methods in large scale (pun intended) and the most popular out-of-the-box scaling method is Scaled Agile Framework (according to 13th State of Agile report).

Image from 13th State of Agile report

 

Small teams kick a**

However, during my decade and a half in the software industry I've experienced that the best results are produced by small, autonomous, cross-functional teams. Put three top-notch full-stack developers together in a room and you can achieve almost anything you'd like. And the stats from the CHAOS report backs me up. Small agile projects have the highest success rate.

But if you are developing a huge system that requires a lot of work, scaling your lean, efficient agile organization might be inevitable. So what to do? Here are my 50 cents...

 

The non-scaling approach

Keep your organization as small as possible and focus on eating the elephant piece by piece. And only eat the really delicious parts of it.

Develop and deliver in small batches. Focus on finding the true MVP by relentless customer research. Get out of the building, understand what your users want to achieve and focus on solving their biggest pain points. Don’t bother to implement the 80% of the features that won’t be used anyway.

Also keep in mind that dependencies are kryptonite for agile teams. Create a system architecture that allows your teams to work as independently as possible.

 

If you must scale up

Organize your staff in several small, cross-functional teams. Create alignment by establishing common vision, goals and architectural guidelines. If needed, synchronize your teams with an agile program plan, like the SAFe Program Board, and run recurring cross-team synch meetings. Design your system and organization to minimize dependencies between teams. And feel free to look at the most popular scaling frameworks for inspiration (e.g. SAFe, DAD, LeSS etc). It does not automatically mean that you have joined the dark side of agile.

And most importantly – remember that you don't have to follow a framework blindly. Do as Spotify, design your own agile development model based on your specific needs. It's all about what works in your context. Experiment and learn!

 

Do you need support on your agile transformation journey? Feel free to reach out to me via the contact block to the right of this blog.

 

More interested in agile teams? Download our white paper: Agile teams - accelerating digitalisation for free here.


comments powered by Disqus

Andreas Rowell

Senior Agile Advisor

Call contact
Email contact