One-man-scrumteam

👋 Schön, dass Du hier bist! Bitte beachte, dass dieser Artikel bereits einige Jahre auf seinem Buckel hat. Seitdem haben sich nicht nur die Welt, sondern auch meine WissenslĂŒcken, Erfahrungen und Ansichten geĂ€ndert. Dennoch stehe ich hinter den Aussagen, die ich damals getĂ€tigt habe. Selbst dann, wenn ich sie mittlerweile anders tĂ€tigen wĂŒrde. Bitte behalte dies beim Lesen im Hinterkopf. Danke. Und viel VergnĂŒgen!

Scrum in kleinen Teams

Scrum und ein kleines Team sind dennoch produktiv

Ich werde auf Seminaren und VortrĂ€gen immer wieder gefragt, ob agile Methoden - und dort vor allem Scrum - auch fĂŒr kleine Teams geeignet sind. Meine Antwort ist dann die Standardantwort aller Dampfplauderer: es hĂ€ngt davon ab. NatĂŒrlich geht es dort nicht, wo das Organisationsumfeld es nicht zulĂ€sst. Aber in diesen FĂ€llen ist die TeamgrĂ¶ĂŸe vollkommen egal. Solange die Struktur und Kultur in diesen Firmen nicht angepasst werden, werden große und kleine Teams mit Scrum scheitern. Aber sehen wir uns die potentiell möglichen FĂ€lle einmal genauer an.

Wie groß muss so ein Scrumteam mindestens sein? #

Der Scrumguide ist da ziemlich eindeutig: nicht weniger als drei Entwickler. Kommen noch mindestens Scrum Master und Product Owner hinzu. Dann sind wir bei fĂŒnf Teammitgliedern
Bei vielen taucht dann die Frage auf: “Kann ich nicht die beiden Rollen Scrum Master und Product Owner zusammenlegen?” NatĂŒrlich geht das. Ich kann auch in meiner Brotfabrik die beiden Rollen BĂ€cker und LKW-Fahrer zusammenlegen. Gehen tut es. Ist es sinnvoll? Ganz klar nein! In dem einen Fall wird mein Brot viel zu spĂ€t zu den Kunden gebracht werden. Was egal ist, weil es ohnehin nicht rechtzeitig fertig werden wird. In dem anderen Fall werden so viele Konflikte auftreten, dass das Team nicht mehr ungestört arbeiten kann. Warum? Vereinfacht: weil der Product Owner subjektiv und der Scrum Master objektiv zu sein hat. Der eine vertritt Kundeninteressen (und oft auch die eigenen, wir sind alle nur Menschen). Der andere vertritt die Interessen aller. Wenn ich diese beiden Rollen in einen einzelnen Menschen hinein packe, bekomme ich Doktor Jekyll und Mister Hyde - einen zerrissenen und leicht schizophrenen Productmasterownerscrum, der wie ein Scheidungskind nicht weiß, auf wessen Seite er sich jetzt schlagen soll. Und ja, es gibt sicher irgendwo die eine oder den einen, die diesen Spagat zustande bringen. Aber in der Regel trage ich gewaltig Unruhe und damit auch eine sinkende ProduktivitĂ€t in mein Team, wenn Scrum Master und Product Owner ein und dieselbe Person sind.

Aber benötige ich immer einen Product Owner? #

Jein. NatĂŒrlich ist der Product Owner wichtig, keine Frage. Jeder, der das Gegenteil behauptet, hat noch nie einen guten Product Owner erlebt. Aber wir reden hier von kleinen Teams. Und da finde ich das Konzept des Story Owners recht hilfreich. Ein Story Owner ist ein Teammitglied, das sich um den kompletten “Life Cycle” einer User Story kĂŒmmert. Von der Erstanforderung und Erstellung, ĂŒber Business Analyse, Refinement und Umsetzung in Iterationen mit Kundenfeedback bis hin zum Release. Also quasi ein Product Owner fĂŒr eine einzelne Story. Und das muss nicht bei Scrum und Softwareentwicklung aufhören, das funktioniert meiner Erfahrung nach mit allen agilen Methoden - Projektmanagement wie Operations.
Und wenn in einem kleinen Team jede und jeder Story Owner ist, komme ich mit vier Teammitgliedern aus.

Und dieser Scrum Master, was macht der ĂŒberhaupt den ganzen Tag? #

Gute Frage.Wenn ich philosophisch werden wollen wĂŒrde
 ich hab mir den Satzanfang jetzt dreimal durchlesen mĂŒssen, ob er richtig ist. WĂŒrde ich philosophisch werden wollen (sicher ist sicher), wĂŒrde ich davon schreiben, dass gar keinen Scrum Master zu haben besser ist, als einen schlechten Scrum Master zu haben. Aber wir gehen davon aus, dass der in unserem Beispiel hier ein guter ist. Und der ist wahnsinnig wichtig. Er muss aber nicht full-time im Team sitzen. Vor allem bei kleineren Teams, wo Konflikte schneller sicht- und somit auch schneller lösbar sind. Und die Zahl der KommunikationskanĂ€le sinkt auch schneller als die Zahl der Teammitglieder.

Ein kleiner Exkurs #

Wer sich nicht sicher ist, wie ich das mit den KommunikationskanÀlen meine, hier ein kleiner Einschub.
Ich kann die Anzahl der potentiellen Kommunikations”linien” mit einer recht einfachen Formel berechnen:

(n * (n - 1)) / 2

n ist die Anzahl der Kommunizierenden, in unserem Fall also der Teammitglieder. Und wenn ich diese Formel fĂŒr die Anzahl an Menschen, die laut Scrumguide Sinn machen (also drei bis sieben) einsetze, bekomme ich folgende Zahlen:

TeamgrĂ¶ĂŸeAnzahl KanĂ€le
33
46
510
615
721

Ihr seht also, dass bei kleineren Teams sehr viel an Kommunikationsaufwand wegfÀllt.

ZurĂŒck zum Scrum Master #

Wenn der Scrum Master gerade nicht beim Team sitzt, bedeutet das ja nicht, dass keiner sich mehr um das Team kĂŒmmert. Ich habe beobachtet, dass in so Momenten die Hauptaufgaben des Scrum Masters - wenn ich diese jetzt grob platt mache, wĂŒrde ich sagen, der “KĂŒmmerer” - oft vom Senior im Team ĂŒbernommen werden.
Das bedeutet, wenn ich jemanden außerhalb des Teams habe, der das Team ab und zu im Sinne eines Scrum Masters betreut (Retros leiten, nach dem Rechten sehen, Team abschirmen, moderieren, Steine aus dem Weg rĂ€umen, etc. - Ihr wisst, was ich meine, Ihr kennt das alles) und ansonsten die Scrum Master-Aufgaben von einzelnen Teammitgliedern ĂŒbernommen werden, benötige ich plötzlich nur mehr drei Teammitglieder.

Warum jetzt aufhören? #

Lasst uns die Kommunikationskanaltabelle mal kurz weiterfĂŒhren:

TeamgrĂ¶ĂŸeAnzahl KanĂ€le
21

Ein Kommunikationskanal, klar. Bei zwei Personen im Raum, können nur a und b miteinander reden. Und ein Kommunikationskanal ist noch unkomplizierter als drei KommunikationskanĂ€le. Also zwei Teammitglieder. Wobei auch zwei Personen miteinander streiten können. Also noch einen weg und ich komme wieder zu meiner initialen Überschrift:

One-man-scrumteam

One-man-scrumteam #

Ein Scrumteam mit nur einem Teammitglied. Wenn ich so ein Team bin, kĂŒmmere ich mich um alles selbst. Da steht dann die User Story - fast schon gezwungenermaßen, aber auf jeden Fall automatisch - plötzlich im Mittelpunkt. Wenn alle NebengerĂ€usche, die in so einem selbstorganisierendem Team nun mal anfallen, verstummen, bleibt der Customer Value. Keine Diskussionen, keine Eitelkeiten, nur der pure Wert.

ZurĂŒck zur RealitĂ€t #

NatĂŒrlich ist das ein sehr abstraktes Gedankenexperiment und natĂŒrlich habe ich bewusst ausgeschmĂŒckt und weggelassen. Aber so ein Ein-Frau- bzw. Ein-Mann-Scrumteam kann

  1. funktionieren (und funktioniert auch) und
  2. uns wertvolle Ideen und LösungsansÀtze bieten. Wenn ich etwas komplett abstrahiere und reduziere, wird KomplexitÀt meiner Meinung nach leichter greifbar.

Das bedeutet, ich kann auch mit weniger als fĂŒnf Personen erfolgreich ein agiles Projektteam haben. NatĂŒrlich sind die Zahlen im Scrumguide und in anderen Methodiken (drei bis sieben Teammitglieder plus ein Product Owner und ein Scrum Master) wohl ĂŒberlegt und basieren auf vielen Gedanken und vor allem Learnings und Best Practices. Aber manchmal ist die RealitĂ€t eben einfach anders als die Theorie es sich vorstellt. Und auch dann kann ich meiner Erfahrung nach tolle Resultate erzielen, wenn ich ein paar Punkte beherzige. Und was all diese VorschlĂ€ge gemeinsam haben: sie erfordern sehr engagierte Teammitglieder und sie fordern diese Teammitglieder auch. Aber mit motivierten Menschen ist das alles kein Problem.

Vielen Dank fĂŒr Deine Zeit! Du kannst den Artikel gerne teilen. Und ich freue mich immer, von Euch zu lesen. Bilder von Jonathan Farber und Jack B auf Unsplash.

← Vorheriger Artikel: Modernes Projektmanagement - der methodische Teil
→ NĂ€chster Artikel: Warum wir scheitern - und kann man das Scheitern ĂŒberhaupt verhindern?

Veröffentlicht am