Continuous Delivery demands Continuous Discovery

This is the second of an informal series of posts suggested in the July roundup,  expanding on tweets that have sprung to mind while writing (or thinking about writing) my third book, working title Right to Left: The digital leader’s guide to Lean and Agile. In case you missed first one: You can’t deliver a task.

Tweet #2:

Do you recognise this pattern?

  • We get somewhat good at building stuff
  • Later,  we get somewhat good at testing it
  • Later still, we get good at deployment, so good in fact that we can do it at will
  • As work starts to flow, deficiencies in development and testing become more apparent, and they get dealt with
  • All of a sudden, the real bottleneck turns out to be outside of development – a lack of high quality ideas in the pipeline and/or frustrating delays in getting decisions made
  • Now what???

There is something almost inevitable in this sequence – in fact anyone familiar with the Theory of Constraints (TOC) will expect it! If you’re unfamiliar with TOC, it’s the model behind Eli Goldratt’s classic business novel The Goal, and much more recently the DevOps novel The Phoenix Project; TOC teaches that once you’ve addressed enough of your internal constraints, your key constraint will be found outside.

Although there’s a lot to be celebrated in that progression, no team wants to get to the “Now what???” stage. Your choices:

  1. Hope that it never happens (or not care, because teams are there to be disbanded)
  2. Plan to deal with it when it does happen
  3. Make Discovery (or “upstream” or whatever else you call it) a first class activity in your process

Option 3 implies some proactivity, but that doesn’t mean that it has to be difficult. Instead of dismantling that capability as your latest initiative gets off the ground, keep it going, even if at a reduced level. Instead of accepting requirements at face value, make sure that someone is taking the time to understand their authentic situations of need. Instead of fire-and-forget delivery, validate that needs are being met, expecting to feed some new learning back into the process. Simple changes, but as documented in my first book, the effect can be profound, even humbling!

You can of course go further. One of the most important moves made by the UK Government Digital Service (GDS) was to insist that every new service had a credible plan to sustain user research and ongoing service evolution – not just at the beginning but indefinitely into the future. “Start with needs” wasn’t just a slogan, it was a strategy, and a successful one! If government could do this in times of austerity, what excuse does your organisation have?

Public workshops (US, UK, IT, DE)

Make yourself known the #agendashift-studio channel in Slack if interested in attending another cozy 1-day or 2-day workshop for 3-4 participants in my studio office in Chesterfield, Derbyshire (minutes away from the Peak District National Park).

Agendashift-cover-thumbBlog: Monthly roundups | Classic posts
Links: Home | About | Partners | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter

We are champions and enablers of outcome-oriented change and continuous transformation. Building from agreement on outcomes, Agendashift facilitates rapid, experiment-based emergence of process, practice, and organisation. Instead of Lean and Agile by imposition – contradictory and ultimately self-defeating – we help you keep your business vision and transformation strategy aligned with and energised by a culture of meaningful participation. More…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s