This is the fourth installment in our blog series describing the transformation of our internal ALM development organization toward a Continuous Delivery model. The previous post was From ‘use what we sell’ to ‘practice what we preach.’ 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 Prototype to Practice

The last time I reported on our journey to transform the way we plan for Continuous Delivery and execute successfully, I poked at my underlying motivation for taking on this challenge. Quite simply, as the lead functional designer for complex IT solutions, I wanted to practice what we preach to customers. Just like actors tackling a challenging role for an upcoming movie who might do a ride-along with law enforcement or drop 50 pounds or hang out with the real life person they are portraying, I wanted to live and breathe the roles involved in business planning and execution. I wanted to feel what you all feel, struggle as you do, and find ways to solve real problems along the way. I can’t say it’s been fun really – I feel for you! But I have learned a ton through my experience. In this blog, I’ll talk about how we started, where we’ve been, where we are now and where we are headed.

We approached this transformation project in a careful, methodical way, starting with concrete goals and an understanding of the roles involved, describing a taxonomy and artifact flow, investigating industry-standard best practices and methodologies such as the Scaled Agile Framework (SAFe), and prototyping how the planning process might work. Just like other enterprise organizations I’ve worked with, ours is full of really smart, highly technical skeptics. We couldn’t just say we would make their lives better – we had to prove it! That’s fair.

So let’s start with the goals:

• Drive IT investments from business objectives and prove it
• Get out of spreadsheet hell
• Be an example for our customers

Did I say we wanted to get out of spreadsheet hell? Honestly there is no way to drive IT investments from business objectives — and prove it — based on days- or weeks-old information gathered through emails and in hallway discussions. No offense to the data gatherers – it is what it is, but when you are charged with delivering software on a 12-week release cycle, that process just doesn’t fly.

Next, the roles. We are trying to gain the mind share of our business decision makers and technical leaders first and foremost, so we focused on these roles in our organization as our “customers”:

• Business Owners, Development Directors – These roles are primarily on the front line, describing our organization’s  vision and strategy, along with the roadmap for when we might deliver which capabilities. Representing multiple domains across the set of industries we support, these roles also oftentimes have differing requirements that compete for the set of IT resources available.
• Program Managers – This role represents managers on both the business and IT sides of the software delivery aisle, working collaboratively to steer the agile teams toward a common business goal while also helping them adjust to the rapidly changing business and market demands. People operating in this role are charged with executing on the business vision, managed via a single Program, or solution-level, backlog of execution items.
• Product Managers – This is a business role working with Program Managers and Product Owners aligned on a common vision. Program Managers have content authority over the business capabilities we deliver to customers and prioritize the backlog of requirements to deliver those capabilities.
• Product Owners – This role is technical, typically represented by a Chief Architect guiding teams that are charged with delivering features in products to support the solutions. Product Owners have content authority over the user stories that define those features delivered by products and prioritize the backlogs at the team level.

For all of these roles, the goal of our new continuous planning process is to provide visibility into the complete set of business level requirements and the capacity we have in IT to deliver on those requirements. Bottom line: we need to arm the business with real time planning information so that they can make informed decisions about priorities.

Enough rhetoric already, where’s the beef?

Are you ready for some details? Let’s explore the taxonomy of artifacts that we manage in this process.

This is not meant to be the holy grail of business planning and execution but it has served as a good starting point for our prototype and we use this image constantly to communicate our vision for transforming the planning process. The important aspect is not what we call things, but what they mean, although we have tried to stick to some industry-standard terminology. In this image, you can see the design artifacts that are key in our process along the right and the refinement of business objectives through the solution level and down to product artifacts that define what we deliver. The scope of these artifacts can be assumed by the timeline, which is our expectation of how long it might take to develop and deliver solutions.

Based on this taxonomy, we prototyped our planning process using our own tools. At this point, we had to deal with some challenges related to tooling and infrastructure – the logistics. We already had work in progress, and 12-week release cycles are very short with little toleration for changes in plans, much less changes to the “systems” used in to manage the work. Like many enterprise-level organizations, we have multiple products, each with their own project planning environments and their own processes already in place. Each product has their own backlog of work to prioritize within the release cycle, but we also had multiple cross-product, or solution-level, backlogs to deal with. There were other environments to manage business-related artifacts, requirements and test, not to mention build and deployment. To ease the transition, our intention was to be additive as opposed to transformational, taking advantage of our tools along the way, wrinkles and all. The image below shows where we have landed in terms of managing the artifacts using our tools.

Our current effort is focused on establishing the CLM lifecycle project in the middle of this picture to capture solution level information. This is our bridge between business planning and IT execution and provides us with a management and reporting “layer” to inform all of the roles I described above.

We have just started phase 1 of the transition from prototype to practice and have a lot of work still to do, but we expect this first step will enable us to make progress on the initial goals of providing visibility into the business objectives that drive the delivery of end-user capabilities and proving it without spreadsheets… okay maybe with less spreadsheets.