Wie sollte die Arbeit im Team verteilt werden?

Kennst du das auch? Einige deiner Teammitglieder arbeiten sich den Arsch ab und andere trinken entspannt Kaffee. Einige deiner Teammitglieder sind an der kognitiven Belastungsgrenze, andere gelangweilt. Oder auch: Monat für Monat erstellt ihr irgendeine Art von Ergebnis, von dem ihr den Eindruck habt, dass es kein Mensch braucht. Das zugrundeliegende Thema all dieser Beispiele ist: welche Arbeit übernehmt ihr im Team und wie verteilt ihr die Arbeit innerhalb des Teams. Es lohnt sich, dieses Thema nicht dem Zufall zu überlassen. Wie das funktioniert, erfährst du in diesem Video.

Transkript des Videos (automatisch erzeugt, bitte entschuldige mögliche Fehler) 

Hallo, heute geht es mal um ein Thema, was immer wieder für Zoff sorgt. Es geht nämlich um die Frage: Wie sollte die Arbeit im Team verteilt werden? Wie sollte die Arbeit im Produkt- entwicklungsteam verteilt werden? Und gleich vorneweg: Es gibt aus meiner Sicht kein richtig oder falsch. Aber bei einer Sache bin ich mir ganz sicher: Es gibt immer Room for Improvement, wie es so schön heißt, es gibt immer Möglichkeiten, wie ihr die Arbeit besser im Team verteilen könnt.  

Was meine ich damit? Naja, gerade als Product Owner solltest du darauf achten, dass ihr mit dem gesamten Team regelmäßig - so alle zwei bis drei Monate - euch mal hinsetzt und reflektiert, ob die aktuelle Arbeitsverteilung eigentlich richtig ist oder ob ihr Anhaltspunkte findet, wie ihr eure Arbeit noch besser verteilen könnt. Und um so eine kleine Hilfestellung an die Hand zu geben, fast wie so eine Art Checkliste, möchte ich hier mal 4 Punkte aufgreifen, die ihr aus meiner Sicht einfach mal systematisch durchgehen könntet, um zu gucken: Ah, gibt's hier irgendwo Potenzial? Was können wir besser machen? Also worauf solltest du achten?  

Punkt Nummer eins: Habt ihr einfach eine ungleiche Belastung? Also im Sinne von: Einer oder zwei Leute im Team arbeiten total viel, schrubben hier die Stunden, sitzen von morgens um acht bis abends um acht da und arbeiten sich echt den Arsch ab. Und andere Teammitglieder lassen so nach sieben oder acht Stunden den Griffel fallen, haben zwischendurch noch die Möglichkeit, in Ruhe den einen oder anderen Kaffee zu trinken, mit den anderen Kollegen zu schnacken und sind eigentlich immer glücklich und entspannt. Das ist so ein bisschen eine Situation, wie ich sie sehr häufig wahrnehme, dass es tatsächlich ein oder zwei Leute im Team gibt, die total viel arbeiten, die also fast überlastet sind, und andere, die - ich sage jetzt mal - eine normale Arbeitsbelastung haben. Und wenn ihr so eine Situation habt, dann achte doch mal darauf: Woran liegt denn diese hohe Arbeitsbelastung? Und auch da gibt's aus meiner Sicht so zwei Klassiker.  

Das eine ist: An dieser Person klebt einfach total viel Arbeit, die gemacht werden muss, aber die eigentlich jeder machen kann. Also es geht darum, dass ich mal ein Sprint Review organisiere. Es geht darum, mal einen Termin mit dem Vorstand zu organisieren. Es geht darum, mal eine Unterlage vorzubereiten. Es geht darum, mal eine Anwender-Doku zu schreiben oder oder oder. Im Prinzip könnte das jeder machen, aber aus welchen Gründen auch immer bleiben solche Arbeiten immer an Herrn Meier hängen. Also das ist so das eine: Viel Arbeit, die eigentlich jeder machen könnte. Da braucht es keine besonderen Fähigkeiten oder Skills. Es muss halt gemacht werden. Und diese Arbeit bleibt aber immer bei der gleichen Person kleben.  

Zweite Variante ist: Es ist jetzt nicht so eine ganz allgemeine Arbeit, die jeder machen kann, sondern es ist ganz im Gegenteil, es ist ein total spezialisiertes Know-How notwendig, also beispielsweise das Erstellen von automatisierten Tests oder das Durchführen von Datenbankänderungen oder das Erstellen von Datenbank Scripts oder so. Und das ist dann vielleicht so, dass tatsächlich nur eine Person im Team überhaupt dieses Know-How hat und die ist dann einfach heillos überlastet. Die ist dann quasi so das Bottle Neck, wo alle Arbeit immer durch muss, damit man vorwärts kommt. An der Stelle ist es jetzt natürlich nicht so ganz einfach zu sagen: Ja, da macht's halt nicht mehr der Herr Meier, sondern Herr Schulze. Nichtsdestotrotz solltet ihr als Team überlegen, ob es nicht sinnvoll ist, einen Teil dieser Arbeit von Herrn Meier ein bisschen wegzunehmen und auf mehrere Schultern zu verteilen. Das hat nämlich gleich mehrere Vorteile. Das eine ist: Diese Ungleichverteilung der Arbeit im Team verringert sich. Und das andere ist: Ihr habt gleichzeitig noch ein Backup, wenn dem Herrn Meier mal irgendetwas passieren sollte oder wenn er im Urlaub ist oder wenn er krank ist oder wenn er im Sabbatical ist, dann habt ihr immer noch eine zweite Person, die zumindest so ein bisschen die Arbeit übernehmen kann, damit ihr nicht total blank seid. Ja, also das war das erste Szenario. Ihr habt einfach eine ungleiche Last im Team.  

Das zweite Szenario, was immer mal wieder auftritt, ist: Ihr habt Langeweile. Also, natürlich habt ihr jetzt keine Langeweile im Sinne von "ihr dreht Däumchen". Aber euch allen oder einzelnen Teammitgliedern fehlt so ein bißchen die Challenge. Also... Keine Ahnung... Also ich nehme jetzt mal den Frontend Entwickler, der seit Jahr und Tag mit der gleichen Technologie die gleichen Frontends baut. Ja, der kann das natürlich aus dem Effeff. Der ist da total effizient drin. Aber für ihn ist es unter Umständen auch ein bisschen langweilig. Und so geht es vielleicht auch anderen Kollegen, die halt schon sehr lange die gleiche Aufgabe wahrnehmen. Wenn ihr auf sowas stoßt, wäre ein  mögliches Mittel, wie ihr da Abhilfe schaffen könnt, so etwas wie Job Rotation. Überlegt euch tatsächlich ganz genau, wer macht gerade welche Aufgabe und wo könnt ihr mal das lustige Hütchenspiel machen, also Job Rotation. Wer könnte welche Aufgabe neu übernehmen und dafür wieder eine andere Aufgabe abgeben? Dass ihr einfach mal neue Impulse in der täglichen Arbeit habt und euch natürlich auch individuell weiterentwickelt. Nicht immer den gleichen Stiefel runter, runter reitet, runter latscht, naja, wie auch immer. Also zweite Möglichkeit: ihr seid quasi ein bisschen gelangweilt. Euch fehlt die Challenge. Ihr entwickelt euch nicht weiter. Wenn das der Fall ist, könnte so etwas wie Job Rotation helfen.  

Das dritte Thema, auf das ihr achten solltet, ist, ob ihr überflüssige Arbeit macht, also ob ihr Dinge tut, die vielleicht irgendwann mal sinnvoll waren oder die irgendwann mal den Anschein erweckt haben, als ob sie sinnvoll wären, die aber in der Praxis keinen Mehrwert bieten, weder für euch noch für das Unternehmen und auch nicht für die Anwender. Das schleicht sich einfach manchmal so ein. Dieses Typische "Ham wa schon immer so gemacht." "Warum?" "Weiß ich auch nicht mehr." "Wer hat denn was davon?" "Weiß ich auch nicht." "Dann hör doch mal auf!" Und keinem fällt's auf. Also insofern: Geht einfach mal systematisch durch: gibt es irgendwelche Tätigkeiten, die Ihr individuell oder als Team macht, die aber keinen Mehrwert stiften und die ihr entweder komplett eliminieren könnt oder zumindest reduzieren könnt? Ja, also das wäre das dritte Thema. Vermeidet überflüssige Arbeit.  

Und das vierte Thema ist jetzt eigentlich das Spannendste und auch das Schwierigste. Nämlich: Findet fehlende Arbeit. Klingt jetzt ein bisschen komisch: "Hä, fehlende Arbeit?" Aber dahinter steckt so ein bisschen die Überlegung: Gibt es Dinge, die ihr momentan nicht tut, die ihr aber tun solltet, um andere Probleme zu vermeiden?  

Also ein paar Beispiele: Dokumentation ist ja immer ein total beliebtes Thema. Vielleicht dokumentiert ihr aktuell nicht oder nicht ausreichend. Und vielleicht führt genau diese fehlende Dokumentation immer wieder zu irgendwelchen Problemen. Also sei es, dass andere... Keine Ahnung... dass andere Entwickler andauernd bei euch anrufen und euch aus der Arbeit rausreißen, weil sie nicht wissen, wie euer Code funktioniert. Oder Anwender schlagen direkt bei euch im Entwicklungsteam auf, weil sie mit der Anwendung nicht weiterkommen, weil ihr kein vernünftiges Anwender Handbuch geschrieben habt oder oder oder. Also es kann durchaus sein, dass die fehlende Dokumentation zu Problemen in der Produktentwicklung führt, die ihr halt vermeiden könntet.  

Oder anderes Beispiel: Test. Test-Automatisierung. Qualitätssicherung. Dieser ganze Bereich. Vielleicht legt ihr dort nicht genug Augenmerk drauf, was dann in Folge dazu führt, dass ihr nicht mehr in der Lage seid, euer Produkt weiterzuentwickeln, weil ihr andauernd im Fire Fighting Modus seid, um irgendwelche gravierenden Fehler ad hoc auf die Schnelle und ungeplant zu beheben. Also diese fehlende Arbeit der ausführlichen Qualitätssicherung fällt euch dann an anderer Stelle auf die Füße. Wenn ihr nämlich mit der Produktentwicklung nicht so schnell voranschreiten könnt, wie ihr das möchtet.  

Oder noch ein Beispiel: Sowas wie Discovery Arbeit oder die Entwicklung und Validierung von Lösungsideen. Vielleicht seid ihr einfach so beschäftigt mit dem umsetzen, umsetzen, umsetzen, liefern, liefern, liefern, dass ihr gar keine Zeit habt, euch eigentlich zu überlegen: Wer sind meine Anwender? Was für Probleme haben die? Wie können wir die Probleme lösen und funktioniert unsere Lösung überhaupt? Das heißt, ihr seid zwar total beschäftigt, neue Features auszuliefern, aber ihr erreicht nicht euer eigentliches Ziel, nämlich ein erfolgreiches Produkt zu bauen. Also: Ja, ihr habt funktionierende Software. Aber ob ihr damit das Ziel dieser Software erreicht, steht in den Sternen.  

Oder... Noch ein Beispiel: Kommunikation. Sowohl intern als auch extern. Wenn's heiß hergeht und wenn man auf irgendeine Deadline zu rennt, dann bleibt das Thema Kommunikation ja gerne mal so ein bisschen links liegen. Und vielleicht führt das aber auch wieder genau dazu, dass ihr an anderer Stelle in der Produktentwicklung Probleme habt. Auf einmal stehen andauernd Stakeholder bei euch auf der Matte und wollen eine Sonderbespaßung. Da kommt der Geschäftsführer A: "hier, erklärt mir doch mal!", Geschäftsführer B: "erklärt mir doch mal", der Vertriebsleiter: "erklärt mir doch mal", und auf einmal seid ihr kontinuierlich dabei, die Partikularinteressen nach Kommunikation, nach Informationen zu befriedigen, einfach nur, weil ihr es versäumt habt, selbst aktiv in den Driver Seat zu gehen und aktiv zu kommunizieren.  

Also, das sind so ein paar Beispiele, was ich damit meine, wenn ich sage: findet fehlende Arbeit. Überlegt euch mal, was ihr gerade nicht tut oder was ihr nicht ausreichend tut, was vielleicht zu Problemen im Team und in eurer Arbeit führen kann.  

Also: Als Product Owner halte ich es für enorm wichtig, dass du gemeinsam mit deinem Team regelmäßig analysierst: haben wir eigentlich eine sinnvolle Verteilung der Arbeit im Sinne von Ist die vorhandene Arbeit richtig auf unsere Mannschaft verteilt? Und machen wir eigentlich auch die richtige Arbeit oder ist da irgendwo was überflüssiges oder was fehlendes dabei? Mach das so alle 2-3 Monate, macht es regelmäßig und adjustiert immer. Und auch da: das ist völlig normal, dass das, was vielleicht letztes Jahr gut funktioniert hat, in diesem Jahr nicht mehr so gut funktioniert. Also dass ihr dort Anpassungen vornehmen könnt / müsst / sollt, das ist völlig normal. Das wäre sogar meine Erwartung, dass das passiert und notwendig ist.  

Ja, wenn du das jetzt so hörst, fällt dir spontan was ein, was du in deinem Team vielleicht mal überdenken solltest? Wenn ja, erzähl mir mal davon. Es interessiert mich und wir können ja auch alle voneinander lernen. In jedem Fall: Denk bitte immer daran: Das Leben ist zu kurz, um in beschissenen Projekten zu arbeiten. Bis bald.