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
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...
16 April, 2019 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?...
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...
21 MARCH, 2019 by Mark Henke Preamble These days, deploying our services to the cloud just makes sense. Deploying to the cloud means you’re letting someone else handle low-level infrastructure costs, which gives us incredible flexibility. And with such flexibility...
15 March, 2019 by Vlad Georgescu Bimodal Explained *From a Release Management Perspective “The Hare and the Tortoise” is Aesop’s most famous fable. In it, we find two characters: one fast (the hare), and one slow (the tortoise). They run a race against each other,...
11 March, 2019 by Sylvia Froncza An IT and Test Environment Perspective Traditionally, test environments have been difficult to manage. For one, data exists in unpredictable or unknown states. Additionally, various applications and services contain unknown versions or...