Observations on Design Thinking, Lean Startup and Scrum (1): Common Ground

Holger Rhinow
3 min readMay 24, 2018

--

Lofty office space, play areas and latte macchiato? The degree of agility in organizations cannot be identified that easily (© HPI)

This post is the first one of a two-part series in which I want to share my observations about commonalities and differences between agile approaches, and different models that explain how combinations can work out in innovation projects.

Part 2 is about the differences between agile approaches.

Agility understood as development and exerience-based learning

In a previous post I have argued for the idea of design thinking as a learning process. In my doctoral reserach from 2011–2017, I have found strong evidence that design-thinking-teams iterate through phases of observation and imagination, shifting between abstract and concrete content. The observations confirm the Beckman and Barry (2007)’s idea that design thinking can be understood as methodology to allow teams to go through an experiential learning process.

In this post I want to argue for the idea that the agile approaches Lean Startup and Scrum are experience-based learning processes, as well. Both approaches enable teams to navigate through iterative phases of observation and imagination, at times abstract, at times concrete (see illustration below of an experience based learning process).

Four phases of experience-based learning (© HPI Academy 2018)

The idea of shifiting from concrete to abstract and back to concrete has been widely discussed. E.G. Gartner illustrates the three agile approaches as an iterative process from generating, to developing, to transfering ideas into product increments (see illustration below).

Source: Enterprise Architecture and Technology Innovation Leadership Vision 2017 by © Gartner 2016

Interestingly, Gartner argues that “the iteration engine” starts with Lean Startup, while design thinking is more or less paving the ground for an initial kickoff into the “customer perspective”. We can argue about the idea of design thinking as a non-linear kick-off phase, of course. Nevertheless the illustration -in my opinion- accurately describes the commonalities between these approaches, even though the vocabulary differs.

Our illustration acknowledges the common ground between those approaches, as well. All agile approaches are enabling teams to learn through observations and phases of development, whether it is through an early design prototype in design thinking, a business experiment in Lean Startup, or a shippable increment in Scrum.

Learning is a major goal in agile approaches

Furthermore all approaches acknowledge the relevance of learning through creation:

  • In design thinking, teams create prototypes for qualitative tests and thereby learn what is desirable to human beings.
  • In Lean Startup, teams create metric-driven business experiments and thereby learn about potential business models for their ideas.
  • In Scrum, teams create product increments and thereby learn how a desirable idea can be developed into an actual product.

The aspects of desirability, viability and feasbility already indicate differences between all approaches. Design thinking seems to focus on aspects of desirability, Lean Startup rather focuses on aspects of viablity and Scrum rather focuses on aspects of feasibility. Furthermore, the teamwork itself, respectively the quality of interactions, changes significantly from one approach to another -I will elaborate on this aspect in a later post.

During projects we offer teams an overview of agile approaches — their similarities and differences (© HPI Academy 2018)

Despite differences between agile approaches, we can find a common ground by looking at agile approaches as experience based learning processes in which teams iterate between concrete and abstract observatory and imaginary tasks. This notion would also argue for the idea that all approaches can indeed be labeled as agile since all of them should enable teams to experience agile teamwork as described in the agile manifesto, e.g. collaborating with customers or responding to change in a self-organizing manner.

In the second part of this series, I want to focus on differences as they help to understand the approaches’ individual strengths and weaknesses. This may help us to understand how we can combine various agile approaches, depending on the context we are in.

--

--