This is part three in our blog series describing the transformation of our internal ALM development organization toward a Continuous Delivery model. The previous post in this series was How does Rational ‘do 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.

From ‘use what we sell’ to ‘practice what we preach’

Agile purists might argue that ‘planning’ and ‘agile’ do not belong in the same sentence. Maybe… if you mean traditional planning as part of a traditional software development and delivery lifecycle in which there is a long planning phase, followed by a long requirements and design phase, followed by a long development phase, and then maybe some testing.  Been there, done that. Sometimes it works, especially for software that has been around for decades with a slow rate of change. This is definitely not characteristic of Rational’s Collaborative Lifecycle Management (CLM) solution. Our customers expect more, better, faster. But I’m not talking about traditional planning.

As part of the Continuous Delivery work group kicked off in April 2013, I was charged with helping the team transform how we plan for Continuous Delivery in the CLM organization. Really? Plan in the context of Agile development? How does that work? The fact is that, even when you have embraced agile development methodology, and especially for development and delivery of complex enterprise software, you must plan — plan for success, plan for meeting business objectives which typically span multiple years, plan for delivery of capabilities that bring real value with each and every 12-week release. Plan at the business solution level. This is not your grandmother’s planning process.

With me so far? Okay, at this point we had a general idea about what needed to be done, but nothing concrete, no real plan for how to plan. With my designer hat on, I thought about the DevOps scenarios, drawing from the work my team has done over the past several months to define these scenarios with feedback from customers. I thought about the roles involved in our organization and what activities they would perform. I am a designer, but I became a user, and this process was like a hall of mirrors: at the same time that we’re trying to deliver complex project management capabilities to our customers across many solution domains, we also need to do this ourselves internally to manage our own complex projects. I would be providing my own user feedback, and engaging the Rational business executives, as users, to provide feedback as well.

This opportunity was really exciting to me. Not only could we succeed in providing the business stakeholders with visibility into how their decisions would impact the delivery of IT solutions, but at the same time we could ultimately adopt a better planning process that would help us deliver those solutions, taking the old adage ‘use what we sell’ to a higher level. Now it is all about ‘practice what we preach’!

Designing the Continuous Planning Process

Now that we had an approach, it was time to put it into practice. The first thing we needed to do was understand the roles in our organization that played a key part in the overall CLM solution planning process. Who were they? What did they need? What activities did they engage in? What questions did they need answered?

We started by asking ‘What would Dibbe (Edwards, Vice President of Rational Development) need to know?’, and came up with an initial set of questions she would want answered:

• What is being done in the current release cycle related to prioritized business tactics?
• What is not being done for prioritized business tactics?
• What is prioritized in the next release cycle at the product level that is not related to a prioritized business tactic?
• Where are the gaps in our proposed capabilities to be delivered in the next year? The next two years? The next three years?
• What areas of the ALM solution do we anticipate the need to grow resources? Next release? Next year?
• How confident are we that the capabilities we are delivering will meet customer needs? This year? Next year?
• When can we deliver business capability X and what will customers be able to do with it?
• When can we demonstrate our planned capabilities to customers?
• What happens to existing schedules and deliveries if we change plans?

If we could help Dibbe answer these questions, it would be a great start! In the next blog, I’ll talk about how we grew the design of the continuous planning process from this premise and gained momentum as other business stakeholders saw our idea and began to get really, truly excited about just having the visibility they did not have before.