Scaling Agile: Conclusion

This is the concluding article of our series on scaling Agile. In the previous articles we discussed the popular Agile scaling frameworks Nexus, DAD, LeSS, SAFe and Scrum at Scale. They all have many good ideas and parts that I like. Some are very prescriptive like SAFe, and others are the complete opposite, like DAD.

Personally, I am the opinion that the best strategy for scaling Agile is very depending on context like:

- How important is speed of delivery?
- How important is innovation?
- How important is team empowerment?
- Where are teams located?
- How agile is the organization already?
- How complex and/or tightly integrated is the product?
- What is the driving timeframe for becoming agile?
- How severe are the repercussions of a product defect?

We should recognize the importance of being agnostic with agility at any level. This means one size does not fit all, one framework is not the answer, and the 'what' and 'how' should be suited to client context and to a wider strategic vision.

Currently, the only scaling approach that really supports this kind of thinking is Scrum at Scale from Jeff Sutherland. His modular approach forces you to think about the different aspects of scaling Agile, and helps you create your own scaling strategy that suits you best.

Based on my experiences with scaling Agile at different companies and in wildly different contexts I am the opinion that the following guiding rules serve me well.

1. Do not scale, in most cases it is not necessary. Create well-defined product boundaries with interfaces and most scaling efforts are futile.

2. Do not multi-site. It makes simple things complex, and hard things even harder.

3. You cannot scale what you do not have, i.e. when you have no well-functioning Scrum teams in your organization you should not talk about scaling Scrum.

4. Think products, not projects. This shift in thinking will help organizations a lot in making better decisions.

5. Continuous improvement. Never stop learning, and do not be afraid to stop what is not working.

6. Technical excellence is important for agile teams, but for scaling it is essential.

7. Take a modular approach, there is no one size fits all framework.

8. You need top-down support, i.e. management wants to change their own way of working too.

9. Change the system, then culture and people's behavior will follow.

10. Tackle one product(group) at a time.

11. Feature teams, not component teams.

12. Empower your Product Owner (or similar role) to take the decisions he/she needs to be taking in that role.

13. Building is the easy part. You should think about operating your products as well. DevOps is the way to go.

Saturday, June 17, 2017

Scaling Agile: Conclusion

Other articles in this series: