Agile, Lean, Design Thinking and a Bottle of Chardonnay — DigIO

What do Agile, Lean, Lean Startup and Design Thinking have in common with a bottle of crisp white? Not much, but I got to thinking about a recent road trip experience and how these disciplines all need to be applied together in order to make sure we build successful software.

Late Spring last year my wife and I were watching a show on the Food Network. The host was sipping on a chilled chardonnay under the glorious dappled sunlight of an Adelaide Hills winery, and my wife commented that she’d like to be doing exactly the same thing.

Sensing an opportunity to do something spontaneous (a rarity after more than 20 years of marriage and with a 13 year old daughter), I thought I’d organise a surprise road trip to that very winery in the Adelaide Hills. Unfortunately, the reality and time pressures of day to day life stepped in and we didn’t take that trip until some five months later, with an outcome that I didn’t expect.

Later in this article I’ll explore that road trip from the lens of some popular disciplines common in software development but first, let’s take a little detour with a layman’s definition of terms.

Part 1 — Introductions

Agile: A software development framework that places the importance on self organising teams focusing on early delivery of software and addition of more features over time, allowing the software to evolve in response to changing customer priority. A common metric from Agile software development is Velocity, a measure of the work or complexity that can be completed by a team in an iteration (typically two weeks).

Lean: Born out of Lean manufacturing, and in particular Toyota’s work in the 1990’s, the focus is increasing efficiency by reducing waste, and improving flow of items through the workflow. Lean often looks at the following two key metrics, amongst others;

• Cycle Time: The duration in time from when work commences on an item, to when it is completed. Think about it as the time it takes to cook a meal.
• Flow efficiency: The amount of time that an item spends being worked on, in proportion the total cycle time to complete the work (work time/work time + wait time)

Lean Startup: Influenced by Lean methods, Lean startup recognises that business plans aren’t perfect, therefore you should build the most important features of a product early, validate with customers and then learn and pivot and iterate, rather than burning through more money to build more comprehensive features that aren’t appreciated The mantra ‘fail fast’ comes from lean startup.

A key metric for Lean Startups is Lead time, which is the time from when a request is made, until when the feature is delivered. Think about it as the time it takes from when you place an order in a restaurant, until the time the waiter serves your food.

Design Thinking: Uses the designer’s sensibility and methods to understand the problems that people and society are dealing with. The processes in Design Thinking helps to unearth unmet emotions, needs and desires, and attempts to find a solution that has market value and is, or could be technically feasible.

Now with that out of the way, let’s return to my plan to impress my wife with a trip to the Adelaide Hills.

Setting the scene again, it’s October, and I’ve started a new job, it’s super busy and I can’t get time away. Then it’s December, Christmas is close and my daughter is on holidays. January slides past and we enjoy the good weather and I finally get my act together well into the first school term.

It’s nearly 750 kilometres from my residence in Melbourne to the Adelaide Hills and Google Maps tells me with confidence that we should arrive in no more than nine hours. Figuring that this should be more than adequate since we’d be driving at 100 kph, we drop our daughter at a friends for a sleepover at 8 am and begin our drive, with the plan to arrive mid afternoon so that we can have a relaxed evening.

As you can imagine, that’s not how it panned out. After nearly 12 hours of driving ,we arrived after dark, having shared greasy fish and chip with the seagulls in a park on the way.

So what happened?

Part 2 — The Agile Lens

Putting on my hat as an Agile scrum master, I tried looking at it like it was a software delivery problem. If it took us 12 hours, then obviously our velocity was a tad over 65 kph. This didn’t make sense as I knew that for most of the time we’d driven at 100 for most of the journey.

Sound familar? All too often on software development projects we feel like we’re all working really hard, and yet our progress is often much slower than what we expected.

Obviously just looking retrospectively at Agile metrics wasn’t going to cut it. It was time to get Lean and have a look at the ebb and flow during our journey.

Part 3 — Getting Lean to improve Flow

Lean focuses on minimising waste and improving efficiency to improve flow efficiency, and drive increases in velocity. Lets look at our lean agile metrics for the trip:

• Cycle time = 12 hours
• Flow efficiency = (total work time — total idle time)/total time = (12–2.75)/ 12 = 77%
• Velocity = 64 kph

I wasn’t prepared to break any speed limits along the way to reduce my cycle time, so the obvious thing to do to improve Flow Efficiency was by looking at idle periods where we were having a break or weren’t progressing at maximum speed to our destination.

I could easily eliminate some idle periods — for example by filling up the day before to avoid having to stop at a service station , bringing a flask of coffee and swapping drivers, and bringing a packed lunch. Put in place these changes we could have shaved hours off our travel time.

I could also see if there were ways I could reduce the periods where we weren’t travelling at 100 kph; for instance if we’d left earlier in the day we could have avoided the traffic jam on the Metropolitan Ring Road, but i couldn’t have have avoided the detour just outside of Ballarat. Even so, I could have taken nearly another hour off our travel time.

The lean agile metrics for this ‘leaned up’ trip is as follows:

• Cycle time = 8 hours 45 minutes
• Flow efficiency = 8.5 hours/8.75 hours = 97%
• Velocity = 91 kmh

So by simply applying some lean principles we could have cut cycle (or travel) time by nearly 3 hours, and as a result increased our velocity by almost 30 km/h, all without having to drive any faster in the process. The same rules apply for Agile software delivery — you can often drive greater improvements in a team’s velocity by focusing on eliminating waste and inefficiencies in the system, rather than by looking at how the team can work harder.

Part 4 — Thinking like a Lean Startup

So imagine now that we’ve had an exhausting 12 hour drive to Adelaide, so to relax I uncork a bottle of crisp chardonnay in our room — and to my dismay my wife reminds me of one key fact i’d forgotten — she hates white wine.

For five months I’d been planning this trip, and had driven over 700 km based off an off-the-cuff comment by my wife while watching television. Five months to find out that I’d been working under a false assumption.

If I’d been thinking like a Lean Startup and tried to ‘Fail Fast’ — I would have done two things:

• Reduced the five month lag between when I first had the idea for a road trip and when I actually started planning it in February.
• Saved myself the effort of a massive road trip a winery in south Australia, by trying something simpler — e.g. by taking a day trip to a similar winery on the Mornington Peninsula.

I could have managed a day trip to Morning Peninsula way earlier, and I’d have driven almost one tenth of the distance to South Australia. I definitely would have wasted less time and energy to be reminded that my wife really dislikes white wine.

While there are definitely many new companies using lean startup methods, its philosophy can also be applied to software development — when you get a product with core features out early you will often learn more about your customers than if you wait until you’ve developed a feature rich product. And if like me, you’ve built it under an incorrect assumption at least you wont have spent as much on development before you find out that you are wrong.

But wouldn’t it be nice if we could somehow understand what our partners (or our customers) really want?

Part 4 — Understanding the Customer with Design thinking

Design thinking is set of disciplines often involving conversation, observation, interviews and talking to empathise with and learn more about the customer’s pain points, and their emotional drivers. With this information, a proof-of-value solution is identified and then tested and iterated with the customer.

After more than 20 years of marriage it seemed like I’d stopped paying attention to the nuances of my wife’s conversation, and its underlying subtext and just jumped to a conclusion without really understanding what was going on.

Imagine, if I’d been that little more attentive and on hearing my wife’s comments, and I’d actually asked her a few questions?

I would have found out that:

• She’d been trying to organise a night out with some of her friends for ages with no success for months.
• Her emotional battery was drained after juggling a job, a teenage daughter, a husband and being a general all round wonder woman
• She needed some ‘me’ time to recharge.

For the investment of a little time an effort on my behalf (which would have been appreciated in any case) I would have discovered what my partner needed was a weekend away with her friends (and not me!) to recharge and relax.

It’s often a similar scenario when we are building software. We often think we know our customers, but in many cases we are often divorced from them, and make decisions and assumptions based on our own experiences and problems rather than theirs. In may cases the closest we get is a collection of user stories. While this is far is better than a technical specification, it is no substitute for getting to speak to or work with real customers. Even just sharing customer personas, empathy maps and other outputs from design thinking workshops will give development teams context as to why they are building something and hopefully empower them to challenge things when they don’t match against the needs of the customer.

Part 5 — Wrapping up, a combined philosophy for success

While it’s currently in vogue for IT companies to undergo Agile transformations, being Agile alone is not a silver bullet for success. We need to build something that matters to our customers, validate against the target market early before we continue investment, and continually optimise to deliver more quickly and with less waste. While my trip was obviously far less complex than a software development project, I believe that I’ve been able to show that the combined benefits are such that as professionals, we all need to bring a basic understanding of Lean, Lean Start Up and Design Thinking methods to our work.

And maybe it could help you with your next surprise road trip with your partner 😉

Originally published at digio.com.au on May 30, 2018.