This is my second article in the SAFe series.
For the first article “When should you consider Implementing SAFe (Scaled Agile Framework)?” — please go here — https://medium.com/@cinemaparadiso/when-should-you-consider-implementing-safe-scaled-agile-framework-d269e8323295
1. Purpose
The purpose aim of this article is to explore the Pros and Cons (or Advantages and Dis-advantages) of SAFe as I see them. It is not intended to compare SAFe with other frameworks but reference to Agile Manifesto and Principles will be made.
2. Pros
2.1 Combines different Agile thought processes in one place
Dean Leffingwell as a person and SAFe as a Framework have put in a lot of effort to combine various Lean and Agile thought processes and tried to amalgamate the best ideas into one place — the SAFe Framework — viz. Agile, Lean, Portfolio Management, (DevOps) and Systems Thinking. SAFe also brings in some of the well-known and proven techniques like TDD, BDD etc. as well.
2.2 Dependency Management
Many teams which are pretty Agile struggle with dependency and risk management as there is no inherent way of resolving them in a regular Agile framework. Some would argue that teams should be as independent as possible and should be able to manage risk within a timebox.
In large organisations with multiple teams and vendors spread across locations, this is far from reality. SAFe has an excellent way of ensuring the teams recognise the dependencies (during PI Planning), discuss and negotiate them, visualise them and plan for them. On an ongoing basis, the teams discuss this through Scrum of Scrums too. The Program Board in SAFe is an excellent way to show the dependencies between teams.
2.3 Sponsor and Business Stakeholder Engagement and Buy-in
SAFe has a robust way of engaging Business Stakeholders on a regular basis with the teams. A lot of the Agile teams do very well in developing the product (they do the thing Right) but they may not be developing the Right thing. This is because the Product Owner and the teams tend to be far removed from the customers or users at times.
SAFe’s PI Planning process (and other mechanisms like PI System Demo, Product Sync etc.) literally force the teams to engage the business stakeholders, customers and even vendors in the Planning process. This has the advantage of better ensuring the Right product is developed, reduces risk and provides better buy-in to the commitments the team provides. The framework also ensures that the business stakeholders take responsibility for the prioritisation of features by assigning business value to features.
Because the business owners decide the priorities and the value, the process within SAFe achieves an inherent buy-in from the business / customers.
2.4 Business to Business, Business to IT and IT to IT Alignment
SAFe events like PI Planning, Scrum-of-Scrums, Product Sync bring together the business stakeholders, the product development teams, shared services teams and enterprise architecture teams into one place. This brings a high degree of alignment through efficient and constant communication and collaboration between business teams, between business and tech teams and between tech teams themselves (including shared services).
2.5 Joint Planning and Synchronised Cadence — Consistency
In SAFe, all the teams within a particular group (called an Agile Release Train) start and end their Sprints on the same day. This brings a degree of synchronicity, efficiency and predictability to the delivery across the group.
There is a Joint Planning session called PI Planning (the most well-known and perhaps the most important feature in SAFe). The Joint Planning session enhances communication, collaboration and alignment between various teams. Also the business stakeholders decide the value of each feature to be delivered and they work with the teams. Senior IT management and business stakeholders also get visibility of the known dependencies and risks even before the product development starts.
The Joint Planning and Synchronised Cadence bring a degree of consistency to delivery.
2.6 Portfolio Level Planning
There is no easy solution or approach to dealing with enterprise level initiatives, business cases, validation of business cases. Many firms struggle with this aspect. Most enterprises appear to start too many initiatives than they can handle / deliver and also have no robust way of ensuring that they spend money / people / resources on the initiatives that provide the best Value for the firm.
SAFe provides a number of tools, techniques and best practices to deal with this e.g. Prioritisation approaches like Cost of Delay and Weighted Shortest Job First (WSJF), Portfolio Kanban, Epic / Feature / Story hierarchy, Lean Business Case Template etc. Some of the Clients I have worked with have found these extremely useful.
2.7 Implementation Roadmap
SAFe has a solid, well proven Implementation Roadmap (please see at the bottom of the article). This is something that SAFe has put together iteratively over many years drawing on experiences, lessons learned from hundreds of implementations.
Many SAFe practitioners feel that this is perhaps the best implementation framework they have ever implemented. I strongly recommend that any firm thinking of implementing SAFe start with the Implementation Roadmap and stick to it as much as possible.
2.8 Structuring the Teams
Many Agile teams do their best to deliver in a consistent, predictable way. But they are hampered because of the way the teams are structured and created. If Agile teams are created incorrectly — e.g. based on technology or component or location — they end up creating a huge number of Dependencies increasing the effort and the time to market.
SAFe has a lot of literature and best practices and strongly emphasises structuring the teams on a feature basis. The framework strongly recommends undertaking a Value Stream Mapping exercise (as part of the Implementation Roadmap) to structure the teams properly and efficiently (with an aim to delivering as independently as possible). Thought a good Agile coach can achieve this even in a non SAFe organisation, it can be a hit and miss. With SAFe you are almost forced to undertake this.
2.9 Business Stakeholder and IT Leadership Buy-in
Research and surveys suggest that many Agile initiatives fail because of 1) lack of support or buy-in from the businesses and senior IT leadership and 2) Insufficient Training. The Implementation Roadmap starts with training and coaching the senior Leadership first before moving down the organisational ladder. Everyone gets trained before SAFe implementation starts thereby reducing the risk of poor adoption or implementation. https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report
2.10 Architecture Roadmap — Intentional Architecture and Emergent Design
Architecture and Architects are sensitive topics within the world of Agility with widely varying opinions in terms of their role in Agile teams.
SAFe tries to strike a sensible balance between completely centralised architecture vs completely de-centralised team based Architecture decisions for various reasons (in large organisations there could be a need to decide on certain tools centrally, purchase licenses on a global basis for certain applications / tools to optimise cost or decide on a central database decision etc.)
SAFe’s mantra is — Intentional Architecture and Emergent Design. SAFe also appears to provide the right amount of balance between letting teams do their own thing but establishes some guard rails. It also encourages teams to think about architecture somewhat ahead of time (Architecture Roadmap).
3. Cons
3.1 Terminology heavy
One of the consistent criticisms of SAFe is it’s heavy use of terminology. There are 4 levels in SAFe (Portfolio, Large Solution, Program and Team). Coupled with its use of Lean, Agile, Systems Thinking, Devops — it does end up with a significant amount of terminology and body of knowledge.
Most people get through this over a period of time. Mandatory training across the board in a very structured way (as part of the Implementation Roadmap) also helps but this is something to be cognisant of.
3.2 SAFe’s own Terminology
In addition to the heavy use of terminology, SAFe has amended some industry standard terminology (Sprint is called Iteration). SAFe also introduces it’s own set of Values and Principles (apart from the Agile Manifesto and Agile Principles).
This does pose a problem for organisations moving from a “normal” Agile approach to SAFe in terms of unlearning and re-learning. Organisations moving to SAFe from Waterfall appear to make the transition relatively more easily.
3.3 Inconsistency with Agile Manifesto and Principles — Reduced Agility
Pure Agilists have an issue with estimating, planning and committing over a 10-to-12 week horizon in SAFe. They argue that this creates longer feedback loops, reduces the ability of the teams to respond to change and forces them to do some upfront planning / bid design upfront.
To some extent this is true. Teams fall into the trap around committing to a 10–12 week period (PI Planning period) and focusing on the commitments and losing their adaptability.
My understanding of the SAFe argument is that a) Providing some degree of visibility and transparency around 3 months to the business and b) delivering consistently, predictably over that period is better at the cost of losing a small amount of adaptability — reason being — large enterprises may not necessarily look to change significantly over a 3 month period.
SAFe does allow for releases during the 10–12 week period and also allows flexibility to change the mind during the PI Planning period but this is more an exception rather than the rule.
3.4 — Estimation in Mandays equivalent in SAFe
SAFe recommends a relative story point based estimation using a (modified) Fibonacci sequence. But SAFe also suggests using a “normalised” Story point (1 story point equivalent to 1 person day effort — e.g. 0.5 days to dev and 0.5 devs to test). This almost makes it a person-days estimate. This does pose a problem.
SAFe has to do this, because it supports a process to do high level estimation for Epics and Portfolios that involve many teams. If each team is using it’s own arbitrary story point approach, then this poses a problem at estimating at a higher level. So SAFe solves this problem by “normalising” the estimates — 1 story point to 1 person day. This can inadvertently create a problem where senior management and teams start comparing each other’s velocity (which should not be the case).
My take is slightly different. An Agile estimation technique involves many things — a) Using a relative scale like Fibonacci b) Getting multiple estimates through Planning Poker rather than a single estimate etc. c) Reconciling the estimates through discussion (and enhancing the knowledge of everyone in the team and also making the stories better) d) Achieving a higher degree of commitment through a democratic estimation process e) An arbitrary scale.
SAFe drops the arbitrariness but retains the other 4 elements. This is another sacrifice that SAFe had to make to achieve a different (larger?) goal of providing better estimates at a higher level.
3.5 Process Overhead
SAFe’s PI Planning events (preferably face-to-face) can be expensive particularly for globally spread teams. There are costs associated with travel, venue and food/drink.
Also, there is a commitment to spend 2 full days of planning every 10 to 12 weeks for the entire team (which could be up-to 120 people). There are other reporting and ceremony overheads.
Lot of clients get concerned about the monetary cost and the loss of capacity of the entire team for 2 days. These costs and process overheads need to be recognised and provided for.
My perspective is slightly different. I absolutely agree that there are costs and process overheads involved but to me — these are costs related to communicating, collaborating and aligning better. If we cut corners on the PI Planning events etc. the costs of mis-alignment and lack of communication can be many times the overt costs of periodic planning etc.
Hope you enjoyed the article. Please look forward to more in the series.
Regards
Ramki Ravulapalli
Agile Coach, Executive Coach, SPC — Walking, Wine and Wellness enthusiast
https://www.linkedin.com/in/ramakrishna-ramki-ravulapalli-82a4161/
