Design Thinking – Lean Start-up – Agile

Understanding the need to combine Design Thinking, Lean Start-up and Agile to form the most powerful way to understand and deliver value to a customer

On my first day as the CI Manager at an IT Services company I attended a two hour meeting with several Engineers, a few Sales and Service Delivery Managers, and a few Help Desk/Support people… during that 2 hours it increasingly became more obvious why they had created the CI Role that I was bought in to fulfill.

Needing to find a starting point I sat down afterwards and digested what I had witnessed. What I was seeing was an organisation that was making poor decisions that were ultimately costing the company rather than improving it. Maybe that sounds a little harsh – but it isn’t at all far fetched to say that any positive change was more luck than judgement.

What I observed was that there were 3 classic traits of disfunction going on

So where do these traits come from? This Gartner model I think shows quite nicely how we flow from the human/abstract/ or problem space through to concrete work and output or solution space.

If we look at where good Insights typically come from it’s the design thinking or Problem space.

Agile companies do most of their work or initiatives within tribes/squads. An Initiative being a package of work that delivers a solution. Well it turns out that the traits occur because we are moving straight into the Initiatives from the Insight generation without doing the due diligence. Sometimes we may not even be having an insight!

So how should we be thinking about continuously improving? and I’m hoping you’ll be able to see how this applies to everything we do – and how this lite-weight minimal approach can help guide us to making more effective and constructive decisions.

We do this by starting with the Insight – which can come from several sources.

Examples could be a P1 event, Help Desk noticing they get 200 support requests for the same issue, Provisioning have a frustration or idea.

The first thing we can do is try to assess the PAIN of the insight in terms of the Customer, the Business, and the Team.  It is useful to articulate this in words but also assign it a number 1 – 5 using a guide which I’ll show later.

Next we need to do the crucial task of defining the real Problem – Don’t let those engineers off the chain yet!

We also need to ask if we need to collect data to ensure it’s real – Don’t take the muzzle off Bob (or Pete) yet!

Brainstorming with the right people we can now let those engineers loose but make sure for every option we assess it’s risks and determine if we need to do more – create a POC, have a wider meeting, gather more metrics etc.

Now we’ve done some due diligence we can assess whether we abandon, pivot, or create an initiative

So here’s a Lean Canvas I have created to help guide people through a constructive thought process. The first question is where we can use a plethora of tools/methods to arrive at an articulated problem. There are alternative rating systems that can be used, but this is a good starting point.

Once a pragmatic decision has been made to create an Initiative for any given Insight, we can look at it’s priority using a similar scoring but this time for the Benefit that will be experienced by the Customer, Business and Team. I should say the hypothesised solution as we should think in terms of experiment/learn/build/measure. The Benefit should sometimes match the Pain score, although this isn’t always the case (e.g. a customer centric solution may cause extra work for a Team).

The solution should be assessed for scope to determine the impact, complexity and constraints.

Now the Initiative can begin, either internally to one team (operational), multiple teams collaborating (tactical) or for the more complex or organisational wide projects – through a signed off, budgeted and fully planned assault (strategic)

Here’s another Lean Canvas for the Hypothesis – What we are saying here is that we hypothesis that by implementing this solution we will solve this problem, and we can confirm through measuring these things. And here is a guide to estimating the Pain and Benefit numbers whether $ or non-$.

To summerise, a universal lite-weight framework can ensure: Consistency of approach, visibility for shared learning, a way to meaningfully prioritise, prove the issue is real, and prove the work added value.

Everyone is responsible for CI, and as a final thought to move us forward and mature our take on CI:

if you see something that is ‘broken’ or ‘an opportunity’ champion it through the framework. CI is revolution!