SAFe - The Scaled Agile Framework..... Idiots guide!
********************************************************************************
NEW UPDATED VERSION OF THIS BLOG
I've just been looking at the stats of this blog and I can't believe how many people are this article!
This is a very old post based on SAFe version 2 (Which I wrote in 2013) !! I'll be writing a new one to cover version 4 very shortly!
*********************************************************************************
Theres a lot of interest at the moment in SAFe - (The Scaled Agile Framework)
I'm hearing about more and more companies that are applying the principles so thought it probably about time that I wrote a brief dummies guide to it :-)
The dictionary definition reads... The Scaled Agile Framework SAFe™ is an interactive knowledge base system for implementing agile practices at enterprise scale. Does that clear it up?
One of the problems I've often seen is how do you scale up agile? Scrum works great in teams of up to about 8 people. However many large organisations may have teams of 50+ developers and engineers working on products and this is where the SAFe framework really comes in.
Put simply SAFe is a framework template designed to allow for agile practices to be scaled and importantly it's a framework that covers the entire organisation - Its roughly operates on three levels.....
1. Portfolio Management
The individuals working with Program Portfolio Management are responsible for Governance, Program Management and Strategy and investment funding.
They are responsible for delivering the strategic themes and are stewards for the portfolio vision - determining value streams and allocating budgets to release trains,
2. Program
A group of multiple agile teams - 50+ people working to deliver functionality together... This is also known as the Agile Release Train (More on that later).... They deliver PI (Program Increments) - usually across 5 Iterations (by default but as ever this can be changed)
A PI will start with the entire train hearing the Vision - Each team then goes away to plan how they will deliver their section in individual teams.
The release train engineer (see below) and Scrum Master meet twice weekly to discuss progress with stakeholders.
3. Team
As per conventional Scrum/Kanban/Scrumban delivering code via cross functional teams in iterations - coached and supported by the Scrum master.
One of the big selling points about SAFe that isn't really mentioned much is that that SAFe finally talks about the role of management (Or hopefully leaders) in Agile.. Something which in my view has been lacking until now.... Why does that matter? Well from an agile adoption perspective I've often observed that management feels a little left out with the Agile process.... It alienates them!... True hardcore agile has no place for management! And for some reasons this doesn't fit well with management (turkeys don't vote for Christmas)
So where traditionally the agile process has been led my a bunch of agile evangelists (such as myself) SAFe acknowledges that for the process to be successful within an enterprise scale organisation the management, leaders and executives need to be trained and be the advocates! In fact much of the SAFe material is aimed at educating the senior leadership team.
As scrum is a transformational mechanism into being agile at the team level.... SAFe is a transformational mechanism at the organisation level.
The Agile Release Train or ART
Well it wouldn't be agile with out some new cool terms would it!
The 'Train' Leaves and arrives at stations to a time-table.... which is fixed and reliable (regular cadence).... Meaning that Software packages/releases are delivered to a given timetable and the depart frequently!!!
The 'Train' will hold all 'Cargo' - Code, documentation, etc
Everyone who's needed to be on the train... is dedicated to the train! (Multiple agile teams each working to deliver their section of the Programme Increment)... Trains are aligned to value streams, trains are funded not individuals.
Perhaps some of the most important concepts are that dates are fixed (The train timetable is you like)... but as in conventional agile the scope is variable. Time tables might be drawn up a year ahead. Most PIs are around 5 or 6 Sprints (Of 2 weeks) Aligning PI increments to the companies quarter financials works well.
Why train? Well if your going somewhere by plane you need to look up flight times, book tickets in advance and if you miss your plane.. Well you're in trouble! Trains on the other-hand are frequent... if you miss one train you catch the next one! This make it's 'easier' to explain to stakeholders that missing a release isn't the end of world.... as another train will be along soon! (Anybody used to British Transport and trains probably won't recognise that analogy)
The Architectural Runway
No more big bang implementation of epics! Instead the enterprise commits to features delivered in the main code-line via release trains.
It may be the case that epics need to be delivered piecemeal on over many release trains,.... Or the functionality delivered but hidden until complete - allowing for incremental code changes and testing to take place behind the scenes until the functionality is exposed.
The Architectural runway is very much the concern of the 2nd tier in the framework and is such a big subject I'll write a blog article purely on this subject.
We have some new cool roles
The Release Train engineer - Chief Scrum Master for the train a bit like a programme manager
Release Management - Plans the scope of the release and has governance authority
DevOps - This is another big concept Integrated with the train and development teams - they facilitate the set of releases.
Business Owners - Have ultimate responsibility for outcomes
SAFe is a massive subject and I've only covered a few of the highlights... When I get time I'll come back and explain each process in more detail.
Thanks for reading,
Christian
As always... Feel free to connect with me on LinkedIn