A friend: “Sami, you’re crazy !! You’re going to work in a transformation SAFe (c), you the agilist! But you read the article by Ken Schwaber? You saw the picture of the thing?”
Me: “Well yes I know, but as Dave Thomas says : Agile is not what you do, Agile is how you do it .I think we can hijack a tool like SAFe (c) and make it Agile … I’ll give it a try and we’ll see “
No, I will not spit on SAFe (c) as some have done. No, I do not make a block rejection of the proposed approach. Based on a 6-month experience of SAFe (c), I will try to give my analysis.
What is SAFe (c)
SAFe (c) is one of the large scale Agile framework with LeSS, Nexus, DAD, spotify model, etc. The goal of these frameworks is to provide agile frameworks on groups larger than a team (a set of teams, a company, etc.). All of these frames are based on the basic brick “Scrum” with several approaches and different philosophies.
Unlike other Agile Frameworks, SAFe (c) has (strong) ambition to attack the company’s overall organization around Scrum teams. Rightly or wrongly it proposes an approach that allows the whole company to work in a Lean / Agile mode. One of SAFe’s main objectives is the alignment of the company. To this end, it proposes an approach that allows the company to ensure that the teams are working on what counts, from top to bottom, and that there is no dispersion in the efforts provided.
SAFe (c) is also the only one to offer a well-structured and clear approach on how a business should be organized around agile teams. It means that for a non-agile company, the deployment path is clear and precise.
What makes SAFe so successful
A small comparative google trends between the research “LeSS agile” and “SAFe Agile” over the last four years shows the trend of adoption:
SAFe (c) is reassuring (since it is safe):
The creators of SAFe (c) have better identified potential users, their needs and how to sell them the product: Those who make the choice of Agile Frameworks, are not agilists but often sponsors who are not yet agile and who are looking to transform their business.
In an old world not yet Agile, the way to reassure is to provide a well-detailed and well-studied plan (at least in appearance). SAFe provides them with a plan that answers a lot of questions and uncertainties (what happens to my managers, what is the deployment roadmap, how do I measure my success, how do I manage dependencies)? Of course the reality is much more complex, and the more rigid the plan, the more it will fail …
SAFe (c) does not just deal with agility
I’m not even sure that agility is well taken into account. From my point of view, SAFe is above all a framework of alignment and predictability. It allows the company to work on the same objectives, with the same vision. This is done via the different layers offered, with their different backlogs. These different layers are essentially linked thanks to the elements of their respective backlogs (Epic, Feature, US).
SAFe also allows for better predictability at the development level. The teams make a big planning together every two months, engage on it. At the end of this iteration we measure the production of the teams and we calculate their predictability. This predictability helps to create more trust and honesty about commitments in the business.
Alignment and predictability … but at what price?
The risks of a SAFe deployment?
- By deploying SAFe (c) we miss a strong recommendation for an Agile company:
- Build as much as possible independent teams that can manage their product area, develop and deliver independently. The initial rule is that the people doing the work are those who know the best how to do it. What SAFe misses is that the PO is also the one who knows the best his part and that needs autonomy in the way he manages his scope.
- Go for a flat company, with a simplification of the structure to have a better collaboration and lighten the weight of the hierarchy. This allows among other to release the initiative and the autonomy of the teams.
- The SAFe (c) approach to innovation is very light. To claim that two weeks of “Innovation and Planning iteration” are sufficient is just wrong. By practice it’s just a buffer to finish what has already been planned and unfinished during the sprints. SAFe(c) misses the point where Innovation is rather a company culture and a continuous process that is reflected in the overall operation of the company.
- An alignment around the strategic intentions that are declined in Epics, Capabilities and Features. The only thing left for the Scrum team is to execute what “falls” in the train’s backlog. We are far from the Product owner who is close to his customers, who knows his product and who adapts his backlog to always be in tune with customer expectations. This cross-company approach means that teams move away from the context and cause a considerable loss of information between the original intent and the final execution. The risk is limited thanks to the demos and reviews, but it is there.
- Too many artifacts! SAFe tries to solve all the problems at the same time. By deploying SAFe one is tempted to take it all without worrying about the initial purpose of the company. And this results in many artifacts that can be useless and harmful. These “useless” artifacts can result in poor return on investment and disengagement from your teams when they do not see the value of what they are doing.
What do I retain from SAFe (c)?
Some aspects of the PI planning:
- Alignment with the company’s vision, the roadmap to achieve business objectives. That managers take the time and make the effort to structure their vision and share it with everyone is great! It gives a lot more visibility to the contextualization of what the teams do and it gives meaning to what people do, a very strong element for the motivation of the troops.
- The collaboration of the whole train structure (BO, PM, architects, teams) around the construction of a plan for the next two months with a common commitment on the objectives to be achieved and very rich discussions.
- The identification of dependencies between teams and with the outside world. Risk identification and sharing with the entire train. This is a very good sharing of responsibilities and allows managers to find concrete elements to support and help teams.
It is interesting to have once every two months a “big demo” with a large audience and in which we show what has been done on the last iterations. I tried in the past to invite people to sprint demos, but the frequency too high multiplied by the number of teams makes it quickly becomes too complex to manage. The idea here is to demonstrate, the result of the work of all teams in collaboration. This ceremony reinforces the idea that we work for common goals in collaboration.
The lean vision of the company
with among others the prioritization and limitation of WIP at the Program level. The construction of this prioritized backlog forces managers to have a global alignment and resolve conflicts of interest upstream. The limitation of WIP allows teams to have a strong focus and avoid the paper jam effect.
Personally, I had a lot of trouble with SAFe (c). I was expecting to work with self-organizing teams who are co-constructing a better way of doing things, and I ended up with a rather heavy framework and limiting in terms of autonomy. The company culture has not helped either, because above SAFe (c) the company has added its layer of mandatory “recommendations” with quotas for maintenance, metrics to use, a corporate DoD hard to reach etc. . It took me a long time to understand that the company is looking for more alignment and continuous delivery than true agility in the sense of the “Agile Manifesto”.
And you, have you tried SAFe ? What is your opinion ? Have you tried it ?