If you work in a large enterprise you know what I’m talking about. Some teams move fast (maybe too fast) while other teams still operate as if they are in 1985. How do you get these teams to move faster?
There’s such a wide range of capabilities in today’s enterprise it can often feel like you are dealing with multiple departments within a single IT department. One team might take months to gather requirements before coding, while another team might be making a release to production every few hours. The slow-moving IT department of the late 90s has been replaced by a patchwork of different approaches to software delivery, and it can present a challenge to the professionals tasked with making sense of releases across multiple teams.
While Agile increased the release cadence for most teams every large IT department still has that one team that will tell you it might take 6 months to get a new data environment configured. Alternatively you might be dealing with a business that has grown comfortable with slow moving releases – a business that doesn’t understand that more frequent software releases can often lead to less risk and dramatically lower overhead.
Teams that move slowly make it difficult to synchronize multi-project release timelines and they force teams ready to move faster to stop and wait for numerous release checkpoints. The mandate today is to move faster, and the responsibility of motivating teams to move faster often falls on release management. Some teams don’t need any motivation to move faster, but teams working on traditionally slow moving technologies might be holding on to that legacy mindset that software development moves slowly.
It doesn’t hurt to give projects some motivation to move faster. Otherwise you could find yourself supporting projects that hold all the others back. Here are some strategies to motivate those unwilling “laggards”:
Motivation #1: Comparative Metrics
“You know what? Other groups don’t take a week to get through QA. I’d really like to get software to market faster. Can you tell me what you need to move faster?”
With Plutora you can create a report that identifies the projects that are taking the longest to deliver and consuming the most release-related resources such as QA and release management. If you do nothing else, calculate how much it costs in terms of time dedicated to qualify a release and write a report that compares projects to one another.
Some healthy competition within an IT department is always a good idea especially when you have such a wide range of approaches. In my own experience managing complex release processes there’s always room for improvement. Drawing contrasts between groups is a good way to identify inefficiency and prove to skeptical projects that more agility isn’t only possible, it’s already in the department.
What you’ll find is that the teams with the most excuses to stay with infrequent release cadences are often the teams that increase the costs associated with release management and introduce release-related downtime.
Motivation #2: Give them a Nudge
“We’re doubling your release cadence next month. Even if you need to cut your release plan in half, I want to see results show up in production faster.”
Release management can often be pushed around by the projects it supports. Depending on the level of support release management receives from IT management you might be able to turn the tables, and establish a maximum time between deployments in order to minimize the risk of larger, infrequent deployments. An “all projects must have a monthly release to production to minimize release risks” strategy often works, and you can use risk reduction as a goal.
Here’s the logic. When a project waits months between releases it stores up change-related risk especially if it is surrounded by a “sea” of faster moving projects. If you only release your core production systems to production once every three months then you don’t have the same level of experience supporting production and your changes are full of high-level, strategic changes that tend to introduce downtime.
If you have a project that is used to releasing every month or even longer tell this project that they are going to be transitioning to a monthly or weekly release cycle.
Motivation #3: Remove the Excuse – Divide and Conquer
“Your releases are too risky because the system you’ve created is monolithic. I’m going to split up the project into a front-end and back-end component and I want each team to be able to release independently.”
This is the most common anti-pattern in the industry. Despite the myriad ways in which enterprise architectures can be decoupled we still have developers and architects creating monolithic systems throughout the industry. What’s more surprising is that many people working on SOA architectures still don’t fully understand how highly coupled service architectures can be when years of bad decision making is compounded.
If your teams have to perform a “Big Bang” release because they haven’t decoupled systems from one another you should provide them with some motivation to do so. Break up monolithic systems into multiple components and define API interfaces across these boundaries. Sit down with teams and get them to think of themselves as independent entities. Some organizations even go as far as forcing independent teams to consider themselves wholly independent companies. You don’t have to go that far, but splitting up a monolith is often the fastest way to achieve more agile releases.
Motivation #4: Ask them Participate in Frequent Release Process
“I know you only release your systems to production twice a year, but as part of our new efforts to align release management across the department I’m going to ask your teams to start participating in the weekly release process.”
Exposing your slow-moving teams to your agile teams will have two effects. First it will show them that there is a way to accelerate development, and second it will give people on these slow-moving teams a change to engage with other, more agile teams. Agile releases and the possibilities of DevOps are infectious within an organization. If you ask teams to monitor the weekly release process, over time they will understand what it takes to transition to this process.
They will understand that a weekly release cadence is a different approach to releases altogether. They involve lower-ceremony meetings, shorter QA cycles, and fewer release milestones. When your slower-moving teams start to see what it looks like they see what it is going to take to prepare for greater agility.
Plutora as a Valuable Management Tool
You can use Plutora to send all of these signals to your slower-moving teams. It creates compelling reports that present data across all projects and teams can use it as a tool to track efforts toward a more agile approach to releases. One of the most valuable motivation tools is simple transparency – having a single source of truth for a release timeline that can illustrate just how long it takes some projects to navigate challenging environment and release management issues.
Start using Plutora now and your projects will start to pick up the pace.
Photo credit: Mike Shaver, Flickr – CC BY-SA 2.0