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. After a few drinks, he 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.
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 [1].
LeSS defined by Craig Larman and Bas Vodde. It is also supported by Scrum Alliance [2, 3, 4].
SAFe 5.0 defined by the RUP aficionados and often trashed by Kniberg, Sutherland, Schwaber, Larmann, and Vodde. It is also 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.
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 to your professional teams. Scale once your agile teams are seasoned.
It takes time to learn and master Scrum and Kanban approaches.
Recognize that technical agility constrains the organizational 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.
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 is 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 product only when used by users.
Velocity and burn-down charts are output.
Study the history and evolution of the various scaling approaches. In particular the changes in SAFe are an archaeological treasury what they wrongly stated and how they corrected some identified flaws.
Continuous delivery is the new approach. Eliminate hardening iterations, integration phases, milestones when software should be integrated. Your teams shall deliver workable software on demand, multiple times a week or a day.
Organize around products. Customers buy products. Eliminate product-based organizations. *Have one backlog for the whole product. Multiple backlogs must be otherwise synchronized, and local optimization is de facto applied. This approach is against all lean principles.
Customer and users talk directly with the development team. Product owners, product managers, and 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. Scrums 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 delivering quality products to the customer. Raise the importance of technical excellence and never forget that when writing software, the technology side is really vital.
Establish agile teams. Thin your process. Choose your scaling approach. Try it and measure the 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.
[1] K. Bittner, The Nexus framework for scaling scrum. 2018 [Online]. Available: https://www.amazon.com/dp/0134682661
[2] C. Larman, Scaling lean & agile development. Addison-Wesley, 2008 [Online]. Available: https://www.amazon.com/dp/0321480961
[3] C. Larman, Large-scale scrum. 2017 [Online]. Available: https://www.amazon.com/dp/0321985710
[4] C. Larman, Practices for scaling lean & agile development. Addison-Wesley, 2010 [Online]. Available: https://www.amazon.com/dp/0321636406