Agile Produkt-Entwicklungsmethoden schlagen gerne vor, eine Warteschlange für Anforderungen zu bilden und diese dann nach und nach abzuarbeiten (Beispiel: Scrum mit seinem Product Backlog). Bis zur Freigabe der ersten Produktversion hat das auch durchaus seine Vorteile: Man schätzt die Komplexität jeder Anforderung, beobachtet dann, wie lange die Realisierung der ersten paar Anforderungen dauert und rechnet das dann hoch auf die Summe der Komplexität der ganzen Warteschlange. Damit weiß man ungefähr, wie lange das Team brauchen wird, bis es die erste Produktversion entwickelt hat.
Nach der Freigabe der ersten Version wäre es doch aber viel interessanter zu wissen, wann das Team das nächste wichtige Feature herausbringt, was man dann schon wieder freigeben könnte, um einen Wettbewerbsvorteil zu haben und die Konkurrenz alt aussehen zu lassen. Plötzlich nimmt die Wichtigkeit der Warteschlange und das Erreichen eines bestimmten Termins ab, weil man sich entschließt, einfach möglichst viel Wert pro Zeiteinheit liefern zu wollen und das Ohr immer nahe an den Kundenbedürfnissen zu haben.
In diesem Moment stellen Sie am besten Ihre Strategie um: Werfen Sie die alte Liste/Warteschlange weg, gehen Sie in den Flow-Modus über und denken Sie in regelmäßigen Abständen darüber nach, was Sie Ihrem Kunden nun schon wieder Gutes anbieten wollen. Treffen Sie sich mit Ihrem Team zu einer Besprechung dieser neuen Features. Füllen Sie die Liste dann nur mit so vielen Features wieder auf wie Ihr Team bis zum nächsten Mal, an dem Sie sich wieder zum Auffüllen der Liste treffen, realisieren und qualitätssichern kann.
Rechengrundlage dafür: Das Team hat eine gewisse Produktionsrate, diese schwankt um einen Mittelwert “m” mit einer Standardabweichung “sigma”. Wenn Sie als Länge der Eingabewarteschlange Ihres Teams nun “m plus 3mal sigma” nehmen, dann sind Sie zu 99% sicher, dass das Team bis zum nächsten Treffen auf jeden Fall genug zu tun hat und die Planung wegen der kurzen Schlange trotzdem agil bleibt.
Beispiel: Angenommen, das Team schafft zwischen zwei Treffen 10 Features mit einer Standardabweichung von 5 Features, dann reicht eine Warteschlangenlänge von 10+3*5=25 Features bis zum nächsten Treffen völlig aus – mehr brauchen Sie nicht. (Ich habe schon Teams gesehen, die arbeiten mit Warteschlangen von 700 Features, von denen 75% bei jedem Treffen ignoriert werden – das kostet Zeit und Nerven).
So genießen Sie folgende Vorteile:
- Die Liste der Dinge, die zu tun sind, bleibt übersichtlich und klar.
- Wenn Sie ein neues Feature hinten an die Liste schreiben, dauert es nicht lange, bis es realisiert sein wird, weil davor nicht so viele Features “Schlange stehen”.
- Die Mitarbeiter liefern bessere Qualität, weil die Klarheit beruhigende und fokussierende Wirkung hat.
- Das Ganze kostet wenig Zeit und spart deshalb Energie, die Sie und Ihre Teams schon wieder in die Entwicklung stecken können.
Viel Erfolg beim Ausprobieren – und: Erzählen Sie mir, wie es geklappt hat. Kontaktdaten finden Sie rechts oben auf der Seite unter dem Foto.
Ich verstehe nicht, warum ein Team nicht vom ersten Tag an so denkt: “einfach möglichst viel Wert pro Zeiteinheit liefern [...] und das Ohr immer nahe an den Kundenbedürfnissen [...] haben.”
Wenn das der Modus ist, bei dem man keine Warteschlange braucht, dann braucht man nie eine Warteschlange. Warum auch? Jeder Backlog-Eintrag über das hinaus, was ein Team in der nächsten Zeiteinheit schafft (vorbehaltlich einem kleinen Puffer) ist Verschwendung. Niemand weiß recht, ob die Einträge so oder überhaupt umgesetzt werden.
Wenn schon “Limit your WIP”, dann aber konsequent, würde ich sagen.
-Ralf
Hallo Ralf,
tja, wenn es nur auf das Team und die Features ankäme, dann würde derselbe Modus sofort vom ersten Tag an gelten!
Doch da sind ja auch noch die Stakeholder, die wissen wollen, wann das erste Release herauskommt und ob sich der Business Case dann rechnet. Dafür braucht man am Anfang halt ein Backlog – zur Planung, nicht zur sofortigen Umsetzung. Die Länge hängt von der Volatilität der Domäne ab: je volatiler, desto kürzer.
Ist das erste Release einmal fertig und das Geld fließt wie erhofft, dann interessiert das lange Backlog fast nicht mehr, sondern die Zeit bis zum nächsten Feature, mit dem man die Kunden erneut begeistern kann, wird immer interessanter. Dann kann man komplett in den Flow übergehen.
Hinzu kommt bei neuen Teams, die zum ersten Mal zusammenarbeiten: Manche Prozesse sind noch nicht so ausgereift, dass Flow immer möglich ist (zum Beispiel kontinuierliche Integration, fortlaufender Build und Deployment). Auch da bildet ein Backlog noch eine gewisse Stütze, die man später fallen lassen kann.
Gruß,
Matthias