Introduction

This is the first in a series of blogs describing the transformation of our internal ALM development organization toward a Continuous Delivery model. In this series, we describe the motivations behind adoption of a Continuous Delivery model and the many challenges we faced as we embarked on this transformation from both the planning and execution perspectives.

Walking the talk – our journey to Continuous Delivery

I’ve been working for IBM for over 10 years and I’m currently the Collaborative Lifecycle Management (CLM) Product Management Program Director charged with ensuring we drive our investments in CLM capabilities based on the business objectives of our organization, Rational and IBM. In this role, I am helping lead the effort toward adoption of a Continuous Delivery model for our organization and have been working closely with stakeholders from the business, design and development areas to define this process and put it into action.

Making the move from more traditional methods to an agile, Continuous Delivery model is anything but trivial. Particularly in a large enterprise organization like IBM, there are all the typical challenges associated with large scale transformational efforts. As the old adage goes, change is good. Sure, often that’s true. It’s also true to say change is hard. So, why bother? Very simple. It’s all about getting value to customers faster.

In the book “Continuous Delivery,” Jez Humble and David Farley talk about “revolutionizing software delivery by making the path from idea to realized value – the cycle time – shorter and safer”. Exactly! The notion of getting value – that is, capabilities in the software that help customers improve efficiency and productivity in their business – more quickly is obviously attractive to all sides. There’s another key concept though – safer! If new capabilities don’t work well – be that from a usability, quality or performance perspective – that will pretty much kai-bash any potential value.

Our cycle had been to deliver one big honking major release every year. It would be loaded with new feature function. Great! Potentially a ton of new value! But wait, it’s not all champagne and roses. All that new feature function puts an enormous amount of stress both on the organization delivering the software as well as the organization adopting it. So much new stuff to test, so much new stuff to learn, probably a lot to migrate with potential architecture changes, database changes, and so on. That’s not all. There’s another problem. As a customer, if there’s something new I want I’m going to have to wait a long, long time. Say I think of something right after the new release comes out. At a minimum I’m going to have to wait a year. If it doesn’t make it into the next release we’re looking at two years. In an age where we’re all accustomed to Smartphone and web-based apps updating in seconds on a monthly, weekly or sometimes daily basis, this just doesn’t cut it.

There’s another aspect of this that doesn’t get as much attention in discussions about agile methods or continuous delivery: business planning. The focus, understandably, is on getting from ideas to realized value as quickly and safely as possible. In my role, I tend to focus on those ideas. What’s the right idea? For anyone with kids, we all talk to them about making “good choices”. In a complex, dynamic rapidly moving highly competitive market, making the right choices is obviously critical. It’s often said that to be agile is not to spend too much time planning. One analogy I’ve heard is that it’s akin to throwing a bunch of stuff in the washing machine, watch it turn for a while, and then hope you like the way things come out. That got a good hearty laugh from a number of executives in a business review I was participating in a few years back. Just as you would not do that with your life savings, no organization is going to do that with their investments. And of course that’s not what’s meant by “no planning”. That “no planning” is about not spending weeks or months putting together project plans with highly detailed Gantt charts and documents and slide decks showing exactly what will be delivered when. Many years ago I worked with a guy who would literally print out about 20 pages of Microsoft Project and tape them to his cubicle wall for everyone to look at. No one did. Once a week he’d make adjustments, print them out, and update the tapestry. Still no one looked. I mean no disrespect to project managers (or MS Project by the way). Certainly we’d be lost without ours! Just trying to make the point about what kind of planning we’re talking about. But I digress. So back to making the right choices.

We, like most business organizations, spend a lot of time talking to customers, doing market analysis, competitive analysis, cost-benefit analysis and so on all with a very simple goal: where are we going to get the best return for our software investment dollars? What will deliver the most value for our customers? No software delivery methodology is going to change that. Where Continuous Delivery can help is twofold. First, as discussed, is in terms of getting that value, and subsequently the return, more rapidly. The second, is to help with understanding exactly what is being delivered and when. As a part of our transformation to Continuous Delivery, we’re spending time to instantiate clear traceability from a set of business objectives all the way through to backlogs and release plans. With DevOps that extends out to build and deploy. Not only will we know what’s been delivered, we’ll be able to get instant feedback. Is it yielding the value we intended? As a product manager who focuses on the business side of things, this is my part in the continuous delivery transformation. Specifically we’re using Rational Focal Point to capture key business data that we use primarily for prioritization purposes. That then maps over to requirements management and change management for specification detail, design documents, backlogs, release plans and so on. I’ll be blogging mostly about our journey on the front end of the lifecycle, and how we are able to trace that all the way through to build, deploy and customer feedback.