The Full Monty: the Continuous Delivery Business Case at Scale

My ThoughtWorks colleague Rolf Andrew Russell recently pointed out on our company intranet that there are implicitly two definitions out there of the agile manifesto's principle of "continuous delivery of value":

• "'technical' CD - the stuff in [Jez Humble and Dave Farley's book, Continuous Delivery].  minimizing lead time from code check-in to production."

• "'business' CD - what we sometimes call the full monty.  minimizing lead time from idea to production and then feeding back to idea again."

He further observed, "When a business person or executive hears the term 'continuous delivery' they naturally interpret it as the latter.  And this makes sense because 'business' CD speaks to the true business value and encompasses 'technical' CD.  But 'business' CD is way more than just the devops stuff.  It is changing the way XD, PMO, analysis, etc, work, and minimizing their lead times."

And yet it's still hard to find a list of the practices a CD-oriented person should follow if she is not a developer or QA, but is instead an Agile user experience designer, program manager, product owner, or business analyst.

Technical CD

But let's start with "technical CD."  What is that?  We've been very excited lately at ThoughtWorks about the concept of technical continuous delivery, championed by Rolf as well as Jez Humble, Martin Fowler, and TW alum David Farley.  Supported by a practice called "Continuous Deployment," this concept captures the imagination especially if you're in a corporate IT department, because you picture a world where not only can you have software teams WRITE software quickly, but you can also have them DEPLOY quickly and safely to production.

Perhaps you live in a world where you've managed to set up a hyperperforming agile team, and you've started delivering small chunks of tested software to your pre-deployment environment every two weeks.  Your users are delighted, even though your well-tested software has to sit in a QA holding bin for a week before it moves laboriously to the UAT testing server, and from there, in ponderous splendor to production.  Months have passed, and a small startup in Albuquerque is already making money on your concept, except in version 3.0.

Now picture that you can put that software into production at will, even ten times per day.  And it's perfectly safe, because you can decide later whether you want to turn new functionality on or not.  And you can even be ITIL compliant.  That is a beautiful dream vision for many of us, and CD is consequently and justifiably quite popular.  Jim Highsmith built this wonderful diagram to show how you might progress from agile development practices to "continuous integration" (frequent check-ins to main and builds), and from there to "continuous deployment", and the accompanying strategic impact to be derived from this progression:

From http://www.jimhighsmith.com/2010/12/22/continuous-delivery-and-agility/strategic_continuous_delivery/

But note that introducing "technical CD" into your environment only gets you from development kick-off to operational deployment.  Although your IT department is now building software "right" in a big way, how do you know that you're building the right thing?  That's what brings us to:

Business CD

What would the "continuous delivery business case" look like?  I think you can look at this from (at least) two perspectives:

1. CD powers the lean startup.  As Jez Humble points out in this InformIT article (and elsewhere), continuous deployment enables what Eric Ries calls "the Lean Startup."  Within the development cycle, agilists have speeded things up considerably by eliminating "Big Upfront Design" (BUFD) in favor of a general design plan whose details evolve to fit the customer need.  Analogously, the Lean Startup calls for eliminating the Big Upfront Business Case (BUFBC) in favor of a general vision and strategy, followed by a series of small experiments which lead to modifications in both the strategy and the resulting software as you go.  Because the Lean Startup comes equipped with CD developers and QAs, it could be 20 minutes from the time a software behavior is requested to the time it is deployed in production to a controlled subset of the software's user base.  What this means is that:
2. Business-side counterparts of CD technical practitioners must therefore be skilled entrepreneurs:  Ries's book provides this diagram for the business side of CD:

   

   Image taken from: http://gumption.typepad.com/blog/entrepreneuria/

   Business-side CD practitioners need to be people who can identify what Ries identifies as the value and growth assumptions in their business cases, devise experiments to test those assumptions, starting with the kind of very small experiments developers can build and deploy quickly, the ability to interpret the data, and an ability to pivot the strategy to allow for the next round of experiments.

What does that mean for today's corporate PMO director, product owner, business analyst or user experience designer?  That answer isn't obvious, but let's take some solace from the fact that the best "traditional" software architects were delighted to descend from their ivory towers and start making software prototypes instead of writing vast theoretical documents.  The best build and release technologists were happy to become specialists in designing and building deployment pipelines instead of sweating with hardware and firmware "surprises" under pressure.  In the same way, the best business-side people who interact with software development have an opportunity to stop making huge, unjustified bets based on risky assumptions, and instead build up excellent and well-grounded business cases. 

So as you put your next agile pilot together, think about your reforms starting at the idea phase, and your business case evolving right along with the software--cost of change is now quite low.  You can and must do experiments that fail in order to feel confident about the strategy that succeeds.  Sure, it's scary, but it's also tremendously exciting, and it can't be done by technology alone.  This is management, analysis, and design stripped to their essence.  (But you can leave your hat on).