Common Sense Agile Scaling

Agile is inspect & adapt

Agile is all about running experiments and seeing what works for you. Inspect and adapt. Grow. Consequently, this applies to scaling your agile organization. Certainly there is no out-of-the-box scaling framework that will fit your organization perfectly and instantly. Experiment, and combine what you need from as many agile models and frameworks as you can to do “Common Sense Scaling”.

What drives your agile scaling?

You might want to compare scaling frameworks like SAFe, LeSS, Nexus and the “Spotify Model” and choose one for your scaled agile implementation. This will yield suboptimal results because you are focusing on the solution rather than focusing on your business goals and the business results that you want to achieve. They should be the drivers for you going agile and scaling up.

Combine scaling frameworks that fit your need

Your company culture highly influences your scaling effort. For example, it defines if you introduce structure to cling to or a vision to self-organize towards. Michael Sahota wrote an excellent mini-book about agile adoption transformation . In his recent blog post Paul Takken wrote to “just use as many agile models and frameworks you can get your hands on”. This is exactly what I have been doing. Inspired by Serge Beaumont’s saying “Scrum is Recursive”, I used what I call “Common Sense Scaling” to do a scaled Scrum implementation for a large enterprise I have been consulting. Both scrum (minimal process, structure) and the agile manifesto and its underlying principles (culture, mindset) provide a solid base. So, these are powerful enough to set the stage for any agile scaling effort at any organization. Frameworks like those mentioned above will help since they allow you to combine framework elements that fit your need.

lllustration how scaling is put into practice and what results yielded

In a series of 3 blog posts I will share with you my experiences in transforming the enterprise into an organization that works more focused, more together. As a result time to market has decreased and productivity has increased (being the company’s most important business drivers at the moment). This transformation has been about optimizing a Waterscrum release process using scaling principles. From 26-week overlapping release periods in which the system development department tried to scrum away the pile of backlog items generated by the business consultants, followed by weeks of testing by the testing department (fig. A), to a network of collaborating teams and individuals that refine and deliver work together in 8-week release periods (fig. B).

Figure A: Waterscrum releases

Figure B: Scaled scrum Releases

I will address the following scaling moves:

My next post will be about scaling refinement. Making work ready just in time. In the mean time I would love to hear from your common sense scaling experiences!

Would you like to train yourself in playing a part in scaling Agile?

Look at the agile scaling trainings we offer