How Compuware shut off the waterfall approach to development and became a DevOps convert

I recently saw a fascinating little cameo of what is likely to become a trend in the IT business, especially amongst the vendor community. One could almost be rude and label it as an outbreak of growing up, for it involves DevOps – an area where the ability to speak `tech’ is both vital and paramount.

Yet at last week’s DevOps Enterprise Summit in London, the opening keynote sessions were notable for the lack of tech content. Mentions of new software technologies, development methodologies or applications development tools was right off the agenda.

Instead the dish of the day set out to address a far more important issue – why should anyone bother with any of it in the first place? What, in simple terms, is the business justification for any of it?

One presentation in particular stood in this context, for it sought the views of two people at the top of their particular C-Level management tree. These are the type of people DevOps activities hope and pray will buy into the notion enough to at least be openly supportive. There’s however, is a story where the main man was not only supportive, but the leader of the charge.

Chris O’Malley is CEO and Joe Aho is CFO at mainframe software tools developer Compuware. They were not the type of people one expects to keynote at a Dev/Ops conference, but the choice was sound. But a year or so ago the company started to introduce DevOps development models into its own business, and who better to report back on what came of the exercise.

Yay and nay

Their story is worth considering as an object lesson on DevOps implementation, not least because the pair make a classic combination: O’Malley was the incoming CEO full of ideas on how to turn round a gracefully declining business, while Aho was the five-year incumbent CFO broadly convinced that such new ideas were never likely to work.

Compuware was indeed declining gracefully. As a producer of software tools and applications for the mainframe market, it was stuck with the annual cycle of producing maintenance updates for existing products. It had, however, not produced a genuinely new product for some 15 years. It was also losing customers.

O’Malley introduced a two-pronged approach to turning Compuware round. Part one targeted the business operations themselves, all of which were performed in-house on legacy systems. They went out, to be replaced by a root and branch move to the cloud based on Salesforce and Netsuite services:

Infrastructure management can be a distraction that brings no value. We needed to get people to believe they could deliver more value. Essentially, I ripped the guts out of the company, re-assembled it and nobody died.

Some of the legacy hardware did, however, and he told how he used their departure for recycling to hold funerals for them as part of signalling the cultural change and the need to be together as a team.

The most dramatic change he introduced, however, was to turn the software development regime on its head. Instead of there being an annual maintenance update that customers could expect, the edict came down that the company would produce new products and features every 90 days, and that development teams would start working in two-week sprints. The old waterfall development approach was banned at a stroke.

CFO Aho was more than a little sceptical at these suggestions. He felt that neither the marketplace nor the developer staff would take it. To be fair, a few of the developer staff did not take to it, especially some of the older ones who had been with the company for years. The other side of that coin, however, is that moving to a scrum-based, agile development methodology running two-week sprints has attracted in new developer blood into the company.

For example, according to O’Malley one of its star scrum masters is only two years out of college, but already developing new tools and features that the mainframe marketplace is keen to buy – a change that ran firmly against the accepted wisdom of both the mainframe user community and the tools providers such as Compuware. It had all become cosy, familiar and predictably circular:

The customers seemed content with buying regular maintenance upgrades because it seemed that was all we could do, and we didn’t try and do anything new because all they seemed to want was regular maintenance upgrades.

Now the company is running regular, regional customer advisory councils where customers get to input ideas and requests for new features and capabilities and, according to O’Malley, sales are now `going through the roof’:

The customer response has been great. Existing customers are buying more, and we are now starting to attract new customers, which is not common in the mainframe business.

This process is also building a backlog of new developments and features with good prospects out in the marketplace with, as he puts it, customers `tapping their feet’ waiting for them to be delivered. This growth in demand for more features, coupled with the two-week sprints and 90-day release cycle, is making working as a developer attractive for the incoming young:

We need to treat our developers like athletes and keep nudging them towards always doing better each time. We measure everything we can about their performance, for gaining improvements in overall performance is that game of continually seeking small, marginal improvements. Compuware is a technology company, and techies want to solve customer problems. If they believe they can do that they get on-board.

This does not mean everything has been plain-sailing of course, and he acknowledges there have been set-backs with some of the products they have delivered. Indeed, he mentioned that the very first product of his new regime ended up `laying an egg’. But with the much closer customer contact part of the 90-day launch cycle, hitting the sweet-spot of what customers need is getting much better.

O’Malley’s story is something of an object lesson, if only because those pushing their businesses towards the agile/scrum/DevOps/sprint model are so often advised to get top-level buy in and support. Here is a CEO leading the charge and taking what he readily acknowledges as a gamble:

I knew I was strapping a target to my chest and telling everyone, if you want to hit it, just don’t do what I am asking. But I also told them that if they did not throw out the waterfall approach the mainframe era would be over.

Now it is adding new mainframe features and capabilities at a steady clip, with the latest – new zAdviser analytics tools that enable development teams to significantly improve mainframe software quality, velocity and efficiency – breaking cover just this week.