Enabling Frequent Software Releases, Greater Independence

As release managers and executives, we address release complexity and complex dependencies between releases by combining software releases.

If you have 20 groups asking to run independent releases, why not just combine them all into one?

Sure, this results in less overhead for support teams, but it also holds the organization back. It’s a limit to agility for teams as they drive toward daily or weekly releases. It’s a “lowest common denominator” approach to release management that is unnecessary when you have the tools available to manage more frequent releases.

This “combine everything in one release” approach creates more interdependent teams trained to wait for each other to release coordinated changes. If all of your releases are combined into one big release, after a certain amount of time has passed you will never successfully separate. A dedicated release management tool gives you the ability to break these dependencies by providing the means to manage and track complexity without having to make compromises.

A Concrete Example: The Monolithic Department

A company designing a website has 10 different teams working on 10 different parts of the site.  There’s a team focused on the e-commerce experience, there’s a team focused on a streaming music service, and there’s yet another team focused on core architecture and services. Each of these teams is a separate, isolated value stream. Despite this separation, the organization does not understand how to support multiple, simultaneous releases.

So they simplify – instead of allowing each team to move independently they create a monthly consolidated build.

A year passes and teams have now socialized this process of a monthly release to the point where features are being added across value streams that depend on this monolithic release.  Instead of achieving independence to encourage greater agility your teams are “joined at the hip” now more than ever.  The department is stuck with a monolithic release process.

Different Teams, Different Release Schedules

Combining multiple releases into one is a common practice that limits the overall agility of the organization. Instead of enabling each team to maintain an independent release cadence, the organization standardizes within a single release – limiting the agility of teams that can and must move faster.

Here are some examples of different types of teams contributing to software development efforts and what sort of cadence they should be delivering at:

Content Teams – Teams focused on content updates and changes to consumer-facing websites need to react quickly to new requirements and defects.  These teams should be able to deploy to production multiple times a day to keep up with the pace of change online.Application Teams – There’s no “one-size-fits-all” solution for application teams because there’s such a wide variety of applications being developed, here’s a breakdown of application types with the timelines one should expect to be able to achieve for frequent software releases:

• Front-end Web Development – Similar to content teams, these teams should be able to deliver once a week or once a day.  Some high profile websites deliver software multiple times a day.  The web moves very quickly and there’s no reason to constrain teams developing web sites to a monthly release process.

• Server-side Web Development – Teams developing systems that mediate access to services or other back-end systems. While not as frequent as front-end web development, these teams should be able to achieve weekly release cycles at a minimum

Core Architecture Teams – Architecture shouldn’t be changing on a daily basis, but this is where a team starts to move to a slower release cadence.  A weekly release to address architecture issues or to roll out new features may make sense.  These are often the teams that look for a bi-weekly or a monthly release cycle as the changes they are pushing are often high-risk and global in nature.Back-end Services Teams – Depending on the risk of a particular system these are also systems that can fall on either side of the release frequency equation.  For a low-risk service that supports a website it is possible that a team could achieve a weekly or a daily release cycle.  More likely these back-end teams would expect either bi-weekly or monthly releases.Mobile Application Teams – Mobile applications, especially native applications, are often released less frequently than once a week, but more frequently than once a month.  These application efforts are also difficult to coordinate with other releases because publishing a mobile app often depends on a lengthy submission process to a third-party mobile apps platform.

This is just a small number of teams but you see the variation in expectations. Front-end teams can move quickly whereas back-end teams might require lengthy preparation and lead time.  The point here is not to force all of these different teams to align and synchronize just to reduce the management burden – instead…

Cut the Cord, Achieve Independence

With a dedicated release management solution, you can support teams with a more frequent cadence alongside teams that might require a month (or even two) between deployments to production.  You do this by taking advantage of the central release orchestration features. In the case of Plutora, these include:

A Single Schedule showing conflicts and overlaps – You’ll have access to a single schedule that will identify potential overlaps and conflicts with other projects and allow you to focus on the overall picture to see how a particular release relates to all others.   This helps manage risk and release sequence across groups.An always up-to-date snapshot of release status -  One of the most common reasons for moving everyone to “one big release” is that it’s almost impossible to keep track of release status.  When project timelines slip, you’ll need to recalculate a huge matrix of timelines and dependencies. This is what Plutora takes care of.  It assembles this information from source systems and provides you with an always up-to-date picture of status.Resource allocation and reports to avoid exhaustion – You moved to a single release to make it easier on support teams. In the end, these teams still have to perform the same amount of work for a larger, riskier, monolithic release.  With Plutora, you can keep track of multiple, simultaneous releases and view their respective statuses alongside their impacts on support teams. This allows you to preserve and protect your most valuable resource – the people that make frequent software releases possible.In summary, when you use Plutora, you can start managing more granular releases because you’ve gained a window in the release status.  Without this necessary view into releases you’ll never achieve more frequent software releases.