Vor nicht all zu langer Zeit habe ich im Online-Magazin infoQ einen Artikel mit dem sehr spannenden Titel “If You Need to Start a Project, You’ve Already Failed” gelesen. Der Autor ist der Meinung, dass der Verzicht auf ein Projekt als zeitlich begrenzter Rahmen für eine Veränderung (z.B. ein neues Produkt) das beste Vorgehen für ein erfolgreiches Unternehmen ist. Ich fand die Idee so spannend, dass ich in dieser Vision die Rolle einer Produktdokumentation bei kontinuierlicher Entwicklung eines Produktes ohne Projekt betrachte. Ich möchte zeigen, dass die Methode CARDS+ auch in diesem Fall funktioniert.

06 Vision Kontinuierliche Produktenwicklung

Ausgangssituation

Ein Startup-Unternehmen hat eine Produktidee, die es umsetzen möchte: Einen Reisebegleiter als Android– und iOS-App. Das Unternehmen hat eine klare Vorstellung, was das Produkt leisten soll. Es ist jedoch noch unklar, woher sie alle notwendigen Daten bekommen sollen, damit die Funktionen realisiert werden können: Fahrpläne, Preise, Zusatzinformationen zur Ausstattung an Bahnhöfen und Haltestellen (z.B. Gastronomie, Raucherbereiche) oder in den Verkehrsmitteln (z.B. Barierefreiheit).

Die Verantwortlichen entscheiden sich für die Methode CARDS+, um ihre Produktideen zu erfassen und kontinuierlich zu pflegen. Mit den Topics bestimmt der Auftraggeber den groben Rahmen, in dem der Product-Owner mit allem ihm zur Verfügung stehenden kreativen Kräften Epics identifizieren soll/darf. Der Produkt-Owner erhofft sich von der Methode die von ihm gewünschte Flexibilität im Backlog-Management. In der Motivation der Epics vermerkt er, wenn es nach seiner Recherche bei der Konkurrenz ein Alleinstellungsmerkmal für das eigene neue Produkt ist. Ähnliche Funktionen oder Highlights anderer Produkte erwähnt er in der Abgrenzung der Epics. Durch die Trennung von Ausgangssituation und Lösung in den Cases kann er sich zu Beginn darauf konzentrieren, alle Funktionen zu erfassen, die aus seiner Sicht das Produkt erfolgreich machen, ohne sich dabei den Kopf zu zerbrechen, woher er die Daten dafür bekommt.

Scrum ist die Methode, mit der das Team agil entwickeln wird. Für den Anfang beschließt das Team mit Sprints von vier Wochen Dauer zu arbeiten. Sie setzen konsequent auf Qualität und Automatisierung bei Entwicklung, Test und Bereitstellung des Produktes.

Der Product-Owner nutzt diesen Sprint, um das Sprint-Backlog für Sprint 1 vorzubereiten. Das Sprint-Ziel ist die Programmierung der zwei wichtigsten Screens der Android-App und die Anbindung der Datenquelle für den Fahrplan.

Das Team beginnt mit der Android-App. In diesem Sprint müssen sie bereits wichtige Entscheidungen zum API-Level und zum Layout der App treffen. Sie binden die Datenquelle für den Fahrplan direkt in der App ein, ohne Server.

Im nächsten Sprint will der Product-Owner neue Datenquellen erschließen, um eine verbesserte Nutzererfahrung in der App zu erzielen.

Mit der Integration weiterer Datenquellen stellen die Entwickler fest, dass die direkte Einbindung in der App nicht gut testbar ist. Sie beschließen, einen speziellen Server für die Anbindung der Datenquellen zu entwickeln. Die App wird nur mehr aus einer zentralen Quelle versorgt.

Am Ende des Sprints wird der Product-Owner informiert, dass das Team den nächsten Sprint dazu verwenden möchte, den zentralen Server auf eine neue, besser skalierbare Basis zu stellen.

Das Team beschließt, den Server mit Software aus dem Hadoop-Ökosystem zu realisieren. Sie wollen einen Server aufbauen, der alle bekannten öffentlichen oder lizensierbaren Datenquellen für Fahrpläne  erschließt und für die App verfügbar macht.

Der Product-Owner hat den Sprint für die Pflege des Backlog benutzt. Er hat sich Features der App überlegt, in denen die zusätzlichen Daten der neuen Datenquelle genutzt werden. Er hat Features identifiziert, die der App mehr Alleinstellungsmerkmale verschaffen.

Die neuen Datenquellen liefern teilweise die gleichen Informationen. Für jeden Konflikt benötigen sie Regeln, nach denen sie gelöst werden. Das Team entscheidet sich für den Einsatz einer “business rule engine” (kurz BRE) von Redhat für die Umsetzung der Konfliktlösungsregeln.

Der Product-Owner ist in diesem Sprint mit der Analyse der Daten und Bestimmung der Konfliktlösungsregeln beschäftigt. Er dokumentiert die Regeln in den entsprechenden Cases.

Die Entwickler erkennen, dass Datenquellen Informationen mit unterschiedlicher Qualität oder Genauigkeit liefern. Sie erkennen keine Systematik in den Abweichungen, keine Regel führt in allen Fällen zum optimalen Ergebnis. Sie wollen das Konzept “machine learning” (kurz ML) von Microsoft dazu benutzen, um effektiv auf Veränderungen in den Datenquellen und auf Konflikte bei den Daten reagieren zu können. Grundsätzlich verwenden sie die gleichen Regeln wie bisher, können aber mit den Ausnahmen von den Regeln besser umgehen.

Kontinuierliche Entwicklung

Das cross-funktionale Team braucht kein Projekt als temporäre Struktur für die Umsetzung der Produktidee. Ohne Projekt bekommt die Selbstorganisation des Teams einen hohen Stellenwert. Durch die agile Entwicklung gibt es einen festen Takt, in dem Produktinkremente in guter Qualität bereitgestellt werden. Die Vorteile agiler Methoden sind auch ohne Projekt wirksam. Für Stakeholder und Projektmitarbeiter.

Durch die Bausteine Topic und Epic macht der Product-Owner die aktuelle “Größe” der Aufgabe und den Fortschritt der Entwicklung für den Auftraggeber im Unternehmen transparent. Ein Epic, dass keinem Topic zugeordnet werden kann, ist möglicherweise vom Auftraggeber nicht gewünscht. So ein Epic wird erst Teil des Produktes, wenn der Auftraggeber beschließt, die Grenzen des Produktes zu erweitern. Mit jedem Case oder Layout sorgt der Product-Owner und das Team dafür, dass alle guten Ideen für Funktionen des Produktes für alle im Unternehmen sichtbar sind. Durch den Einsatz eines Wiki können alle Mitarbeiter sich über das Produkt informieren. Das Glossar sollte jeden Leser in die Lage versetzen, die Beschreibungen im Wiki ohne große Probleme zu verstehen. Jeder Mitarbeiter kann sein Feedback direkt im Wiki als Kommentar hinterlassen. Oder er kann sich an einer Diskussion zu einem Case oder Epic aktiv beteiligen. Der Product-Owner erhält auf diesem Weg Feedback wie von Kunden, denn Mitarbeiter reisen und sind in der Lage, Funktionen eines Reisebegleiters zu beurteilen

Kontinuierliche Einführung

Der Product-Owner und das cross-funktionale Team können sehr schnell eine erste Version des Produktes herstellen. Dieses Produktinkrement hat am Anfang zu wenige Alleinstellungsmerkmale und wird nach Einschätzung aller Beteiligten am Markt kaum erfolgreich sein. Das Unternehmen wird das Budget für die Umsetzung der Produktidee jedoch nutzen, um so schnell wie möglich eine Version des Produktes zu liefern, das Chancen am Markt hat. Auf diesem Weg werden die Entwickler viele wichtige Entscheidungen treffen, die sie mit dem Baustein Decision dokumentieren. Die Architekturdefinition wächst mit dem Fortschritt in den Sprints.

Mit der ersten erfolgreichen Version des Produktes kann schnell die Situation entstehen, dass die Leistungsfähigkeit der App an seine Grenzen stößt. In diesem Fall sorgt die lückenlose Dokumentation der Funktionen in der Systembeschreibung, dass ein Wechsel von Technologien in vielen Fällen schmerzlos erledigt wird. Der Product-Owner muss in den Cases nur dort ändern, wo das Produkt sich durch die neue Technologie neue Funktionen eröffnet. In meinem Beispiel war es die schrittweise Entwicklung von einer App ohne Server zu einer mit zentralem Server. Auch der zentrale Server entwickelt sich von einer regelbasierten zu einer “intelligenten” Lösung mit ML.

Kontinuierliche Verbesserung

Ist das Produkt einmal bei Kunden in Verwendung, muss das Team Defekte im Produkt laufend korrigieren. Mit der Veränderung der Software stellt das Team auch sicher, dass die Beschreibung im Wiki weiterhin stimmt und zur realisierten Lösung passt. Das kann einerseits eine kleine Ergänzung im Case sein, ein zusätzlicher Nebensatz, der die dem Defekt zugrundeliegende Situation erklärt. Ist der Defekt jedoch eine Lücke in der Software, dann legt der Product-Owner einen neuen Case an. Er orientiert sich dabei an den bestehenden Cases, für die es bereits eine passende Lösung gibt.

Bei größeren Änderung im Produkt wird ein neues Epic, bei sehr großen Änderungen in Abstimmung mit dem Auftraggeber sogar ein neues Topic angelegt. Der Product-Owner hat durch das Wiki die Möglichkeit, eine neue Produktidee mit Volltext- oder zielgerichtet mit Stichwortsuche intensiv zu recherchieren. Er kann bereits sehr früh prüfen, welche Auswirkung das neue Epic auf bereits existierende Epics hat.

Fazit

Die Methode CARDS+ befähigt ein Team, nachhaltig und vollständig ein Produkt zu beschreiben und alle wichtigen Entscheidung zu dokumentierten. Ein Projekt ist dazu nicht unbedingt notwendig. Die Vorteile durch den Verzicht auf ein Projekt sind vielfältig:

  • Ein Projekt kostet Geld, das nicht für das Produkt eingesetzt wird. Der “overhead” durch ein Projekt und eine Projektorganisation wird eingespart und für das Produkt eingesetzt.
  • Ein Projekt hat Meilensteine, auf jeden Fall einen Beginn und ein Ende. Das Unternehmen will aber kontinuierlich am Produkt arbeiten. Das Ende eines Produktes wird durch andere Faktoren bestimmt als das Ende eines Projektes.
  • Das Produkt ist Ergebnis des Unternehmens, nicht eines Projektes. Jeder Mitarbeiter des Unternehmens ist somit direkt beteiligt, betroffen und motiviert, am Erfolg mitzuwirken.
  • Ein Projekt scheitert, weil Ziele nicht erreicht wurden, obwohl ein Produkt gut ist. Betrachten wir nur das Produkt, beurteilen wir nur Qualität der Entwicklung und Erfolg am Markt.

Die Diskussion über den Sinn und Wert eines Projektes mag spitzfindig erscheinen. Meine persönliche Erkenntnis ist, dass eine gut gepflegte Produktdokumentation in jeder Organisation einen hohen Wert darstellt. Die Methode CARDS+ hilft, diesen wichtigen Wert zu erhalten und genau so kontinuierlich und inkrementell wie Code und Tests zu “entwickeln”. Mit oder ohne Projekt.