First rule of scaling agile - DON'T!

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 2015 CHAOS report, agile projects have an average success rate that is almost 4 times higher than traditional waterfall projects. Pretty impressive numbers, aight!?

Enterprises are becoming 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 10th State of Agile report). The figure below shows the Google trend for "Scaled Agile Framework" – a steady increase over the last 5 years.

 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 3 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 - 58%. Compared to 3% for large waterfall projects…

But if you are developing a huge system that requires a lot of work, scaling your small, 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.

If you must scale up

Organize your staff in several small, cross-functional teams. Create alignment by establishing common vision, goals and architectural guidelines. Synchronize your teams with an agile program plan, like the SAFe Program Board, and run recurring Scrum-of Scrum meetings. Design your system and organization to minimize dependencies between the teams. And look at the most popular scaling frameworks for inspiration (e.g. SAFe, LeSS and DAD).

And remember, you don't have to follow a framework blindly. It's all about what works in your context. Experiment and learn!

Peace!