Product Owner 101: 9 Gründe für gescheiterte Projekte (Part 3)

Building the right thing and build the thing right: Lerne, woran du erkennst die richtige Software zu entwickeln und erfahre was du tun kannst, um einer Flut an Bugs und Change Requests zu entgehen.

Der erste und zweite Teil meines Product Owner 101 hat dir schon einen Überblick verschafft, an welchen Stellschrauben du in deinen Projekten drehen könntest, um ein Scheitern zu verhindern. Dieser dritte und abschließende Part baut auf bisherigen Punkten wie Value Optimierung auf und befasst sich mit den Themen Kommunikation und Tests.

#8 – Dein Kommunikationsgeschick stammt aus einer anderen Galaxie.

Wir schreiben das Jahr 2019. Dies sind die Abenteuer des Raumschiffs Entersize. Die Crew sitzt angespannt auf der Brücke: Ein Teammeeting steht an.

„Der Lieutenant und ich haben uns etwas Schlaues überlegt, um uns finanziell etwas besser dastehen zu lassen.“, erzählt der Captain freudig vom neusten Vorhaben. „Wir bauen ein zweites Raumschiff.“

„Verzeihung Captain?“, Sonderbotschafter Spocki meldet sich unsicher zu Wort. „Was ist das Besondere am neuen Raumschiff? Soll das Erste abgeschafft werden?“

„Nein, nein! Wir betreiben beide.“, antwortet der Captain. „Doch das Neue kostet fast nichts in der Umsetzung, hat kaum nennenswerte Features und ist nur für alle Freiwilligen, die derzeit im Bug des Schiffs untergebracht sind. Natürlich behalten sie ihre Kabine, aber es wäre doch toll, wenn die auch noch etwas zur Miete im zweiten Schiff zusteuern.“

Spocki zieht eine Augenbraue hoch: „Aber warum würden sie zwei Kabinen mieten wollen?“

„Na ist doch klar. Die zweite Kabine kostet monatlich fast nichts, aber man kann mehr Sterne aus den Fenstern sehen.“

Ob die Menschen wirklich dieselben Sterne aus einem anderen Winkel sehen wollen? Davon will hier niemand etwas wissen.

„Great things in business are never done by one person. They are done by a team of people.“ – Steve Jobs

Verschiedene Meinungen einholen.

Eine gut funktionierende Kommunikation ist die ultimative Schlüsselqualifikation, um Missverständnisse zu überwinden und Unklarheiten zu klären. Das gilt nicht nur für das Refinement oder das regelmäßige Besprechen der Anforderungen. Zudem ist visionäres Denken gut und ausdrücklich erwünscht. Neue Ideen dürfen nicht eingeschränkt werden. Frische Vorschläge sind immer willkommen. Doch was bringen fantastische Ideen, wenn sie im stillen Kämmerchen bis ins kleinste Detail durchgeplant und beauftragt werden?

Prüfe deine Ideen, Änderungsvorschläge & Co. Was sagen User, Kunden, das Management oder deine Kollegen dazu? Identifiziere alle Stakeholder, die Interesse an deinem Produkt haben könnten. Beziehe alle Stakeholder aktiv ein und entwickelt eure Ideen gemeinsam.

#9 – Testen? Ach, das machen wir 2 Wochen vor Release!

Ein Projekt neigt sich dem Ende und du reibst dir schon die Hände. Glücklicherweise hast du viele Zeit- und Budgetpuffer eingeplant. Alles ist on-Time, on-Budget und sogar on-Scope. Jetzt muss nur noch getestet werden!

Plötzlich bricht das Kartenhaus vor dir zusammen. Ein Großteil der Tickets kommt fehlerhaft aus dem Test zurück. Ihr dreht mehrere Korrekturrunden. Immer und immer wieder werden ein und dieselben Fehler behoben und kurz darauf erneut gemeldet. Du hast das Gefühl, als säße ein Elefant im Porzellanladen: Wird vorne herum etwas repariert, wird hintenrum alles erneut umgeschubst. Für jeden behobenen Fehler tauchen drei Neue auf. Schnell wird dir klar, dass zwei Wochen testen vielleicht doch nicht ausreichen.

Wie hätte man das verhindern können?

Eine Variante wäre sicherlich, viel mehr Zeit für das Testen einzuplanen. Doch wie du bereits in Kellys laws (Grund #3) festgestellt hast, wächst das Scope mit der verfügbaren Zeit. Steht mehr Zeit zur Verfügung, nutzt man sie vermutlich auch aus. Diese Annahme verfolgen auch Hofstadter und Parkinson:

„It always takes longer than you expect, even when you take into account Hofstadter’s Law.“ – Douglas Hofstadter [1]

„Work expands so as to fill the time available for its completion.“ – Parkinson’s Law [2]

Unter diesem Aspekt erscheint es mir sinnvoll, das Testen bereits frühzeitig in den Lifecycle einzuplanen. Eine Möglichkeit früh und häufig zu testen ist die verhaltensgetriebene Entwicklung.

Behavior Driven Development.

Die verhaltensgetriebene Entwicklung (BDD) baut auf den Ansätzen der testgetriebenen Entwicklung (TDD) auf. Durch BDD verfolgen du und dein Team das Ziel, noch vor dem Entwickeln der eigentlichen Funktionalität Software-Tests zu schreiben. Dabei nutzt ihr Beispiele, die sehr einfach automatisiert werden können. Die kollaborativ erarbeiteten Beispiele dienen dazu, Missverständnisse und verlorengegangene Informationen durch Kommunikation zu reduzieren. Dieses Set von Softwareentwicklungspraktiken unterstützt dein Team, möglichst schnell wertvollere und qualitativere Software zu entwickeln. Das Team fokussiert sich dabei auf das Identifizieren, Verstehen und Umsetzen von wertvollen Funktionalitäten. Und so geht’s:

BDD-Übersicht: Vorgehenweise und Anregungen für Methoden

Identifiziert die Vision und high-value Ziele.
Nehmt euch ein Ziel vor und schreibt eine User Story. Ihr könnt hierfür das gängige Muster „Als [Rolle] möchte ich [ein Feature], um [ein Businessziel zu erreichen].“ benutzen.
Illustriert die Story durch ein detailliertes, konkretes Beispiel, um das eigene Verständnis des Problems zu validieren bzw. ein gemeinsames Verständnis zu schaffen.
Nutzt das Beispiel, um Akzeptanzkriterien daraus abzuleiten indem ihr es umschreibt. Ihr könnt hierfür das Muster „Gegeben sei ein [Kontext], wenn [etwas passiert] dann [erwartest du ein Ergebnis].“ verwenden.
Schreibt einen Test auf Basis eines Akzeptanzkriteriums. Hier trifft zu: Verfügt eine Story über mehr als ein Akzeptanzkriterium, kann ein Aufteilen auf mehrere Stories sinnvoll sein. Wie eine Story aufgeteilt werden kann kannst du in Teil 1 nachlesen.
Passt den Code mit möglichst wenig Aufwand an, bis der zuvor definierte Test erfolgreich bestanden ist.
Restrukturiert den Code, um das Programm schlicht und verständlich zu gestalten. Es wird kein neues Verhalten implementiert.

BDD ist in Acceptance Test Driven Development (ATDD) eingebettet und grenzt an Specification by Example an. Doch eines haben diese Methoden gemeinsam: Sie sind kein Allheilmittel, aber eine gute Ergänzung.

Takeaways

Gemeinsam sind wir stark: Beziehe Kollegen, User, Kunden oder das Management in deine Produktvisionen mit ein.
Teste früh und oft: Probiere neue Entwicklungsmethoden aus, reduziere Fehler und verbessere deine Code-Qualität.
BDD bietet sich an, um früh und häufig zu testen. Gleichzeitig ist es eine kollaborative Möglichkeit auf Basis von Beispielen und durch gute Kommunikation ein gemeinsames Verständnis von Vision, Zielen und den daraus abgeleiteten Features zu schaffen.

Noch nicht genug?

Hattest du bereits ähnliche Erlebnisse? Oder war die passende Lösung nicht für dich dabei? Teile deine Erfahrungen, Anregungen und Feedback zum Product Owner 101 unten in den Kommentaren! Wir freuen uns, dich auch in unseren Schulungen anzutreffen: