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).

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica