Enterprise Release Management Tools: Plutora

Introduction

image3Enterprise Release Management is an increasingly prominent discipline, occupying the intersection of technical release management, project delivery and change management. Its focus is on understanding and governing the full portfolio of multi-stream changes, be they quarterly ERP releases, one-off project deliveries or monthly patching.

The demands on enterprise level release managers are many: governing and managing individual releases, maintaining the forward schedule as far as 12 months ahead, making sure non-production environments are efficiently used and more. Most release managers will have built and refined an array of spreadsheets and calendars to manage everything from release scope, defect lists, release gateway checklists, cutover plans and forward schedules.

Spreadsheets and calendars can work perfectly well when there are only half a dozen releases to track across 2-3 test environments, but once this starts scaling up – especially with multiple release managers – keeping these spreadsheets up to date becomes an administrative challenge and resource drain, letting inevitable errors creep into manual processes.

This is the tipping point where dedicated Enterprise Release Management tools make their case. The initial benefits are obvious: moving spreadsheets online to offer a single version of the truth slashes administrative waste and allows for pivoted views of the same data. Common tasks or release governance structures can be defined and re-used.

Clever reporting can replace hours of spread sheet and Powerpoint wrangling with the click of a button, and this is only scraping the surface. In this review, we’ll see what else leading vendor, Plutora, has built into their tool to add some real intelligence into the process far beyond simply lifting and shifting a spreadsheet online.

Quick facts & review highlights

Version Reviewed

Plutora V 3.5
October 2014

Market focus & customer counts

Large/very large IT organisations with a strong or dedicated project delivery arm who are presently struggling with visibility of their forward release schedule, environment utilisation or quality of repeatable release activity.

Customers:

  • USA: 18
  • EUROPE: 8
  • ASIA PAC: 15

License Options

SaaS licenses available in packs of 25 or unlimited enterprise option.

Competitive Differentiators

  1. Purpose-Built and Comprehensive: Plutora Enterprise Release Manager enables all of your end-to-end release management processes out of the box. Plutora is differentiated with its capability to combine release management, test environment management, deployment management and self-service reporting in a single comprehensive tool.
  2. Enterprise SaaS: Plutora is 100% SaaS to ensure rapid implementation and adoption of the solution within your organization. Plutora scales in the cloud to meet the growing complexity of your organization as teams become increasingly distributed.
  3. Vendor-neutral integrations: To provide a unified view across all your releases, Plutora integrates seamlessly into your landscape with an open API and adapters to your existing Project Portfolio Management, Application Lifecycle, Quality Management and IT Service Management tools.

Products

  • Plutora Enterprise Release Manager
  • Plutora Test Environment Manager
  • Plutora Deployment Manager

We think Plutora is stronger in…

Conversion of simple, powerful & common tools frequently used (and easily recognised) by release managers into a web application and expanded to make the most of pivotable underpinning data.

Strong & flexible presentation of critical information, both from pre-configured views & reports, and user-built reporting.

Powerful deployment management command & control function.

Clever system impact matrix with regression-test flagging.

We think Plutora is weaker in…

As a release-focused tool, less emphasis on non- transition related IT Service Management information may mean release decisions are taken in isolation and solved problems are not learned. Plutora offers the ability to add customized data fields and comments for non-transition related information.

Not aggregating change/feature resource cost into release-level capacity monitoring (and instead doing this manually) feels like a missed opportunity.

Some medium-sized IT organisations do not have 25 users, Plutora’s minimum license. Less focus on technical release aspects such as build/integration tooling, though this is on the feature roadmap.

In their own words…

Plutora’s purpose-built SaaS solution for Enterprise Release Management, Test Environment Management and Deployment Management enable you to manage complex application releases with transparency and control. Using Plutora, organizations can deliver higher quality software more frequently to meet customer demand with no impact on downtime.

Plutora ensures high-quality, on-schedule releases by driving enhanced enterprise collaboration and coordination for all key elements of a successful release: timing, composition, status, and stakeholders across their lifecycle – with ease. Real-time dashboards show release schedules and how they are tracking according to governance gates within the release framework.

Plutora provides a unified repository for all release information where users can source data, including project dependencies, without needing to piece together the shape of a release from multiple sources. Plutora integrates with your existing IT management tools to ensure that no data needs to be manually re-entered by users.

Customers

Over 30 enterprises across the globe as of March 2015, including Telstra, ING Direct, Boots UK, News Corporation, and GSK, manage $5 billion of releases using Plutora.

About this review

This was an unusual review, since Enterprise Release Management is an emergent discipline, combining both technical release management and project-delivery capabilities, but with an operational focus.

As an emergent discipline, there are no standard ways of dealing with the inherent challenges in this field, so the assessment of quality comes both from a mixture of judgements made during the review, in-depth use* and trusted industry awards. In this last category, Plutora has pedigree: named by Gartner as ‘Cool Vendor of the Year’ in 2014.

This review was written on the basis of a maximum 2 hour demonstration of the 5 key capabilities by each of the vendors. It is not exhaustive, and some capabilities which you especially require may be present in the tools but not covered in this review. As such, if you believe that Enterprise Release Management tooling is appropriate for your organisation, it is worth speaking to Plutora to ascertain best fit for your specific objectives.

*and thus not part of this review

Assessment Criteria

  • Tracking and managing a release with repeatable & templated processes
  • Tracking the entire release portfolio and presenting this information to diverse stakeholders
  • Managing resource and environment usage
  • Using data inside or connected to the tool and built-in intelligence to help inform release activities.
  • A single tool to remove reliance on spread sheets, calendars or manual processes.

Functional Review

Plutora is purpose built to enable end-to-end release tracking in a single solution. It comprises 3 modules: Enterprise Release Manager, Test Environment Manager and Deployment Manager.

A release in Plutora comprises a number of customer-specified phases that focus on their respective exit gates, and each has a checklist of activities or exit criteria a release manager would need to have completed before moving to the next. For example, a ‘QA’ phase exit gate would be reliant on, say, Completion of Functional Testing, Completion of Performance Testing and Signed Off Test Completion Report as activities required to move to the next phase.

Once a release ‘model’ has been built using these phases and checklists, it is then very easy to clone this to a new release. According to Plutora, many of its customers prefer using this cloning approach to template their releases rather than building dedicated theoretical templates which may themselves require overhead to manage and keep up to date. The cloning approach allows a maturing release management organisation to learn and adapt quickly to changing situations – taking only the elements they know work and evolving them organically.

Additionally, some customers of Plutora also use this cloning feature and general checklist features to build operational maintenance checklists – so, although the tool is heavily targeted at the change delivery side of the organisation, it can also be of significant benefit to operational and technical maintenance functions.

The templating and checklist functionality doesn’t stop there. Implementing a release is another area often devolved to shared spreadsheets, but Plutora delivers not just a single-source-of-truth replacement for these spreadsheets, but in Deployment Manager a clever, real-time command and control capability to let a single release manager monitor, trigger and track deployment steps in multiple releases simultaneously with internal or external delivery teams.

Once the work has been put into ensuring that the individual releases are accurate, the aggregate view starts to take shape and provide value. The Plutora Enterprise Release Schedule provides a tailored view of all releases. The schedule can be detailed, showing all phases, gateways and environments, or quickly summarised into a powerful senior stakeholder view. The schedule also supports diverse delivery approaches, whether agile, continuous delivery or more traditional waterfall as well as the simple operational checklists mentioned earlier.

However release management tooling is not just about visibility of the release schedule or implementing releases effectively. Plutora has two additional features, the release capacity planner and the systems impact matrix which add data-driven intelligence to release management.

The systems impact matrix is a simple-seeming view of dependencies between systems and releases. This on its own is a useful tool, giving a summary of which releases touch which applications. But the really clever bit is how Plutora not only identifies which systems are being touched by the release, but which linked systems are also impacted thus needing a regression test. This feature alone could make the business case to purchase Plutora.

The release capacity planner is also a useful feature. It allows release resource ‘containers’ (eg. number of test cases) to be specified and tracked in an accessible and easily summarised view, letting release managers clearly articulate release capacity. However my only major criticism of Plutora is that this capacity specification is manual and performed by the release manager. Since many ALM tools with which Plutora can share data (eg. Jira) can contain the development & test effort within their own records, it would seem logical for Plutora to take in this change-level data and aggregate it into a total release effort measure (adding extra overhead as necessary for release-level activities). The overall size of the release container can still be defined by the release manager, but the usage of each container could, and in fact should come from the individual change/feature records, and Plutora doesn’t do this. Despite this, the capacity tool is still incredibly useful for discussions with the business about setting realistic delivery expectations and customized fields can be added to incorporate additional information relevant to the release management process.

The last core area of functionality is test environment management. Test Environment Management in Plutora is fairly tightly coupled with the rest of the release functionality in planning and executing releases, but there are a couple of additional features worth noting.

Plutora contains an environment request and approval tracking system to allow projects or releases to book time in specific environments. Combined with the system impact matrix described above, Plutora’s ability to ingest data from external configuration/discovery tools and the ability to define complex environment groups of related systems makes for a powerful management suite to make better use of non-production environments.

The Test Environment Manager also has its own version of the release schedule (but from an environment-centric view) and likewise can be used to easily identify & articulate over or under utilisation at a glance. In addition, by specifying those stakeholders within the tool and enabling message broadcasts, clashing stakeholders can be made aware of contentions and work to resolve the issue.

This feature actually extends throughout all of Plutora. Stakeholders, systems, organisations and more are specified when initially configuring the tool and message broadcasting can be selectively activated at release or environment level.

Finally, reporting. Plutora has obviously invested considerable time and effort in getting reporting right, with pre-configured single-page overview reports providing real value to release managers as well as keeping senior stakeholders happy. The reporting dashboard is also configurable, allowing release managers to build graphs and displays from data within the system and then combining these into a personalised dashboard. This isn’t revolutionary functionality, but it is solid and well executed in Plutora.

Verdict

Enterprise Release Management tooling is ostensibly about removing the array of spreadsheets that proliferate to manage scope, timelines, environment usage and cutover plans. Plutora not only does this exceedingly well, its also used the opportunity to add some intelligence and polish to the tool to make people’s lives easier and improve the quality of the release passing through it.

Plutora is the tool one release manager would build for another. Plutora has taken existing practices, made them collaborative, structured and business-ready, then extended them to both pre-empt and answer the most common questions asked of release managers or that release managers ask of themselves.

Feature by Feature Summary Scoring

Tracking and managing a release with repeatable & template processes ★★★★
Tracking the entire release portfolio and presenting this information to diverse stakeholders

★★★★★

Managing resource and environment usage ★★★★★
Using data inside or connected to the tool and built in intelligence to help inform release activities.

★★★★

A single tool to remove reliance on spreadsheets, calendars or manual processes.

★★★★

Scoring Key

★★★★★ – Advanced features well developed

★★★★ – Advanced features present

★★★ – Solid coverage of basic requirements with some additional/advanced features

★★ – Basic requirements covered, some less thoroughly than expected or with minor gaps

★ – Not all basic requirements, significant gaps

Last words

Plutora is the tool which, in the reviewer’s opinion, embodies the term ‘Enterprise Release Management’.

It will work well in busy, large IT organisations and whilst it has a place in supporting operations, it feels targeted firmly at the development/delivery side of the IT organisation where teams of project managers, release & environment managers and more can collaborate with tooling they already instinctively know how to use.

Appendix – Screenshots

DISCLAIMER, SCOPE AND LIMITATIONS

The information contained in this review is based on sources and information believed to be accurate as of the time it was created. Therefore, the completeness and current accuracy of the information provided cannot be guaranteed. Readers should therefore use the contents of this review as a general guideline and not as the ultimate source of truth. Similarly, this review is not based on rigorous and exhaustive technical study. This is a paid review. That is, suppliers included in this review paid to participate in exchange for all results and analysis being published free of charge. The ITSM Review © 2015.

Simple steps towards Agility and Service Management improvement

Dead as a...

There have been many hundreds of words recently written on the subject of Agile Development and IT Operations practices. For the average ITSM practitioner, however, a life where both are interwoven into the organisations day-to-day work seems as unattainable as ever.

Sure, you might work for one of the few organisations that practices DevOps. If so congratulations… you’re one of the cool kids. Maybe you picked up a copy of “The Phoenix Project“** and the authors words resonated with you.

“I should start introducing Agile and Lean concepts into my IT organisation”

It’s not as if these words have fallen on deaf ears as such – it’s just that most ITSM practitioners are struggling to join the dots in their head, not even able to mentally apply Agile/Lean/DevOps to their own environments.

It’s hard to see how you get from your current position today to a position of continuous delivery and business agility, along with the bragging rights on Twitter about how great your aligned development and IT Operations organisations are.

You now want to improve… So what can you do to get started?

I have two quick tips for those IT Operations folk that want to start taking steps towards Agility and Service Management improvement. These tips won’t transform your IT department overnight but they are both cheap and easy to implement (in fact you could do it this week).

Tip number 1: Hold retrospectives

The most valuable skill of a good Agile team is the ability to self-learn. Self-learners have a habit of looking at their performance as a team and can identify positive and negative characteristics from their recent behaviour. By learning from past experiences they pledge to improve in the future.

The mechanism for Agile teams to drive improvements is to hold regular retrospectives.

A retrospective is a time boxed activity (a meeting) that is held at the end of a period of work, or in Agile-speak an “iteration”.

Development teams often work in regular short bursts of work called “sprints”, which in my company are always two weeks long, therefore we hold retrospectives on the last day of each sprint.

IT Operations work is not normally neatly defined in two week iterations – you tend to deal with KTLO work (Keep the lights on – Incidents and Problems) and perhaps projects. However, you should avoid the habit of only holding retrospectives to find improvements at the end of projects or when things are going wrong.

If you want to take a few Agile steps in your IT Organisation my advice is that you open your calendar application right now and setup a recurring meeting for your team that lasts for an hour every two weeks. Take this time to review work from that two week period and identify improvements.

Build self-learning and improvement sessions into your schedule. Don’t leave opportunities for improvements to project post-mortems or to when things have already gone wrong.

So what happens in a retrospective session?

Firstly, it should be a facilitated session so you’ll need someone to lead the team, but this isn’t a daunting task (OK – it is the first time you do it but it gets easier after that). Secondly, it’s a structured session rather than an hour to ‘bitch and moan’ about the Incidents that came in during the last two weeks.

Retrospectives are structured meetings with a clear objective – not a general conversation about performance

The objective of a retrospective is to get a documented commitment from the team to change one or two aspects of their behaviour. Documenting these commitments is covered below in tip number two.

Changing the behaviour of a team is absolutely not as challenging as it first seems, people only need a few things to happen to change their behaviour: to have their opinion heard; to be able to commit to the change; and to be held accountable. The format of a retrospective allows for all of this.

Also with retrospectives we don’t focus purely on examples where things went wrong. I’ve been in many retrospective sessions where teams have focused on unexpected success, have researched the factors that contributed to that and committed to spreading whatever practice caused the success to a wider organisation.

Identifying what worked well for a team in the previous two weeks and pledging to repeat that behaviour is just as powerful as pledging not to repeat negative behaviours.

I mentioned that retrospective sessions are structured. This really helps, especially when a team starts out on a path of self-learning and improvements. The structure holds the meeting together and guides the team to its objective for the meeting – validation of existing working agreements and proposals for new working agreements.

Esther Derby and Diana Larsen, who both inspired me to focus on retrospectives with their book, “Agile Retrospectives: Making Good Teams Great“ describes the structure for retrospectives very well in the SlideShare presentation below. Take time to study and implement their meeting structures.

What should the meeting structure look like?

The recommended meeting structure is as follows:

  • Set the stage

  • Gather data

  • Generate insights

  • Decide what to do

  • Close the retrospective

Each element in the meeting agenda is an opportunity for the facilitator to engage the team and run exercises to uncover what worked well (to be repeated) and what did not work well (to be avoided).

By structuring the meeting and facilitating people through the process you avoid the temptation for people to use the time simply complaining and placing blame for things that didn’t go well.

The meeting structure drives the retrospective towards its objective – an actionable set of Working Agreements for the team to use.

Tip number 2: Use Working Agreements

In a previous role in IT Operations and support I often felt the sensation of “spinning plates”. As soon as we could put one fire out another would flare up. Our problems as a team were that different people worked in different ways which is a real problem in Infrastructure teams.

My solution at the time was to try and write an all-encompassing “rule book” which described how we as a team react to any given circumstance. We’d build this “rule book” up over time and end up with a comprehensive document to remove confusion on how to perform work.

I’m sure you can imagine the outcome – we started.. we didn’t get that far.. as soon as the rule book was of any decent size it became out of date and unwieldy.

What my team then really needed, and the way that my Agile development team now works, is to have a lightweight document explaining the rules of the road. We call this document our “Working Agreements”.

What should Working Agreements look like?

  • They should be small enough to fit on a single side of A3 paper

  • Agreed upon by the team

  • The output of retrospective sessions, worded to enforce good behaviour or to prevent negative behaviour

  • Should be reviewed during each retrospective – do we need this Working Agreement now or is it part of our standard behaviour.

  • Should be very visible in the area

Having a lightweight set of agreements that the team commit to and that are reviewed regularly are a great way to drive cultural and technical changes that actually stick! Rather than review meetings that mean nothing once the team leave the room.

In summary

Driving improvements to a team means you are trying to change peoples behaviour which is never an easy task. Teams will change if some basic needs are met. They need to be listened to, they need to commit to the change and they need to be held accountable for future behaviour.

This is possible in your IT Operations teams today – hold regular retrospectives to identify what works and what does not. Get the team to commit to working agreements which are agreed by the team, meaningful and visible.

Let the improvements commence!

** If you didn’t nod when I mentioned The Phoenix Project then you aren’t one of the cool kids and you better find out what it is… pronto!

Image Credit