Agile@Scale - Are Common Patterns Emerging?

Your organization has decided to introduce agile at scale in all development departments or better in the whole company.

Your Chief of Agility COA, Chief of Digitalization COD or Chief of Change COC was in an expensive training and has selected the appropriate framework for your company.

Welcome to the club of companies introducing agile approaches and having no clues why they do it and how they could be successful.

Here some hardly learnt truths worth knowing when starting such an endeavor.

Imposing Agile methods introduces a conflict with the values and principles that underlie Agile methods -- Martin Fowler

Know Popular Scaling Approaches

The scaling approaches I encounter at customer sites in Switzerland and Europe are

• Spotify Model was popularized by Henrik Kniberg. His YouTube videos are worth watching. The banking group ING adopted the approach and made it fashionable.
• Scrum@Scale defined by Jeff Sutherland and Scrum Alliance. Henrik Kniberg has written an interesting article stating Spotify Model is a kind of Scrum@Scale. 
• Nexus defined by Ken Schwaber and Scrum.org.
• LeSS defined by Craig Larman and Bas Vodde. It is also supported by Scrum Alliance.
• SAFe 5.0 defined by the RUP aficionados and often trashed by Kniberg, Sutherland, Schwaber, Larmann and Vodde. At the same it is the most popular approach in quite a few countries.
  And I would never state it is the most successful.

Additional approaches exist but I did not encounter them lately.

Delay Scaling

The key learning is

Delay your Scaling.  First Lean the ropes.  Try to descale your processes.

Learn the ropes with small agile teams applying Scrum, Kanban, eXtreme Programming or our own approach. Learn as much as you can through experiments before considering scaling. The invested capital in small experiments with small teams is tremendously cheaper than experimenting with company-wide approaches.

Be gentle and kind with your professional teams. Scale once your agile teams are seasoned.

It takes time to learn and master Scrum and Kanban approaches. 

Recognize that organizational agility is constrained by technical agility. Focus the first years on technical excellence, software craftsmanship and clean development.

All the above mentioned methods emphasize the importance of technical excellence for durable success.

Simplify your processes, roles and structures. Reflect if you really need scaling.

Now you are ready to experiment with scaling.

Understand the Principles of Scaling

• Create a learning organization. It is the building block for agile approaches
• Train your collaborators,
• Experiment with new approaches and measure success,
• Organize around up to eight teams, one backlog for one product
• Avoid team backlogs,
• Have one product owner in charge of the whole product,
• Pull, do not push
• Collaborators and teams select workload,
• All information are available to all collaborators,
• DevOps is king
• Automate aggressively,
• Put all artifacts under version control,
• Focus on outcomes and impact, not on outputs
• Customer features are outcome only when used by users,
• Velocity and burn-down charts are output.

Avoid Common Errors

Study the history and evolution of the various scaling approaches. In particular the changes in SAFe are an archeological treasury what they wrongly stated and how they corrected some of the identified flaws.

• Continuous delivery is the new approach. Eliminate hardening iterations, integration phases, milestones when software should be integrated. Your teams shall deliver a workable software on demand, multiple times a week or a day.
• Organize around products. Customers buy products. Eliminate project based organizations.
• Have one backlog for the whole product. Otherwise multiple backlogs must be synchronized and local optimization is de facto applied. This approach is against all lean principles.
• Customer and users talks directly with the development team. Product owners, product managers enterprise architects should never be filtering the information flow between customers and engineers.
• Eliminate step by step all coordination roles. Emphasize communication between developers in the team and between teams. Scrum of Scrums where only Scrum masters attend, Release Train Engineer, System teams, corporate Solution Engineers are just a waste of resources.
• Realize technical excellence is the only approach to deliver quality product to the customer.
  Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital.

Final Words

Establish agile teams. Thin your process. Chose your scaling approach. Try it and measure impact. Iterate and improve continuously. Therefore it could be necessary to change your initial scaling approach and adapt it to your company needs.

I wish you successful scaling of agile approaches. And I have to warn you the path to success is long and risky. Personally I had some successes with Large Scale Scrum - LeSS.