Zu den positiven Auswirkungen des Aufstiegs der agilen Softwareentwicklung gehört die Verbreitung des Konzepts, eine große Menge Anforderungen in kleinere Stücke aufzuteilen. Diese Stücke – Stories – erlauben viel bessere Einblicke in den Fortschritt eines Entwicklungsprojektes. Wenn ein Produkt Story für Story entsteht und jede Implementation einer Story vollständig in das Softwareprodukt integriert ist, kann jeder sehen, wie das Produkt wächst. Dadurch, dass sie Stories verwenden, die aus Usersicht Sinn ergeben, können Entwickler ihr Projekt steuern, indem sie festlegen, welche Stories sie als Nächstes bearbeiten werden. Die bessere Sichtbarkeit fördert eine stärkere Mitwirkung von Userseite – Sie müssen nicht mehr ein Jahr oder länger darauf warten, dass Sie sehen können, was das Entwicklerteam so getrieben hat.

Die Zerstückelung hat aber auch negative Konsequenzen. Dazu gehört, dass man schnell den Überblick darüber verlieren kann, was die Software als Ganzes tun soll. Man kann ein Durcheinander an Stücken herausbekommen, die nicht in ein zusammenhängendes Ganzes passen. Oder man baut ein System, das den Usern nicht wirklich etwas nutzt, weil einem zwischen all den Details der Sinn für das, was im Kern benötigt wird, abhanden gekommen ist.

Story Mapping ist eine Methode, mit der der Gesamtzusammenhang hergestellt werden kann, den ein bloßer Haufen von Stories oft vermissen lässt.

Und das war's auch schon – die Beschreibung dieses Buches in einem Satz. Dieser Satz trägt in sich ein großes Versprechen. Der Blick auf das große Ganze hilft dabei, mit Usern effektiv zu kommunizieren, er hilft allen Beteiligten, zu vermeiden, unnütze Features zu produzieren, und er dient als Orientierungshilfe für eine in sich stimmige User Experience. Wenn ich mit meinen Kollegen bei ThoughtWorks darüber spreche, wie sie ihre Stories entwickeln, nennen sie Story Mapping regelmäßig als Schlüsselmethode. Häufig haben sie die Methode in Workshops mit Jeff gelernt, denn er hat die Methode entwickelt und kann sie am besten kommunizieren. Dieses Buch gibt mehr Menschen die Möglichkeit, die Methode direkt an der Quelle zu erlernen.

Aber dieses Buch ist nicht nur etwas für Leute, die einen Titel wie »Business-Analyst« auf der Visitenkarte oder ihrem Online-Profil stehen haben. Eine der größten Enttäuschungen für mich war in diesem Jahrzehnt, in dem agile Methoden immer mehr Anwendung fanden, dass viele Programmierer Stories als eine Kommunikations-Einbahnstraße vom Analysten zu ihnen ansehen. Von Anfang an waren Stories als Zündfunken für Konversationen gedacht. Wenn man sich tatsächlich effektive Softwarelösungen für bestimmte Tätigkeiten ausdenken will, muss man diejenigen, die die Software schreiben, als lebenswichtige Ideengeber für die Einsatzmöglichkeiten betrachten, denn es sind die Programmierer, die am besten wissen, was Software leisten kann. Programmierer müssen verstehen, was ihre User zu erreichen versuchen, und sollten kollaborativ Stories entwickeln, die diese Bedürfnisse der User abbilden. Ein Programmierer, der Story Mapping beherrscht, ist besser in der Lage, den Kontext des Users zu erkennen, und kann dabei helfen, die Software zu umreißen – und somit seine Arbeit besser zu machen.

Als Kent Beck (auf den der Gedanke der »Story« zurückgeht) seine Ideen zur Softwareentwicklung erarbeitete, bezeichnete er Kommunikation als Schlüsselwert für effektive Teams. Stories sind die Bausteine der Kommunikation zwischen den Entwicklern und denen, die ihre Arbeit benutzen werden. Story Maps organisieren und strukturieren diese Bausteine und verbessern damit den Kommunikationsprozess – der den wohl wichtigsten Part der Softwareentwicklung darstellt.

In Mary Shelleys berühmtem Science-Fiction-Roman Frankenstein erschafft der wahnsinnige Dr. Frankenstein eine Kreatur aus verschiedenen Stücken toter Menschen und erweckt diese Kreatur mit der damals neuartigen Technologie der Elektrizität zum Leben. Natürlich wissen wir, dass das eigentlich nicht möglich ist. Man kann kein Leben erschaffen, indem man zufällige Körperteile zusammennäht.

Und doch ist es das, was Softwareentwickler immer wieder versuchen: Sie erweitern eine Software um gute Features, eins nach dem anderen, und dann wundern sie sich, wieso so wenige User ihr Produkt gut finden. Der Kern des Problems liegt darin, dass Entwickler ihre Konstruktionsmethode als Design-Tool benutzen, die beiden aber nicht untereinander austauschbar sind.

Es ist absolut sinnvoll, dass Programmierer die Software Feature für Feature produzieren. Das ist eine hervorragende Strategie, die sich jahrelang bewährt hat. Was sich allerdings auch über die Jahre gezeigt hat, ist, dass der Ein-Feature-nach-dem-anderen-Ansatz – setzt man ihn als Designmethode für das Verhalten und den Umfang eines digitalen Produkts ein – zu einem Frankenstein'schen Monster(-Programm) führt.

Wenn sie auch eng verwandt sind, so unterscheiden sich die Praxis des Softwaredesigns und die der Erstellung ebendieser Software doch deutlich voneinander und werden üblicherweise von verschiedenen Personen mit unterschiedlichen Skills absolviert. Zahllose Stunden damit zuzubringen, User zu beobachten und Verhaltensmuster zu mappen, wie das die Interaktionsdesigner tun, würde die meisten Programmierer in den Wahnsinn treiben. Umgekehrt wäre stundenlanges Brüten über Algorithmen eine viel zu einsiedlerische Tätigkeit für die meisten Designer.

Aber wenn diese beiden unterschiedlichen Ansätze – Design und Entwicklung – zusammenarbeiten, kommt eine elektrische Spannung auf, die das Potenzial besitzt, ein lebendes, atmendes Produkt zu erschaffen. Teamarbeit haucht dem Monster Leben ein und bringt die Leute dazu, es zu lieben.

Zwar ist die Idee der Zusammenarbeit weder neu noch sonderlich aufschlussreich, aber es ist dennoch sehr schwer, sie tatsächlich effektiv umzusetzen. Die Arbeitsweise der Entwickler – ihr Tempo, ihre Sprache und ihr Rhythmus – unterscheidet sich sehr von der der Interaktionsdesigner.

Die Fachleute beider Gebiete sind stark, kompetent und innerlich diszipliniert, aber sie haben beide die gleiche Schwäche: Es ist wirklich schwer, ein Designproblem in Programmierersprache auszudrücken, und es ist ebenso schwer, ein Entwicklungsproblem in der Sprache der Designer zu formulieren. Die beiden Schwesterdisziplinen haben keine gemeinsame Sprache. Und genau dort, auf der Kreuzung zwischen den beiden Disziplinen, finden wir Jeff Patton.

Jeffs Methode des Story Mapping ist für Entwickler gut verständlich, und sie ist ebenso gut verständlich für die Designer. Story Mapping ist der Rosetta-Stein des digitalen Zeitalters.

Trotz gegenteiliger Behauptungen ist die agile Entwicklung kein sonderlich gut geeignetes Designwerkzeug. Es handelt sich um eine Art, über Entwicklung nachzudenken, die designfreundlich ist – was eine gute Sache ist –, aber für sich genommen, führt sie nicht zu einem Produkt, das die Nutzer toll finden. Auf der anderen Seite kann man oft erleben, dass gute, wohldokumentierte Designs in die Hände von Entwicklern gelegt werden, die dann – agil oder nicht – die inneren Werte dieses Designs in der Umsetzung vollständig plätten.

Pattons Story-Mapping-Ansatz ist ein Brückenschlag über diesen Abgrund. Beim Interaktionsdesign geht es darum, die Wahrheit des Users zu finden und als Erzählung abzubilden. In der Softwareentwicklung geht es darum, diese Erzählung in kleine, funktionale Stücke zu zerlegen und diese wiederum zu implementieren und zu integrieren. Es passiert ganz schnell, dass in diesem komplexen Prozess der Wesenskern der Erzählung flöten geht. Ja, die Funktionen wurden implementiert, aber der Patient stirbt auf dem OP-Tisch.

Indem es die User Stories als Landkarte auslegt, behält das Design seine narrative Struktur, kann aber dennoch für eine effektive Implementation dekonstruiert werden. Die Geschichte des Designers, die eine formalisierte Fassung der User Story ist, bleibt durch die gesamte Entwicklung hindurch intakt.

Die klassische Welt der Konzerne hat bewiesen, dass es nahezu unmöglich ist, mit Teams von zwei- oder dreihundert Leuten Produkte herzustellen, die jemand wirklich richtig gut findet. Die Startup-Community wiederum hat bewiesen, dass ein Team aus vier oder fünf Personen sehr wohl kleine Produkte machen kann, die die Leute mögen. Aber selbst solche Produkte werden irgendwann groß und verlieren diesen inneren Funken. Die Herausforderung, der wir uns stellen müssen, ist, große Software zu erschaffen, die die Leute lieben. Große Software bedient große Gruppen von Nutzern, die komplexe, kommerziell relevante Aufgaben damit verrichten. Es ist unglaublich schwer, solche Software so zu gestalten, dass ihre Benutzung Spaß macht und leicht zu erlernen ist.

Die einzige Methode, auf die wir große Software produzieren können, die kein Frankenstein'sches Monster ist, ist, indem wir lernen, das Softwaredesign und die Entwicklung miteinander zu vereinen. Und niemand weiß das besser als Jeff Patton.

Ich hatte das große Glück, mit vielen der besten Technologieteams der Welt arbeiten zu dürfen. Mit Menschen, die die Produkte erschaffen haben, die wir jeden Tag benutzen und gern haben. Teams, die im Wortsinn die Welt verändert haben.

Man hat mich auch hinzugezogen, um Firmen zu helfen, bei denen es nicht so gut lief. Startups, die Bodenhaftung bekommen mussten, ehe ihnen das Geld ausging. Größere Firmen, die versuchten, ihre frühen Innovationen zu replizieren. Teams, die es nicht schafften, etwas Wertvolles zum Unternehmen beizutragen. Führungskräfte, die darüber frustriert waren, wie lange es dauerte, bis aus einer Idee Realität wurde. Techniker, die über ihre Produkt-Owner verärgert waren.

Ich habe dabei gelernt, dass es einen wesentlichen Unterschied dazwischen gibt, wie die besten Firmen ihre Technologie-Produkte erschaffen, und wie der Rest es macht. Und damit meine ich nicht kleine Unterschiede. Ich meine alles, angefangen davon, wie sich Führungskräfte verhalten, über das Empowerment von Teams und die Art und Weise, wie Teams zusammenarbeiten, bis hin zur Unternehmenskultur und der Art und Weise, auf die Produktentwicklung, Design und Technik gemeinsam daran arbeiten, effektive Lösungen für ihre Kunden zu erschaffen.

Dieses Buch trägt den Titel User Story Mapping, aber ihr werdet schon bald merken, dass es um sehr viel mehr geht als nur diese einfache, aber wirkungsvolle Technik. Dieses Buch reicht bis in den Kern der Frage hinein, wie Teams zusammenarbeiten, kommunizieren und schlussendlich gute Dinge finden, die es sich lohnt zu produzieren.

Viele von euch hatten noch nie die Gelegenheit, aus der Nähe mitzuerleben, wie ein starkes Produktteam arbeitet. Alles, was ihr möglicherweise kennt, ist das, was eure jetzige oder vorige Firma tut. Deswegen möchte ich versuchen, hier einen kleinen Eindruck davon zu vermitteln, wie stark sich die besten Teams vom Rest unterscheiden.

Mit einer dankbaren Verneigung vor Ben Horowitz’ Good Product Manager, Bad Product Manager habt ihr hier einen flüchtigen Einblick in einige der entscheidenden Unterschiede zwischen starken Produkt-Teams und schwachen Teams:

Mir ist klar, dass ihr euch vielleicht fragt, was das alles mit Story Maps zu tun hat. Ich glaube, ihr wärt überrascht. Und genau deswegen bin ich ein Fan von Story Maps.

Ich habe nur wenige agile Experten getroffen, die ich für qualifiziert halte, einem Produktteam dabei zu helfen, sich so sehr zu verbessern, dass es das leisten kann, was seine Firma braucht und verdient. Jeff Patton ist einer davon. Ich habe erlebt, wie er mitten in der Produkt-Discovery mit Teams in den Schützengraben stieg und die Ärmel hochkrempelte. Ich stelle ihn gern Firmen vor, denn er ist effektiv. Teams mögen ihn, weil er Ahnung hat, aber ein bescheidener Typ ist.

Die Tage, in denen Produktmanager Anforderungen zusammenstellten und dokumentierten, in denen Designer sich abmühen mussten, um auch nur einen Hauch Lippenstift auf den Look auftragen zu können, und in denen sich die Techies im Keller verschanzten und Code tippten, sind bei den besten Teams lange vorbei. Und es ist an der Zeit, dass sie auch in eurem Team vorbei sind.

Ich stelle gern Sachen her. Was mich motiviert, ist, dass es mir Freude macht, Software zu erschaffen und zu sehen, wie Leute sie benutzen und davon profitieren. Ich bin ein wenig zögerlich, wenn es um Methodologie geht. Ich habe festgestellt, dass ich erst lernen muss, wie Prozesse und Verfahren funktionieren, um sie besser einsetzen zu können. Nach über 20 Jahren in der Softwareentwicklung lerne ich gerade erst, wie ich weitergeben kann, was ich selbst gelernt habe. Und ich weiß, dass das, was ich anderen beibringe, eine bewegliche Größe ist. Was ich verstehe, verändert sich jede Woche wieder. Wie man es am besten erklärt, verändert sich nahezu ebenso schnell. All das hat mich jahrelang davon abgehalten, ein Buch zu schreiben.

Aber die Zeit ist reif dafür.

Stories und Story Maps sind eine unglaublich gute Idee, von der schon sehr viele Leute profitiert haben. Sie haben das Leben der Entwickler besser gemacht, und ebenso die Produkte, die diese entwickelt haben. Aber während sie manchen zu einem besseren Dasein verholfen haben, ringen auch immer mehr Leute mit Problemen, die sie mit Stories haben. Ich möchte dazu beitragen, dass das ein Ende hat.

Dieses Buch ist etwas, das ich beitragen kann, um zu helfen. Und wenn es auch nur das Arbeitsleben einer Handvoll Leute verbessert, habe ich einen Grund zu feiern.

Eine Menge Firmen und Organisationen benutzen heutzutage agile und schlanke (»lean«) Prozesse, und damit auch Stories. Dabei passiert es schnell, dass man in eine oder mehrere Fallen tappt, sofern man falsche Vorstellungen von Stories hat. Und zwar Fallen wie diese:

Wenn ihr schon mal in eine dieser Fallen gestolpert seid, werde ich versuchen, die Fehlannahmen zu beseitigen, die dazu geführt haben. Ihr werdet lernen, wie man im Gesamtzusammenhang denkt (das »Big Picture«), wie man im Großen wie im Kleinen plant und schätzt, wie man produktive Konversationen darüber führt, was User zu erreichen versuchen, und was eine gute Software tun kann, um ihnen dabei zu helfen.

Du natürlich. Ganz besonders, wenn du es gekauft hast. Ich persönlich denke, das war eine weise Investition. Wenn du es dir nur ausgeliehen hast, bestell dir gleich dein eigenes Exemplar und gib dieses hier zurück, sobald dein Buch ankommt.

Tatsächlich ist die Lektüre dieses Buches aus verschiedenen Gründen besonders vorteilhaft für Leute mit ganz spezifischen Aufgaben:

Ich hoffe, ihr könnt euch mit einer oder mehreren der beschriebenen Gruppen identifizieren. Falls nicht, reicht dieses Buch an jemanden weiter, der das kann.

Falls ja, lasst uns anfangen.

Ich gehe davon aus, dass dies nicht das erste Buch zu Softwareentwicklung ist, das ihr in eurem Leben in Händen haltet, von daher sollte euch nichts überraschen.