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!)
01 JULY, 2020 by Diego Gavilanes Ever since the dawn of time, test environments have been left for the end, which is a headache for the testing team. They might be ready to start testing but can’t because there’s no test environment. And often, the department in...
29 JUNE, 2020 by Carlos Schults In today’s post, we’ll discuss data literacy and its relevance in the context of GDPR. We start by defining data literacy and giving a brief overview of GDPR. Then we proceed to explain some of the challenges organizations might face...
23 June, 2020 by Arnab Roy Chowdhury In this digital era, online businesses have become mainstream. Consequently, online commerce has flourished—and led to loads and loads of data! Businesses need to build data centers to store information. Not only that, but if you...
08 JUNE, 2020 by Eric Boersma Every company needs a disaster recovery plan. This is just a simple fact of life. Your company needs to know how to recover when something breaks or you can’t get access to something you need. In larger, more advanced tech companies,...
25 May, 2020 by Daniel Longest Zombie and ghost assets sound exciting, like a late-night movie you’d watch around Halloween. While in reality they may not be that exciting, they’re scary if you don’t understand and prevent them. The good news is the steps you need to...
05 May, 2020 by Eric Boersma Taking on Site Reliability Engineering (SRE) is not an easy task. It doesn’t matter where you’re coming from. Some organizations have done a little DevOps and are trying to break into SRE. Others haven’t even taken that step, and figure...