Monday, November 02, 2015

Scaling Agile: SAFe

The Scaled Agile Framework
This is the fourth of six articles on approaches that try to help scaling Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The second article is about Disciplined Agile Delivery (DAD) and the third about Large Scale Scrum (LeSS). This article will present the Scaled Agile Framework, or SAFe.

The creator of SAFe, Dean Leffingwell, tries to provide a receipe for adopting Agile at enterprise scale. So not just scaling Scrum, it is all about the Enterprise. SAFe provides guidance on architecture, integration, funding, governance and roles at scale. SAFe, as many enterprises, loves three letter acronyms like DBT, ART, RTE, PSI, NFR, RMT and I&A. I will try do give a short and understandable overview of SAFe, but I have to admit that this is not so easy to do. The whole framework is described in a single poster.
The Scaled Agile Framework
The Scaled Agile Framework (click to enlarge)

What is so special about SAFe?

There are three levels in SAFe:

1 Team
2 Program
3 Portfolio

Team Level

SAFe uses Scrum with XP engineering practices at team level. Define/Build/Test (DBT) teams deliver working, fully tested software every two weeks. This is called one iteration. There are five to nine members in each team.

Program Level

SAFe defines an Agile Release Train (ART). As iteration is to team, train is to program. The ART (or train) is the primary vehicle for value delivery at the program level. It delivers a value stream for the organization. Between 5 and 10 teams work together on a train. They synchronize their release boundaries and their iteration boundaries. Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI). A demo and inspect and adapt sessions are held. Planning begins for the next PSI. PSIs provide a steady cadence for the development cycle. They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.

New program level roles are defined
- System Team
- Product Manager
- System Architect
- Release Train Engineer (RTE)
- UX and Shared Resources (e.g., security, DBA)
- Release Management Team

In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles. If they have deep domain expertise, they are likely to fill the Product Manager role. If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.

SAFe makes a distinction between content (what the system does) and design (how the system does it). There is separate “authority” for content and design. The Product Manager (Program Manager) has content authority at the program level. She defines and prioritizes the program backlog. SAFe defines an artifact hierarchy of Epics – Features – User Stories. The program backlog is a prioritized list of features. Features can originate at the Program level, or they can derive from Epics defined at the Portfolio level. Features decompose to User Stories which flow to Team-level backlogs. Features are prioritized based on Don Reinersten’s Weighted Shortest Job First (WSJF) economic decision framework.

The System Architect has design authority at the program level. He collaborates day to day with the teams, ensuring that non-functional requirements (NFRs) are met. He works with the enterprise architect at the portfolio level to ensure that there is sufficient architectural runway to support upcoming user and business needs.

The UX Designer(s) provides UI design, UX guidelines and design elements for the teams. In a similar manner, shared specialists provide services such as security, performance and database administration across the teams.

The Release Train Engineer (RTE) is the Uber-ScrumMaster. The Release Management Team is a cross-functional team - with representation from marketing, dev, quality, ops and deployment – that approves frequent releases of quality solutions to customers.

Portfolio Level

PPM has a central role in Strategy, Investment Funding, Program Management and Governance. Investment Themes drive budget allocations. Themes are done as part of the budgeting process with a lifespan of 6-12 months. Portfolio philosophy is centralized strategy with local execution.

Epics define large development initiatives that encapsulate the new development necessary to realize the benefits of investment themes. There are business epics (customer-facing) and architectural epics (technology solutions). Business and architectural epics are managed in parallel Kanban systems. Objective metrics support IT governance and continuous improvement.

Enterprise architecture is part of SAFe. The concept of Intentional Architecture provides a set of planned initiatives to enhance solution design, performance, security and usability.

Are there well documented use cases of companies using SAFe?

On the SAFe website there are almost 20 case studies available. See SAFe Case Studies for the complete list. They include companies like John Deere and Intel.

Other articles in this series:

1. Scaling Agile: Nexus Framework
2. Scaling Agile: DAD 
3. Scaling Agile: LeSS
4. Scaling Agile: SAFe
5. Scaling Agile: Scrum at Scale
6. Scaling Agile: Conclusion

Workshop Scaling Agile in an Enterprise Environment

When you want to learn more about the different scaling approaches then join our Scaling Agile in an Enterprise Environment workshop. In this intensive one-day workshop you will pursue three goals:

1. Create an understanding of the common challenges with scaling scrum and formulating your company-specific challenges.

2. Create a basic understanding of the four popular Agile scaling frameworks Nexus, DAD, SAFe, LeSS and Scrum at Scale. We will discuss their common grounds, their differences and how they want to tackle scaling challenges.

3. Create a toolset to help you make the right decisions for your organization by breaking down the scaling challenge into building blocks and asking yourself some important questions regarding the context in which you want to use Scrum.

There is no one-size-fits-all solution so you will have to create one yourself. That is what being Agile is all about!
Posted on Monday, November 02, 2015 by Henrico Dolfing