The problems of integrating a Design Thinking approach with a Scrum operational framework

By Vincent Loiseau.

After introducing you to the Design Thinking approach and its usefulness for product management, we share with you some problems frequently encountered by our clients.

Problem 1 – Having a fully structured product backlog based on the screens from the prototypes

The learning generated through prototypes can lead to the construction of a Product Backlog that is completely oriented towards "action on the graphical interface", to the detriment of functionality. We have observed that the writing of User Stories can be broken down into a User Story describing the access to a screen or information, and a second User Story describing the expected screen or information:

US 1: As Richard I want to click on the "My Orders" button to access the list of my orders

US 2: As Richard I want to see a list of my orders sorted by date of creation in order to know the delivery status of the last order I placed.

By confronting these two User Stories with the INVEST model they should follow, we see the following:

• I – Independent – The two US are dependent on each other. If one is not realized, the other is not usable.
• N – Negotiable – The first US is too simple and small – There is no possibility to negotiate it.
• V – Valuable – What is the value of clicking a button to access a list of orders? No value. The first US is way too small.
• E – Estimable – Yes of course.
• S – Sufficiently small – Yes, but they are even too small.
• T – Testable – Yes they both are, although testing the display of a screen or a feature when a button is clicked is not the most interesting and relevant test to perform.

This type of User Story breakdown, oriented towards the graphical interface, imposes a too high workload on the development teams and their product owners. The former have to set up tests to validate topics that do not provide value. The latter spend too much time writing small User Stories, often to the detriment of discussions with users or market analysis.

Problem 2 – Time to market of the product is slowed

The vast majority of the five phases of the Design Thinking approach are completed before the implementation is launched. The Scrum framework has allowed us to drastically reduce the start date of the implementation of the features compared to traditional project management approaches.

We have seen several times with different clients that the Design Thinking approach was fully realized before any development was launched. The deliverable for the development teams was a complete and validated prototype of what was to be done. This means that a detailed specification phase has to be completed before the implementation can be launched.

This causes a delay in the first sprint, a delay in feedback on the increments made and therefore a delay in the market launch.

Problem 3 – We don’t take advantage of increasing the functional knowledge of the development team

We have found that many of our clients have restricted their Design Thinking approaches to experts. If the development team cannot participate in the different phases of the approach, it cuts itself off from the knowledge of the users’ context and the real problems they are trying to solve. As a result, the team will only be able to contribute very little innovation. We must not forget that a team cannot be efficient if it does not know the functional subject and the real problems it must solve. It will be content to implement solutions imagined by others.

Problem 4 – The validated prototype is considered a validation of the hypotheses

The Design Thinking approach limits the risks of targeting the wrong solution to answer users’ problems. However, just because a prototype is validated by users does not mean that the solution is satisfactory for them. Here are two cases that we have encountered with our clients:

• the users the client relied on to carry out the Design Thinking approach were experts in their field. The proposed user experience turned out to be a failure when the defined solution was put in the hands of "regular" users. The solution was too complex for them to grasp.
• The new version of a solution offered new functionalities and opened to new users outside the company. The user experience was validated by prototypes that were only presented and validated to internal users. New external users were only given access to the new version at the end of the project. There was no way to ensure that the chosen solution would also be suitable for them.

Problem 5 – The output of the prototypes from a Design Thinking approach is added to an already heavy workload in the Product Backlog

The integration of a Design Thinking approach works quite well in a new product context. However, we have seen with many of our clients that this is not that smooth when the product backlog is already full of issues and the development team does not have the capacity to address them all quickly.

We noticed the difficulties that some Product Owners had in prioritizing the topics contained in their Product Backlog. Here are the three options that they generally retained the most:

We need to redesign the user experience we offer to users as soon as possible!

This certainly satisfies the participants of the workshops, but risks to stress many users who were expecting other features already planned.

We need to finalize our initial engagements before we work on the user experience!

This usually frustrates all stakeholders in the implementation of the new approach and, in the long run, adds further defiance to any willingness to change in the companies.

Or, and certainly the worst solution:

We have to deal with these issues at the same time!

The first to grumble are the members of the development team, for whom the wish of a "sustained but sustainable rhythm" becomes only a utopia.

And then finally everyone is dissatisfied since no subject really progresses, the expected benefits even less.