Was passiert, wenn das Wort agil in den Raum gestellt wird? Ein Manager ist verführt zu übersetzen: günstig, extrem schnell und modern. Projektmitglieder freuen sich auf spannende Aufgaben ohne lästige Dokumentation. Im Kontrast steht agiles Projektmanagement jedoch für das schnellere Erreichen von Teilergebnissen. Also ein Hilfsmittel, um gezielter den richtigen Weg zum Ziel zu finden. Dabei ist es valide, Fehler zu begehen, wenn man diese zügig erkennt, daraus lernt und die Steuerung korrigiert.
Wird IT-Produktentwicklung über agiles Produktmanagement gesteuert, ist es oft eine direkte Reaktion auf eine „unknown-unknown“ Projektherausforderung. Das Team soll eine komplexe Aufgabe lösen, mit Technologie, welche während der Ergebniserstellung entsteht. Es ist also sicherzustellen, dass die abzuarbeitenden Teilaufgaben, von Vorteil für die Gesamtlösung sind.
Vision
Damit dies gelingen kann, benötigt das Vorhaben eine klare Vision für die Ziele, welche erreicht werden sollen. Es wird Transparenz für Stakeholdern und Projektmitarbeiter geschaffen, die es ermöglicht, dass ein Projektmitglied befähigt ist, autark taktisch zu agieren.
Die Vision ist für alle am Projekt beteiligte Personen gut sichtbar zu platzieren und aktuell zu halten.
Nutzen
Die Definition von Werten, also Vorteile, die durch die Nutzung des Produktes entstehen, sorgen dafür, dass kontinuierlich Abnahmen durchgeführt werden können.
Die Vision gibt die strategische Richtung vor. Aber ohne die Perlen, die auf dem Weg entstehen, gibt es keinen Nutzen. Ein gutes Projektteam identifiziert innerhalb des Backlogs die vielversprechendsten Perlen (Nutzen) und fädelt sie auf den Faden (Vision).
Bestätigung
Jede Idee ist gut, aber sie muss validiert werden. Der identifizierte Nutzen muss also den Beweis antreten, dass er wertschöpfend ist und im Sinne der Produktvision sinnstiftend einzahlt.
Im Kontext von Scrum wird in wiederkehrenden Sprint-Reviews der Nutzen der aktuell fertiggestellten Inkremente inspiziert und durch die anwesenden Stakeholder bewertet. Selbst wenn die Projektbeteiligten Zufriedenheit verspüren, der wirkliche Nachweis kann erst in der Produktion erbracht werden. Der Product-Owner wird eine Feedbackschleife mit seinem Anwenderkreis einrichten. Es empfiehlt sich ein Release-Rhythmus, so oft es das Geschäft sinnvoll zulässt.
Product Owner Schach-Matt gesetzt
Der Product Owner hat die Aufgabe das Produkt über eine verständliche, zieldefinierende und prüfbare Vision zu beschreiben. Er erzeugt die notwendige Transparenz für das Team und die identifizierten Stakeholder.
Er verantwortet die Produktroadmap und plant gemeinsam mit dem Team Sprints, Liefergegenstände und Qualitätskriterien. Dabei berücksichtigt er die Rückmeldungen der Stakeholder und lässt diese, wo nötig in Produktvision und Featureliste einfließen.
Der Erfolg seiner Arbeit ist direkt in den während der Sprints ausgelieferten Werten messbar.
Damit dies funktioniert, muss der Product Owner mandatiert sein. Die Unternehmung muss ihn mit Ressourcen, geeigneten Personen und Entscheidungsbefugnissen ausstatten.
In diesem Beispiel sind die Voraussetzungen auf dem Papier nach Lehrbuch erfüllt. In der Durchführung sind die Hinderungsgründe zunächst kaum sichtbar.
Beispiel: „Teammitglieder werden in der übergeordneten Organisation als Ressourcen gesehen und in Full-Time-Equivalents (FTE) berechnet und verteilt.“
Die Basis für erfolgreiche Produktentwicklung sind motivierte, mit den richtigen Fähigkeiten ausgestattete Mitarbeiter, welche über die Vision und positivem Produktfeedback eine emotionale Bindung aufgebaut haben. Diese Bindung steht nicht mehr zur Verfügung, wenn Mitarbeiter zu 20% einem Projekt zugewiesen werden, da eine ihrer Fähigkeiten auf dem Papier zum Projekt passen.
Beispiel: „Stakeholder sind durch die Organisation definiert, in der Realität kaum verfügbar, treffen keine verbindlichen Aussagen zu Abnahme- und Qualitätskriterien“
Agile Produktentwicklung lebt von kurzen Feedbackschleifen. Eine Vision wird zu Beginn formuliert, mit Stakeholdern validiert und durch das Ausformulieren von Wertbeiträgen konkretisiert. Features mit dem größten Nutzen werden im Productbacklog höher priorisiert und als erstes umgesetzt. Ob ein Feature auch einen „Nutzen“ bringt, kann nur durch Überprüfung im Sprint Review und ultimativ im Markt gemessen werden. Fehlen Abnahme- und Qualitätskriterien, kann eine Lieferung nicht bewertet werden. Eine Aussage, ob das Inkrement positiv auf die Vision einzahlt, ist über Annahmen einschätzbar, ultimativ jedoch unmöglich.
- Stimmt die Richtung der Entwicklung?
- Muss die Vision korrigiert werden?
- Welcher Return on Invest (ROI) ist realisierbar?
- Wieviel Entwicklungsaufwand ist noch zu leisten bis das Ziel erreicht wird?
Kein Release bedeutet kein Feedback
Auf dem Papier sehen sie lukrativ und sinnvoll aus, in der Erprobung können sie sich als völlig falsch erweisen. Deshalb müssen diese Annahmen überprüft werden. Eine zügige Erprobung verkürzt entweder den „Time-to-Market“ oder verringert das Produktrisiko. Es wird frühzeitig dafür gesorgt, dass Ressourcen sinnvoll investiert werden.
Ein guter Haltepunkt, um diese Validierungen durchzuführen, ist der Sprint Review. Die Stakeholder haben die Möglichkeit, den aktuellen Stand des Produktes zu prüfen und einen Ausblick über die nächsten Schritte zu erhalten. Je ähnlicher die Reviewer einem Endanwender sind und je näher der Liefergegenstand am Releasestand ist, desto realistischer fällt das Feedback und die folgende Adaption der Überprüfungsergebnisse aus.
Die finale und nachhaltigste Rückmeldung erzeugt das Produkt im Markt und zwar beim Anwender. Dies hilft das Produktrisiko nachhaltig zu reduzieren. Es ist deshalb sinnvoll, eine kontinuierliche Feedbackschleife mit dem Endanwender zu etablieren.
Beispiel: „Wenn fertig nicht fertig ist“
In SCRUM bedeutet die Aussage DONE, dass das Produktinkrement alle Eigenschaften erfüllt, welche für einen Release erforderlich sind. Die Definition of Done (DoD) wird durch das Entwicklungsteam gemeinsam erarbeitet, vereinbart und gelebt. Zu vereinbarende Kriterien können beispielsweise sein
- Featureabnahmekriterien sind erfüllt und geprüft
- Peer Review für Sourcecodes durchgeführt, Feedbacks eingearbeitet
- Notwendige Dokumentation für Anwender und Betrieb erzeugt und geprüft
- Setup-/ Upgrade-Skripte angepasst und getestet
- Testsuiten angepasst und geprüft
Wird das DONE nicht gelebt, dann kann das Produkt dem Anwender nicht zur Verfügung gestellt werden.
- Hat das Produktteam einen Fortschritt erzielt?
- Welcher Gegenwert wurde für das Investment erzeugt?
- Ist die Produktvision weiterhin aktuell?
- Realisiert das Produkt die gewünschten Einnahmen?
Mangelnde Professionalität des Projektteams
Nicht selten wird ein neues Vorhaben mit der Unterstützung von externen Partnern gestartet. Aber es ist genauso wichtig zu beachten, dass jedes Unternehmen eine eigenständige Kultur in das Projekt einbringt. Unterschiedliche Sichtweisen, Denkmuster und Entscheidungsstrategien können die kreative Lösungsfindung positiv beeinflussen.
Voraussetzungen sind, eine klare, verständliche Produktvision, hohes Vertrauen im Team und Vertrauen des Unternehmens in das Vorhaben und die Mitarbeiter. Nicht zuletzt müssen Scrum Master und Product-Owner ihre Rollen konsequent ausfüllen.
Beispiel: „Doppelrollenzielkonflikt“
Jede Rolle im agilen Kontext verfolgt ein wichtiges Ziel, welches innerhalb des Gesamtkontexts notwendig ist und in der Gruppe ausbalanciert, bessere Ergebnisse entstehen lässt.
Der Product-Owner ist der Eigner des Produktes. Seine Aufgabe ist es, mit den gegebenen Mitteln den höchstmöglichen Wert zu erschaffen. Dafür ist es notwendig das Team kontinuierlich zu Höchstleistung anzuspornen. Sein Ziel ist die erfolgreiche Prüfung des Produktes und seiner Eigenschaften am Markt.
Der Scrum Master ist der Wächter über den Scrum-Prozess. Seine Aufgabe ist es, dem Entwicklungsteam die Mittel zur Verfügung zu stellen, die es für seine Arbeit benötigt. Gleichzeitig berät er das Entwicklungsteam in Fragen zur Selbstorganisation, Administration und Leben im agilen Umfeld. Sein Ziel ist die erfolgreiche Implementierung des agilen Prozesses und die kontinuierliche Überwachung und der Schutz der damit verbundenen Arbeitsschritte.
Werden beide Rollen durch eine Person ausgefüllt, sind essentielle Prozesssicherheiten nicht mehr gegeben.
- Animation des Teams zu Overcommitment – Resultat: Underdeliver
- Aufbruch das Schutzgebiets: „Der Sprint gehört dem Entwicklungsteam“ – Messbarkeit geht verloren (Velocity, Capacity)
- Unklare Definition of Done – siehe „Wenn fertig nicht fertig ist“
Beispiel: „Prozess wird vom Team nicht definiert und nicht gelebt“
Agile Prozesse tragen Engagement, Verpflichtung und Selbstverantwortung in ihrer DNA. Das zeigt sich besonders an Scrum, welcher in seinem Manifest keinen Prozess definiert, sondern ein Framework beschreibt. Agile Teams können das Framework wie einen Baukasten verwenden und sich einen eigenen, selbst entwickelten Prozess definieren. Wesentlicher Aspekt ist, der entstandene Prozess ist spezifisch für das Team und er gehört dem Team. Fehlt es einem Team an Erfahrung, ist ein vorgefertigtes Prozesstemplate durch einen agilen Coach festgelegt, Garantie für Misserfolg.
- Das haben wir so nie gewollt!
- Die DoD / DoR passt nicht auf unser Feature!
- Kann ich nicht einfach nur meine Entwicklungsaufgabe erledigen?
- Ich verstehe den Sinn der Akzeptanzkriterien nicht!
Der nächste Beitrag „How To Fix“ wird Wege skizzieren, wie auf Fehlergründe sinnvoll reagiert werden kann.