Common Sense Agile Scaling (Part 1: Intro)

26 Mar, 2016

Agile is all about running experiments and see what works for you. Inspect and adapt. Grow. This also applies to scaling your agile organization. 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”.

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.
Your company culture highly influences your scaling effort since for example it defines if you introduce structure to cling to or a vision to self-organize towards. Michael Sahota wrote an excellent minibook on this.
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 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 and 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.
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:

Before ScalingAfter Scaling
Component TeamSystem of Component Teams
SprintRelease Timebox (sequence of sprints)
Sprint PlanningRelease Planning
Sprint ReviewRelease Review
Sprint RetrospectiveRelease Retrospective
Daily StandupScrum of Scrums
Focus on team output and utilizationFocus on cocreating valuable outcome
Functional SilosIntegrated disciplines
Long analysis phaseRelease Refinement
Long testing phaseIntegrated testing

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!

Explore related posts