Skip to main content

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":
  • "'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).

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…