Wie kann man WIP mit Schwärmen in Agile/Scrum-Teams niedrig halten?

tl;dr Hören Sie auf, sich so viele Gedanken über die Menge an WIP zu machen, und fangen Sie an, sich Gedanken darüber zu machen, wie Sie den Sprint erledigen können

Bei meiner Arbeit haben wir viele verschiedene Dinge ausprobiert, um den WIP so gering wie möglich zu halten. Wir sind ein extrem funktionsübergreifendes Team mit Mitgliedern (insgesamt 8) in sechs verschiedenen Bereichen (iOS, Android, .Net, Web, Testing und Design) und wir sind derzeit sehr zufrieden mit den folgenden Praktiken:

• Das Wichtigste: Wir machen uns nicht mehr so ​​viele Gedanken über den WIP, solange das Sprintziel nicht in Gefahr ist. Das bedeutet, dass es uns nichts ausmacht, wenn unsere Leute von all den User Stories schwärmen, solange das Ziel, den Sprint zu bekommen, klar in Reichweite ist. Natürlich arbeiten wir, wenn möglich, alle gleichzeitig an einer User Story.
• Wir haben uns um das Problem gekümmert, dass wir uns gegenseitig auf den Zeh getreten sind, indem wir daran erinnert und uns mehr auf den Wert des Teams als auf den Wert des Einzelnen konzentriert haben. Das Ziel des Teams ist das Wichtigste. Das bedeutet, dass die Zusammenarbeit mit der Zeit einfacher werden sollte. Es erfordert eine Menge Zusammenführung verschiedener Commits (codebasiert), aber die Entwickler gewöhnen sich daran. Es hilft Ihnen, sich gegenseitig auf die Zehen zu treten, weil Entwickler dazu neigen, kooperativer zu werden und anfangen, Dinge wie Paarprogrammierung zu tun, ohne dass irgendjemand auch nur einen Hinweis darauf gibt.
• Jede User Story haben wir mit einer Reihe von Disziplinen zu verbinden, so dass es klar ist, wenn jemand, dem es in einer bestimmten Disziplin völlig an Erfahrung mangelt, die User Story überspringt. Dies sollte jedoch sehr bewusst geschehen, und jeder Standup sollte sich darauf konzentrieren, die oberen zu erledigen. Wenn also jemand dabei helfen kann, wechselt der Fokus schnell zurück.
• Wir haben festgestellt, dass es ziemlich schwierig ist, Tester einzubeziehen. Wir haben sie früher einbezogen, indem wir ihnen bereits nach fast einer Stunde Versionen gegeben haben, damit sie mit dem Testen beginnen und neben Ihnen sitzen können, während Sie einige der Probleme lösen, die sie gefunden haben. Normalerweise produzieren wir nicht so viel Software für einen Tester, also teilen wir uns einen Tester mit mehreren Teams, was bisher keine wirklichen Probleme aufgeworfen hat, außer dem logistischen (wo man sie platziert).

Dies sind nur einige Praktiken, die wir als sehr nützlich empfunden haben. Ich weiß, dass sie nicht alle strenges Scrum sind, aber andererseits funktioniert Scrum nur, wenn Sie es innerhalb Ihrer eigenen Domäne anwenden. Bei uns funktioniert das so super, bei deinem Team mag das etwas anders sein.

Schwärmen definiert

Dies ist eines dieser Schlagworte, die mehr Ärger verursachen als lösen. Es klingt großartig, aber die Leute müssen sich auf eine konkrete Definition einigen, bevor sie darüber diskutieren. Schwärmen bedeutet normalerweise eines von zwei Dingen:

1. „Alle Mann an Deck“, um eine einzelne User Story anzusprechen. Dies ist eine Erweiterung der Idee des kollektiven Eigentums und wirft maximale Ressourcen auf ein bestimmtes Problem.

2. Grassroots-Organisation um eine Reihe von Problemen herum, die oft in einem Scrum-of-Scrums-Kontext gesehen werden. So wie Ameisen ohne zentrale Richtung um eine Nahrungsquelle herumschwärmen, soll das Schwärmen zu Bottom-up-Lösungen statt zu Top-down-Anweisungen führen.

Schwärmen sollte jedoch niemals ein Synonym für „Todesmarsch“ sein. Nicht jedes technische oder prozessuale Problem wird dadurch behoben, dass man mehr Leute damit beschäftigt, und es gibt kein kostenloses Mittagessen.

Wie Schwärmen auf Ihre drei Fragen zutrifft

Wie sollen wir beim Schwärmen die Arbeit so gestalten, dass sich die Teammitglieder nicht gegenseitig auf die Füße treten?

Du nicht. "Die Arbeit arrangieren" ist das genaue Gegenteil dessen, worum es beim Schwärmen geht. Sie können jedoch sicherlich verhindern, dass die Situation zu einem Autoskooter-Spiel wird, indem Sie Ihren WIP auf einem vernünftigen Niveau halten.

Scrum unterstützt implizit WIP-Limits durch Sprint Planning. Teams sollten User Storys, die in einen Sprint aufgenommen werden, basierend auf ihrer nachhaltigen Geschwindigkeit begrenzen . Dies schränkt den WIP für den Sprint von Natur aus ein. Einige Teams schränken WIP weiter ein, indem sie sicherstellen, dass sich zu einem bestimmten Zeitpunkt nur X Story-Punkte auf dem Kanban-Board (oder in einer bestimmten Spalte des Boards) befinden können.

Wir sind in der Lage, Designer und Entwickler dazu zu bringen, beim Testen mitzumachen. Was können wir für Cross-Train-Tester tun, damit sie auch beim Design und der Entwicklung helfen können?

Dies ist eher eine Frage des kollektiven Eigentums als eine Frage des Schwärmens. Überprüfen Sie zuerst Ihre Kapazität; Sind Sie sicher , dass Ihre Tester genügend Zeit haben, um Zeit für andere Aufgaben als das Testen aufzuwenden?

Wenn Sie sicher sind, dass Ihre Tester nicht so sehr mit dem Testen beschäftigt sind, dass sie woanders eingreifen sollten, müssen Sie im Zeitplan Zeit für das Pairing, das Training und den Informationsaustausch einplanen. Sie müssen auch Geld für Schulungszeit und Schulungsmaterialien bereitstellen. Mit anderen Worten, Cross-Training muss in Ihren Organisationsprozess und Ihr Budget integriert werden, es sei denn, Sie möchten, dass es ein Slogan für etwas bleibt, das Ihr Unternehmen eines Tages tun möchte.

Wenn eine Story blockiert ist, arbeitet der Scrum Master daran, sie zu klären. Sollten wir das Team in der Zwischenzeit nicht mit der nächsten Geschichte beginnen lassen, obwohl WIP steigt?

Nun, nein. Der Scrum Master erleichtert die Kommunikation , die zur Klärung erforderlich ist. Das kann bedeuten, die Probleme der Geschäftsleitung zu melden, mit anderen Projektteams zusammenzuarbeiten, um Ressourcen zu koordinieren, oder ein Teammitglied darin zu coachen, wie man ein politisches oder prozessuales Problem innerhalb der größeren Organisation angeht.

Das Erhöhen des WIP bei blockierten Artikeln ist normalerweise eine schlechte Idee. Das Wechseln von Tasks ist für jeden Prozess von Natur aus schlecht; Scrum ist nicht anders. Wenn eine Geschichte blockiert ist, sollte sich das Team darauf konzentrieren , die Blockade zu beseitigen, anstatt die Aufgabe vom Problem weg zu wechseln.

Was tun, wenn "Swarming" nicht funktioniert

Natürlich können einige Probleme nicht in einem angemessenen Zeitrahmen oder mit einem angemessenen Aufwand behoben werden. In diesem Fall könnte das Team Folgendes in Betracht ziehen:

1. Arbeiten Sie mit dem Product Owner zusammen, um die Story zu verfeinern oder gegen eine gleichwertige Story auszutauschen – aber tun Sie letzteres nur, wenn Sie im Sprint noch genügend Kapazität haben!

2. Zusammenarbeit mit dem Product Owner, um die Story (und alle damit verbundenen Punkte) vollständig aus dem Sprint zu entfernen, solange das Spring Goal nicht beeinträchtigt wird.

3. Zusammenarbeit mit dem Product Owner, um andere unkritische Storys aus dem Sprint zu entfernen, um mehr Teamkapazität für diese (offenbar erhebliche) Hürde zu reservieren.

4. Wenn die Story für das Sprint-Ziel wesentlich war, hat der Product Owner die Möglichkeit, den Sprint vorzeitig zu beenden. Das Team kann eine Retrospektive durchführen, um herauszufinden, was schief gelaufen ist, und dann zur Sprint-Planung zurückkehren.

Wenn Teammitglieder viele Geschichten haben, von denen Sie glauben , dass sie sie innerhalb des Sprints austauschen können, dann haben Sie wahrscheinlich ein Prozessproblem mit:

• Sprintlänge,
• Kapazitätsplanung,
• Einschätzung,
• organisatorische Unterstützung des Projekts,
• politische Unterstützung für das Scrum-Framework, oder
• irgendeine Kombination aus all diesen Dingen.

Da das Team niemals mehr Arbeit in den Sprint ziehen sollte, als es seiner Meinung nach in einer einzigen Iteration erledigen kann, sollten keine „zusätzlichen“ Geschichten herumliegen, die darauf warten, erledigt zu werden.

Wie gestaltet man beim Schwärmen die Arbeit so, dass sich die Teammitglieder nicht gegenseitig auf die Füße treten?

Wenn alle am Schwärmen teilnehmen und sich auf die nächsten Schritte einigen, sollte es nicht passieren. Machen Sie die Ziele/Verpflichtungen/Zielvorgaben klar und transparent.

Wir sind in der Lage, Designer und Entwickler dazu zu bringen, beim Testen mitzumachen. Was können wir tun, um Menschen in die andere Richtung zu schulen?

Was meinst du damit?

Wenn eine Story blockiert ist, arbeitet der ScrumMaster daran, sie zu löschen. Sollten wir das Team in der Zwischenzeit nicht mit der nächsten Geschichte beginnen lassen, obwohl WIP steigt?

Wenn Sie das tun, ist die ganze WIP-Idee sinnlos. Wenn etwas blockiert ist und die Warteschlange/Spalte/Zeile voll ist, sollten alle an den gestoppten/blockierten Elementen arbeiten. Wenn das Team mit keinem der blockierten Elemente etwas anfangen kann, haben Sie einen großen organisatorischen Engpass gefunden, der nicht durch eine Erhöhung des WIP gelöst werden kann.

Das richtige WIP-Limit zu finden, ist eine Herausforderung, die Disziplin erfordert. Ich erinnere mich, dass wir lange Diskussionen und Kämpfe geführt haben, bevor wir den WIP geändert haben, und am Ende haben wir es immer geschafft, die Engpässe zu beseitigen und den vereinbarten WIP zu halten. Nach meiner Erfahrung werden diejenigen, die mit dem WIP-Konzept nicht vertraut sind, diese Art von Ansatz nicht wirklich verstehen (oder billigen), bis sie ihn vollständig verstanden haben.

Ich werde Ihre Fragen anhand der Erfahrung, die ich gemacht habe, beantworten. Beachten Sie, dass meine Antworten aus einem allgemeineren agilen und schlanken Prozess stammen, nicht aus einer strikten Scrum-Sicht. Obwohl sie hilfreich sein sollten, müssen Sie sie wahrscheinlich anpassen.

1. Wie sollten wir beim Schwärmen die Arbeit so gestalten, dass sich die Teammitglieder nicht gegenseitig auf die Füße treten?

Wir gehen dies oft im Rahmen des Priorisierungsprozesses an. Wir werden versuchen sicherzustellen, dass die begonnene Arbeit verschiedene Funktionsbereiche abdeckt, um die Notwendigkeit zu verringern, dass mehrere Personen an denselben Codebereichen arbeiten. Offensichtlich erfordert dies während des Priorisierungsprozesses einige Kenntnisse der Codebasis und erfordert, dass genug getan werden muss, damit Sie auswählen und auswählen können.

Wenn Sie es nicht vermeiden können, sich gegenseitig auf die Füße zu treten, ist es eine der wichtigsten Hilfestellungen, sicherzustellen, dass die Menschen sich der Überschneidungen bewusst sind und ihre Änderungen besprechen. Dies trägt normalerweise dazu bei, widersprüchliche Änderungen zu reduzieren.

Abhängig von dem von Ihnen verwendeten Änderungsverwaltungsprozess und der jeweiligen Änderung kann es so einfach sein, dass einer der Mitarbeiter damit beginnt, seine erforderliche Änderung am konfliktbehafteten Code zu implementieren und sicherzustellen, dass dieser Teil seiner Änderung dies nicht tut alles andere negativ beeinflussen und nur diesen Teil ihrer Gesamtänderung einchecken. Dann können beide Seiten weitermachen.

2. Wir sind in der Lage, Designer und Entwickler dazu zu bringen, beim Testen mitzumachen. Was können wir für Cross-Train-Tester tun, damit sie auch beim Design und der Entwicklung helfen können?

Bei den meisten Projekten, mit denen ich mich befasse, beziehen wir Tester aktiv in das Design, aber nicht in die Entwicklung ein. Eine der größten Hilfen, die unsere Tester beim Design leisten, besteht darin, die Designer wissen zu lassen, wie testbar ihr Design sein wird, wie lange es voraussichtlich dauern wird und welche Änderungen am Design dazu beitragen können, die Testfähigkeit zu verbessern oder die Testzeit zu verkürzen. (Offensichtlich gibt es immer Kompromisse, aber es bietet zumindest die Option im Voraus während der Designphase und nicht nachdem der Code geschrieben wurde). Die Tester liefern auch Beiträge zu häufig übersehenen Fehlerfällen, die sie gesehen haben, Vorschläge für Testfälle, die Entwickler sicherstellen sollten, bevor sie die Entwicklung als „fertig“ betrachten, und Datensätze, gegen die getestet werden muss. Dies alles ist im Grunde ein Fall, in dem sie anwenden, was sie aus ihren Tests gelernt haben,

Wir neigen dazu, Tester nicht so oft in die Entwicklung einzubeziehen, obwohl dies im Allgemeinen darauf zurückzuführen ist, dass ihre Zeit besser mit Tests oder der Unterstützung des Designs verbracht wird.

3. Wenn eine Story blockiert ist, arbeitet der Scrum Master daran, sie zu löschen. Sollten wir das Team in der Zwischenzeit nicht mit der nächsten Geschichte beginnen lassen, obwohl WIP steigt?

Unter der Annahme, dass die blockierte Geschichte nicht die einzige aktive ist, sollte das Team sehen, was es tun kann, um andere bereits in Bearbeitung befindliche Elemente zuerst fertigzustellen.

Erwägen Sie, einen kleinen Fehler oder eine andere Form von technischer Schuld zu beheben.

Sehen Sie nach, ob irgendwelche Untersuchungsarbeiten für bevorstehende Funktionen durchgeführt werden müssen.

Eine neue Geschichte zu beginnen, ist das Letzte, was getan werden sollte.