… and I liked it. We had a skilled trainer (Michael Stump) and also very good discussions among the participants who all had excellent knowledge about agility.
I’m involved in an agile transition of a large health care insurance company. We have invented the processes on program- and portfolio-level on our own. I think this is still a good idea; the involved people developed a good understanding of agility while organizing themselves. And it is now their process, created by them, understood in-depth, improved from that understanding, and defended when necessary.
But during the Scaled Agile Framework (SAFe) training I learned many new, good ideas how to improve: Program Increment (PI) instead of just Sprint Planning, System Demos instead of each team having their own Sprint Review, feedback on PI Objectives are a very smart idea, trying out large Retrospectives at a PI end, etc.
After the training, I will not stop encouraging people to design their working environments on their own. But with SAFe, I have terms, smart solutions, and a direction towards which I can coach them.
SAFe has a big potential. Scrum is common sense in Software development and successfully applied in Software shops and small to midsize companies. But the transition for large enterprises to Scrum is very difficult: Scrum misses the program- and portfolio-level. SAFe fills that gap and provides a blueprint how to organize large enterprises. SAFe has the potential to become common sense for large enterprises as Scrum already is for small to midsize Software shops.
Management likes SAFe:
- On the big picture of SAFe (http://scaledagileframework.com), middle management and supporting functions find themselves again which is not the case for Scrum.
- The big picture shows a hierarchy that reflects the current hierarchy of the company. Applying SAFe properly requires organizational and cultural changes in the extent as when applying Scrum. However, the big picture does not show this.
- Selecting SAFe as name shows the marketing potential of Dean Leffingwell: “Hey, we need to change, let’s use the SAFe-Method”.
Software Developers do not like SAFe to the same extent:
Seasoned Scrum coaches criticizes SAFe:
- Software developers are banned to the lower left corner on the big picture. They feel again the same small cog, they have been before.
- Management and supporting functions are found in masses; the same that have been in the way of the developers in the old organization and will (on the first sight) do it again.
- In every training, experienced Scrum coaches ask critical questions about the deviation from the Scrum Guide. In my training, we stopped this on the first day since it does not lead to anywhere in a training.
I have some suggestions to improve the acceptance of SAFe:
- SAFe defines a lot of roles, does not describe all of them well and opens room for (mis-)interpretation. I would not only reduce the roles, but also distinguish between contributing and supporting roles. Maybe, you remember the old chicken/pig analogy. Contributing roles are product management, portfolio management, release train engineer, and Scrum Team (Product Owner, Development Team, and Scrum Master). All other roles are in my view supporting and should be e.g. reduced in size on the big picture. This would help to emphasize that the people prioritizing and developing are central.
- The big picture shows a hierarchy with the portfolio management on top and teams on the bottom. Kenneth S. Rubin has rotated that picture by 90° in his book Essential Scrum: Portfolio, program, and team levels as columns, central roles and workflow on top, supporting roles on the bottom. I can understand that it is too late for realignment and it furthermore would not attract management to the same extent. And the main purpose of the big picture is to be attractive to management.
- SAFe teaches an old version of Scrum from about 2010. Since then, the Scrum Guide has seen three revisions and is currently merged by Scrum.org and Scrum Alliance. It would be good, if Scaled Agile would contribute their experience and align their message of Scrum to the Scrum Guide too. Some important differences (not complete):
- The Development Teams still commit to the entire Sprint backlog in SAFe. The Scrum Guide proposes commitment on the Sprint goal only due to good reasons.
- SAFe uses demos, the Scrum Guide Sprint Review. “Demo” implies more information flowing from the developers to the stakeholders, but in effective Sprint Reviews, it is the other way round: The feedback from the stakeholders is important.
- A backlog is not prioritized, but ordered. Prioritization is done using three levels, leaving some items on the same level. Ordering defines a clear ranking.
Scrum.org, Scrum Alliance, Scaled Agile, and other agile organizations are in direct competition. Such a competitive environment is welcome and keeps the people moving and thinking. However, these organizations should not stop talking with each other and should not talk badly about each other. We should not forget that there is a strong enemy: managers that do not know agile, do not believe in agility, have no or a wrong idea about the values behind agility and therefore use command and control in their companies. We all should stand united against this enemy and should improve agility so that finding arguments against agility get more and more difficult.
Want to learn more about the Scaled Agile Framework? Zühlke Academy offers the following SAFe trainings: