Sail Better - from user research to product backlog - hands-on experience in applying Design Thinking in SAP's lean and agile environment

In one of our recent projects, we had the chance to experiment with blending user research and ideation practices from Design Thinking with practices from lean and agile software product development.

Here are some impressions of how this worked out...

YouTube video showing Sailing Team Germany in action with our software



For some details how we did it, please refer to our recent talk at the German XP Days 2011 (XP Days website - presentation):

Is Design Thinking the next best thing after LEAN software product development and agile team practices? We don't think so: the two "schools" actually complement each other well.

While LEAN thinking and agile principles help organizations to build and ship products right, Design Thinking focuses on building the right product in the first place. On the one hand, Design Thinking can help us to understand the full context of the problem space including potential users and other relevant stakeholders. This, in turn, leads to the product vision and ideas for what the product should actually do. Lean and agile methods provide the process framework to efficiently bring the product to life. User stories and user story maps, for instance, provide a means for a continuously user-centric break-down of the product vision and high-level backlog items.

As a proof of concept, we applied this set of methods in order to explore a relatively unknown domain for SAP applications: software for professional sailors and coaches so that they can optimize their training and competitive performance. Feedback from potential users, the development team, and other stakeholders is very promising so far...

How to achieve Flow without a waterfall?

In Lean Software Product Development (see Don Reinertsen's video, for instance), Flow is one of the major principles and target states to be achieved. Flow, at the first glance, might trigger an association with our good old waterfall model. However, it is exactly the opposite way: you will have a very hard time achieving lean development and flow with a stage-gated sequential process including lots of horizontal handovers.

To achieve flow, you need to have a single view on the backlog of remaining work, i.e. requirements, user stories, and development tasks to schedule. In order to achieve a steady output at a sustainable pace which has an economic benefit for the software company, e.g. by providing supreme value to customers, you will also need cross-functional, interdisciplinary teams and decentralized control. These principles become even more critical as we enter large-scale development organizations with 10-100 teams and multiple aggregation levels, i.e. Scrums of Scrums of Scrums...

In large-scale enterprise software development effects known from systems and queueing theory come into play requiring to understand and actively manage these queues. As in most complex systems, the behavior of large software development units is not determined by the sum of all constituents, but rather by the product of its internal and environmental factors (see e.g. Russ Ackoff on systems thinking). Our recent cluster research project on lean tackles some of these issues. Results will be dicussed here...