Posts will go on...

Please expect new post on how to build the right software right to come this March ff.

Tobias.

Design Thinking: "How might we help different generations to benefit from each other?"

In a recent Design Thinking camp for future coaches, we worked on the challenge of "how to re-design the professional networking experience". On of the teams came up with the idea of a platform to bring older and younger generations closer together. This was based on some key insights concerning the need of younger people to gain professional experience and built up a personal network as well as the fact that older generations often look for new challenges but do not feel so comfortable with the latest tools and technology, e.g. facebook and linkedin.

The German city of Wiesloch on the other hand is supporting generation-spanning ideas and projects - hence, we will train a team of students with business and computer science background to apply Design Thinking in these kind of projects, where it is key to understand the needs and concerns of distinct user profiles and develop empathy as well as innovative solutions.

Impressions and first results from these workshops will follow...

Fusion Modeling - Lean, Agile and Design Thinking

29 October 2012, I met Matthias Pohle from Swisscom. Awesome character and very competent in product management and innovation approaches.

We conducted a little lean, agile and design thinking cross-over session from both our company perspectives (see red and blue visuals above) - Swisscom calls this "fusion modeling", i.e. take the methods that help the team in a particular situation and don't be religious about being pure in one single method...

One thing I learned from Matthias was how to include the relevant stakeholders from the very beginning of an product innovation effort. In an approache called "speed creation", these stakeholder are in the project jury...

What Kids and Students have in common...

When teaching requirements engineering, lean and agile development, and design thinking at university, it's always surprising to me how natural the latter approaches are to students. In the same manner, you do not have to teach creativity to little kids - they just are creative and act accordingly.

In this year's Design Thinking and Lean Development class at the University of Mannheim, for instance, it was really a pleasure to teach design thinking in a 3-hour workshop format. As opposed to many experienced developers, the students couldn't wait to transfer the few "theoretical inputs" into practice with their challenge "how to redesign the mobile experience for students on campus" (or "off campus" as alternative challenge). 

Find some highlight results below - story to be continued...

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