Stellen Sie sich vor…
Sie sind fünf Jahre alt,
es ist Weihnachtszeit…
Sie freuen sich darauf, dass Ihnen der Weihnachtsmann das eine Geschenk bringt, von dem Sie fast ein Jahr lang geträumt haben.
Sie sind auch erstaunt, wie der Weihnachtsmann das tatsächlich kann: In einer Nacht so vielen Kindern auf der ganzen Welt Geschenke liefern – er muss ein Superheld sein!
Jingle Bells, Jingle Bells
Endlich ist es so weit. Sie haben Verständnis dafür, dass der Weihnachtsmann keine Zeit hatte, „Hallo“ zu sagen – aber er hat Ihnen eine verpackte Geschenkbox hinterlassen. Ist es wirklich das kleine weiße Spielzeugauto, auf das Sie gehofft haben? Die Aufregung steigt, während Sie die Geschenkbox auspacken.
Und da ist es: Ja, ein Spielzeugauto! Sie lieben diese Form des Autos – aber, was ist das? Warum ist das Spielzeugauto grün und nicht weiß? Das ist alles, worum Sie gebeten haben – ein kleines weißes Spielzeugauto.
Ihre Aufregung über die falsche Farbe lässt langsam nach. Das ist schon in Ordnung, denn nächste Weihnachten gibt es eine weitere Gelegenheit – vielleicht ist das Spielzeugauto dann weiß.
Dies ist die Geschichte eines enttäuschten Product Owners, der ein weiteres Jahr warten muss, um zu bekommen, was er erwartet hat.
Warum müssen Sie besser sein als der Weihnachtsmann?
Der Weihnachtsmann hatte die besten Absichten, aber er arbeitet klassisch phasenorientiert mit der Wasserfall-Methode. Er hätte besser enger mit den Stakeholdern zusammenarbeiten, sich häufiger über Zwischenergebnisse abstimmen und sich kontinuierlich verbessern sollen.
Im Laufe unserer Berufsjahre haben wir zu oft Projekte beobachtet, in denen ein Product Owner nicht das Ergebnis erhalten hat, das zu erwarten war. Daher ist es sehr wahrscheinlich, dass auch die Erwartungen der Kunden nicht erfüllt werden. Leider ist die Beschreibung eines Produktes in aller Regel nicht so einfach und eindeutig wie eine Farbe. (Ja, die Experten unter den Lesern werden anführen, dass auch die Bezeichnung „weiß“ alles andere als präzise ist). Ein weiterer Aspekt agiler Produktentwicklung ist jedoch auch, dass zum Zeitpunkt der Anforderungsdefinition sogar „grün“ gewählt wurde, sich aber die Bedingungen zwischenzeitlich geändert haben und man zum Auslieferungszeitpunkt mit einem grünen Auto gar nichts mehr anfangen kann.
In schnelllebigen Zeiten von Cloud-Einführung und maschinellem Lernen, könnte Ihr Unternehmen so sehr schnell ins Hintertreffen geraten. Sie sollten sicherstellen, dass Sie die Bedürfnisse Ihrer Kunden verstehen. Im Idealfall sind Sie sogar einen Schritt voraus und lassen ihre Kunden etwas ausprobieren, bevor sie überhaupt merken, dass sie darauf gewartet haben.
Zurück zum Weihnachtsmann – er hat ein paar Dinge richtig gemacht, die schauen wir uns jetzt an.
Was hat der Weihnachtsmann richtig gemacht?
Der Weihnachtsmann hatte die besten Absichten, die man sich vorstellen kann, aber wie alle anderen musste er das unten abgebildete „Projektmanagement-Dreieck“ meistern:
Eine schnelle Einschätzung der drei Parameter ergibt folgendes:
- Zeit: Ein Jahr, um die Lieferung vorzubereiten und er hat das Spielzeugauto pünktlich geliefert – Erfolg
- Qualität: Der Weihnachtsmann lieferte das Spielzeugauto, dass das Kind wollte – teilweiser Erfolg (mit einem Vorbehalt: falsche Farbe)
- Kosten: Er hatte wahrscheinlich auch dort eine Einschränkung und es gelang ihm, im Rahmen des Budgets zu bleiben – Erfolg
Wenn man sich das Projektmanagement-Dreieck ansieht, könnte man sagen, dass der Weihnachtsmann alle Voraussetzungen erfüllt hat. Da wir aber einige unglückliche Gesichter sehen konnten, wollen wir auf jeden Fall nach möglichen Verbesserungen suchen.
Wie kann sich der Weihnachtsmann verbessern?
Es reicht nicht aus, einmal im Jahr Feedback von Stakeholdern zu erhalten. Die Dinge ändern sich – der Markt, die Wettbewerber und die Kundennachfrage. Wie stellen wir sicher, dass wir das erwartete Ergebnis verstehen und es effektiv liefern können? Es gibt ein paar Dinge, die uns helfen:
- Kontinuierliches Feedback Ihrer Stakeholder: Stellen Sie sicher, dass die Lieferung den Erwartungen der Stakeholder entspricht. Dafür werden die Stakeholder in den Teamraum eingeladen, wo auch alle anderen Werkzeuge und Arbeitsmittel, wie Whiteboards, Build Screens, JIRA Boards, To Do Listen, Priorisierungs-Matrizen u. ä., in Augenschein genommen werden können.
Das Team demonstriert zuerst den aktuellen Stand der Produktentwicklung, dieser kann aber auch schon den Status unfertiger Features beinhalten, wenn die Stakeholder dazu Informationen wünschen. Während dieser Phase, in der das Team ungestört funktionierende und an den Kunden auslieferbare Produktteile präsentiert, können sich Stakeholder Fragen notieren, auf die im Anschluss eingegangen wird. Je nach Anzahl der Teilnehmer und Fragen, wurden letztere zwischendurch in Cluster aufgeteilt und durch Dot Voting oder “buy-a-question” mit Pokerchips priorisiert, um sicherzustellen, dass die wichtigsten Fragen zuerst besprochen und definitiv beantwortet werden.
Kurze Intervalle und Release-Zyklen helfen dabei, kontinuierliches Feedback zu erhalten. Ein typischer Intervall ist ein Sprint, der nicht zufällig so heißt. Er ist üblicherweise zwischen zwei und vier Wochen lang. Das hängt ein bisschen vom Produkt ab. Wichtig ist, dass die Sprints immer gleich lang sind und die Länge strikt eingehalten wird. Eine beliebte Sprintlänge sind 14 Tage. Da ist für die Stakeholder alle 14 Tage Weihnachten.
- Zusammenarbeit: Die Kommunikation mit den Teammitgliedern muss effizient sein.
Agile Methoden und Praktiken fokussieren unter anderem den einzelnen Projektmitarbeiter, das Teams als solches und schließlich den Teamentwicklungsprozess. Beispielsweise fördert die Anwendung von Retrospektiven den Lessons Learned Prozess während des Projektes und auch den Mut, Änderungen am Prozess voranzutreiben. Durch tägliche Treffen (z.B. Stand-Up-Meetings oder Daily Scrum Meetings) wird die Möglichkeit zur direkten Kommunikation und zum Informationsaustausch geschaffen. Ein regelmäßiger Austausch hilft dem Team, sich kontinuierlich zu verbessern. Wichtig ist dabei, die Kommunikation in kurzen, regelmäßigen Intervallen durchzuführen. Das Einhalten der Zeiträume ist dabei essentiell.
- Funktionsübergreifende Teams: Durch den Aufbau funktionsübergreifender Teams können Sie die Wartezeiten, die Sie bei einem typischen Wasserfall-Ansatz haben, auf ein Minimum reduzieren. Diese entstehen nämlich häufig dadurch, dass Zwischenergebnisse auf teamfremde Zulieferung oder Antworten warten müssen.
Das Arbeiten am Produkt mit funktionsübergreifenden Teams bedeutet, dass die Teams die gesamten Anforderungen, z. B. eines Features, jeweils vollständig selbst implementieren. Teams sind also so zusammengesetzt, dass sie aufgrund ihrer gemeinsamen Fähigkeiten in der Lage sind alle Aktivitäten auszuführen, die dafür notwendig sind. Teams könnten zum Beispiel aus Personen bestehen, die designen, Client-Code und Server-Code schreiben, die Qualität sichern und das Endprodukt ausliefern und betreiben können.
Um fair zu sein, Kinder würden sich nicht so auf Weihnachten freuen, wenn sie an all den oben genannten Zeremonien beteiligt wären. Auch die Freude am zweiwöchentlichen Feiern von Weihnachten kann ziemlich schnell nachlassen. Aber Ihr Geschäft wird davon profitieren, wenn Sie die oben genannten Routinen übernehmen.
Bis dahin: Allen ein frohes Weihnachtsfest wünscht Ihre NOVEDAS Consulting.
Mitarbeit: Jörg Lucas
