Scrum Gathering London: Delivering the real yummy pie slices

At the ScrumGathering 2011 in London we brainstormed in a small group on the open space session ideas of applying design thinking in the context of agile development. As a starting point I presented Mary Poppendiecks lean and more holistic view of product development seen as a design task and her critique of scrum implementations failing to address the real problems of the users by drawing a line between sprinting on the one side and defining the problem of the user on the other side (see my earlier post on this).

A good example of drawing such a line is the common approach of pipelining the user interface design work as it was proposed in the open space session on agile UX by Luke Walter and also known from the work of Desirée Sy. Pipelining is a way to put design work outside of scrum team to prepare user stories for upcoming sprints. The assumptions that would make pipelining necessary where that the design work, e.g. building and testing a set of prototypes, does not fit into a sprint and that the work would not require the full team but just a designer to complete it. Nevertheless slicing the work into appropriate chunks and specialists doing specialist work in cross-functional teams is a general problem scrum teams need to solve and I see pipelining as a workaround to it and not as a solution. And it comes with the penalties of extended cycle time, handover and in the worst case some sort of scrumfall where the required rework of design becomes very expensive due to the long long cycles and broken feedback loops.

In our session we came up with a much simpler approach of including all design activities to the team just like any other task to build a product as illustrated in the picture. Adding the sometimes messy planning activities of understanding WHY the product is needed and finding out WHAT the problem is to the team's agenda will involve everyone in experimenting the way thru to know HOW to build the product. Bringing this task to the whole team has the great benefit that everyone is involved in understanding the problem, full information saturation without handovers and a shared vision from day one on. The trade off is reduced team velocity measured in converting ready user stories into increments since ideation, experimenting with prototypes etc. does not necessarily result in potentially shippable product increments but concepts and knowledge. It's so obvious to me that the knowledge gathered by the team is much more worth than any shippable code when the problem to be solved is still fuzzy, thus this approach provides a fast track for a scrum team to shortcut the uncertainty cone whenever design and problem understanding are the main source of the uncertainty. I don't see so much of a change in the scrum framework than in the mindset and indicators to measure progress. 

The benefits of knowledge gathered to reduce uncertainty, level of knowledge spread throughout the team, motivation from working with real users on their problem as well as having a real feature team outweigh the optimized implementation workflow many scrum teams stick with: open, ready, in-progress and done. Adding unclear and checked-with-user to your task board will help to overcome the local optimization of measuring pure implementation speed. The challenge is enabling real cross-functional team work, which is a great one for agile coaches, and letting go of some meaningless numbers that say nothing about success of a sprint.

Thanks to Thoralf, David, Tom and everyone who joined the session and I missed to take contacts joined the session.


Desirée Sy, 2007 Adapting Usability Investigations for Agile User-Centered Design, http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.html