The Scaled Agile Framework (or SAFe) aims to address the perceived problem of scaling Agile methodologies in enterprise environments. The brainchild of Dean Leffingwell, amongst others, SAFe has been adopted with success at a number of large organisations internationally and is rapidly gaining a footing in the local enterprise market.
Nam Huynh and I recently completed the SAFe (Scaled Agile Framework) Program Consultant course with Colin O’Neill and Mark Richards. As Nam has a fair bit of experience of Agile at scale (in complex, distributed environments), I was really interested to see how SAFe differs from what he has seen in practice. We both walked away fairly impressed: SAFe seems to address a lot of the challenges that large enterprises face.
I’d like to use this post to give a bit of an overview of the framework and also to share some of my thoughts.
Components of the SAFe Framework
By way of introduction to SAFe, let’s start by describing the fancy diagram that you may have seen before. SAFe is divided into three layers: Team, Program and Portfolio.
At the coal-face is the Team layer, where Agile teams build software using “SAFe Scrum” (a blend of eXtreme Programming and Scrum that most Agile practitioners would be familiar with). Stories are drawn from a Team Backlog and are elaborated, built and tested within an Iteration. Scrum ceremonies such as sprint planning, stand-ups, retrospectives and definition of done are adopted within the Iteration.
Some of the key differences in the SAFe framework are mandated common cadence (all teams within a Program work on the same 2 week sprint/iteration cycle) and the “Hardening, Innovation and Planning” or HIP sprint which occurs every 5 Iterations. The HIP sprint serves several purposes, but primarily aims to provide a bit of a breather for teams (supporting sustainable pace), permits teams to work on the stories that they believe will add most value to the platform and provides time for participation in planning for the next release.
Roles involved in the team layer are the Product Owner, Scrum Master, Developers and Testers. The Business Analyst is a notable absentee here – story writing and elaboration / acceptance criteria development is the responsibility of the Product Owner.
Sitting above the Team Layer is the Program Layer which comprises mainly of a concept called the “Agile Release Train” or ART. The ART is a group of Agile Teams which work on a common value stream, towards a common goal, with a common cadence (5 x 2 week Iterations comprising a 10 week “Potentially Shippable Increment” or PSI).
Each PSI commences with an intense 2 day workshop wherein the entire team (50-125 people!) perform participatory design on features that are drawn from a prioritised Feature backlog. Features within the Value Stream are prioritised according to SAFe’s Weighted Shortest Job First framework and according to pre-defined capacity allocation for different feature types (e.g. business feature vs architectural feature vs tech feature, etc.).
A core feature of the SAFe framework is the concept of “Develop on Cadence” / “Deliver on Demand”. This concept addresses a couple of concerns: Firstly, that often in large enterprises there are significant impediments to achieving “one-click deployment” that might take several years to resolve; Secondly, that completion a Minimum Mandatory Feature Set might not be achievable within a 10 week PSI.
Roles and teams that are involved at the Program level include Product Management, Release Management, DevOps / Systems Team, Business Owners, System Architect, User Experience and Release Train Engineer.
The Release Train Engineer is the proxy leader of the release train who is responsible for guiding the teams, leading the PSI Planning session and for managing collaboration (e.g. Scrum of Scrums). However, the concepts of servant leadership and self managing teams are prevalent throughout the framework.
The Release Management team is responsible for ensuring that the organisation’s release controls are defined and understood and for conducting / participating in deployment related activities.
SAFe has two teams that provide value incrementally at the Program Layer, working in common cadence with the Teams:
- The System team are responsible for building the development infrastructure and managing development environments. The System team stages the system sprint demo which is a compilation of Team efforts and assists with test automation and continuous integration.
- The DevOps team (recently added to the framework) are responsible for downstream environment management (e.g. testing / staging environment management and development environment alignment), for deployment to staging and also for automating the deployment process.
Guiding all the Agile Release Trains is the Portfolio Layer which has four primary responsibilities: Firstly, it needs to identify Value Streams that can be initiated as Programs for delivery by Agile Release Trains; Secondly, it has to manage the funding of the Release Trains to keep them on the rails; Thirdly, it is responsible for definition and management of Business and Architectural Epics that run across value streams and need to be managed at the Portfolio level; Finally, it is responsible for collecting Metrics throughout the system that help to inform Portfolio Management.
Roles at the Portfolio Layer are more loosely defined than they are at other Layers of SAFe but the include Program Portfolio Management, Enterprise Architecture and Enterprise Owners (Epic Owners).
Architecture and SAFe
Architecture is repeatedly referred to as a “First Class Citizen” in the SAFe framework and appears in several parts of the model. The framework also enforces the Agile Manifesto Principal that “the best architectures, requirements and designs emerge from self-organising teams”. This manifests itself as Intentional Architecture and Emergent Design.
Enterprise Architecture ie responsible for defining “Architectural Epics” at the Portfolio Layer which describe requirements that cannot be implemented within a single Value Stream / Release Train. Examples of Architectural Epics might include enterprise wide policies (e.g. “all production platforms must use IP-SAN or FC-SAN storage”). Programs either have a specified capacity allocation for Business / Architectural Epics or agree to incorporate Portfolio Epics on a needs basis.
Systems Architecture is introduced via the “Architectural Runway” concept which ensures that sufficient architecture is in place to enable optimum feature development. The Systems Architect will inform the teams of architectural decisions which impact future stories and may play achitecture stories / spikes in advance of business stories. Architecture places constraints on the Team and the Teams correct and inform the architecture through emergent design.
Analysis in SAFe
Business Analysts might get a bit of a shock when they first view the SAFe framework as at first glance the role has disappeared. However, further digging reveals that that many of the roles in SAFe require BA competencies.
The Product Owner at the Team Level is a natural fit for a Business Analyst with experience writing User Stories and Acceptance Criteria, especially those with experience in automating acceptance testing using RSpec / Cucumber / etc. The Scrum / Agile Master role (also known as the Iteration Manager role) is also one that is well suited to Business Analysts.
At the Program Level there is a need for Domain Modelling, Feature Analysis and Dependency Analysis, which would require someone with the competencies of a Senior Business Analyst. I would also expect that strong Lead Business Analysts with experience delivering on large programs of work and facilitating at scale would be ideal candidates for the Release Train Engineer role.
At the Portfolio Level the Business Analyst Role is actually described in the Portfolio Backlog Grooming process. This would be an ideal fit for someone with the Enterprise Analysis competency. Additionally, Enterprise Analysis is important for decomposition of the IT Organisation into Value Streams.
Criticism of SAFe
There has been a fair bit of recent criticism of SAFe but some of it needs to be taken with a grain of salt as the sources of the criticism often have a commercial stake in decrying its effectiveness.
David J Anderson writes a fairly detailed critique of the framework (The difference between Kanban and SAFe for enterprise agility1) that does have some value, although it is prefaced with the statement that
To be honest, I don’t know a great deal about SAFe. I haven’t taken the classes or spent much time studying it. Most of what I know is reported second hand from those who have taken the classes or are working in organisations that are now going through SAFe adoption.
Ken Schwaber also has some fairly strong views on the framework (unSAFe at any speed2), but given his investment in Scrum and the Agile Alliance, once again you need to take what he’s saying with a grain of salt. Interestingly he closes off his post recommending that people investing in SAFe measure the RoI with a set of metrics which seems not dissimilar to the set of metrics proposed within the SAFe framework itself.
Proponents of Scrum find it difficult to understand why SAFe is needed given the ability to scale Scrum (Scrum of Scrums, Scrum of Scrum of Scrums, etc.). This is reasonable criticism given that Scrum has been proven to scale effectively.
There are also some concerns with the concept of normalizing estimation (Normalized Story Point3). The framework recommends normalising estimation in order to make planning at the program and portfolio level more easy and to contribute to the SAFe principal of Predictability. I think the best summary of these concerns is: Firstly, that normalised estimation runs the risk of being used as a management “stick” (Method Wars: Scrum vs SAFe4); and secondly, that in some cases estimation may in itself be wasteful (NoEstimates at Oredev 20135).
Jason Yip from Melbourne has written a lengthy and very considered critique (Problems I have with SAFe-style WSJF6) of SAFe’s implementation of Don Reinhertsen’s Weighted Shortest Job First (WSJF) framework.
Personally I think that while some of the criticism is well founded, it is often misdirected. There is nothing that I have learned that suggests to me that SAFe is a methodology, rather it is collection of best of breed practices for Agile software development at the Team, Program and Portfolio level. With very few exceptions most of the criticism I have read is aimed at customisable components of the framework. Start with the framework, but If you don’t like what you get out of the box, or find that it doesn’t work in your environment, change it.
In Summary
SAFe provides enterprises with an opportunity to rapidly deploy Agile to large parts of the IT value stream and provides a common language for teams. SAFe’s partnership with Rally means that the framework is natively supported by tooling. This assists with rapid adoption and helps to ensure synchronisation across teams.
Things that I like:
- I like the fact that someone is specifically tackling the challenge of enterprise agile adoption. At Elabor8 we often see organisations that have adopted Agile at the Team level reach a point where they start to struggle with Program and Portfolio integration and enterprise prioritisation. SAFe provides a non-prescriptive solution to this problem.
- I like the fact that the deployment of Agile Release Trains includes a training element and that Certified Program Consultants can deliver training within their organisation at a low ($100 per seat) fee. This seems like a really good way to encourage adoption.
- I like the way that architecture is woven into the framework and the way that teams and architects work together. There seems to be a fair bit of conflict between architects and developers on a lot of projects and I think the framework helps to reinforce roles and responsibilities and allow both competencies to work more efficiently together.
- I like the way that Feature backlogs are managed at the Program, rather than the Portfolio level. Initiatives that cross value streams are managed with Business and Architectural Epics, but once an ART is funded, decision making within the value stream is decentralised. Hopefully this will lead to organisations starting to fund IT capability rather than the current practice of funding IT projects through up front lengthy business case development.
- I like the fact that the framework provides genuine customisation capabilities. The team at Australia Post seem to be doing some great things here, they’ve deployed a version of the framework and have branched from the source to extend the framework to fit their organisation. The fashion in which they have deployed the framework internally means that they can rapidly integrate new versions of the SAFe core as they emerge.
Things that I’m not sure about:
- I’m not sure about the concept of using limited WIP with cadence in multidisciplinary teams. To me there is a dichotomy here – either drop the cadence, or drop the WIP limit, or embrace waste.
- I’m not sure that the PSI Planning sessions, as described in the framework, are an optimal use of team time. In my experience feature planning takes a lot more than two days and I believe that if the first analysis and design of a feature occurs two days before commencement of the first sprint you will not get the highest quality outcome. I would personally like to see some additional participatory analysis and design prior to the PSI planning sessions so that teams are focussing on how to build features rather than what they are building.
- I’m not sure about the concept of pre-defining capacity allocation. While I like the fact that it will reduce arguments at the team level (about tech stories vs business stories, etc.) I think it presents opportunities for misuse.
- I’m not sure about the WIP limit on Portfolio backlog analysis. To me it seems like the Portfolio team (and hence the WIP limit) should be able to scale in the same way that you scale by adding additional ARTs or scaling within the ART. At some point adding people to a problem stops being effective and WIP limits seem to be an unnatural constraint in that regard.
Things that I don’t like:
- I don’t like the Weighted Shortest Jobs Framework. Jason Yip’s post above describes some of my concerns from a theoretical perspective but my issue with the framework goes beyond that. To me prioritisation is a complex problem that doesn’t have a “one size fits all” answer – every prioritisation framework that I’ve seen in the wild has been misused and I doubt that this is an exception to that rule.
All in all I think that SAFe is a very useful addition to the Agile landscape and one that if nothing else has prompted some interesting debate. I believe that it is an appropriate framework for organisations that wish to rapidly deploy Agile and that it also contains some valuable insights for organisations that have deployed Agile at the Team level and are struggling to integrate it with their broader IT portfolio.
References:
- The difference between Kanban and SAFe for enterprise agility: David Anderson
- unSAFe at any speed: Ken Schwaber
- Normalized Story Points: Mike Carey
- Method Wars: Scrum vs SAFe: Ian Mitchell
- NoEstimates at Oredev 2013: Woody Zuill
- Problems I have with SAFe-style WSJF: Jason Yip
