<-- background -->
Last updated on
Plutora Blog - Release Management, Test Environment Management

How to Support Agility through Enterprise Release Management

Reading time 6 minutes

How to Support Agility through Enterprise Release

The challenge facing today’s project management professionals is supporting a more agile approach to software releases while managing orderly governance and production controls that are necessary.  Project managers have become air traffic controllers landing more projects more frequently on more runways, and as the skies become more crowded it’s important to understand both the trends and some strategies for managing the increasingly agile enterprise.

Three trends stand out in the Enterprise over the past decade:

  • IT Portfolio sizes are increasing
  • Individual projects are smaller and more agile
  • Projects are more service-oriented and increasingly interdependent

The monolithic “enterprise” project of 2001 has been broken up into separate, interdependent systems.  What was “The Website” project in 2004 is now a combination of multiple teams working together on a common platform.  While the e-Commerce team and the content management team were part of a single project ten years ago they are now running independent systems with independent release cycles.

More Teams, More Agility

The other big trend has been one of “agility.”  The term “Agile” has a specific meaning in the software development community and I’m not talking about a specific flavor of development.  When I say “agility” I’m referring to the fact that smaller, more independent projects tend to move faster than they did 10 years ago.  What once took six months to complete with a project team of 80 has now been deconstructed into smaller, more nimble groups of developers.  As an industry we’ve grown more “agile” because we’ve started to mature.  We understand the limitations of distributed systems development, we’ve all seen what happens when project teams are too large or too small, and the modern enterprise has now been tuned to operate more efficiently that it was operating ten years ago.

Distributed service-oriented architectures have been around for more than a decade. While there was a brief period of over-adoption and over-simplification we’ve reached a happy equilibrium with technology.  Our engineers understand the right mix of synchronous and asynchronous interaction patterns, and you can see every day that industry is getting better at software production.

Agile from the Bottom Up: A Tools Revolution

It’s tough to put a date on the start of this transition to more agile software development practices, but the transition to a more decentralized approach to software development coincided with the growth of the web and the influx of talent over the last decade.  The “enterprisey” norm for software projects in the 1990s has been replaced with a pervasive “startup-culture” in even the largest organizations.   Developers are empowered to deliver software in rapid iterations using the tools and techniques they find appropriate.

Decentralized source control, issues trackers, continuous integration systems, continuous delivery pipelines, and other tools that have come to define what we now call DevOps have been decades in the making, but they’ve enabled a sort of self-service approach to software creation.  We’ve optimized Agile development with a bottom-up approach influenced by the decentralized development patterns of Open Source communities.

Despite these successes in fostering a more agile approach to development, the Enterprise still faces issues coordinating and collaborating across these more agile teams. 

When everyone’s delivering on independent release schedules, when the developers feel empowered to deploy directly to production how then does the Enterprise manage risk?

Optimizing the Last Mile: Agile Software Release Management

While the nature of development has changed, the basic rules for releases haven’t.  Corporations are more risk-averse than ever, security threats call for rigorous production controls and end-users are immediately allergic to downtime.  The enterprise is still required to adhere to rigorous reporting requirements such as Sarbanes-Oxley to name just one example of a regulation that affects release management.  For all the talk of agility the last few steps to production are often anything but.

While we’ve optimized for agile software production there’s still a ways to go when it comes to agile software delivery. It’s that last mile that continues to be the bottleneck in most organizations.  The modern Release Manager has to appreciate both sides of this transition – the transition from an Agile development environment to a rigorous, risk-averse, centrally-planned approach to production releases.  The smart release managers can manage this transition without upsetting the conditions that make Agile software development work.

Back to the Analogy: Air Traffic Control Watches the Entire Flight

Release Managers frequently report that they are worried about being perceived as part of the problem – a roadblock to Agile software development in the organization.  A necessary “queue” that projects enter into toward the end of the software development lifecycle: an obstacle.  This is the reality when a release manager is asked to support too many projects without the tools necessary to manage frequent releases.

When release management becomes a bottleneck it is often due to a single factor – release management lacks adequate insight into agile software development projects from start to finish.  Instead of being able to track the approach of projects to a release they are in a constant “reactive” mode attempting to coordinate and manage complex release events as they approach release events almost by surprise.   With a tool like Plutora, a release manager is able to gain insight into projects throughout the development and release life cycle giving a release manager a greater ability to adapt, react, and orchestrate projects when more projects are expecting to perform coordinated releases.

Back to the air traffic controller analogy – a modern air traffic controller doesn’t just guide aircraft to a runway on approach there’s a whole network of radar systems and tools that allow different controllers to have insight into the progress of a flight. If a flight is late other planes can be routed in response, and if two planes demand use of the same runway at the same time an air traffic controller has the tools he or she needs to manage these conflicts.

As portfolios increase and smaller, more independent teams deliver interdependent projects with more frequency, Plutora is the tool you need to solve this intractable problem of release coordination and orchestration.  Without Plutora you’ll be managing releases through manual processes and spreadsheets.  It’s time to upgrade the technology you use to manage releases to facilitate more agile development strategies.

When you are thinking about release management ask yourself if you’d feel comfortable landing at LaGuardia if you knew that the Air Traffic Controllers were still pushing model planes around a physical map instead of using radar.  Based on what we’ve seen in the industry, project managers who don’t have a comprehensive tool like Plutora are doing just that. It’s time for an upgrade.

Share on LinkedInTweet about this on TwitterShare on Facebook

- About Plutora -

Our mission is to enable companies to manage their enterprise IT pipeline, enterprise IT releases, and IT environments in a simple and transparent manner. Learn about us or find out more about our products.

Learning More