Lean, Agile and Design Thinking: Pick A Buzzword, Any Buzzword

Scrambling Towards a Scrabble Game of ‘Scrums’

Almost all large enterprises have heard of, or even parroted, the need to be “Agile”, “Lean” or “Sprint like a Startup”. Many have begun building “Design Thinking” into how they research or develop their products, and we see more “scrums” on a weekly basis in some orgs than in the Japanese World Cup.

Honestly, I get a regular facial workout from trying (and failing often) not to raise an eyebrow or roll my eyes with the amount of buzzwords bouncing around big companies anytime the concept of “innovation” is mentioned.

And in all this noise, it’s really, really hard to work out what’s meaningful. Where are companies even using the right word for the right methodology; let alone working to develop the principles and skills behind them at a real practitioner level.

This doesn’t just affect large corporations either. Startups are bombarded with new methodologies they have to at least say they’re practicing to appease investors — but how we they sort the sense from the lip service when it comes to startup skills and methodologies.

Which processes and approaches are right for what you’re trying to achieve? How many of these methodologies do you need? Do you need to teach them internally? Can you find the right person to outsource them to if you don’t? What’s a Scrum-master and can there be a Scrum-mistress? The list of questions goes on and on.

We Definitely Need Better Definitions

NB: before someone throws a heavy book on Agile Management or a hardcover copy of “The Lean Startup” book the below definitions are the ones I’ve found most helpful.

In this article I’m going to summarise one take on methodologies many have gone far deeper into than me. Some people have told me my take is a contentious one. My goal is not to give the one true answer, but a set of core definitions which build to a practical way to understand the interplay between these three key methodologies. I’ve spent several years playing with and teaching these methodologies, and have found the below to work best for me, and specifically for Corporate Innovation — but I’d love to hear other definitions and how they differ in the comments box.

Avoiding Agile Bureaucracy

Agile offers a core manifesto for product development. It was created to help developers prioritise customers and iteration when building new products:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

It comes as a response to traditional development, where the design happened up front and then the build happened as a waterfall — with no way to change course or learn from the customers once you’d crossed the precipice into code. Developers would do huge code releases, only to learn what they’d built didn’t serve a real customer need.

To counter this Agile development encourages rapid releases and shorter loops to build:

So in agile development we constantly iterate our product, with the customer to avoid spending too much time and resource building the wrong thing.

To keep ourselves to these rigorous release and learn loops, agile methodology uses “sprints”. This is a way to practically time-box how we work, so we don’t wait too long to assimilate our learnings and we don’t get feature creep, where things drag on and we delay releasing until we have a “bug free” version. The goal is to prioritise learning from customers over perfect product.

I love these core tenets. We teach sprint design in all of our accelerators. If you can hold yourself fast to moving at pace and constantly reprioritise where you’re targeting learnings you give yourself a significant advantage over executing on your original hunch.

The danger is when agile morphs into something new…

I was invited to a three hour “Agile Sprint” meeting by a client who shall not be named. In hindsight, stopping the meeting 30 minutes in to ask if anyone was getting value from the session may have been a tad harsh- but harsher still… noone in the room was. We’d found another way to waste time in a meeting which could take the name of Agile, but was anything but.

So here’s a checklist to help check if you should be using agile sprints:

1. Are you executing something that is inherently new/risky?
2. Are your sprints really time boxed? Or do tasks just run on sprint after sprint?
3. Are you using the sprints to reflect on what you’ve learned? The good and the bad?
4. Are you using sprints to reprioritise your focus based on learnings?
5. Are you constantly improving not just your product but how you work with this process.

This is a simplifcation (that is afterall, the goal of the the article). There’s a lot more to truly mastering agile and sprints, and I would never claim to be a “scrum master”; my goal here is not to be exhaustive, but simply to highlight the core things Agile can offer, and to caution anyone from creating too much process and structure around Agile. And perhaps to give people the grounds to question those who are taking its name in vain.

Are you doing it for the right reasons? Are you creating more buzzwords in place of real ownership and action? Is the sprint serving your need? Are you learning faster because you’re following this process.

If not, time to rethink how you’re using the methodology.

Lean Startup: A Definition

A set of principles to test fundamentally risky things which have not been proven before.

Rather than trusting our gut instinct, Lean Startup holds that any new idea is just a big pile of guesses. To lower the risk of building a business around those guesses, we want to test them, in a scientific way we can trust, and in the real market we will ultimately be selling to.

To do this, we break down our ideas into their component risks, at a customer/user, business model and product level, and design experiments to test these risks as quickly as possible with real customers.

The faster we can run these cycles of experimentation, update our assumptions with our learnings and repeat the cycle, the better we will do, because we’re prioritising de-risking out business over everything else — even product build.

So, to test in line with Lean Startup Principles, you might not need a product at all. You just need a way to test that risk as quickly as possible in the market — a Minimum Viable Test.

To practice Lean this means we follow a basic loop:

1. Identify what we need to learn
2. Work out what we would need to measure to prove it true or false
3. Work out what we would need to build (remember this is building an experiment not necessarily an early version product)
4. Run the experiment and gather the data
5. Update our learnings and repeat

By now, some of you may be wondering if I have in fact run a loop on this article. After-all, build measure learn sounds strikingly similar to the Define, Build and Release circuit seen in Agile…

Not a happy accident. Lean was built on agile principles. It has frequency of testing with customers at its heart, just like agile.

The key difference?

Lean goes beyond Product Development. In fact, Lean is about de-risking three things in parallel: Product, Customer and Business Model.

It also shouldn’t seem coincidental that Eric Ries (author of the Lean Startup) was a student of Steve Blank. In The Four Steps to the Epiphany, Steve introduced the concept of startups “searching” for a business model, while large existing companies “execute” them. Drawing this fundamental delineating, Steve also introduced the concepts of not waiting to throw your in front of customers until the product was launched, highlighting the risk of treating assumptions as anything to be trusted instead of tested.

And what’s been dubbed the missing piece of Lean? The Business Model Canvas. Published a year before the Lean Startup, Alex Osterwalder and Dr Yves Pigneur’s new framework is a highly practical tool to actively breakdown a business model, unpick the inherent risks, rapidly prototype new versions and test the interdependency of the core elements. If you’ve tried it and not loved it, I’m afraid to say you’ve missed a trick- it’s game changing. When used well it lets you communicate, test and innovate business models — fast.

Play Nicely Kids

So, Lean brings together product, business model and customer development in parallel.

It’s all about rapid experimentation, iterations informed by data and keeping the customer at the heart of everything to avoid over-investing at any stage.

No one thing happens in isolation, so data from customer development feeds product, product data feeds customer development questioning, business model determines how you build your product and take your lessons from customer development into a viable way to make money.

To do the above, you have to put customer at the heart of everything you’re doing: not off to one side.

Lean gives us the set of guiding principles to do this in practice when we approach any new idea: building beyond how we build it- to how we test every element of it.

Oh Hello Design Thinking, I Didn’t See You There

Enter stage left, Design Thinking.

To me, design thinking is best defined as customer empathy.

Design thinking focuses on building deep understanding of our customers. We may do that in different ways (though please, please, don’t let one of those ways be a survey). It may be following them for a day, it might be conversations, doing a task with them or for them, it’s not necessarily how that’s the key here, it’s the why. Customers are king (or queen) — we’re wasting our time if we don’t build something to delight them.

Again, its process is remarkably similar to Lean and Agile, even if it appears more linear.

It aims to avoid jumping straight to build before we’ve really understood and tested what we’re delivering to the customer.

Design Thinking is also often associated with something called “the double diamond” which is just a way to visualise divergent and convergent thinking.

It’s also a great way to bridge the gap to Lean Startup, where the challenge is that you need an idea in the first place to start testing.

So with design thinking, you can go broad and explorative on customer problems first, then reduce and refine on a pain you want to relieve or joy you want to relieve. Then you repeat the diamond, going broad on ideating different solutions and then converging on the best solution to deliver to the customer.

Another way of thinking about this is focusing first on learning about the customer aka “learning to learn”:

And then we make our entrepreneurial leap of faith to generate the solution and try to “learn to confirm” that we’ve landed on the right one (something the customer will actually use/buy).

Concepts like the double diamond work brilliantly when applying them to the search for problem market fit, product market fit and business model market fit.

This can also help give an order to our Lean learning curve too: we want to focus our experimentation on learn to learn, then learn to confirm, and always start with the customer. This means our Lean execution actually looks more like this (where we always start with the customer and then bring in business model and product to test).

Put another way: first test desirability (does anyone care), then feasibility (can we deliver what they need) and then viability (can we repeatably make money doing it).

So it’s a Mashup

When used well, each methodology builds on the others to create something that really does offer significant competitive advantage:

The iteration of agile…

The customer centricity of Design Thinking…

Gives us a Lean Startup set of principles to generate and test ideas.

Combines to de-risk new ideas, because searching for a new business model is inherently uncertain, and we don’t want to hit an assumption when it’s too late to change course.

Create Your Own Toolbox

I didn’t hold back on mixing metaphors in this article, and I encourage you not to hold back in mixing methodologies, tools and approaches to find what works best for your context.

Lean Startup isn’t scripture, it’s a set of guiding principles to help you go faster, and go faster in the right direction when there are so many ways you could run.

If you find creating personas in Design Thinking impractical, don’t use them. Focus on the customer however you can and focus on building real empathy not selling. My favourite tool for this is customer development, Mom Test Style.

If you’re wasting hours being agile, call it out! Sprints are short and sharp, and you can’t run sprints together to make a marathon — so don’t.

I hope this article helps you start the conversation, and becomes a way to begin building your own basis to determine which tools are best to use when.

And I’d love to hear what you think! Where you disagree, what resonates and how you’re making the most of these approaches!