Probleme und Lösungen für Teilzeit-Scrum in kleinen Teams: Wie viel Zeit für die verschiedenen Meetings?

Liest man sich im Netz zum Thema Scrum ein, entdeckt man viel Wissenswertes und Interessantes. Allerdings geht es dabei meist um Scrum-Teams, bei denen sich die Mitglieder in Vollzeit ihren Projekten widmen. Doch was ist, wenn das nicht oder nur sehr eingeschränkt möglich ist? Im Folgenden wollen wir uns deshalb den Herausforderungen und Problemen stellen, denen Teilzeit-Scrum Teams gegenüberstehen.

Weiterlesen

Ihr seht, Agilität hat ihren Preis und manchmal kommt es eben vor, dass Mitglieder von anderen Teams, auf deren Input man gerade angewiesen ist, wenig bis gar keine Zeit haben, um sich auszutauschen. Im Folgenden gehen wir auf Teilzeit-Teams ein, die versuchen agil zu sein und ihr Produkt stetig und selbstverantwortlich weiterzuentwickeln. Auf die Methoden Scrum und Kanban gehen wir hier nicht im Detail ein, dazu gibt es bereits unzählige Informationen im Internet, und setzen das als Voraussetzung an, diese vom Konzept her verstanden zu haben.

Nehmen wir mal an, wir sind ein zusammengestelltes kleines Team (bspw. ein Startup) und möchten mit der agilen Methode bzw. dem Framework SCRUM in 4-wöchigen Sprints kontinuierlich Features und Verbesserungen am Produkt durchführen – aber können nicht in Vollzeit am Produkt arbeiten, weil man noch nebenher andere operative Tätigkeiten „an der Backe hat“. Wie lange wäre dann nach Scrum dann die Dauer der einzelnen Meetings?

Diese Situation haben wir schon bei einigen Teams festgestellt. Doch keiner kann genau „im Kopf“ ausrechnen, wie groß die einzelnen Meetings idealerweise angesetzt sein sollten, dass Meeting- und Entwicklungszeit noch im Verhältnis zueinander stehen. Eine Hilfe kann dieses praktische Excel-Tool zum Ausrechnen der idealen Dauer eines Meetings sein. Hier findet Ihr auch zusätzliche Infos.

Vorab gesagt: Teilzeit-Scrum ist prinzipiell nicht zu empfehlen, denn Teilzeit-Scrum birgt eine Reihe neuer Probleme und Stressfaktoren. Dennoch möchten viele Teams trotzdem auf diese Weise die Inkrements des Produkts weiterverfolgen.

Dauer eines Meetings berechnen – ein Beispiel

Unser Beispiel sind 4-wöchige Sprints mit einer „Teilzeit-Beteiligung“ an der Produktweiterentwicklung von 8 Stunden pro Woche für jedes Team-Mitglied. Ergibt 32 Stunden pro Sprint. Dann ergeben sich daraus:

Da Meetings idealerweise 20% der Gesamtzeit einnehmen, stehen demgegenüber 80% für die Entwicklungszeit  = 25,5 Stunden. Man könnte das noch unterteilen in erfahrungsgemäß 2/3 für die Realisierung und 1/3 für Konzeption und am Ende Abnahme- und Korrekturzeit. Ergäbe ca. 16 Stunden maximum für Realisierung und den Rest für gemeinsame Konzeption und Abnahme, bzw. Korrekturen.

So sähen rechnerisch die idealen Dauern aller Arten von Meetings aus:

• 3x wöchentliche kurze Stand-Up Meetings á 5 Minuten
• Backlog Refinement: 3,25 Stunden => Runden wir ab zu: 45 Minuten pro Woche für jeden!
• Sprint Planning: 1.5 Stunden
• Sprint Review: 0,75 Stunden
• Sprint Retrospektive: 40 Minuten

D.h. auch für die Einschätzung im Planning-Meeting, was man sich im Sprint zutrauen kann, zeigt sich, dass man (pro Kopf) maximal 16 Stunden investieren kann für Realisierungsarbeiten. Das ist gar nicht mal so viel. Hinzu kommt die Herausforderung vorab, die Userstories klein genug zu kriegen, dass sie in einem Sprint auch tatsächlich umgesetzt werden können.

Auch die 3 Stand-Up Meetings von 5 Minuten und nur einmal pro Woche sind in der Praxis eigentlich zu knapp – Probleme können oft nicht angesprochen werden oder es ist schon zu spät, um noch rechtzeitig reagieren zu können. In der Praxis haben sich aber 15 Minuten ganz gut gemacht. Noch besser sind zwei Stand-Ups pro Woche bei so etwa 8-10 Minuten.

Das Backlog Refinement wird fast bei allen Teams, die wir kennen, unterschätzt bzw. nicht genug Zeit für jeden mit eingeplant. Dabei sind Diskussionen hier sehr wertvoll, und jeder kann guten und wertvollen Input liefern.

Besser in der Praxis klappen 4-Wochensprints mit doppelter Teilzeit-Beteiligung, also alle Dauern einfach mal 2 nehmen. Und das sollte unserer Erfahrung auch das Minimum sein: 16 Stunden pro Woche zu investieren. Erst dann greifen so langsam die Vorteile des SCRUM Frameworks.

Teilzeit-Scrum: Probleme und Herausforderungen

Unserer Erfahrung nach zeigen sich folgende Probleme bei Teilzeit-Scrum in der Praxis am häufigsten:

• Fokus-Problem: Dadurch, dass man noch andere Tätigkeiten in der Woche verfolgt, wird es insgesamt ganz schön viel. Darunter leiden die Qualität, Absprachen, und auch die Kreativität. Noch mehr Stress und Unruhe sind die Folge – insbesondere, wenn auch noch das Backlog Refinement jede Woche Fokus und Aufmerksamkeit erfordert…
• Die wertvollen Stand-Up Meetings finden zu selten statt, dadurch wird der ganze Entwicklungsprozess recht zäh, besonders wenn die Team-Mitglieder zu unterschiedlichen Tagen am Sprint arbeiten.

• Schnelle Hilfe von Kollegen ist kaum möglich und überhaupt stellt sich kein umfassendes Team-Gefühl ein und am Ende landen wir doch wieder bei „jede/r-macht-was-alleine“.
• Man verschätzt sich ordentlich: Ein 4-Wochen-Sprint erzeugt irgendwie unweigerlich immer das Gefühl, noch viel Zeit zu haben – ein Trugschluss! Das sind unterm Strich gerade einmal 16 Realisierungsstunden. Das ist verdammt knapp!
• Durch die begrenzten Kapazitäten pro Sprint werden die Userstories so derart klein runtergebrochen, dass es am Ende doch 3 Sprints dauert, bis ein nennenswertes Feature als Ganzes herausspringen kann. Das macht die Produktentwicklung recht zäh und „sichtbare“ Erfolge lassen auf sich warten. Motivierend ist anders.

Teilzeit-Scrum: Wie man ein Nicht-Vollzeit-Team aufstellen kann

• Gleicher Tag: Alle arbeiten an gleichen Tagen zusammen am Sprint. Morgens das dazugehörige Stand-Up. Nachteil: Eine Woche warten bis zum nächsten Sprint-Tag kann schaden – man muss sich nach einer Woche wieder komplett neu reindenken.
• Komprimierter Sprint: In einem 4-Wochen-Zyklus reservieren alle Team-Mitglieder eine Woche komplett für den Sprint, und arbeiten Vollzeit und zusammen. So wird daraus dann quasi ein 1-Wochen-Sprint. Dafür bleiben die nächsten 3 Wochen pprintfrei und können für die operativen Tätigkeiten mit klarerem Kopf genutzt werden. Macht richtig Spaß und fördert sowohl die Produktivität und Kreativität als auch die Teamkultur. Nachteil hier: Dass alle Teammitglieder wirklich 100% ihrer Zeit dem Sprint widmen können, ist in der Praxis leider oft mit an Sicherheit grenzender Wahrscheinlichkeit unmöglich – zumindest bei kleinen Teams. Es gibt nämlich immer etwas anderes, das dazwischenfunkt: Wer beantwortet in der Zwischenzeit bspw. Customer Mails und Anrufe?

• Man unterteilt das Team: Die eine Hälfte arbeitet Vollzeit am Sprint, die andere Hälfte am operativen Geschäft. So wäre beides unter einen Hut gebracht. Im nächsten Sprint könnte man tauschen, dass jede/r die Chance hat, in einem kleinen Team am Produkt zu arbeiten. Nachteil: In kleinen Teams gibt es viele Fachkompetenzen nur einmalig, und sie würden dann entweder hier oder dort fehlen. Ein weiterer Nachteil ist der ständige Handover zwischen den beiden Gruppen, damit beide auf dem gleichen Stand sind.
• Der Kompromiss aus allem: Die Team-Mitglieder einigen sich darauf, an mindestens 3 Tagen pro Woche zur gleichen Zeit am Tag am Sprint zu arbeiten. Das kann z.B. in 3-Stunden-Blöcken geschehen. Jeder Block beginnt mit einem zeitlich strikt eingehaltenem Stand-Up Call mit 5 Minuten, um sich gegenseitig zu updaten. Man arbeitet zusammen an einem Tisch / im selben Raum (kann natürlich auch Remote sein, aber dann im Breakout-Raum einer Videokonferenz, bei der alle anderen gemutet sind). Es macht Sinn, dass in diesem Team (kann auch aus 3 Personen bestehen) verschiedene Fachbereiche vertreten sind, um gemeinsam an einer Userstory zu arbeiten. Beispiel eines kleinen Teams könnte sein: Jemand, der die Software-Funktion implementiert, jemand für die Marketing-Realisierung und Texte, eine Person für Testszenarien und noch jemand für Usability und Beschriftungen oder Übersetzungen.

Eine ganz andere Alternative bei Teilzeit wäre das wesentlich einfachere Kanban als Methode. Das sollte nicht außer Acht gelassen werden. Und was sich auch immer mehr durchzusetzen scheint, ist eine Kombination: Scrumban. Was nach einer langweiligen Indie-Band klingt, ist in Wirklichkeit recht weit gefasst – und zwar ganz ohne feste Definition, da jedes Team das anders realisiert. Aber auf diese Kombinationsmodelle werden wir in einem gesonderten Artikel nochmal tiefer eingehen.

Was sind Eure Erfahrungen mit Teilzeit-Scrum? Was könnt ihr anderen Anfängern und Anfängerinnen für Tipps geben?