SAFe (Scaled Agile Framework) is a method for organising large-scale agile programs within large organisations. It has been around for a few years and is gaining a lot of momentum. There are other methods for managing agile on a large scale such as LeSS, but SAFe is in version 3 now (4 coming soon) and is 3 years ols. That makes SAFe one of the more mature methods!
SAFe has a lot of great stuff going for it, and if you want the fine detail, you should attend the “Leading SAFe” course which is a fantastic two day experience with lots of practical exercises. The three key aspects of SAFe I am focussing on today are:
- Is SAFe right for my organisation?
- The Agile Release Train
- SAFe Release Planning
Is Safe Right For My Organisation?
SAFe is designed for organisations with 50 or more developers, testers, UXers etc. I feel that the SAFe principles could be applied on a smaller scale of 20 or more team members in a SAFe-lite kind of approach, but core SAFe is really 50 people or more.
SAFe does not organise teams around projects, products, components or skill sets. Instead it is feature-team based. If you want SAFe to work, you need to be willing to use feature teams as an approach (more on this in a minute).
SAFe has a big planning event every 8 – 12 weeks (more on this in a minute), so you need to be willing to allocate two days every 8 – 12 weeks for EVERYONE to get together for a collaborative planning session in a really big room.
If you have 50 people or more and you are willing to move into feature teams (not necessarily on day one) and you are willing to run a big planning event every 8 – 12 weeks, the SAFe could be for you!
The Agile Release Train
At the heart of SAFe is the Agile Release Train (ART). This is essentially the “Team Of Teams”. If you have 5 teams of 10 developers, testers etc, then the 5 teams constitute your ART. The ART should be enough to go from “Concept To Cash” (AKA a value stream) within your organisation. This means that the ART should be able to do all of the analysis, design, development, testing, deployment, configuration work that is needed for a product.
Each team within the ART is a classical Scrum team. This means it is a cross-functional team containing devs, testers, UXers and whatever else the team needs. All teams inside an ART are equal (in theory!). This means that ANY feature in the program / product can be built by ANY team in the ART. This is the foundation of being a “Feature Team” and this can be a big shift for many organisations. It may not be easy to achieve this on day one and so a migration plan will be needed to get there.
SAFe Release Planning
SAFe Release Planning is not particularly well named since it does not involve much release planning! It would be more accurately called Program Increment Planning. Every 8 – 12 weeks (4 – 6 sprints), all of the teams get together in the same room along with the business owners and senior management team of an organisation to plan the work for the next 8 – 12 weeks. This is a large, two day collaborative planning event. This event gives huge power to the organisation. It allows complex problems and dependencies to be solved face to face. Everyone who is needed to solve a problem will be in the same room!
There is a strict timetable for the planning event which involves a couple of iterations of the plan and a confidence vote. The first time you engage in a planning event, the strict timetable is very useful for maintaining order! After a couple of events, the whole process runs like clockwork – I have even heard it described as a “cocktail party!”.
The planning event centres around a “Program Board” which shows which team is working on which feature when. The dependencies (or “collaborations” are highlighted) between features and teams are highlighted on the Program Board. This gives a visual guide to what can be done by when and allows releases to be marked on the board. Releases are important as they require the whole ART to be ready for release at the same time.
During the event teams pull Features from the Program Board that they want to work on and break down the Features into user stories (along with their Product Owner). They estimate the user stories just like a normal Scrum team would to work out what they can do by when.
The “business” people all attend the event. Their presence is critical as they will assign “business value” to features and help create the objectives for the coming Program increment. This enables everyone to understand the priorities of the organisation over the next 8 – 12 weeks.
The key benefits of SAFe Release Planning are Alignment and Synchronisation. The business objectives, values and strategic themes align everyone towards the same goals. The Program Board and collaborations help to synchronise the teams’ activities.