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.
Ron JeffriesJeffries, Ron, einer der drei Väter des Extreme Programming, schlug schon 2001 den sehr populären 3C-Ansatz vor. Diese drei C stehen für Card, Conversation und Confirmation.
Card (Karte) soll daran erinnern, dass eine User Story auf eine kleine Karteikarte passen soll. Es soll eben bewusst nicht zu viel analysiert und spezifiziert sein. Details und konkrete Lösungswege sollen in einer Zusammenarbeit des Teams entstehen. Dafür steht das zweite C, Conversation (Konversation, Gespräch). Hier kommt das Team zusammen und spricht über die User Story, nimmt sie auseinander, schneidet sie kleiner, bringt neue Ideen ein. Schließlich kommt es zum dritten C, der Confirmation (Bestätigung). Hier wird noch einmal sichergestellt, dass die Ziele der Konversation auch erreicht wurden, also ein Verständnis für das Problem und mögliche Lösungsansätze vorhanden sind. Hier werden oftmals Akzeptanzkriterien auf die Rückseite der Karte geschrieben. Diese dienen dazu, sich schon vor Beginn der Umsetzung Gedanken zu machen, was genau das fertige Produkt leisten muss, damit es die User Story erfüllt.
Eine User Story ist bei ihrer Formulierung aus Sicht des Kunden beschrieben und liefert Antworten auf die folgenden Fragen:
Wer möchte etwas? (Rolle)
Was wird benötigt? (Funktionalität)
Wozu wird es benötigt? Welches Ziel soll erreicht werden oder welches Problem gelöst werden? (Wozu)
Zwar gibt es keine Vorgabe, wie eine User Story zu formulieren ist, allerdings hat sich unter Anwendern das Connextra-Muster etabliert, das User Stories in der folgenden Form vorschlägt:
Als <Rolle> möchte ich <Funktionalität/Ziel/Wunsch>, um <Nutzen/Warum>.
Im klassischen Anforderungsmanagement wird oftmals der Grund, warum etwas benötigt wird, nicht mittransportiert. Es entsteht eine sehr starke Fokussierung auf die konkreten und spezifizierten Anforderungen und bei der Lieferung der Lösung merkt man erst, dass das Problem nicht ganzheitlich verstanden wurde. User Stories helfen durch die Art ihrer Formulierung dabei, erst das Problem zu verstehen und erst dann gemeinsam nach Lösungen zu suchen.
Damit User Stories in einer Iteration von maximal vier Wochen auch erledigt werden können, müssen sie oftmals in kleinere Pakete unterteilt werden. Dafür gibt es eine ganze Reihe von hilfreichen Techniken. Ein Hilfsmittel zum sinnvollen Zerteilen der Stories ist die User Story Map, die durch Jeff Patton populär wurde (Patton/Economy 2015).