Delivering at Scale, Why SAFe Is Essential for Agile Teams
by Eric Goebelbecker
Your organization is in the midst of an agile transformation. You know that agile is the way to go, and you’re looking forward to, or maybe already reaping, some of the benefits.
Who can argue with what agile brings to the table? Here’s a short, and incomplete, list of benefits an enterprise gets when they implement it.
- Increased team autonomy
- Improved response to customer input
- Enhanced ability to respond to change
- Better visibility into results
But even with the possibility of realizing these perks, you might be skeptical about adopting SAFe and the agile release train. Why does something called “agile” come with so much bureaucracy? Isn’t the point to get away from meetings, diagrams, and milestones, not make them official?
Well, the thing is, large organizations have a problem; agile doesn’t scale on its own. Agile works well with small and medium-sized teams. But a large number of small groups organized around independent agile programs isn’t efficient. So when enterprises want to become agile, they need SAFe. Let’s take a look at why.
Shared Vision Between Management and Development
Essential SAFe starts with the Vision. The term “vision” sounds lofty and idealistic, but there’s something essential hiding underneath the rhetoric. It’s a shared picture of where the enterprise is going, and an agreement on how important it is to get there.
So, let’s look at part of vision’s definition from the SAFe website:
The Vision is a description of the future state of the Solution under development. It reflects Customer and stakeholder needs, as well as the Feature and Capabilities, proposed to meet those needs.
Copyright © Scaled Agile, Inc.
What does that mean? Well, let’s look at what happens when we don’t have a shared vision. Maybe something like this happened to you once.
A development team works with a stakeholder to define the features and the schedule for a project. Perhaps it’s a set of new features, or maybe it’s a new product. Once it’s all agreed upon, the team starts working on making it happen. But before they can finish, priorities change. The project goes on the shelf, or it’s altered so significantly that it’s no longer what was originally designed and a lot of work is thrown away.
SAFe’s vision prevents this by design. By creating a checklist of features and benefits and transforming it into a plan, stakeholders are more apt to stick with the program. The vision provides a long-term context for short-term decisions. It gives the development team a way to explain how a change in priorities today will affect the team’s ability to met goals tomorrow.
SAFe’s vision is essential for agile teams. It provides a shared set of goals, priorities, and milestones for all team members.
Program Increments Provide Focus
But let’s not throw management under the bus when it comes to derailing projects. At least, not without throwing a few more roles under the wheels to keep them company. Developers are just as capable of creating distractions for themselves and are adept at finding reasons to delay a release.
That’s why after the team agrees on vision, they break it down into Program Increments (PI). Some people call PIs the heartbeat of the agile release train. They provide teams with a reliable cadence for delivering product to customers. Whatever label you use for PIs, they’re what keeps the program participants focused. If you’re not delivering features and value at regular intervals, you don’t have a program.
Planning PIs gets everyone together, hopefully face-to-face, and gives them an opportunity to take the shared vision and design a plan that delivers value on a regular basis. Once the program is formed, everyone has an agenda, and it’s time to get the agile release train (ART) rolling.
The Agile Release Train Is What Makes SAFe Essential
The ART is what makes SAFe essential. Agile is about iteration. By focusing on short, digestible, and manageable increments of work, teams receive immediate feedback that they can use to fine-tune their efforts.
These increments work for a small team of five to ten people. They don’t scale well for larger groups because the feedback can’t be applied to the overall program. At the same time, managing a large number of small teams from a central vantage doesn’t scale well either.
So in SAFe, we establish the PI and then use it to build and direct the ART. The PI creates a feedback loop at the program level, usually lasting a calendar quarter, but never more. Then scrum teams are established inside the program.
During each PI, teams work on two-week sprints. From their viewpoint, it’s agile scrum. Under ideal circumstances, they don’t care whether they’re working inside SAFe or not. They’re working on sprints that provide them with the regular feedback they need to operate efficiently. The development teams work on a half-dozen or so sprints comprised from the backlog the current PI has defined.
The train metaphor models how releases work in this system. Each quarter the teams assemble and define the next increment. If a feature doesn’t make it in, it’s not addressed during that increment. It can try to get on the train at the “next stop” when a new program increment is defined. This discipline is what keeps everyone focused.
What happens without the train?
Well, the teams may quietly fall into a waterfall of sprints. Even though they lack the pressure of picking a set of features and executing on them on a regular schedule, they need to stay busy. So they’ll just keep scheduling sprints and adding features as they go. Since they’re making up these deliverables on their own, they may never add up to a releasable product or something that a customer wants.
Or, they may define their releases without input from other teams. When this happens, the enterprise product portfolio is a disjointed mess. The train doesn’t only determine the interval. It also translates the shared vision into a plan. Without that plan, the enterprise may look like a federation.
What Makes an Organization Agile?
Does a collection of teams using scrum add up to an agile enterprise? Or does it require teams with a shared vision and common schedule? SAFe’s orchestration is essential, and without it, the enterprise is less than the sum of its parts.
The agile release train is the structure SAFe employs to deliver value to customers. Its composition will differ depending on the program and organization that’s using it, but the core principles remain the same. When implemented correctly, the ART keeps teams focused and working in harmony across the enterprise.
Are you interested in learning more about implementing an agile release train in your organization? Contact us about Enov8 release management, a complete platform that takes you across the release spectrum from ART (enterprise program-centric) through to implementation planning (typically project-centric), system deployment operations (systems and component-centric), and automation.
This post was written by Eric Goebelbecker. Eric a regular Enov8 blogger, has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!)
20 MAY, 2019 by Mark Henke It’s a great step when teams deliberately manage their deployments instead of treating them as second-class citizens to writing code. But there are many pitfalls to managing deployments effectively. Many things lurk, waiting to trip us up....
08 MAY, 2019 by Mark Henke Taking enterprise release management seriously is a great step toward helping our organization flourish. Embracing release management will allow us to make the invisible visible. We’ll be able to effectively manage how work flows through our...
04 MAY, 2019 by Rodney Smith If you work in an organization that uses the scaled agile framework (SAFe), chances are it's not a small company. It's enterprise-y. It's probably gone through some growing pains, which is a good problem to have in the business sense. The...
29 APRIL, 2019 by Carlos "Kami" Maldonado "DevOps at scale" is what we call the process of implementing DevOps culture at big, structured companies. Although the DevOps term was coined almost 10 years ago, even in 2018 most organizations still haven't completely...
24 APRIL, 2019 by Mark Robinson It’s the normal case with software buzzwords that people focus so much on what something is that they forget what it is not. DevOps is no exception. To truly embrace DevOps and cherish what it is, it’s important to comprehend what it...
28 March, 2019 by Christian Meléndez Even though containers are different from virtual machines (VMs), most of the metrics you get from a container are pretty similar to the ones you get from a VM or a physical server. What’s different is the meaning a metric has in a...