September 14, 2011

Agile Visioning

One of the things I wanted to do at the ALE2011 unconference is to discuss Design Thinking in the context of Agile and Scrum. Here is roughly what I took home from this great event about the topic. 


Lightning Talk: Scrum and Design Thinking on a Napkin

In my lightning talk I have presented a sketch illustrating where Design Thinking could fit into a Scrum based product development process to improve ways to find answers to the often difficult question of what to build
Open Space
During the follow up open space session Agile Visioning we shared stories of product owners struggling with the problem of designing a vision to get a better understanding of the issues that Design Thinking could solve in the development process.


Story 1 - Product owner can't see the whole picture
One person told a story of a product owner in a Scrum team that does have the skills of user interaction design but lacks knowledge of other important aspects of the product. The development team does not believe she/he is the right person to see the whole picture of the product but is not working together with the product owner to compensate this.


Story 2 - Product owner missed to adapt vision to changing conditions and wrong assumptions
The CEO of a company defined a product vision but was reluctant to test the assumptions behind it as early as possible. He rather drove the development team to add more and more features while ignoring feedback to the product that indicated that the vision needed to change. Finally the product failed on the market.


Story 3 - Product owner created product vision without involving development team
The product owner worked with non-team members to design a product vision without involving the development team. He failed to engage the team in accepting and to further on adapt the product vision. The development team worked mechanically on their sprints creating a mediocre product.

My bottom line is that the whole Scrum team is much better suited than the product owner alone to design and evolve the product vision. Assigning this task exclusively to the product owner separates the design of the vision from the implementation of a product.  It puts the responsibility for understanding the problem and designing the vision solely into the hand of a single person, who may even not be the most skillful designer in the team and it lets the development team only contribute to the product design by refining the product backlog. This approach is suboptimal for complex product development where often the problem definition is vague, changing and the solution design affects the problem definition itself.


ALE2011, Karl Scotland on Kanban
Roman Pichler suggests in his booAgile Product Management with Scrum: Creating Products that Customers Love (P. 36) to use Scrum for creating the vision as an alternative team based approach led by the product owner. Following his approach the vision sharing within the team is straightforward and could evolve as more knowledge is gathered sprint by sprint. A team that continuously loops back to the vision while building the product will implement a double loop as Karl Scotland presented in his great talk on Kanban. A Scrum team can integrate the double loop into their sprint by simply setting the whole sprint goal to designing the vision or by including items which address aspects of the vision in the backlog but will need additional skills to deal with the design task o creating a vision.

A development team enters unfamiliar terrain when it has to design a vision, a task which requires different skills than working on user stories with clear acceptance criteria. In the open space we have just started a discussion about design thinking methods that could help teams become good in this area of product development. The ideal team would consist of actual users of the product, the development team including designers and the product owner, to be able to "match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity" (Tim Brown, HBR 2009).


We concluded the open space with brainstorming some ideas of what to try when working on the product vision:
  • iterate over tangible results
  • apply direct customer feedback
  • empathize with user of the product
  • understand the problem 
  • co-create the vision with the users of the product

Conclusion
One can argue that the common issues of the stories we have shared could easily be solved by implementing Scrum well and following Agile principles. I agree that this may be good enough for projects where the problem definition and the vision is obvious. When this is not the case - which is quite often from my POV - design thinking skills could be a real benefit for a Scrum team. The session left me with a much better understanding of this problem but we had no time to get much into details of design thinking itself.
The ideas we came up with are still vague and theoretical thus I think the best would be to use the methods on a project guided by someone experienced in design thinking. I am eager to try out some of the practices or learn from others who have practical experiences in design thinking within Agile product development.


Participants
Christoph Oberle, Nadine Irene Hamann, Bruce Scharlau, Katrin Elster, Ulf Brandes, someone from Finland and 3-4 more persons I forgot to write down the name


Thank you for joining and contributing to the open space session (and apologize that I did not record all names, just let me know when you want to be listed here)!


References



2 comments:

  1. Great thoughts you got there, believe I may possibly try just some of it throughout my daily life.

    Scrum Process

    ReplyDelete
  2. This is such a great resource that you are providing and you give it away for free. I love seeing blog that understand the value of providing a quality resource for free. Quality Assurance tool

    ReplyDelete