Scaled Agile Framework (SAFe) already has its version 4.0. It delivers in their own words “knowledge for the people building the world’s most important systems.” The popularity of ’s SAFe makes finding training or consulting easily. There are plenty of articles, tutorials and videos online, and the certification process is clear and fairly mature. Leffingwell wrote Scaling Software Agility with best practices for large enterprises. That book led to SAFe.
In November 2016, Leffingwell’s new book, SAFe® 4.0 Distilled: Applying the Scaled Agile Framework® for Lean Software and Systems Engineering will be released.
Relatively easy for organizations to transition to, SaFE is also prescriptive – it tells organizations exactly what to do, although with good intentions. A pitfall is the to try to adopt all of it without understanding the advantages of every piece of SAFe. It could lead to new mantras and language, including teamwork, program work, business epics, technical epics, metrics at every level and a host of other requirements, without a clear rationale. Complexity then ruins the simplicity which is core to Agile.
A fool with a tool is still a fool
Introduction to SAFe
Because the Scaled Agile Framework‘s home page or overview posters may be overwhelming, I took this SAFe in a nutshell from a Henrik Kniberg presentation.
In accordance with decentralized decision-making, SAFe prescribes a content authority chain that extends through three levels. Solution management is responsible for guiding the solutions that constitute the value stream. Product management is responsible for program vision and backlog. Finally, Product owners make fast, local content decisions on behalf of the agile team. A team in SAFe might be 8 to ten people, with everything they need to deliver software, end-to-end: requirements, coding, testing, and deployment. Several teams create what SAFe calls a release train, which organizes around a program. That’s a single project, or at least, one program-of-projects. It has a single line item in a budget – the company is buying one specific thing. This is the small project the executive talks about.
In SAFe terms, the Release Train is the team-of-teams, typically 50–125 individuals. Like a real train, the release train runs on a schedule, though that schedule can be as flexible as your organization needs it to be. This Program Increment. SAFe suggests that people involved in a release train be dedicated full-time to that release train, regardless of reporting structure.
A portfolio is a collection of these programs, the total amount of budget dollars within IT going into software development. SAFe calls this Program Portfolio Management, and suggests that one office has the responsibility for strategy and investment funding, program management, and funding. A Rally Software Blog lists 40 things you need to know about SAFe.
Let’s get to work as a team and jump on the release train
Each release train (remember, that’s 50–125 people) meets once at the beginning of each release cycle to develop Program Increment Objectives and the team-level objectives that make the increment objectives possible. The meeting is typically two days long. In addition to simply planning, the meeting has other benefits, like allowing the team to have a sense of team-ness – to create the face-to-face conversations that make real progress possible. The meeting includes representatives from both business and technology; over the course of the event, the two groups merge and align, again reducing friction and errors from misunderstanding.
After planning, the team works on the next Program Increment, and a small team needs to steer or coordinate that work to success. SAFe calls that the release management team, which typically consists of the Release Train Engineer (a program facilitator, chief scrum master for the train), Product Management, and a few executives who are not committed to that program full-time. It may also include development managers, senior testers, architects and other roles on the program that could give input. This is the group that communicates with external groups on timing and takes corrective action when there are schedule problems. SAFe suggests that the group meets weekly.
To avoid crappy code, SAFe suggests a handful of practices that are aimed more at prevention than traditional test/fit testing. SAFe starts with Agile Architecture, a principal that architecture is emergent, but the system architecture needs to evolve ahead of the newest features, to make adding those features possible. It includes continuous integration, having the software build and automated checks run for every check-in. SAFe advocates test-first as a philosophy, not just unit tests but also at the specification level. This practice of creating concrete examples, down to the inputs and expected results as a collaborative, whole team effort is called Acceptance Test Driven Development in SAFe.
SAFe also includes classic eXtreme Programming practices like pair work, not just for programmers but for many roles, along with refactoring (improving the design of existing code) and collective ownership. Collective ownership of code gets more complex with multiple teams, but it also means that teams can make corrections instead of create a “ticket,” or “make-work” for another team. This prevents the first team from being blocked and also does not create priority problems for team two – as team one’s priority and blocker will probably be team two’s “nice to have.”
SAFe at portfolio level
At the portfolio level, SAFe looks for the IT organization ability to deliver, and perhaps support/maintain, working software. The metrics that SAFe suggests are things like employee engagement, customer satisfaction (these may be internal), agility, time-to-market, quality and the ability to work with partners outside of the software organization. In addition to these measures, SAFe suggests burn-up charts manage the process of an individual epic and a bar chart showing actual and to-be-done work to compare the progress of multiple epics at one time.
Where most agile development organizations focus at the team level, on sprints or iteration, SAFe focuses on the program, which could be five to 15 teams. The program-level sprint in SAFe is the Program Increment, formerly known as the Potentially Shippable Increment.
Now we start to see the pieces of SAFe coming together: Release Planning defines the objectives for the Agile Release Train, which are built during the Program Increment.
Again: is SAFe evil?
In his 2013 blog post UnSAFe at any Speed, Scrum founder Ken Schwaber argues that SAFe is essentially the Rational Unified Process (RUP) rebranded as agile and that after the failure of IBM’s RUP in the marketplace, the RUP people came to agile. Dean Leffingwell, the lead author of SAFe, was a senior vice president at Rational Software Corporation (now a division of IBM), and many of the contributors to SAFe do have a Rational or IBM background. One highly-placed source suggested that where the Agile Software Movement came out of practice, RUP, SAFe, and other methods were derived theory-first, not out of what has worked, but instead on what should work, based on models. So far Schwaber’s position.
Reading the SAFe descriptions, however, gives a different impression. Most of the pieces of SAFe are familiar, borrowed from existing agile methods that work like Scrum, XP, and Kanban. The argument that SAFe derives from theory has less credence than the argument that SAFe is a transitional point sold as the end goal.
Is SAFe evil? It depends. If your organization benefits from a ‘follow the rules’ approach, SAFe is valuable. If your process maturity is more on an ‘adapt the rules’ or ‘ignore the rules’ level, then implement a more light-weight, non-descriptive framework. SAFe may be a good, transitional step. After that, the organization needs to figure out what improvement should happen next, and that requires context. Agile coach Yves Hanoulle puts it this way “For most of these I would say, SAFe goes further as they are ready to go, not far enough as they should go.”