Author blog: Henny Portman
This week I joined a great Leading SAFe 4.0 training class. Pieter de Beijer from Capgemini managed to give a good overview of the SAFe 4.0 framework. We simulated a PI Planning meeting and had many discussions regarding the practicality and usage of the method. I summarized this SAFe 4.0 framework for the readers of my blog.
The Scaled Agile Framework (SAFe 4.0) synchronizes alignment, collaboration, and lean-agile delivery for a large number of agile teams operating in a business as usual/indefinite environment. For one-time programmes/projects you could better use MSP, AgilePgM, AgilePM or PRINCE2 Agile.
Extensive information about SAFe 4.0 is freely available on www.scaledagileframework.com. See attached picture. If you use the website this picture contains behind every icon a hyperlink to the explanation, including hyperlinks to definitions or other articles and where applicable downloadable templates etc.
SAFe 4.0 is based on four core values, a lean-agile mind set, nine principles and can be divided in four levels: team, program, value stream and portfolio level and is supported by many techniques/practices.
- Core values: Build-in quality, program execution, alignment and transparency.
- Lean-agile mind set: Lean house, leadership, respect for people and culture, flow, innovation and relentless improvement and support the agile manifesto.
- SAFe principles:
- Take an economic view
- Apply systems thinking
- Assume variability; preserve options
- Build incrementally with fast, integrated learning cycles
- Base milestones on objective evaluation of working systems
- Visualize and limit WIP, reduce batch sizes, and manage queue lengths
- Apply cadence, synchronize with cross-domain planning
- Unlock the intrinsic motivation of knowledge workers
- Decentralize decision-making.
- Techniques/practices (not limitative):
- WSJF: Weighted Shortest Job First: to prioritize based on CoD/duration (CoD =Cost of Delay)
- CoPs (Communities of Practice)
- MBSE (Model Based System Engineering)
- Economic framework
- Metrics on Portfolio, Value Stream, Program and Team level
On the Team level we find Agile Teams. These teams are cross-functional, empowered and self-organizing teams who deliver valuable, tested, working products every two weeks. These teams will benefit from Scrum, XP and Kanban practices including planning, execution, demonstrations and retrospectives and deliver value via (Enabler) User Stories in a Team Backlog and Team Objectives. On this level we see the Agile Team and the Scrum Master and Product Owner.
On Program level we see a virtual self-organising organisation of 5-12 agile teams (50-125+ individuals). Every two weeks a tested and working product increment will be delivered that fits within a vision, and is compliant with architecture and user experience guidelines. In the framework this is visualised by an Agile Release Train to deliver solutions to customers via system demos and any time releases. This Agile Release Train will synchronize the iterations of the underlying Agile Teams to frequently deliver valuable and evaluable system/product-level solutions driven by Enablers and Features in a Program Backlog.
On the Agile Release Train, we see, besides de Agile Teams the following roles: Release Train Engineer (RTE; Chief Scrum Master), Product Management (to define, prioritize the Program Backlog), System Architect-Engineering (technical solution guidance), System Team (integration), Business Owners (the key stakeholders).
One iteration is a fixed time box of ten weeks (default) called a Program Increment containing five iterations (sprints). Every increment starts with a Program Increment (PI) Planning meeting of two days and ends with an Innovation and Planning (IP) iteration (the fifth). In this iteration there is room for validation, innovation/hackathon/spikes for the next PI, education and a Program Inspect and Adapt (I&A) workshop and the next PI Planning meeting.
Value Stream level
Value Stream level: this optional level (new in version 4.0) will help to build really big systems or products and coordinates and integrates multiple Agile Release Trains and suppliers into one Value Stream to deliver an integrated solution via enablers and capabilities prioritized in a value stream backlog. All Agile Release Trains will have their PI Planning meetings at the same time. Before and after the PI Planning meeting there are scheduled pre- and post PI Planning meetings to build an aligned plan and to recap, communicate and provide feedback via Demo and Inspect and Adapt
Within the Value Stream level we see the Value Stream Engineer (VSE, compare the RTE), Solution Management (compare Product Management) and Solution Architect/Engineer (compare System Architect-Engineering) and all the other roles mentioned at program level.
On the Portfolio level we have a Portfolio Backlog of prioritized Enablers and Epics related to Strategic Themes of an Enterprise which will be delivered by several Value Streams. Financial governance with dynamic budgeting will take place on Value Streams to accommodate dynamic budget adjustment to meet changing business needs. We see the following roles: Program Portfolio Management, Epic Owners and Enterprise Architect.
Witin SAFe we will not see separate manager positions but self organising teams on all levels:
- Team level: Agile Team – PO – SM
- Program level: System Arch/Eng – Product Mgmt – RTE
- Value Stream level: Solution Arch/Eng – Solution Mgmt – VSE
- Portfolio Level: Enterprise Architect – Program Portfolio Mgmt – Epic Owner
Relations between the levels:
- Process: SM – RTE – VSE – Epic Owner
- Product: PO – Product Mgmt – Solution Mgmt – Program Portfolio Mgmt
- Delivery: Agile Team – System Arch/Eng – Solution Arch/Eng – Enterprise Architect
Hierarchy of artifacts: Epics – Capabilities – Features – Stories
Henny Portman Publications: