When should you consider Implementing SAFe (Scaled Agile Framework)?
To (be) SAFe or NOT to (be) SAFe — Considerations for adopting Scaled Agile Framework (SAFe)
This is the first in a series of Articles on SAFe — the subsequent ones will be a) Pros and Cons of SAFe b) How to go about implementing SAFe — if you have chosen to go down the route.
If you are hard pressed for time, just read the headings under the sections — When to Consider implementing SAFe (5.x) and When not to use SAFe (6.x) — though I encourage you to read the whole thing to get a better context and understanding.
For my second SAFe Article please visit — https://medium.com/@cinemaparadiso/pros-and-cons-of-scaled-agile-framework-safe-cc142f0c74cf
1. Background and Purpose
Whether to implement/adopt SAFe and When to implement/adopt SAFe is a question that I get asked regularly by my trainees / clients / potential clients. Thought it would be a good idea to write an article outlining some of the aspects that people should consider when deciding whether to go down the SAFe route. These are my thoughts based on my understanding of SAFe, the interactions during the SAFe training I have delivered and my experiences in SAFe implementations across multiple Clients / Geographies.
2. Coming Clean
I am a SAFe Program Consultant (SPC). During my Agile journey (non-SAFe and SAFe), I have benefited enormously from the generosity of many Agilists who have shared their knowledge and trained/coached me. I would like to do the same and share my thoughts with fellow Agilists, Executives and Managers on SAFe.
This is not a recommendation to implement SAFe. I am not paid for writing this article and these thoughts are purely my own. The idea is to inform people, put it out there, create some food for thought and generate a debate. Even though I would like to say this is an unbiased piece, I know well enough as an Agile Coach and Executive Coach, that there is no such thing. Please use it as you see fit and take it with a pinch (or a bucket) of salt.
3. How should you use this Article
I have categorised the considerations around 1) When to adopt SAFe and 2) When not to use SAFe. When I refer to SAFe — I mean a full scale SAFe implementation.
Considering Implementing SAFe is a major decision for any organisation and should not be taken lightly. It will involve a significant amount of time, effort and cost. Your organisation may be impacted by more than one of the considerations outlined below and hence you need to take a well considered and balanced decision. Any major decision like whether to or not to implement SAFe is also likely to be very contextual and so please use the information below in the right Context.
There is no suggestion here that SAFe is the only game in town if you need to Scale Agile. There are other answers out there — perhaps even better ones but I am not qualified enough to compare and contrast. This article is just about SAFe.
4. Is SAFe very Agile?
There are a number of aspects that I am not very fond with regards SAFe and there a few things I like about SAFe. I think it has a place in certain contexts, in certain organisations and at the right time. SAFe is NOT for everyone at all times.
Senior Agilists like Ken Schwaber, Ron Jeffries, Jez Humble have written or spoken critically about SAFe or Scaling Agile in generally. I will mention some of these and add links to provide a more balanced view — in my next Article — Pros and Cons of SAFe.
As for as this Article is concerned, I will stick to whether or not to implement SAFe.
5. When to consider implementing SAFe
5.1 When there are significant dependencies across agile teams or agile teams and support / functional teams (infrastructure teams, deployment teams etc,)
Many teams (even some Agile teams) struggle with managing dependencies with other teams. They struggle to get visibility of these and the dependencies end up being blockers and are dealt with as such. (In an Ideal world or a pure Agile world, the aim for any team should be to be as independent as possible and this can be done by forming feature based teams or through design considerations (decoupling, API/Micro services based approach etc.) but most teams are not there yet). Dependencies really end up impacting the ability of teams to deliver, deliver predictably and they end up costing significantly.
SAFe’s Approach: I believe SAFe has a robust framework to make sure teams discuss, make visible and manage dependencies pro-actively. This typically is dealt with three different aspects in SAFe — a) A co-ordinated and aligned planning session called PI Planning b) An excellent Program Board which makes Dependencies visible c) A Scrum-of-Scrums (SoS) session that enables a regular and focused discussion around Dependencies (and Risks).
5.2 When there are too many silos between business and technology making feedback slow and inefficient
In many organisations (typically the larger ones), product delivery teams tend to be far removed from the customers or end users (there might be a change team or some other team in between). This makes it difficult for the development teams to get proper feedback on the products and also to get the right Value signals. Though these teams may be very Agile and develop excellent products — the value delivered to the organisation may not be great — this ends up being — Doing the thing Right but NOT doing the Right thing.
SAFe’s Approach: SAFe forces business stakeholders to regularly interact with delivery teams and also assign business value to various initiatives / features and commit to them. The business stakeholders and product managers also are forced by the Framework to prioritise the Features being planned. This is done via a periodic planning session. This aligns the business and the technology in terms of value and priorities. (We can argue this is the role of a Product Owner (PO) in a Scrum Team but I have seen many instances where POs are internal project team members who try to imagine where the value lies rather than really getting the value signal from customers / values).
5.3 If there is a total mis-alignment between business strategy and IT delivery
Please see under 2 above
5.4 When the communication is broken between Business, Product Teams and Dev teams
Too often, the communication between business sponsors and product teams, various product teams themselves, between product teams and tech teams and amongst tech teams either does not happen or does not happen efficiently. Some Agile teams and organisations do a better job by facilitating communication but it can become a hit and a miss.
SAFe’s Approach: SAFe deals with this problem through a regular and structured framework with the a) A co-ordinated and aligned planning session called PI Planning (and pre and post planning activities b) A Scrum-of-Scrums (SoS) session between Scrum Masters c) A Product Sync meeting for all Product Owners and d) A regular bi-weekly Product demo (like a Sprint Review) and a periodic Integrated system demo.
5.5 When business sponsors are looking to get more transparency around delivery, risks and dependencies
Business sponsors need to be able to understand when things are going to be delivered, how much it will cost, risks for delivery, whether they need to make some people/staffing related decisions. A Scrum team can potentially give an answer for what it is doing (and different Scrum teams answer in different ways). Senior business sponsors are looking for an integrated, holistic view. Many organisations solve this problem through programme managers, PMO etc. but individual Scrum teams cannot solve this problem most of the times.
SAFe’s Approach: SAFe deals with this through four different aspects — a) A co-ordinated and aligned planning session called PI Planning where the business participates in the team planning sessions so they know what to expect b) An excellent Program Board that shows which features are delivered by what team and when c) Regular Reporting and d) A formal Risk Register.
5.6 When there is a need to plan or forecast on a medium to longer term basis
Many organisations (typically medium to large) need to forecast and plan for the next few months. Agile teams tend to deal with this through Roadmaps and Release maps but different teams end up doing this in an inconsistent way.
SAFe’s Approach: SAFe ensures clarity around the near to medium term through the following a) A co-ordinated and aligned planning session called PI Planning that aims to articulate the delivery over a 10–12 week time frame b) A Roadmap with more certainty in the near term and less certainty in the medium to long term ) Regular updates to Vision d) An Architectural vision for the near to medium term (Architectural Runway).
5.7 Large organisations spread across multiple geographies, external vendors, suppliers etc and function based contracts
There is no easy answer in normal Scrum to dealing with teams spread across countries and particularly where there are external vendors who have their own way of doing things and where teams are organised functionally (e.g. a Bank has outsourced all it’s testing to a third party vendor or some of the Product development to a third party). Co-ordinating across multiple geographies and parties (with their own agendas/interests and delivery frameworks) can be a nightmare.
SAFe’s Approach: SAFe tries to align all related parties internal and external (including Suppliers, Vendors) through co-ordinated and aligned planning session called PI Planning. 3rd parties participate as if they are internal and SAFe recommends dealing with vendors on a long term, partnership basis. There is also some very good SAFe literature with some ideas about dealing with suppliers, different delivery Frameworks (Waterfall vs Agile) and Agile Vendor contracts (this is something I get asked regularly in training sessions).
5.8 When there is advantage in enforcing some central decisions (like going cloud or buying central licenses for software or implementing a tool)
For commercial, administrative or regulatory reasons, organisations might want to enforce some centralisation or standardisation across teams. The default mode in a pure Agile team is to let the team decide on Architectural, Tooling and Design decisions.
SAFe’s Approach: SAFe tries to solve these high level decisions through a robust decision framework on when to centralise decisions and when to decentralise (as for as possible decentralise — that’s the default). It also tries to strike a pragmatic balance between providing a near to medium term view on Architecture / Tooling etc. while letting teams do their own thing at the ground level. SAFe establishes these guard rails through what it calls — Intentional Architecture and Emergent Design.
5.9 When you need Dynamic budgeting / cross program prioritisation / lean portfolio governance
As mentioned previously, Scrum teams may be doing their best and developing great products but there is no guarantee that the products deliver optimal value for the organisation (this is not the fault of Scrum — it is not meant to deal with this aspect in general). For example, the 5th priority Project in business division 1 may be more valuable than the top priority Project in business division 5. Scrum teams in these divisions may be doing their best but this is not necessarily the best overall for the firm.
SAFe’s Approach: SAFe brings a number of conceptual ideas, techniques and practices forward to address the above — a) SAFe introduces dynamic budgeting and asks for continual evaluation b) SAFe introduces concepts and techniques like Cost of Delay (CoD) and Weighted Shortest Job First (WSJF) to quickly and efficiently prioritise across Programmes and Divisions optimally c) SAFe introduces a light weight Portfolio Kanban to evaluates ideas before they get executed (but keeps a Work-In-Progress limit) because too often organisations take on too many projects — SAFe recommends robust Demand management.
5.10 When you have a number of non-tech considerations — Compliance documentation, Release communications, Training, Packaging etc.
There is more to organisations than software elements of the product — for any organisation but more so for companies working in regulatory environments — healthcare, electronic and electrical devices. Organisations need to consider compliance documentation, training, packaging etc.
SAFe’s Approach: Though there is nothing Agile about this, SAFe recognises large Solutions and provides for a robust compliance documentation approach and also provides for Non Functional Requirements as part of it’s approach.
5.11 When senior stakeholder buy-in is needed on the benefits of agility
One of the top 3 reasons for failure of Agile initiatives is the lack of management support. This could be partly due to lack of buy-in from them or a lack of belief in the benefits of Agility or it coud be lack of awareness about Agility itself. Also, some of the business sponsors Agility as “something the techies do” and a normal Scrum approach does not give much of an holistic and integrated view to very senior sponsors.
A lot of the Agile initiatives are either undertaken from bottom up or adopted solely within technology with no business involvement.
SAFe’s Approach: SAFe has a very strong and effective step-by-step “Implementation Roadmap” (in my opinion) (affectionately called the Snake by SPCs — image at the bottom of the Article). This starts with training / coaching senior business sponsors and provides for training to the whole organisation (top layer then middle layer and then the teams). This way SAFe adopts a top-down, business first approach to adopting Agility.
6. When not to use SAFe
The below are some of the situations / reasons why you many not want to go down the SAFe route:
6.1 When different teams need to Sprint at different speeds
Different Agile teams wish to have different cadences (e.g. In a bank, a Front office team may wish to have a 1-week Sprint and a back office team may wish to have a 4-week Sprint) for any number of reasons (technology, pace of market change, stakeholder demand, risk aversion, lack of automation of testing or deployment).
SAFe’s Approach: SAFe has a mandatory requirement to synchronise and align the cadence within an Agile Release Train (a Program Team). If this does not work for whatever reason, then SAFe is not for you (at least not until you are able to align and synchronise).
6.2 When the teams are relatively very independent (feature teams)
When you have teams that are fairly independent of each other with little in common amongst them and they can develop and deploy at will, then the benefit case for SAFe will be smaller. There are still quite a few other things you can benefit from but you need to consider carefully the costs and benefits (e.g. business / IT alignment, transparency and visibility etc.).
SAFe’s Approach: One of the biggest selling factors and advantages of SAFe is the so called PI Planning (big planning event). This is a 2-day Planning event with everyone on the team in the same place (to the extent possible). So there is a considerable cost and process overhead to this and some of the other processes. Make sure the benefits outweigh the costs.
6.3 When the entire team size is less than 50 or 60 people
If your organisation or the program team size is around 50 to 60 people then SAFe is not for you. There is some process overhead and costs of SAFe and the benefits will be significant only if the size is considerable.
SAFe’s Approach: SAFe’s own recommendation is for a minimum size is 50. So if your overall team size is around 50, then there is no need for you to consider SAFe.
6.4 When you are a start-up and need to react very, very quickly to market conditions
If you are a start-up and need to react very, very quickly to market conditions or opportunities or competition, then you need to carefully consider the decision to implement SAFe.
SAFe’s Approach: SAFe does give predictability and forecast over 10 to 12 weeks (typical planning horizon is 8 to 12 weeks) but it does reduce the flexibility somewhat over that period. So if you need react very fast, then perhaps SAFe is not for you.
6.5 If you just started your agile journey and have not come to grips with it yet
If your organisation or division has just started implementing some form of Agility (Scrum, Kanban etc.) and are still trying to adapt your ways of working and are trying to adjust to the new terminology, then it may not be appropriate to adopt SAFe at this time.
SAFe’s Approach: SAFe introduces it’s own terminology and is quite content and terminology heavy. It may create considerable confusion to your teams and reduce the productivity and pace of adoption of Agility. It may be best to let the teams get better at Scrum etc. before you start introducing them to SAFe.
References / Links
SAFe Website — https://www.scaledagileframework.com/
SAFe Case Studies — https://www.scaledagileframework.com/case-studies/
I hope you have enjoyed the article and found it useful. Would be grateful for any feedback and comments.
All the very best.
Regards
Ramki Ravulapalli
Agile Coach, Agile Transformation Lead, SPC 4.5, Executive Coach
Wine, Wellbeing and Walking Enthusiast
