This is part two in our blog series describing the transformation of our internal ALM development organization toward a Continuous Delivery model. The previous post was Walking the talk – Our journey to Continuous Delivery. 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.

How does Rational ‘do Continuous Delivery’?

I’ve been working for IBM for over 26 years and I’m currently the lead functional designer in charge of complex ALM scenarios on Rational’s Design team. In my career, I’ve been a developer, a development manager, and most recently a solution architect helping customers realize the value of our complex ALM solutions in enterprise, multiplatform development environments. When I was young I actually wanted to be a writer, not a software developer, so telling the story about our journey is fun for me… I hope it is useful for you!

The million dollar question… this is what we needed to figure out. In 2012, the Rational Collaborative Lifecycle Management (CLM) organization announced its commitment to a more aggressive quarterly release cycle, but as we put this into practice for a few quarters, we found that this commitment led to some challenges related to our ability (or inability) to do Continuous Delivery.

My role in this organization is as the lead functional designer for complex IT. What in the heck does that mean? After spending nearly all of my 25+ years at IBM working on complex, mainframe and multiplatform solutions and scenarios, I realized that there is one area we simply had not focused on related to complex IT – Complex Project Planning. It is with this in mind that I embraced the challenge to help the organization understand the critical role planning plays even in an agile development environment and develop the scenarios that we could ‘live and breathe’ to really prove that Continuous Delivery and DevOps are not just the latest technological catch phrases.

In April 2013, I became engaged with a small work group charged with figuring out how to ‘do Continuous Delivery’. We had some understanding about how difficult this kind of transformation could be, but did not yet fully realize how much faith would be required in reaching the end goal when we could not see immediate improvements. We wanted (maybe needed?) immediate results, immediate feedback, but this kind of transformation is more like changing the direction of a 3000-passenger cruise liner; it was as much transitional as it was transformational. It would take some time and comprise a series of baby steps, with continuous feedback on the process.

Why were we even doing this? Weren’t things working fine as they were? We were delivering software on 12-week release cycles and had been for a few quarters already with some success. Internally, though, we were struggling. The development team was under tremendous strain to understand what we promised to deliver during each release cycle, prioritize the product backlogs accordingly, and then actually deliver on time. The executive team understood what our business objectives were but could not easily determine whether or not we were on a path to succeed. In short, we had no insight into the process of driving IT investments, and the solutions delivered, from the business objectives. Business stakeholders had little visibility into the IT activities that were supposed to drive revenue based on their own decision-making, and IT organizations were struggling to keep up with changing business needs while also dealing with the day-to-day realities of software development and delivery.

Enter ‘Continuous Planning’. The idea is that Continuous Delivery encapsulates two key activities: planning and execution. And even in the context of agile development, there is a degree of agile planning that must occur in order to ensure close alignment between business and IT. Agile development does not preclude the need to have a vision and strategy for the business; it does not mean we should not plan.

In this series of blogs, we’ll be talking about our journey toward Continuous Delivery through the lens of the planning process, including both the business and IT perspectives. For my part, I hope to develop and refine the scenarios for complex project management that help drive the solutions we deliver, but also ensure our own success in delivering those solutions. This will be ‘drinking our own champagne’ in action.