Saturday, June 17, 2017

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 creating 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.

Other articles in this series:

1. Scaling Agile: Nexus Framework
2. Scaling Agile: DAD 
3. Scaling Agile: LeSS
4. Scaling Agile: SAFe
5. Scaling Agile: Scrum at Scale
6. Scaling Agile: Conclusion

Workshop Scaling Agile in an Enterprise Environment

When you want to learn more about the different scaling approaches then join our Scaling Agile in an Enterprise Environment workshop. In this intensive one-day workshop you will pursue three goals:

1. Create an understanding of the common challenges with scaling scrum and formulating your company-specific challenges.

2. Create a basic understanding of the four popular Agile scaling frameworks Nexus, DAD, SAFe, LeSS and Scrum at Scale. We will discuss their common grounds, their differences and how they want to tackle scaling challenges.

3. Create a toolset to help you make the right decisions for your organization by breaking down the scaling challenge into building blocks and asking yourself some important questions regarding the context in which you want to use Scrum.

There is no one-size-fits-all solution so you will have to create one yourself. That is what being Agile is all about!
Posted on Saturday, June 17, 2017 by Henrico Dolfing