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
26 JULY, 2018 by Niall Crawford Deploying an instance in AWS, Azure or Google is typically a straightforward process. However, architecting, managing and optimizing your end-to-end platforms that consist of application tiers, data tiers, integration points and...
Deployment shouldn’t be the most nerve-racking task for IT and DevOps Teams, but many times it is. But what if we’re talking about bigger systems, like those used by a major online retailer or a bank?…
Speak to any CIO nowadays and one of their top initiatives and commitment to the business will be moving to the cloud…
Some might think that because DevOps is hard to implement, it’s not for everyone, especially not large organizations. That’s not true. Outcomes are what really matter…
The roles of governing Enterprise Release Management and the Deployment Management are complementary, yet involve various different functions (or sets of many hats)…
We have all heard of the term Business Intelligence (BI), coined in 1865 and described more recently by Gartner as “an umbrella term that includes the applications,…