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...

From Business Goals to Product Backlog...

After this year's XP Days, I came across Gojko Adzic's effect mapping technique for deriving product features from a software company's business goals (see also his recent paper). Hence, features and user stories implemented can be traced back to a common business goal and prioritized according to the respective effect they have. On the way from goals to backlog, effect mapping determines relevant stakeholders and how they need to act in their respective real-life contexts - this might in turn be a challenge to be tackled by a design thinking team...

Requirements Engineering Research

By the way: I have been putting some effort in researching the topic for quite a while (since 2004, to be precise). I will try to refer to some of my previous work in the course of this blog...

Agile or not, many of the approaches, methods, and tools for requirements engineering and management we developed together with medium-size software companies and some customers from the banking industry still make sense (as you can seen on the picture below, I also did not refrain from making some observations on the "waterfall model").

Please find my research publications so far at my University of Mannheim homepage. Most articles can be found on Google Scholar as pdf - here is my publications list on Google Scholar.

As illustrated in the picture above and as it is with most scientific research, our contributions take more of a 13,500+ feet perspective on RE topics.

SAP XP ?! – Lean and Agile Development at SAP

Agile development and eXtreme Programming practices at SAP?

You would not expect that association in the first place. However, a growing mass of colleagues from different departments of the company (including me) are trying to "turn the tanker" in that direction. At last week's XP Days, there was a great keynote speach by some colleague exactly on this topic.

Find Juegen's keynote here...

German XP Days 2011 - How Much Waste Do We Need for Innovation?

This year's German XP Days (see program) included several contributions and discussions regarding agile development on a larger scale and what it takes to become and reliably stay innovative as a software company.

Johannes and me also presented some thoughts on how Design Thinking can help software development teams to leverage observations and user research to come up with more innovative user stories and build the right software for customers.

The feedback from the XP community was awesome and we had great follow-up discussions throughout the conference - and hopefully beyond... However, one question was brought up by several colleagues in the community (see e.g. Holger Rhinow's blog post - he is part of the Design Thinking Research Program at HPI):

How Much Waste Do We Need for Innovation?

"Waste" is a term from Lean Thinking and Lean Production (as practiced at Toyota or Porsche, for instance) and denotes activities and processes that do not add direct value for the customer (value = sth. the customer is willing to pay for).

Innovation approaches such as Design Thinking, on the other hand, foster "real" brainstorming and the creation of ideas in large quantities - many of which might be discarded later, i.e. end up in the waste bin. Moreover, Design Thinking suggests rapid and cheap prototyping to get feedback ("fail early") Again, many of theses prototypes will end up in the waste bin - on purpose...

Now, can these two thinking schools intertwine to solve problems for the software industry that neither one could on its own? I think so, especially in standard software development processes. Just imagine this simple example: Development team A combines Design Thinking and Scrum (Scrum implements many lean principles out-of-the-box). They spend a seriuous amount of time for user research, brainstorming, ideation, paper prototypes, etc. 20 percent of their ideas make it into the final product which becomes a blockbuster - i.e. in lean terms 80 percent waste! On the other hand, team B does it the "old school" agile way with some requirements workshops, user story writing, and backlog grooming. They realize 80 percent of the initial backlog, but the product fails on the market. In lean terms: 100 percent waste...

(to be continued here)

Stop to Think - Design Thinking and Lean Thinking have something in common...

One major finding from the design thinking project described below was the fact that despite the short timeline of three months, it was more than worth spending over week with user research and backlog refinement.

Hence, Design Thinking suggests to spent sufficient time for observing and conducting user research to better understand the underlying problem space, customer needs, and develop some serious empathy and thus better requirements. This enables teams and organizations to build products that are desirable, feasible, and viable in the first place...

Lean Thinking, on the other hand, reserves time to analyse which processes directly contribute to customer values, which ones are non value-adding but nonetheless necessary, and which ones are obviously waste. Retrospectives in Scrum (see for instance Ester Derby's tips & tricks) and other methods, such as A3-based problem solving (see Mike Rother's homepage) give guidelines on how to achieve continuous improvement, i.e. "sharpening the axe" efficiently and sustainably...

From User Research to Product Backlog - First Experience with Design Thinking and Lean

Some months ago, I had the challenge to guide a team from complete ignorance of the product domain towards a backlog and a first release after barely three months - luckily, they were very smart and eager to learn...

So we also heard of design thinking and how it has been successfully applied to grasp the customers' need and desire across different industries, including software (see Tim Brown's blog, for instance). Hence, we engaged an experienced coach for the team and started user research to better understand the domain and the problems at hand. We even spent a full week at a major event, observed, conducted interviews, and exchanged our experience within the team.

Based on that first-hand experience, we conducted a 3-day workshop after the event (see agenda poster in the picture): On day 1, we brough all our experience together in the form of a "storytelling session", so that everybody in the team is on the same page. Due to the plethora of data points and observations, we had to cluster and select certain topics to focus on. In particular, we focussed on two major personas as assumed future users of our software. We created their profiles and wrote down what motivates them, what they liked and what they don't like about their daily business. Still on day 1, we also created an initial product vision in the form of a fictitious product box (lead by the product owner as moderator) and gathered the first low-fidelity paper prototypes for possible features (entire team)... On day 2, we took on these results (personas, vision, and features) and started building up the product backlog in the form of a story map (see Jeff Patton's homepage). In this two-dimensional map (priority on the vertical and usage sequence from customers' perspective on the horizontal axis) we collected and arranged the first set of user stories (see Mike Cohn's contributions for Mountain Goat Software). At this point, the whole team was capable and motivated to describe the requirements from the formerly unknown domain from a user perspective, i.e. in the form of user stories along a typical usage sequence. On day 3, we decided on which agile process framework to use (Scrum) and the team's detailed working model (sprint length, done criteria, tooling, etc.).

On day 4 we started working... (to be continued)

Scrum Day 2011 - Agile Software Product Development at SAP

--> see my talk at the Scrum Day 2011 (28 September, Darmstadt, Germany):

http://www.scrum-day.de/vortraege/agilesoftwareproductdevelopmentatsap.html

Abstract:

After more than four years of successful experience with Scrum (worldwide 300+ projects), SAP has decided to introduce a Lean Software Development Model at a large scale in its development organization based on Scrum. The presentation describes the approach including Lean introduction and transformation models, Scrum scaling concepts , key success factors and challenges for an organization with approx. 10.000 people. The audience will participate in one of the most challenging and fascinating Scrum introductions underway including real life examples.

Agility and Reuse in Large-Scale Enterprise Software Development

As I mentioned before, large-scale settings on the development side and complex enterprise software as product make achieving agility and efficiency even harder to achieve. Efficiency can, for instance, be improved by managed reuse of existing solutions, components, code as well as other artifacts.

However, this leads to lots of non-trivial trade-off decisions and conflicts among different organizational units (within and/or between companies).

This in turn made me design an according lecture at the University of Mannheim...

Here comes agile - or even lean - development

After some years of maturing both, technology-wise and with respect to development processes, a paradigm of iterative and incremental software product development emerged - today this is called agile development and deeply intertwined with values stemming from lean thinking which is rooted in the automotive industry, e.g. the well-known Toyota Production System (TPS).

It is not by chance that some agile pioneers, such as Kent Beck, had a history of software projects in the automotive before compiling and agreeing the agile manifesto in 2001...

Software Requirements Engineering - quo vadis?

After 8 years in the software industry and software engineering research, one topics comes back over and over again: requirements engineering - or how to build the right software right?

That is, this “simple” process of understanding what the user wants and deriving a useful solution for that problem as well as building that solution in an efficient manner.

Traditional requirements engineering assumed that the more time you invest upfront, the better the specification (as collection of requirements) will get and thus the rest of the project is just about implementing this set of requirement.

However, as numerous projects in the industry showed this assumption might be flawed. The fact that software in an intangible good and that software vendors promise to be able to solve any given problem with their solutions does not really help either…