Der agile Projektmanager: WIPping Things Into Shape

Artikel von Bob Galen

Einmal habe ich ein Team geführt und gecoacht, das große Schwierigkeiten hatte, als Team zusammenzuarbeiten. Ich war der Leiter von R&D bei einem Hersteller für Produkte aus dem Bereich eCommerce SaaS. Wir haben Scrum einige Jahre mit recht gutem Erfolg genutzt und hatten etwa zehn Scrum-Teams mit Schwerpunkt auf den verschiedenen Aspekten unseres Online-Produkts.

Es gab jedoch ein paar Teams, die wirklich Probleme hatten, was oft die Natur der Dinge zu sein scheint. Von zehn Teams gab es etwa drei, die sehr leistungsstark waren, drei, die mittelmäßig abschnitten, und drei, bei denen es nur Probleme gab. Verstehen Sie mich nicht falsch, die Teammitglieder waren gute Leute und prima Mitarbeiter. Es war nur so, dass diese ganze Sache mit der „agilen Zusammenarbeit“ für einige von ihnen schwierig zu fassen und anzunehmen war.

Besonders ein Team hatte große Schwierigkeiten. Es hatte schon einige gescheiterte Sprints in Folge zu verbuchen, und so griff ich als Coach ein. Lassen Sie mich für einen Augenblick zum Punkt Misserfolg ausschweifen, bevor Sie anfangen Tomaten zu werfen:

Wir haben den Erfolg oder Misserfolg nicht in Stunden, Punkten oder „Done“-Storys gemessen, sondern daran, ob das Team das Sprint-Ziel erfüllt hat, auf das es sich beim Planen des Sprints festgelegt hatte. Es herrscht in der Scrum-Community große Angst in Bezug auf die Verwendung von Wertungen wie Erfolg und Misserfolg oder sogar von Begriffen wie „sich festlegen“. Im Rahmen dieses Artikels möchte ich auf diese Praxis nicht weiter eingehen. Sie finden Verweise auf einige relevante Beiträge am Ende des Artikels. Es genügt zu sagen, dass wir zum Zeitpunkt dieses Beispiels Sprints in Hinblick auf Erfolg und Misserfolg bewerteten.

Wenn die Teams scheiterten, war in ihrer Retrospektive von Anpassungen die Rede. Doch die Änderungen waren häufig ziemlich einfach und ungefährlich gehalten. Ich hatte das Gefühl, dass sie nicht die Probleme angingen, die tatsächlich negative Auswirkungen auf ihre Leistung hatten. Ich weiß noch, wie in einer Retrospektive entschieden wurde, dass die verwendeten Schätzungseinheiten fehlerhaft waren. Also wechselten sie von einer modifizierten Fibonacci-Sequenz zu Gummibärchen. Ich brauche nicht zu betonen, dass der nächste Sprint durch die Anpassungen nicht positiv beeinflusst wurde. Das ging eine ganze Weile so.

Normalerweise bin ich ein gelassener Coach und versuche Teams so zu beeinflussen, dass sie sich selbst beobachten und verbessern. Doch dieses Team bekam es einfach nicht hin. So bat ich nach dem vierten oder fünften Misserfolg in Folge den ScrumMaster und den Product Owner zu einer Unterhaltung in mein Büro. Ich bestand darauf, dass die gegenwärtige Serie von Misserfolgen aufhören müsse. Ich sagte ihnen, dass ihr Hauptproblem meiner Meinung nach in der fehlenden Zusammenarbeit des Teams bestehe, und dass Einzelarbeit die Norm sei anstelle von Zusammenarbeit, Schwarmarbeit, Kollektivarbeit und Teamwork. Sie stimmten mir zu und äußerten ihre eigene Frustration über die fehlende Verbesserung. Sie wussten jedocht nicht, was sie tun sollten, und wollten dem Team keine Vorschriften machen. Ich machte sogleich zwei Vorschläge, doch das Team musste die Probleme selbst angehen.

Wenn ihnen meine Empfehlungen nicht gefielen, dann sollten sie selbst sinnvolle Vorschläge machen, doch sie sollten nicht länger um die eigentlichen Probleme herumtanzen und sinnvolle Lösungen zur Anpassung in ihrer Retrospektive entwickeln. Offensichtlich musste sich etwas ändern – dem Team zuliebe.

Meine zwei Anpassungen

Ich empfahl zwei einfache Anpassungen für ihr Team:

  • Erstens bat ich sie, sich als Team zusammenzufinden und sich einen Raum zu suchen, wo sie alle für einen Sprint zusammen sitzen konnten. Ich sprach über die Quintessenz der agilen Teamumgebung, wo jeder an einem langen Tisch sitzt – verteilt auf beiden Seiten. Das gesamte Team in einem einzigen Raum, wo die Teammitglieder einander sehen und hören und sich auf natürliche Weise zu Paaren zusammenschließen können. In einem Raum, in dem sie sich von ihren Laptops losmachen und sich an einem Whiteboard versammeln können und der es ihnen auch ermöglicht, ihren Daily Scrum abzuhalten. Könnten sie es einfach mal probieren … nur für einen zweiwöchigen Sprint?
  • Als nächstes bat ich sie, ihre „work in progress“ oder WIP zu begrenzen. Es gab für mich nicht unbedingt eine „magische Zahl“, doch ich glaubte, dass eine Obergrenze von drei WIPs für sie hilfreich sein könnte. Hier sei angemerkt, dass dies eine harte Grenze sein würde. Das Team durfte nur an drei User Storys aus dem Sprint Backlog gleichzeitig arbeiten. Diese würden die höchste Priorität haben. Um die nächste Story anzufangen, würden sie eine der drei bestehenden abschließen und beweisen müssen, dass sie ihre Definition von „Done“ erfüllt.

Das war alles. Zwei kleine Änderungen, die gezielt auf die Herausforderung, als Team zusammenzuarbeiten, ausgerichtet waren. Eine Weile später, nach der nächsten Retrospektive, hat das Team meine Empfehlungen angenommen und ausprobiert. Sie fanden einen großen Konferenzraum, den sie als Teamzimmer in Beschlag nahmen, und jeder zog in den Raum: Frontend-Entwickler, Tester, Backend-Entwickler, die Scrum-Master sowie der Product Owner. Das ganze Team an einem Ort für einen Sprint. Ihre Sprint-Planung lief größtenteils wie zuvor ab, doch die Workflow-Strategien wurden stark von den WIP-Obergrenzen beeinflusst. Tatsächlich planten sie nur die ersten drei Storys anzupacken und den Rest der Arbeit im Laufe des Sprints entstehen zu lassen. Sie mussten folglich ein bisschen schätzen, wie viel in einen Sprint passen würde.

Jedoch, und das war wichtig, widmeten sie sich nach Planung des Sprints voll und ganz ihren Aufgaben und verrichteten ihre Arbeit als Schwarm. Sie waren bereit, den Anpassungen eine ehrliche Chance zu geben. Ergebnisse Ich verwende ungern Zahlen zur Veranschaulichung von Ergebnissen, denn sie können irreführend und nuancenarm sein. Allerdings möchte ich in diesem Fall einige der Teamzahlen hervorheben, einfach weil sie verdeutlichen, welche Auswirkungen dieser Veränderungen hatten und welche Ergebnisse das Team erzielen konnte.

Das Team hatte sich früher auf einen gewissen Umfang festgelegt und am Ende typischerweise nur 60 bis 75 % der Arbeit (Storys) bezogen auf ihre Sprint-Ziele geliefert. Sie hatten es auch häufig nicht geschafft, höher priorisierte Storys vor niedrig priorisierten Storys zu liefern.
In dem Sprint nach der Einführung dieser zwei Anpassungen lieferte das Team 140 % der zuvor festgelegten Aufgaben und schaffte somit mehr, als es für möglich hielt. Außerdem lieferte es der Priorität nach, so dass, wenn etwas passiert wäre, es die höher priorisierte Story als erstes geliefert hätte.

Doch gibt es eine Tatsache, die ich ausgelassen habe. Zufälligerweise erhielt dieses Team ein paar Tage vor Beginn des Sprints ein neues Teammitglied. Es handelte sich um einen erfahrenen Ingenieur, doch waren das Unternehmen, das Produkt und das Team völlig neu für dieses Teammitglied. Unter dem erneuerten Schwerpunkt auf Zusammenarbeit und Arbeit im Schwarm nahmen sie den neuen Entwickler im Team auf, und er hatte tatsächlich eine positive Auswirkung auf die Sprint-Ergebnisse.

Welche Veränderungen werden durch WIP-Obergrenzen beeinflusst?

Schon bevor Kanban populärer wurde, habe ich WIP-Grenzen in meinem Coaching als Hilfestellung für die Förderung von Zusammenarbeit und Schwarmarbeit genutzt. Die Realität ist, dass ein Team einfach mehr bewältigt, wenn es Schwarmarbeit einsetzt und Verzögerungen, Übergaben und Prüfpunkte beseitigt. Aber es ist oft schwer für Teams, dies zu realisieren. Kommen wir zurück zu unserem Team. Was für Erfahrungen hat es in seinem ersten Sprint gesammelt?

1. Das Daily Scrum wurde immer mehr zu einem gemeinschaftlichen Planungsmeeting als einem Statusmeeting für das Team. Die Diskussionen beinhalteten, wer mit wem zusammenarbeiten würde, um den Schwerpunkt auf die begrenzte WIP zu maximieren und effektiv zusammenzuarbeiten.

2. Da das Team nur noch an wenigen Sachen arbeiten musste, war es wichtig, den Arbeitsfluss nicht zu unterbrechen. Also wurden jegliche Verzögerungen, Hindernisse oder Probleme sofort sichtbar und erforderten Anpassungen des gesamten Teams. Dies half, die Arbeit zu erledigen und den Durchsatz zu verbessern.

3. Es war lustig. Obwohl sie alle sehr dicht beisammen saßen, hatte das Team bislang nicht wirklich zusammengearbeitet. Doch das Entfernen aller Wände und das Zusammenbringen aller änderte die gemeinschaftliche Dynamik. Es gab viel mehr dynamische Paararbeit sowie CrossTeam-Kommunikation unter den Teammitgliedern.

4. Ein weiterer Aspekt des Konferenzraums war die Visualisierung der Arbeit. Es gab ein gemeinsames Whiteboard, auf dem das Team seine Sprint-Pläne hatte. Die Story- und Task-Card-Bewegung war unglaublich visuell und das Team verbrachte jeden Tag Zeit am Whiteboard für die Anpassung ihrer Visualisierungen für die Paararbeit und den Workflow.

5. Die Qualität verbesserte sich, als sich die Entwickler und Tester häufiger und auf natürliche Weise zu Paaren zusammenfanden. Sie fanden schnell Bugs und konzentrierten sich auf deren Korrektur, anstatt sie zu besprechen oder für spätere Behebung zu dokumentieren.

6. Wie ich bereits erwähnte, plante das Team den Sprint nicht im herkömmlichen Sinne von vorne bis hinten. Statt dessen planten sie jede neue Story, während sie sie aufgriffen, und passten ihre Zusammenarbeit nach Bedarf an.

Im täglichen Meeting ging es nicht mehr um Fragen wie: „Was hat jeder Einzelne geleistet und was plant er zu tun?“, sondern: „Wie maximiert das Team ihre tägliche Gewichtung, um die höchstpriorisierten Aufgaben so schnell und so gut wie möglich abzuschließen?“

Nachbereitung

Was mein Beispielteam betrifft mögen sich manche fragen, was nach dem ersten Sprint geschah. Zogen sie in ihre alten Büros zurück? Kehrten sie zu ihren alten Gewohnheiten zurück? Und verbesserten sie sich weiterhin? Ich verschiebe die Beantwortung dieser Fragen auf ein anderes Mal und einen anderen Artikel.

Der Kernpunkt ist: Hat Ihr Team Schwierigkeiten, zusammenzuarbeiten? Halten sich Ihre Entwickler zu lange mit einer Aufgabe auf? Haben Sie zu viele Storys auf einmal zu bewältigen und schaffen Sie es nicht, wichtige Aufgaben abzuliefern? Wird in Ihrer Organisation vom „Scrummerfall“ reger Gebrauch gemacht? Oder sind Sie einfach nicht so produktiv, wie Sie es Ihrer Meinung nach sein könnten? Wenn dies zutrifft, denken Sie bitte darüber nach, sich zusammenzusetzen und die Anzahl der WIPs zu begrenzen. Vielleicht erhalten Sie ja ein anderes Ergebnis.

 

Weitere Artikel vom testing experience Magazin

Automatisierung oder nicht – Lösen wir das richtige Problem? von Markus Gärtner

TMMi: Warum Reifebestimmung wichtig ist von Michiel van der Voort

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

German Testing Board Premium Partner
Ausgezeichnet.org