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)