Roadmap durch die VUCA-Welt

Der Scrum Master hat dafür drei große Fokuspunkte, auf die er sich konzentriert. Zum einen unterstützt er den Product Owner. Er hilft ihm, die Anforderungen zu priorisieren und mit dem Entwicklungsteam in kleine, zu bearbeitende Aufgaben zu zerlegen. Zudem hilft er dem PO, sich in der agilen Produktplanung zurechtzufinden.

Als Zweites richtet der Scrum Master seine Aufmerksamkeit auf das Entwicklungsteam. Hier liegt sein Fokus darauf, das Team zu einer Selbstorganisation zu befähigen und die Zusammenarbeit zu verbessern. Dafür muss der Scrum Master ganz auf seine Überzeugungskraft und seine Coaching-Fähigkeiten zurückgreifen, denn in Scrum ist niemand vorgesehen, auch nicht PO oder Scrum Master, der in irgendeiner Form weisungsbefugt wäre.

Und zuletzt ist die Rolle des Scrum Masters auch dazu gedacht, in die Organisation hineinzuwirken. Wenn man mit Scrum beginnt, wird man schnell feststellen, dass gewisse Hindernisse, die eine selbstorganisierte Arbeit verhindern, nicht nur innerhalb der Teamgrenzen zu finden sind. Viele Probleme und Herausforderungen sind teamübergreifend und zum Beispiel in vorhandenen Strukturen oder Prozessen begründet. Es ist unvermeidlich, dass ein Unternehmen, das sich agil aufstellen möchte und dafür Scrum einführt, sich auch organisatorisch deutlich verändern muss.

Exkurs | Rollen und Positionen

Scrum definiert drei Rollen. In vielen klassischen Organisationen besteht eine sehr starke Fokussierung auf Positionen. Auch wenn beide Begriffe oft synonym verwendet werden, besteht hier ein deutlicher Unterschied. Eine Position ist untrennbar mit einer Person verknüpft. Frau Maier oder Herr Müller haben eine Position inne. An diese Position wiederum sind gewisse Rechte und Pflichten geknüpft. Ein Projektleiter trägt die Verantwortung für ein bestimmtes Projekt und hat vielleicht ein Budget zur Verfügung und dann auch eine Weisungsbefugnis für die Projektbeteiligten. Positionen sind in der Regel ein Kästchen in einem Organigramm, in dem ein bestimmter Name steht.

Rollen hingegen definieren erst einmal nur Verantwortlichkeiten, sind aber nicht personenbezogen. Das heißt, die in einer Rolle definierten Verantwortlichkeiten müssen erfüllt werden, aber es ist nicht unbedingt festgelegt, welche Person dies tut. Somit kann eine Rolle auch durch mehr als eine Person ausgefüllt werden, indem man beispielsweise die Verantwortlichkeiten aufteilt.

In sehr vielen Unternehmen wird eine Rolle an eine Position geknüpft. In manchen Fällen ist der Product Owner, der in Scrum als Rolle definiert ist, eine feste Position mit einer zugeordneten Person. Andernorts sind an die Position (das Kästchen im Organigramm) noch zusätzliche (nicht im Scrumguide definierte) Aufgaben, Rechte oder Pflichten geknüpft. Hier findet schnell eine Vermischung von Rolle und Position statt, die am Ende zu einem falschen Verständnis von den eigentlichen Rollen führen kann.

Neben diesen Rollen gibt Scrum auch ziemlich genau vor, welche Bestandteile es gibt und zu welchen Anlässen und wann die Teams zusammenkommen (Scrum Artefakte und Events).

Das Product BacklogProduct Backlog haben Sie ja schon kennengelernt. Es handelt sich dabei um eine Liste, die alle Arbeit enthält, die vom Team zu erledigen ist, um ein Produkt herzustellen. Diese Liste ist geordnet und die wichtigste Aufgabe befindet sich an der Spitze dieser Liste. Der Product Owner ist dafür verantwortlich, das Product Backlog aktuell zu halten und die Reihenfolge der Arbeit festzulegen. Die einzelnen Bestandteile des Backlogs nennt man Product Backlog Items. Diese werden oftmals in Form einer User Story (also aus der Sicht des Benutzers) geschrieben. Product Backlog Item ist alles, was eine Änderung am bestehenden Produkt darstellt, also zum Beispiel neue Anforderungen, Fehlerbehebungen oder die Beseitigung technischer Schulden.

Die Abarbeitung der Product Backlog Items erfolgt in Iterationen, sogenannten SprintsSprint. Ein Sprint ist per Definition maximal vier Wochen lang. Da die Vorausplanung mit zunehmender Länge der Iteration immer ungenauer wird, legt der Scrumguide hier diese Obergrenze fest. Für die meisten Teams hat sich eine Sprintdauer von zwei Wochen in der Praxis als guter Startwert herausgestellt. Es gibt aber auch Scrum Teams, deren Sprints nur einen Tag dauern, oder die sogar mehrere Sprints an ein und demselben Tag durchführen.

In einem gemeinsam Scrum Event (so nennt man bei Scrum die gemeinsamen Termine in Abgrenzung zu den gemeinhin oftmals als unproduktiv angesehenen „Meetings“), dem sogenannten Sprint PlanningSprint Planning, setzt sich das gesamte Scrum Team (Product Owner, Scrum MasterScrum Master und Entwicklungsteam) zusammen und überlegt, was es im nächsten Sprint voraussichtlich liefern kann. Dafür wird erst einmal ein Sprintziel festgelegt und dann Aufgaben aus dem Product Backlog ausgewählt, die zur Erreichung des Ziels notwendig sind.

Diese Aufgaben werden dann in das Sprint BacklogSprint Backlog übertragen. Dieses stellt somit eine Teilmenge des Product Backlogs dar und wird jeden Sprint neu angelegt. Die Aufgaben im Sprint Backlog werden so verfeinert, dass das Team jederzeit überprüfen kann, wie sein Fortschritt in Hinblick auf die Erreichung des Sprintziels ist. Es werden nur so viele Aufgaben in das Sprint Backlog übernommen, wie das Team meint, im nächsten Sprint fertigstellen zu können.

Im Laufe des Sprints erstellt das Entwicklungsteam ein Inkrement. Ein Inkrement besteht aus dem Ergebnis des aktuellen Sprints sowie den Ergebnissen aller vorheriger Sprints. Ein Produkt Inkrement wird also von Sprint zu Sprint immer größer und umfangreicher.

Damit die Arbeit selbstorganisiert stattfindet und möglichst gut abgestimmt wird, trifft sich das Entwicklungsteam täglich zur selben Zeit am gleichen Ort für ein Planungs- und Abstimmungsmeeting, dem Daily Scrum. Das Daily Scrum findet in aller Regel im Stehen statt (daher auch der alternative Name Daily-Stand-Up). Dies soll dazu dienen, dass die Teilnehmer sich kurzfassen und schnell zum Wesentlichen kommen. Alle Scrum Events haben eine Timebox (Zeitrahmen), also eine maximale Dauer, die nicht überschritten werden darf. Das Daily Scrum soll maximal 15 Minuten dauern und ist somit das kürzeste Scrum Event. Hervorzuheben ist, dass das Daily Scrum nicht dazu gedacht ist, den aktuellen Status zu berichten. Das Team soll sich gezielt abstimmen, wo man im Hinblick auf das Sprint Ziel steht, was noch zu tun ist, was in den nächsten 24 Stunden (bis zum nächsten Daily Scrum) erledigt werden kann und wie man sich am sinnvollsten aufteilt. Zudem sollen Hindernisse (Impediments) sichtbar gemacht werden, die die Arbeit behindern oder sogar verhindern.

Damit eine Aufgabe vom Team als erledigt gekennzeichnet werden kann, muss sie der Definition von Fertig (Definition of Done) entsprechen. Diese Definition stellt eine Checkliste dar, die alles enthält, was erfüllt sein muss, damit eine Aufgabe fertiggestellt ist. Diese wird häufig von dem Unternehmen vorgegeben, damit alle Scrum Teams nach den gleichen Qualitätsstandards arbeiten. Wenn auch nur eine geringe Kleinigkeit fehlt, darf eine Aufgabe nicht als fertig deklariert werden.

Am Ende des Sprints präsentiert das Scrum Team allen Interessierten das fertige Inkrement (also alle Aufgaben, die gemäß der Definition von fertig abgeschlossen wurden). Dies geschieht im sogenannten Sprint Review, das eine öffentliche Veranstaltung ist und zu dem der Product Owner alle interessierten Stakeholder einlädt. Gemäß dem Leitsatz von Scrum – Inspect & Adapt (Feedback einholen und Anpassen) – wird hier das Produkt Inkrement gezeigt und Feedback eingesammelt. Auch das Review ist somit kein einfaches Statusmeeting, um einen Fortschritt zu präsentieren, sondern eine wichtige Gelegenheit, um Feedback einzuholen und strategische Entscheidungen zu treffen. Neue Erkenntnisse hält der Product Owner im Backlog fest, mit dem er dann in das nächste Sprint Planning gehen kann.

Im Anschluss erfolgt dann ein weiterer Schritt, der dazu dient, Feedback einzuholen und eventuelle Anpassungen vorzunehmen: die Sprint Retrospektive. Hier kommt das Scrum Team zusammen und reflektiert gemeinsam den Entwicklungsprozess mit dem Ziel, Verbesserungsmaßnahmen zu definieren, die im Laufe des nächsten Sprints angewendet und in der folgenden Retrospektive auf ihre Wirksamkeit hin untersucht werden können. Diese werden dann auch gleich in das Sprint Backlog des nächsten Sprints eingetragen, damit das Team bei der Planung diese Aufwände mitberücksichtigen kann.

Prinzipiell geht der Zyklus an dieser Stelle wieder von vorne los, allerdings zeigt die Erfahrung, dass das Team auch eine gewisse Zeit in die Pflege und die Verfeinerung des Product Backlogs investieren muss. Diese Aktivität wird als Refinement bezeichnet. Der Scrumguide macht hier, im Gegensatz zu den klar definierten Scrum Events, keine klaren Vorgaben, wie das Refinement abzulaufen hat. Aber er gibt eine Empfehlung, die darin besteht, dass das Team bis zu 10 % seiner Zeit im Sprint für Refinement aufwenden sollte. Das Ergebnis – ein gepflegtes und feingranulares Product Backlog – wird dann als Eingabe für das nächste Sprintplanning genutzt.

Auch in Scrum gibt es Metriken, die helfen sollen, den Prozess kontinuierlich zu verbessern. Allerdings schreibt Scrum hier nichts vor. Viele Praktiker messen zum Beispiel gerne die Menge der Arbeit, die das Entwicklungsteam in einem Sprint erledigt hat. Dies wird dann als Velocity bezeichnet. Dafür muss die Größe der Aufgaben berücksichtigt werden, so dass man entweder alle Aufgaben in die gleiche Größe bringt oder aber die Größe schätzen und in Relation zueinander setzen muss. Hierfür werden meist Story Points verwendet. Dementsprechend wird auch die Velocity eines Teams in der Regel in Story Points pro Sprint angegeben.

Scrum und Kanban erheben beide nicht den Anspruch perfekt zu sein und die Antwort auf alle Fragen zu liefern. Im Gegenteil, sie ermutigen die Anwender dazu, Anpassungen vorzunehmen, um die Vorgehensweisen zu verbessern. Dies ist sicherlich eine gute Idee, denn die Erfinder konnten nicht jeden erdenklichen Kontext in ihre Überlegungen einbeziehen.

Shu-Ha-Ri und Cargo-Kult

Ich erinnere mich noch recht gut an einen Lieblingsfilm meiner Kindheit. Ein schmächtiger, schwarzhaariger Junge steht vor einem Auto. Ihm gegenüber steht ein kleiner Japaner mit einem Schwamm in der Hand. „Auftragen rechte Hand, polieren linke Hand“, leitet der kleine Japaner ihn an. Dabei solle er das Atmen nicht vergessen, ergänzt der wunderliche alte Mann, dann macht er die Bewegung noch einmal vor. Er übergibt dem sparsam dreinschauenden Jungen den Schwamm und überlässt ihn dann seiner Aufgabe. Der Junge ist verdutzt, will er doch eigentlich Karate lernen und sein Lehrer, Mr. Miyagi, lässt ihn nun mit einer Aufgabe stehen, deren Sinn er nicht versteht. Diese Szene aus dem Film „Karate Kid“ ist ein schönes Beispiel für ein Prinzip namens Shu-Ha-RiShu-Ha-Ri. Dieses Konzept aus der Kunst des fernöstlichen Kampfsports ist auch bei der Einführung und Umsetzung von Arbeitsweisen und Methoden hilfreich.

Die erste Stufe ist Shu, was so viel heißt wie „erhalten“ oder „gehorchen“. In dieser Phase sollte das, was der Lehrmeister sagt, minutiös befolgt werden, auch wenn der Sinn sich noch nicht so ganz erschließt. Bei den meisten Dingen, die wir neu lernen, verstehen wir manche Zusammenhänge erst, wenn wir sie mechanisch angewendet haben. So wie Daniel Larusso, der etwas verwundert ist, aber seinem Lehrmeister vertraut und seine Aufgaben erfüllt. Damit trainiert er Bewegungsabläufe ein, und wird immer sicherer bei deren Ausführung.

Abb. 15:

Shu-Ha-Ri in Kanji geschrieben

Wenn die Regeln befolgt wurden und wirklich verinnerlicht sind, dann folgt die zweite Stufe. Ha heißt in etwa „frei werden“ oder „abweichen“. Hier werden die Abläufe angepasst auf die jeweilige Situation. Es wird experimentiert und neues ausprobiert. Nur, wenn vorher die Regeln ganz genau befolgt wurden und verstanden wurden, ist das Verständnis da, warum manche Abweichungen funktionieren und manche eher nicht. Im Film ist Daniel schließlich in der Lage, die gelernten Bewegungsabläufe auch in einem Karate-Umfeld anzuwenden. Hier erscheint er erst noch überrascht, dass die Bewegungen fast von allein fließen. Da er aber aus den grundlegenden Übungen weiß, was ein positives Resultat und was ein negatives Resultat ist, kann er auch einschätzen, ob die kleinen Abwandlungen, die er vornimmt, hilfreich oder eher hinderlich sind.

Die dritte und höchste Stufe ist schließlich Ri. Übersetzt steht dies für „trennen“ oder „abschneiden“. Dies ist die Stufe der Meisterschaft. Die Prinzipien hinter den Regeln sind in Fleisch und Blut übergegangen und das Variieren, Anpassen und Entwickeln neuer Regeln stellt für den Meister keine Hürde mehr dar. Mister Miyagi ist in der Lage, die Elemente des Karate ganz einfach in Übungen zu übersetzen, die er seinem Schüler Daniel aufgibt. Als Meister ist er in der Lage einzuschätzen, dass auch das Polieren des Autos Daniel helfen wird, ein besserer Karatekämpfer zu werden. Er hat seinen eigenen Stil entwickelt, der seiner Persönlichkeit und seiner Individualität entspricht. Den Weg dorthin muss Daniel erst noch gehen, aber vielleicht wird er eines Tages auch selbst ein Meister sein. Dann wird er sich wahrscheinlich losgelöst haben von der Technik des Mister Miyagi und seinen ehemaligen Meister vielleicht sogar überflügeln. Dies ist ihm aber nur möglich, wenn er die vorherigen Stufen erfolgreich gemeistert hat.

Die beiden Autoren des Scrumguides Ken SchwaberSchwaber, Ken und Jeff SutherlandSutherland, Jeff haben schon in den ersten Sätzen darauf hingewiesen, dass Scrum ein einfach zu verstehendes, aber schwierig zu meisterndes Rahmenwerk darstellt. Befolgt man die Regeln, die im Scrumguide festgelegt sind, so stehen die Chancen gut, dass Scrum funktioniert. Erst wenn die Elemente verstanden wurden, macht die Anpassung Sinn. Oftmals tendieren unerfahrene Anwender dazu, die Regeln aufzuweichen, wenn sie „weh tun“. Zum Beispiel, wenn Aufgaben innerhalb eines Sprints nicht fertiggestellt werden können oder wenn jeder im Team ein Spezialgebiet hat, für das er allein verantwortlich ist. Gleiche Gefahr gilt bei Kanban, wo sehr schnell das WIP-Limit bei unerfahrenen Anwendern in Frage gestellt und aufgeweicht wird.

Begibt man sich einmal in die – sehr aktive – agile Community, die in so gut wie jeder größeren deutschen Stadt vertreten ist, und hört man den Teilnehmern an den Diskussionen aufmerksam zu, so wird man viel Frustration bemerken. Vieles rührt von einer nicht sachgemäßen Anwendung der Frameworks her. Dann wird gerne vom sogenannten Cargo-Cult gesprochen.

Ursprünglich war der Cargo-Kult eine Bewegung aus dem Bereich der Fidschi-Inseln und Neuguinea. Hier trafen im zweiten Weltkrieg die Inseleinwohner, die zuvor sehr abgeschieden lebten, auf die US-Armee, die die Inseln als Basis nutzten. Sie errichteten provisorische Flughäfen und Landebahnen und warfen auch Lebensmittel und westliche Kleidung über der Insel ab. Die Einwohner beobachteten die merkwürdigen Fremden und sahen, dass sie auf komische Türme stiegen und so etwas wie Schalen auf den Ohren hatten. Sie winkten mit Stäben und ab und zu fielen von den Göttern gesandte Pakete vom Himmel oder große, stählerne Wesen kamen aus der Luft und aus ihren Mäulern kamen mehr Menschen und Lebensmittel.

Als die Amerikaner irgendwann die Insel verließen, wollten die Einwohner nicht auf den Reichtum aus der Luft verzichten. Um die Götter zur Rückkehr zu bewegen, bauten die Einwohner die Einrichtungen der Amerikaner nach, setzten sich Kopfhörern nachempfundene Konstruktionen auf den Kopf und winkten mit Stäben in den Himmel. Aber kein Paket segelte auf die Insel hinab und kein großes Wesen landete mehr auf den Inseln. Die Einwohner konnten das nicht verstehen, sie taten doch alles genauso, wie die merkwürdigen Fremden es zuvor auch getan hatten.

Der große Unterschied bestand darin, dass sie nicht verstanden, warum es funktionierte, wenn die Amerikaner in den Himmel winkten. Gleiches Risiko besteht auch bei der Anwendung von Methoden, deren Wirkweise man (noch) nicht durchschaut hat.

Häufig liegt die Ursache darin, dass unterschätzt wird, dass die Verwendung agiler Methoden auch Veränderung auf allen Ebenen mit sich bringt. Folglich werden dann zu Beginn nur auf Teamebene Methoden etabliert, die schnell auf organisatorische Grenzen stoßen. Werden diese Grenzen nicht durchbrochen, dann führt dies zu Frust und Resignation. Nicht selten endet das dann darin, dass die agilen Methoden wieder abgeschafft werden. Dies ist aber auf Dauer keine Lösung, weil die VUCA-Welt nach Agilität verlangt. Die Bereitschaft zur Veränderung und die Fähigkeit zu verändern, stellt eine wichtige Kompetenz dar.

➤ Tipps für VUCA-Helden

Agilität stellt eine wichtige Kompetenz des 21. Jahrhunderts dar. Die Anforderungen, die von der Umwelt an uns als Individuum, aber auch an Unternehmen und an die Gesellschaft gestellt werden, erfordern die Fähigkeit, mit Komplexität umzugehen und anpassungsfähig und innovativ zu sein.

1 Verstehen Sie die Ursprünge und Hintergründe von agilen Ansätzen.

Machen Sie sich bewusst, dass Agilität immer schon hilfreich war. Lernen Sie aus der Geschichte und beschäftigen Sie sich mit den ersten Ansätzen und den Kontexten, in denen diese entstanden sind.

Machen Sie sich auch klar, dass hier Entweder-Oder-Denken nicht hilfreich ist. Auch in einem (oftmals als sehr unagil bezeichnetem) Wasserfallmodell können agile Elemente untergebracht werden.

 Wo sehen Sie in Ihrem Umfeld Denkweisen, die Sie als „agil“ bezeichnen würden?

 Was ist Ihre eigene Definition von agil? Was wäre „unagil“?

 In welchem Kontext wurde eine gewisse Methode erstmals angewendet und warum hat sie dort geholfen?

1 Seien Sie kein Dogmatiker.

Der Grundsatz aller agilen Arbeitsweisen lautet „Inspect & Adapt“, also Feedback gewinnen und daraus Anpassungen ableiten. Schauen Sie sich Vorgehensweisen, Prozesse und Produkte kritisch an und nehmen Sie Anpassungen vor. Es mutet merkwürdig an, wenn Frameworks und „agile Gesinnungen“ dogmatisch vertreten werden. Eine Praktik oder Methodik sollte immer zum jeweiligen Kontext passen.

 Warum sind Sie der Meinung, dass eine bestimmte Praktik, Methode oder Verhaltensweise genutzt werden sollte? Haben Sie eine zum Kontext passende Erklärung?

 Haben Sie die Leitplanken und Regeln durchschaut, so dass Sie sich auf die dahinterliegenden Prinzipien und Werte beziehen können?

 Passen die Werte und Prinzipien zu Ihren eigenen Werten (den Werten Ihres Unternehmens, Ihres Auftraggebers, Ihres Kunden, …)?

1 Nutzen Sie die Erfahrung von „Meistern“ bei der Einführung von neuen Methoden und Frameworks.

Gerade bei der Einführung von Frameworks, die das Potenzial haben, ganze Unternehmensstrukturen und Führungsparadigmen zu hinterfragen und die Kultur zu verändern, sollten Sie sicherstellen, dass Sie Menschen mit Erfahrung in diesem Bereich an Bord haben. Erinnern Sie sich an Shu-Ha-Ri. Wenn Sie selbst in Ihrem Umfeld niemanden haben, der mindestens auf dem Ha-Level ist, dann suchen Sie sich Unterstützung.

Nicht wenige agile Transformationen scheitern daran, dass sie halbherzig oder mit guten Absichten (aber schlechter Umsetzung) durchgeführt werden. Die Resultate sind dann häufig zerstörtes Vertrauen beim Management, frustrierte Mitarbeiter, Rückkehr zu alten Prozessen und Arbeitsweisen und Verlust von Mitarbeitern, die einen Einblick in eine neue Arbeitswelt bekommen haben, die sie fortan woanders suchen.

 Suchen Sie sich erfahrene Coaches, Berater oder Unterstützer, die bei der Einführung von agilen Frameworks unterstützen. Wer kann Ihr „Mister Miyagi“ sein?

 Bauen Sie eigene Kenntnisse auf und vernetzen Sie sich, so dass Sie selbst zukünftig in der Lage sind, Anpassungen vorzunehmen (Ha-Level).

 Haben Sie die Wirkweise wirklich verstanden?

Der Kundennutzen steht im Mittelpunkt

Unternehmen müssen heute in einen Konkurrenzkampf um die Kunden treten. Die effiziente und kostengünstige Produktion selbst ist kein Erfolgsgarant mehr, denn die Technik und das Wissen, wie man beispielsweise ein Smartphone oder Tablet kostengünstig herstellt, sind keine Raketenwissenschaft. Die Preise und damit die Gewinnspanne für etablierte Produkte sinken. Die Kunden wollen nicht einen weiteren Klon eines schon vorhandenen Produkts, sondern sie erwarten Innovationen und Alleinstellungsmerkmale.

Dies gilt für fast alle Branchen und Produkte. In der Digitalisierung verlagert sich der Fokus der Produktentwicklung in Richtung Kunde. Diese sind oft schon sehr früh beim Produktdesign mit im Boot. Der kreative und innovative Umgang mit Kunden und deren Wünschen ist eine wichtige Kompetenz geworden.

Zur Verdeutlichung möchte ich an dieser Stelle eine Geschichte nacherzählen, die für mich die Kundenzentrierung auf den Punkt bringt. Sie zeigt sehr anschaulich, worauf es auch in Zeiten der Digitalisierung ankommt. Diese Geschichte stammt von Reinhard Sprenger (Sprenger 2018) und stammt mitten aus dem Alltagsleben, ohne viel Technik oder neuartige Apps.

Stellen Sie sich eine Familie vor, die an einem schönen Samstagabend in ein Restaurant zum Essen geht. Die Familie besteht aus Vater, Mutter und zwei Kindern. Alle sind gut gelaunt und es verspricht ein schöner Abend zu werden. Beim Blick auf die Speisekarte kündigt sich aber ein Problem an. Die Kinder finden nichts, was ihnen zusagen würde. Auf der Karte sind auch keine Pommes Frites zu entdecken. Als der Kellner an den Tisch der Familie kommt, fragt die Mutter nach, ob es denn möglich wäre, für die Kinder eine Portion Pommes Frites zu bestellen und der Kellner nickt freundlich und notiert den Wunsch auf seinem Notizblock. Der Abend ist gerettet und alle lassen sich ihr Essen schmecken. Als schließlich die Rechnung kommt und der Vater sie kontrolliert, bemerkt er, dass die Pommes Frites nirgendwo aufgeführt sind. Er weist den Kellner darauf hin und bekommt dann eine verwunderliche Erklärung, warum die Pommes Frites fehlten. „Oh, da haben Sie Recht“, räumt der Kellner ein. „Das liegt wohl daran, dass wir sie vom Restaurant auf der anderen Straßenseite geholt haben und dann vergessen haben, sie auf Ihre Rechnung zu setzen“.

Hier ist wahrlich der Kunde König und in den Mittelpunkt gestellt worden. Das Restaurant hat sich bemüht, einem Wunsch zu entsprechen, der über die standardmäßig angebotenen Leistungen hinausging. Dadurch gingen sowohl das Restaurant als auch die Gäste als Gewinner hervor. Und es zeigt auch gleich, dass Vernetzung und Zusammenarbeit eine wichtige Komponente in der Digitalisierung darstellen. Das Restaurant hat nicht nur nach innen geschaut und das geliefert, was es aufgrund der Produktionsmittel liefern konnte. Da es den Kundenwunsch nicht allein erfüllen konnte, hat es nach einer Kollaboration gesucht und sie im Restaurant gegenüber gefunden. Stellen Sie sich vor, was dies für ein Paradigmenwechsel für viele Unternehmen darstellen muss.

User Stories und Story Mapping

In vielen agilen Teams und Unternehmen verwendet man User StoriesUser Stories, um Anforderungen aus Kundensicht zu beschreiben. Das klassische Anforderungsmanagement versucht, klare Beschreibungen mit möglichst vielen Details vom Kunden zu bekommen. Diese werden dann in Lasten- und Pflichtenheften vertraglich festgelegt. Im Gegensatz zu klassischem Anforderungsmanagement ist im agilen Umfeld zu erkennen, dass die Anforderungen erst einmal technisch sehr unspezifisch formuliert werden. Dafür wird aber stets die Perspektive des Kunden eingenommen und die technische Lösung später gemeinsam entwickelt.