Springe zum Inhalt

Seit einiger Zeit beschäftigte ich mich mit Design Thinking. Diese Methode hat eigentlich nichts mit Software-Entwicklung zu tun. Sie soll dazu dienen, innovative Ideen hervorzubringen. Agile Methoden verfolgen in erster Linie das Ziel, auf Veränderungen der Anforderungen zu reagieren. Aber wie kommt der Anwender oder Kunde überhaupt auf die richtigen Anforderungen?

Was ist Design Thinking?

Diese Methode basiert auf eine Reihe von Werten und Prinzipien, die jedoch nicht so gut niedergeschrieben sind, wie die Werte und Prinzipien im Agilen Manifest. Die beiden Wertesysteme sind aber sehr ähnlich und daher kompatibel. Zusammengefasst ist bei Design Thinking folgendes wichtig:

  • Gutes Design ist nicht das Ergebnis eines einzelnen, sondern eines interdisziplinären Teams.
  • Teams arbeiten iterativ in festen Zeitrahmen (Timebox).
  • Jeder wird zum Experimentieren ermutigt.
  • Fehler werden als Anlass zum Lernen angesehen.
  • Teams involvieren echte Benutzer in ihre Arbeit.
  • Jeder lässt sich inspirieren von anderen Ideen, Prototypen und Lösungen.
  • Empathie ist notwendig, um die Bedürfnisse der Benutzer zu ergründen.

Ein wichtiger Aspekt vom Design Thinking ist das interdisziplinäre Team, also ein Team, was sich in einer Firma aus verschiedenen Bereichen rekrutieren würde. Zu einem solchen Team könnten z.B. Techniker und Marketing-Leute gehören. Dieses Team durchläuft einen Prozess, der jedoch nicht starr und rigide ist. In den Prozess können je nach Bedarf Iterationen eingefügt werden. Ein wichtiger Bestandteil dieses Prozesses ist die Entwicklung von Prototypen, die dann an echten Benutzern getestet werden.

Konkret beschäftig sich Design Thinking nicht nur mit Werten und Prozessen, sondern auch mit Praktiken, in die in einzelnen Phasen des Prozesses angewendet werden können. Dazu gehören, z.B.:

  • Story Telling
  • Verschiedene Brainstorming Techniken
  • Prototyping

Wir bezeichnen Design Thinking auch als einen "Body of Knowledge", der von verschiedenen Seiten weiterentwickelt wird. Im letzten Jahr fand in Deutschland die erste Design Thinking Konferenz statt. Mittlerweile entwickeln sich lokale Gruppen, die sich mit Design Thinking beschäftigen. Aktuell wird gerade die Gruppe Design Thinking München gegründet.

Product Owner als Flaschenhals

In der agilen Methode Scrum ist der Product Owner verantwortlich für das Hervorbringen und Priorisieren der Anforderungen. Er legt die Anforderungen als User Stories ins Product Backlog und das Entwicklungsteam setzt diese Anforderungen um. Aber wie kommt der Product Owner zu den richtigen Ideen? Sind die Features, die er umgesetzt haben möchte, die richtigen? Da er eng mit dem Team zusammenarbeitet ist die Situation viel besser als im herkömmlichen Wasserfall. Der Product Owner kann direkt Ideen auf technische Machbarkeit mit dem Team klären. Ob diese Ideen dem Kunden bzw. Anwender der Software helfen und mehr als ein "Me Too"-Feature sind, wird mit dem agilen Vorgehen nicht angegangen.

Wedding Day by flickr:Mike_fleming

Die agile Community hat dieses Problem erkannt und schaut über den Tellerrand. Design Thinking bietet Anregungen, die Arbeit des Product Owner anders zu organisieren, sodass innovativere Produkte entstehen. Viele Konferenzen haben mittlerweile Design Thinking als Thema, so z.B. die SEACON in Hamburg oder die XP2012. Pierluigi Pugliese und ich waren bereits mit dem Vortrag "Innovation needs Waste!" auf verschiedenen Konferenzen. Ich bin gespannt, wie sich der "Body of Knowledge" Design Thinking mit dem der Agilen Softwareentwicklung verbindet. Beide Communities können von einander lernen.

I had a discussion recently with a colleague about the usefulness of the Last Responsible Moment (LRM) in the context of a complex project. The LRM is when the Cost of Delay overweights the Benefits of Delay. In other words, it's often useful to wait with a decision until a certain point - last responsible moment - before the cost of making a decision too late will be higher than the benefits. I want to come up with an example that may happen quite often in a project:

Lets assume you want to order server hardware that will host your web application. If you order it very early, you may not have enough information to buy the hardware properly sized. Later in the project you may have enough information to make the decision about the hardware sizing. But ordered too late there is a risks that the hardware will not be up and running before the release date and you will loose some expected income from your web application.


We came to the conclusion that the LRM makes practically no sense. The only thing we know is that not all decisions have to be made in the beginning. The nature of complexity is that we cannot plan all details in advance. Only after a project has finished, we know exactly which decisions have been made correctly. Although there exists a LRM, we cannot find it in advance (in complex software projects). By focusing too much to find the LRM in advance, we may actually risk that some business value is not delivered.

Of cause, if we can quantify the Cost of Benefit and Delay then we can find the LRM. It may also help us to know about the LRM while we are still making decisions trusting our guts. But agile coaches should teach the whole story, so people avoid gambling for the LRM.

Ken Schwaber explained the changes to Scrum in a Keynote at the Scrum Day in Germany. One major change is the renaming of the Sprint Commitment to Sprint Forecast. Ken said that some Product Owners were yelling to the team that had just missed to Sprint Commitment. I understand that this yelling is not something you want to have when you introduce Scrum.  Scrum and agile methods in general rely on highly motivated teams. Choleric Product Owners wont help you. But is the reason for this behaviour the much more binding term "Commitment"?

From http://www.flickr.com/photos/fabiovenni/

If a team fails to meet the commitment, then this may be an indicator for two things:

  1. change in the environment of the team is needed
  2. the problems the team has to solve are to complex.

In both of these two circumstances the team or the organisation should learn and improve. The team can learn how to better cope with the complexity of the given problems and the organisation can learn how to transform to support the teams better to get things to done. IMO: Renaming the Sprint Commitment to Sprint Forecast will take away the urgency of the necessity to learn.

We find commitment in many cultures. The Germans for instance are well known for their punctuality. Everybody commits to be at a certain place on time. It reduces the time to wait and people can start working immediately. Every German who has worked in another country realizes how this behaviour helps to get things done and avoids wasting time. Commitments help us to better work together.

In the organisation we have commitments on various level. Shareholder, investors and owners give their capital and want commitment from the board that the investment will have a return. Customers pay for the products and services and want commitment from the vendor to keep the promises. Employees want a commitment that they get a monthly salary. There are commitments everywhere on the boundaries of the organisation. Inside the organisation we have managers who commit to certain goals, e.g. increase revenue, create innovative products or reduce costs.

Is a commitment by a team to deliver some value after two weeks not possible within a learning organisation?

Related to my last post on the need for documents during the design of software, I came across the topic of Design Thinking. Unlike analytical thinking, Design Thinking is aimed at building up ideas. It fits perfectly to agile methods, because it requires iterations and team work. I would say that agile methods include many parts of the theory of Design Thinking.

Here are some statements that I want to make related to Design Thinking:

  • A team should know the theory of Design Thinking in order to support best the generation of ideas. Agile coaches should explain to team, how ideas and solutions are created and what hurdles will probably in its way.
  • Our education has formed us to pick the first best idea and carry on with it. That may not be the very best idea to solve a problem. We have learnt that creating bad ideas is unacceptable. Children are very creative and can come up with lots of variations. We learn at school and from our parents what is right and get punished for what is wrong. Therefore we try to create right ideas and hesitate to communicate bad ideas. This blocks the idea generation within ourselves and within a team. If a team can overcome this issue, the creative output of the team will be higher. A team should be aware of this issue and create trustful relationships. This relates to "phychological safety" that is higher developed in a long lived team.
  • We also have another problem with intuition. If people bring up ideas, the ideas are discussed in a team to validate and merge them with other ideas. If someone has a intuitive idea, it will be difficult for him to explain it. He or she just knows that it's right. But without explaining the idea, the collaborative process to build a common understanding will fail. Either the idea will be lost - and maybe it is the very best solution - or someone else can explain it. This also relates to leadership. Leaders can have intuative ideas and others may simply follow without understanding it. They trust the leader.

Well, I think that a team that is aware of the principels of design thinking can use it to create better solutions. It may also help the team to create trustful relationships quicker.

It's common sense in the agile community that design is emerging during the development. Some extremist state that modelling before coding is not necessary at all. Well, that is not true. But is it necessary to create design documents to capture the models?

Every problem solving for even a little complex problem is done by an evolutionary process. Evolutionary means that variations are created and the best variant is selected. If design is a solution for a problem, then the process to get to a design will look like this:

  1. The developer creates variations of possible solutions in his brain. By playing virtually with it, he finds and selects the best solution.
  2. Then the developer will collaborate with other developers and compare the possible solution. They select again the best solution or may even find a better one. This step creates a common understanding.
  3. The final step is that the solution is put into the code. That really proves it and the common understanding from the second step will help if multiple developers implement the solution. During this the solution may even be amended iteratively by going back to step 1 and 2.

First of all it's important to note, that the inital step is to create a possible solution in the brain of the developer. That requires creativity and experience. Good developers will come up with good solutions. But nobody is perfect and other developer with different experience may come up with other solutions.

In the second step the solutions can be merged together. That works best with synchronous collaboration and a modelling technique. An asynchronous review process (send review comments via email) is inefficient. Also, developers can come up with solutions that wont be selected - they are wasted. It's a nature of the evolutionary process that variants are wasted. The question is, how much effort has be invested into the variant and is it possible to create a variant with less effort.

The third step will transfer the solution - at this point it is only an idea of a solution - into the code. Only with the code the solution becomes real.

In which part of this process do we need design documents? While a developer thinks about the solution, he can write it down. That can be done with a word processor, modelling tool or paper and pen. He is maybe so bright that he actually don't need to write it down. Given that in the second step the solution variant may not be selected, he should invest not much effort. But he needs something to show the solution to others. In the ideal scenario, he has it in his head and draws it on a whiteboard by talking to others. After the second step the developers may want to fix the common understanding, because it may take some days to implement it. You could take a white board photo and store it on the wiki. After the third step the solution is in the code. The common understanding may have changed a little.

The light weight documentation (paper/pen, whiteboard, photo) may not be useful when you have large systems and bigger changes. But that would require a more high level design, aka architecture. An architecture is more long term, may change but not quickly. Also a developer cannot implement the architecture in a few days. It is more a guidance for lower level designs. Architecture and high level design documents can be reasonable. And - documentation for later maintainance is reasonable as well. It depends on the effort to what level starting from the highest level you want to create the documentation.