Artikel

Dr. Agil, Teil 3: das wackelnde Produkt

Beitrag von Udo Loeb
17. Dezember 2013

In der heutigen Ausgabe unseres Magazins widmen wir uns nur einem einzigen Krankheitsbild: dem „wackelnden Produkt“.

Das wackelnde Produkt tritt verstärkt auf, wenn mehrere Teams im gleichen Projekt arbeiten, und es ist äußerst schwer zu diagnostizieren. Zwar gibt es Symptome wie den „ewigen Prozess“ (siehe Dr. Agil Teil 1) oder „the daily off topic“ (siehe Dr. Agil Teil 2), doch um das „wackelnde Produkt“ von anderen Krankheiten zu unterscheiden, muss man sehr genau hinhören, und zwar außerhalb des Entwicklerteams, bei den Projekt- oder Produktverantwortlichen. Oft ist sogar geschicktes Nachfragen nötig, da die Kollegen verständlicherweise symptomatische Aussagen nicht offiziell tätigen, bedeuten sie doch Skepsis gegenüber dem Projekterfolg, wie wir sehen werden.

Das wichtigste Symptom der Krankheit ist nämlich die Befürchtung, dass die Arbeitsergebnisse der verschiedenen Teams „nicht passen“, dass etwas „vergessen wird“ oder „am Ende irgendwas funktioniert“ bzw. das Gefühl, dass durch die agilen Methoden „insgesamt im Gesamtprojekt eine sehr große Unsicherheit entsteht“. Wie kommt das? Soll nicht durch die Agilität alles besser und transparenter werden?

Nehmen wir zur tiefergehenden Analyse die Perspektive der verantwortlichen Kollegen ein. Was ist der größte Unterschied zwischen der Projektarbeit „vor“ und „nach“ der Einführung agiler Methoden?
„Früher“ haben speziell für bestimmte Aufgaben zusammengestellte Teams solange an ihren Aufgaben gebastelt, bis „alles passte“. Jeder konnte jederzeit mit jedem interagieren, um das Endergebnis „passend zu machen“. Dafür wurden Puffer eingeplant, und wenn ernste Probleme entstanden, fand sich zumindest immer jemand, der „verhaftet“ werden konnte.

Heute sieht die Welt anders aus:
Es werden User Stories geschrieben (oder auf andere Art Tätigkeiten definiert), für die es granulare Abnahmekriterien gibt. Diese werden auf mehrere Teams verteilt, die dann, „schlimmstenfalls“ (vom Scrum Master beschützt) an nichts anderem arbeiten sollen. Die Teams ziehen sich hinter diese Arbeitspakete zurück, wer genau an was arbeitet ist nicht klar und alle denken nur an Sprintziele, keiner schaut mehr rechts oder links.
Wenn man nur diesen Teil des Systems betrachtet, fehlen also wichtige Elemente, die man braucht, um erfolgreich zu sein!

Denn: Kann der Product Owner überhaupt sicherstellen, dass die oft sehr technischen Querbeziehungen zwischen den einzelnen Produktkomponenten bei der Aufgabendefinition berücksichtigt sind? Vor allem, wenn die Erfahrung doch zeigt, dass man immer erst beim eigentlichen Doing an alles denkt! Was ersetzt die bisher doch so wichtige M-zu-N-Kommunikation (alle reden mit allen)? Die Scrum Meetings? Und wenn Probleme auftauchen, die ein Team nicht alleine lösen kann: Haben dann die anderen Teams überhaupt Zeit? Immerhin haben die ja ihren eigenen, streng definierten Sprint! Wer ist eigentlich verantwortlich dafür, dass nachher alles zusammen funktioniert?

Die Lösung dieser Probleme ist natürlich nicht trivial. Allerdings gibt es, wenn Fragen wie oben gestellt werden, Anlass, folgende Prozesse genauer zu untersuchen:

1. Anforderungsdefinition
Wie stark ist der Zusammenhang zwischen den Aufgaben des Teams und dem Endprodukt des Projekts? Können Sie nach Erledigung einer Aufgabe ohne Probleme einen höheren Fertigstellungsgrad des Produktes erkennen?
Wenn nicht: Arbeiten Sie an dem „Herunterbrechen“ von Anforderungen, an der Ableitung von Einzeltätigkeiten aus der Vision! Definieren Sie Aufgaben oder zumindest Sprintziele für das Team aus Benutzersicht! Auch wenn dies theoretisch selbstverständlich scheint: In der Realität neigt man oft dazu, alles was „irgendwie“ getan werden muss „irgendwie“ in die Form einer User Story zu pressen, ohne Blick auf das Produkt und ohne gut definierte Inkremente. Ein so gefülltes Product Backlog kann zu immensen Problemen führen!

2. Koordination
Wenn tatsächlich Teams so eng zusammenarbeiten müssen, dass auch während des laufenden Sprints großer Abstimmungsbedarf besteht, dann lassen Sie sie ihre Aufgaben selbst definieren und die Zusammenarbeit selbst organisieren! Hierfür ist Punkt 1 natürlich eine wichtige Voraussetzung, aber es spricht nichts dagegen, beliebige Untermengen von Teams vor ein Whiteboard zu stellen und selbst den Weg zur Erreichung eines Ziels zu bestimmen, selbst User Stories o. ä. zu definieren und die Zusammenarbeit zu organisieren. (Hierbei sind natürlich kulturelle Begebenheiten und die Fähigkeit zur Selbstorganisation von immenser Wichtigkeit).

3. Integration
Prüfen Sie Ihre Integrationsmaßnahmen, den Weg von der Entwicklungsumgebung über Test- und Integrationsumgebungen in das Produkt. Berücksichtigen Sie diese Maßnahmen bei der Definition of Done. Stellen Sie die entsprechenden Prozesse (Releases, Konfiguration, continuous integration etc.) auf Sprintzyklen um (Voraussetzung hierfür ist natürlich ein gutes Qualitätsmanagement).

Wenn Ihnen noch weitere Maßnahmen einfallen, mit denen man das Vertrauen in agil geführten Teams und Projekten steigern kann, würde ich mich über Feedback freuen!