Agile Release Train Smells – The Most Common Mistakes
by Eric Goebelbecker
Whether your organization is starting an agile transformation now or is well on its way, there are always pitfalls.
Scaled Agile Framework (SAFe) is a big leap for most organizations. After all, even if some of your development teams were already using agile methodology before the change, SAFe is an enterprise program with its own risks and rewards.
Let’s look at some of the most common —and most painful— mistakes.
Teams Blocked on External Resources
An Agile Release Train (ART) is “a virtual organization that plans, commits, and executes together.” SAFe describes the team as cross-functional, composed of people with the skills needed to execute their mission. But does that always happen?
Large organizations can be, well, a little balkanized. Specialized skills such as security, networking, and database management often report into different reporting lines, or management cloisters them into Centers of Excellence that produce policy and procedure instead of working with teams.
So, release trains end up stopped on a siding waiting for external resources instead of executing projects.
SAFe places shared services specialists into pools of resources, rather than dedicating them to specific ARTs. SAFe recognizes that these resources are expensive and that avoiding duplication and introducing new specialties with Centers of Excellence benefits enterprises. However, these resources are part of the release train, taking part in planning, execution, and feedback. If they remain siloed as external resources and answerable to different priorities, trains will inevitably end up blocked.
If external resources block your teams, maintaining cadence will be near impossible.
Development and Release Concerns Intertwined
The basic building block of agile development is the iteration. SAFe organizes these components into Program Increments (PI). We achieve cadence by organizing and executing these PIs into predictable intervals.
A regular cadence makes planning simple. If a feature doesn’t make it into an increment, its delivery can still be predicted by stakeholders since the next PI will begin and end in a predictable timeframe.
Meanwhile, releases run on their own schedule. An organization may issue a new release at the end of each PI, less frequently, or even in the midst of a PI, depending on their unique needs.
There is a crucial separation of concerns here; don’t intertwine Program Increments and releases. They can and should be planned well in advance, and perhaps in parallel, but the ART is about maintaining cadence and iterating through PIs. Its role is not to feed a release schedule or change direction midstream to make a date.
SAFe’s structure ensures that teams deliver new value regularly. We achieve this with planning and execution, not a weeks-long death march at the end of each quarter.
Companies accustomed to Waterfall can have difficulties grasping this separation of concerns. Once something is finished and (hopefully) tested, the urge to release can be almost irresistible, leading to cadence-breaking distractions and out-of-band feedback.
And then there is the critical new feature. A competitor releases something new or a new technology comes on the scene, and we need to get our answer out now. This was a problem in the Waterfall methodology, and it still is with Agile.
If releases and PIs are intertwined, development will suffer.
Agile’s tight loops are an essential part of iterating effectively. Sprints timed at regular intervals enhance sustained effort, optimized with constant feedback. Steady feedback means short, productive, and focused, scrums, retrospectives, and planning sessions.
Breaking this feedback means diminished or maybe even foundering effort.
Teams may defer or even skip testing entirely in the name of finishing an iteration on time, or so they can move on the next more interesting thing. This isn’t a new problem or one that is unique to an ART, but it is one that will break a feedback loop.
Reorganizing a development during a project isn’t a new problem either. As long as there have been large organizations, there have been better organization charts. Breaking up a team will always cause delays. With an ART, it’s a derailment and a broken loop.
Steady cadence and tight loops require short sprints and reasonable program increments. Long sprints or overfull increments that try to fit 10 pounds of requirements in a 20-pound bag can break up cadence and diminish the usefulness of feedback.
Similarly, terminating a sprint, or worse a PI, and redirecting effort means breaking cadence completely. This concern is similar to overlapping release and development concerns.
The larger the organization, the higher the number of possible reasons for open loops and broken cadence. SAFe operates in the House of Lean. There’s a reason for that.
Complaints about the excess bureaucracy in large enterprises are common enough that they are almost a cliché. And they almost are, but not entirely.
SAFe works best when ARTs operate as small and focused agile teams. Once they have set the scope of their PI, it’s time to get to work and limit meetings to scrum and reporting to project tracking tools. When the PI is over, it’s time to review the results, set a new scope, and get back to work.
Traditional organizations struggle with letting go of authoritative management models. Sometimes they fall into a “dotted-line” scheme or create a series of hurdles erected in the name of “governance.” These efforts can stymie progress by creating unnecessary meetings and paperwork.
Agile often leads to increased efficiency and for many, and improved efficiency always points to an opportunity to reduce costs.
We already touched on how limiting access to specialists and shared services with reporting lines can sabotage SAFe efforts. Understaffing them in the name of containing costs and walling them off in a Center of Excellence that can’t do much more than issue policies and papers serves no one.
ARTs need to have cross-functional staff and operate as independently as possible, but this can’t come at the cost of quality, security, and technical depth. Efficiency and agility are competitive advantages, not cost-containment measures.
An unhealthy focus on costs also tends to lead to authoritative management and the bureaucracy that we discussed above. While teams appear to be able to operate independently, a desire for compliance and predictably turns into distractions and a drag on productivity that sacrifices agility for cost savings.
These mistakes have a common thread: not committing to the process and compromising SAFe’s core values. SAFe has built-in flexibility with four basic configurations and plenty of room with procedures that allow for different needs. But when we compromise the core values, the process will fail.
If you are interested in learning more about implementing an Agile Release Train in your organizations, then speak to Enov8 about Enov8 Release Management. Enov8 RM is 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 (system and component-centric), and Automation.
Author – Eric Goebelbecker
19 MARCH, 2020 by Michiel Mulders SRE vs DevOps: Friends or Foes? Nowadays, there’s a lack of clarity about the difference between site reliability engineering (SRE) and development and operations (DevOps). There’s definitely an overlap between the roles, even though...
06 MARCH, 2020 by Arnab Roy Chowdhury Top 10 SRE Practices Do you know what the key to a successful website is? Well, you’re probably going to say that it’s quality coding. However, today, there’s one more aspect that we should consider. That’s reliability. There are...
20 FEBRUARY, 2020 by Arnab Row Chowdhury Technically, the world today has advanced to a level we never could’ve imagined a few years ago. What do you think made it possible? We now understand complexities. And how do you think that became possible? Literacy! Since...
14 FEBRUARY, 2020 by Michiel Mulders A site reliability engineer loves optimizing inefficient processes but also needs coding skills. He or she must have a deep understanding of the software to optimize processes. Therefore, we can say an SRE contributes directly to...
07 February, 2020 by Arnab Roy Chowdhury Do you remember what Uncle Ben said to young Peter Parker? “With great power comes great responsibility.” The same applies to companies. At present, businesses hold a huge amount of data—not only the data of a company but also...
17 JANUARY, 2020 by Sylvia Fronczak Site reliability engineering (SRE) uses techniques and approaches from software engineering to tackle reliability problems with a team’s operations and a site’s infrastructure. Knowing the history of SRE and understanding which...