Scaled Agile Framework (SAFe) can look quite complicated and intimating at first glance. However the essence of SAFe is pretty simple:
- Fractal Plan-Do-Check-Act feedback loops (Team- and Program-level)
- Fractal levels of work filtering and prioritisation
- Priority alignment at scale (i.e. across a large number of people)
Around 6 months ago I got trained in Scaled Agile Framework (SAFe) and became certified as a SAFe Program Consultant (SPC) for SAFe 4.0. Before doing the training, I had a somewhat negative opinion of SAFe, as well as other scaling frameworks, e.g. LeSS, DAD etc. I can now say that my former opinion was based on very little understanding of what SAFe is and how it works, and was without a doubt an uneducated opinion. I admit to being somewhat ashamed for having the views I held then. Anyway, since the training, I have coached almost full-time in an organisation practicing SAFe, and have done a fair amount of thinking, training and speaking on SAFe. The following is what I believe to be the essence of SAFe. (Disclosure: my training and certification is in SAFe 4.0. SAFe 4.5 was released relatively recently. I have not yet caught up with 4.5, though I believe my thoughts remain valid and accurate.)
Fractal feedback loops: SAFe has 2 main Plan-Do-Check-Act feedback loops. At the team level, Scrum (or Kanban), and at the program, or team-of-teams level, the
Program Increment. A Program Increment (PI) is analagous to a sprint in Scrum, that is a timebox wherein a group of people plan, execute, reflect and adjust together. The differences between a PI and a sprint are that a PI involved more people, is longer lived (typically 4-5 sprints), and has ceremonies designed for the level of scale. Note that although a plan is made at PI Planning, this plan is not set in stone. It is revisited frequently during execution of the PI, much the same way a Sprint plan is revisited every day at a Daily Stand-Up or Daily Scrum (HT to Kevin Shine for reminding me about this point).
Fractal work filtering and prioritisation: Kanban is used at various levels (portfolio, value stream and program levels in SAFe 4) to filter and prioritise the work that the people in the teams do. This is to ensure as far as possible that we don’t waste time and effort working on the wrong things. This is similar to how work gets filtered and prioritised in Scrum. The feedback loops mentioned above provide a limit to the length of time the teams work on anything before getting feedback from stakeholders.
Priority alignment at scale: An
Agile Release Train is a way of making sure that everybody, across the organisation, required for work to happen has the same single list of priorities. That is, all the necessary people are dedicated solely to this set of priorities. This is analagous to cross-functional teams in Scrum. When everyone has the same priority, we have much less coordination overheard and much less waiting for each other compared to being dependent on people with other priorities.
SAFe does have a lot of roles and moving parts, there is no doubt. However I believe that the three things mentioned above form the core and essence of the framework. I certainly believe that most organisations, certainly those I’ve worked in, would benefit from all three of these structures and practices.
Kent Beck is fond of saying:
Work on the most important thing until either its done or its no longer the most important thing
If you look closely at the three things above, you might find that they’re simply ways of doing just this, when there are a large number of people working together on the same thing.