SAFe In A Nutshell
I wrote my last serious blog around SAFe in 2013(ish) and a lot’s moved on in that time…. In 2015 I became a SPC (SAFe Program Consultant) and have since helped several clients launch their first ART and provided SAFe consultancy and training to many others.
SAFe (Scaled Agile Framework) is one of the most ‘in use’ frameworks for organisational agility, probably the most controversial and almost certainly the best marketed, with glossy posters, videos, case studies and a long list of training courses!! It has been unashamedly packaged in a way where it can be delivered with confidence to large enterprises and is reassuring detailed and complete unlike perhaps Scrum or LeSS (I’ll let you decide the relative pro’s and con’s of such an approach)
Overview
I’ll assume that anyone reading this blog has a good understanding of single team Scrum and I’ll concentrate mainly on the roles and ceremonies that SAFe includes to enable it to operate at scale.
SAFe is designed for PRODUCT development with between 50 - 150 people… If you have less than 50 in your engineering teams SAFe is probably too much of an overhead - If you have around 150 or more you need to be looking at multiple Agile Release Trains.
SAFe is run around the Agile Release Train (ART) an ART is made up of a team of teams (Think scrum teams) each team being around 5-9 people, As mentioned above trains should be between 50 - 150 people in total. (Dunbars number.)
SAFe - Big Picture
ARTs run on a cadence of Program Increments each around 5 iterations (sprints) of 2 weeks in duration followed by a 6th iteration being used as an innovation/hackathon/prep. It makes a lot of sense to tie each PI into your companies financial quarters - so 4 PI’s per year, 13 weeks each would allow for 5 or 6 sprints and a week for prep, travel and other activities before your next PI.
Each iteration within SAFe is similar to a sprint in Scrum - Except you should be aiming to fully integrate code/hardware every 2 weeks (at the maximum) - Ideally all teams should be practicing continuous integration (CI), Continuous integration in SAFe means Continuous Integration! Not just installing a Jenkins server! Everyone works in the same branch (trunk) of code… So that could be 150 engineers all making coding changes in the same branch - No sub branches (Or at least no long lived sub-branches)
A PI begins with PI planning - This is a 2 day event where all teams come together to plan the next Program Increment (Usually between 10-13 weeks) It’s a little like the planning event in Scrum - only on a massive scale and much more noise!
Ideally everyone should be together for a PI planning event which often requires flying teams from around the world to one location - I usually say try and avoid having teams joining via video conference… However due to COVID-19 I have recently participated in my first fully remote PI planning event… So it’s doable…. But it’ll be interesting to see how well this PI goes compared to previous ones.
SAFe Roles
SAFe has all the roles of traditional one team scrum, Scrum Master, Product Owner, Team member, but there’s some new roles to help cater for running at scale.
Release Train Engineer (RTE) - At its simplest the RTE is a sort of Scrum Master that operates at the program level… They should be helping to ensure that the SAFe process is understood and being followed, supporting teams and helping to identify and resolve impediments.
Product Manager - Product manager's steer the Release Trains, choosing and prioritising features that the ART (Agile Release Train) will work on during a Program Increment (PI)
SAFe still has Product Owners (PO) - Who work with the team… The Product Manager will work with a number of PO’s and teams and focus on business goals.
System Architect - The system architect helps to maintain a coherent architecture strategy - working with teams to set guardrails - The trick is to not be too prescriptive and allow teams the autonomy to solve their own problems but ensure that it’s within the strategic direction of the company and plays nice with what other teams are doing.
This is one of the areas where traditional one team scrum autonomy is sacrificed in order to achieve benefits of working at scale.
Business Owner - The business owners serve as a proxy for the needs and wishes of the ‘business’ they will primarily liaise between Product Managers and executives…. It can be considered yet another controversial area of SAFe - with many arguing that this creates yet another barrier/handoff…. Whilst I agree with this view in many cases operating at scale it is a pragmatic solution but certainly not ideal.
Moving beyond a single ART
Personally I’ve only worked with one client that had more than one Release Train working on the same solution…. So this is where my experience becomes more theoretical.
ART’s become Solution trains - Of between 3 - 10 ART’s!! Solution trains run on the same cadence of single trains… And we have a few new roles.
Solution Manager - The scaled up Program Manager, Owns the capabilities (features) on the solution backlog.
Solution Train Engineer - A scaled up Release Train engineer
Solution Architect - A scaled up System Architect
In addition to the new roles - A Pre-PI and Post-PI ceremony is added.
Criticism of SAFe
There is plenty of criticism of SAFe and SAFe practitioners within what I’ll loosely call the ‘Agile Community’ and many arguments as to if SAFe is agile or not!
I’ve worked with many organisations that use SAFe and many that don’t - I’m agnostic around frameworks and methodologies and like to think I’m fairly pragmatic in my approach, so this is my view….
If you’re arguing that SAFe is or is not agile… In my opinion you’re completely missing the point. Whilst I work with many companies that come to me saying they want to be more Agile…. What they really want is to reduce their time to market.. Shorter lead times, more predictability, better coordination, less waste, less mistakes and happier customers.
At the point I meet and work with many organisations what SAFe offers is considerably better than where they are now and will pull them closer to their goals - Is that being agile, well I’ll let people argue over that…. Does it help organisations to reduce cycle times, prioritise portfolios/program backlogs better and coordinate large teams - Yes, does it offer an improvement of where they currently are, Yes!
I still come across many SAFe implementations that are problematic - ART’s which have not been funded correctly (Still relying on traditional project/individual funding rather than funding a train) PI planning events that are more push than pull. Component teams rather than feature teams, dependencies that are managed rather than removed and too little team autonomy - However I can say the same about most non-SAFe organisations that I’ve worked with.
For those organisations that fully embrace SAFe - who implement a lean-portfolio and are able to start and complete work on cadence the benefits are incredible. Whilst many in the agile community consider a quarter (1 PI) too long a planning horizon and not very nimble (or agile) - I have yet to see many companies of size that can completely pivot direction within 3 months and that’s what SAFe helps to deliver!
Thanks for reading… I’ll be adding a few more SAFe articles soon discussing value streams and lean portfolio management and a few around Disciplined Agile.