Observations on Design Thinking, Lean Startup and Scrum (2): Differences in Teamwork

Image for post
Image for post
Agile approaches differ significantly (© HPI)

In a previous post I summarized my personal observations on commonalities between agile approaches. In this post I aim to focus on differences and why these differences matter especially for project managers and coaches.

From a need-solution fit to product increments

All agile approaches are more or less based on the axiom that solutions are only as innovative as they are

  1. desirable to human beings,
  2. technologically feasible
  3. and viable in terms of a business model.

Nevertheless all approaches emphasize those three aspects differently.

The outcome of a successful design thinking iteration would be to fulfill a human need, addressed by a prototype. Design thinking methods help teams to iterate towards this need-solution fit. Methods of choice are typically qualitative observation techniques such as open-ended interviews, workaround observations, self-immersion, and prototyping tests. Teams thereby gain an intuitive understanding of relevant needs in specific contexts and prototypes that surpass existing solutions or workarounds.

Teams that already have a strong idea or a product vision are less inclined to be on the look out for how they can fulfill a need. For instance, most startups and entrepreneurs do not sell poorly addressed needs to venture capitalists, but rather ideas that are yet to be proven valid. The idea behind the Lean Startup approach is to test the validity and market potential of business ideas, before making big investments. Lean startup is a way to organize business experiments for ideas that have not yet been fully developed. By defining hypotheses and metrics and testing them, teams can systematically minimize inherent business risks. If testing results show up to be in favor of a business model, the team eventually arrives at a solution-market fit.

Highly user-relevant solutions with a valid business model are the foundation for any successful product. Nevertheless there are still development risks that need to be managed carefully on the way to market success. Scrum is an agile development approach that allows teams to manage development risks while working on product increments. Scrum teams iteratively develop product increments in 2–4 week long sprints. Through careful sprint planning, reviews and retrospectives, teams, guided by a Product Owner and supported by a Scrum Master, manage to deal with uncertainties. They thereby emphasize aspects of technical feasibility, even though they may still iterate on business aspects and user needs as well (e.g. in user testings). The team’s ultimate goal is to continuously develop product increments that can be pushed into market.

To sum it up, different approaches in agile teamwork explore different aspects of an idea: from finding and adressing a human need (design thinking), to defining a valid business model (Lean Startup), to minimizing development risks (Scrum).

From conceptual conversations to detailed work tasks

As previously shown, agile teamwork is defined by a continuous shift between concrete and abstract work. Even though all approaches enforce teams to shift, one can still detect a relative difference in the degree of abstraction and concreteness. E.G. it seems to me that design thinking methods allow for the highest abstraction in teamwork. Here, many teams find vast opportunities to discuss conceptual aspects. Once they start prototyping the work gets more concrete, but it is still relatively abstract compared to work where teams focus other agile approaches. As Alex Rios argues: Even though design thinking allows for concrete work we are “still in the abstract world” compared to what is happening in the Lean Startup world.

  • In design thinking, teams are mostly handling qualitative data, very often evaluated based on a gut feeling.
  • In Lean Startup teams are defining their market insights, assumptions and goals in metrics.
  • As soon as teams actually move into a phase of agile development the work tasks and results become as concrete as possible, ending up in product increments delivered to real customers.

The evolution from a conceptual and intuitive to a rather detailed and metric-driven work justifies why teams often begin with design thinking and end up in agile development processes. The more they have learned about a certain topic, the closer they get to the development of concrete solutions (see illustration below).

Image for post
Image for post
Shift in conversations between agile Approaches (Rhinow 2018)

Teamwork does not necessarily follow a linear path from abstract conversation to concrete work tasks. The cycles in the illustration above indicate that iterations may lead teams back to previous, more conceptual and abstract questions that need to be re-asked as new data emerges.

From radical collaboration to loosely coupled interaction

All agile approaches declare teams as the core unit of their actions. Nevertheless teamwork looks different in all of these approaches:

  • Design thinking teams are often described as teams under the influence of radical collaboration. These teams often work together closely in one team space for days without separating for individual work tasks. Especially in early iterations, design thinking teams tend to interact intensely with each other in all phases, trying to cope with a relatively high uncertainty. Every action is followed by short reflections: are we doing the right thing here? Do we agree on what to do next?
  • The Lean Startup methodology seems to offer more opportunities for teams to split up and work in parallel. As soon as the team defines and prioritizes business hypotheses and potential testing scenarios, it often seems possible to test these hypotheses independent of other team members. However after evaluating test results, there seems to be a need to meet again in person and discuss further steps and priorities.
  • In Scrum, agile teams work under formal roles and processes that allow them to develop parts of solutions as individuals, in pairs or in smaller groups. Through events such as daily standup, every team members is in sync with what the rest of the team is currently working on. A Scrum Master makes sure that everyone can rely on the consistency of the work being done in parallel. Scrum allows team members to individually focus on single work tasks without distraction for a defined period of time. The level of interaction between team members is relatively low compared to design thinking. Most interactions happen in designated events such as standup, sprint planning, sprint review, and retrospective.

Why differences matter

In my post I focused on three major differences that I consider important for project managers and coaches. If you set up and manage innovation projects you want to make sure your teams are operating under the right circumstances at the right time. We can see that different agile approaches allow for adjustments in ongoing projects.

Depending on what a team needs to learn more about, different agile approaches explore aspects of desirability (design thinking), viability (Lean Startup) and feasibility (Scrum). Teams may rightefully jump back and forth between agile approaches, if new questions come up in one or the other field.

Agile approaches allow for different levels of abstraction in teamwork. On a rather abstract level, teams may aim to define the overall concept of an idea (design thinking). If they aim to understand the business context around the idea, they may apply Lean Startup. Once they have figured out the overall concept, they may need to work on details or features of an idea, by applying Scrum.

Teams in innovation projects are always facing a certain level of uncertainty. The more questions are unanswered, the higher the uncertainty those teams have to manage. Design thinking seems apporiate in project situations in which neither the underlying problem nor the solution is fully understood. These teams work highly iteratively, sometimes switching between ideas on a daily basis. They are therefore inclined to work closely together to constantly make decisions with high impact on the overall project. As soon as the overall idea becomes more stable, teams naturally start to work more in parallel. Especially Scrum seems to enable teams to work more in parallel while still allowing for designated times to make decisions within the team.

Experienced coaches are able to observe dynamics in projects and adapt the teamwork approach accordingly. The differences in agile approaches are therefore a great chance to customize innovation projects along the way.

Written by

Design Thinker, Coach, Program Manager at HPI

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store