… wenn man mit den Konsequenzen leben kann.
Unter den Fragen, welche mich im Training am häufigsten erreichen, befindet sich diese weit oben im Ranking.
„Mein Skillset ist sehr besonders, daher soll ich in 4 verschiedenen Projekten gleichzeitig mitarbeiten. Wie sieht Scrum das vor?“
Woher kommt der Bedarf, sich nicht fokussieren zu dürfen?
Das erste mal, das „Scrum“ als Wort, wie wir es heute kennen, in einem ähnlichen Kontext fallen gelassen wurde, war im Harvard Business Review 1986.
Nonaka und Takeuchi schrieben in ihrem Paper „The new new product development game“ darüber, dass es wichtig ist wie in einer „Scrum“-Bewegung des Rugby zu agieren, um EINEN Ball möglichst schnell nach vorne bringen zu können.
Der Fokus auf effektive gemeinsame Abarbeitung und die Fähigkeit als Team stets diesen einen Ball ohne Wartezeiten nach vorn bringen zu können war der damals revolutionäre Ansatz.
Im Kontrast dazu verglichen die Autoren konventionelle Ansätze mit einem Staffellauf, in welchem ein Stab von Person zu Person weitergegeben wird.
Der Nachteile dieser herkömmlichen Variante ist, dass der Stab stets warten muss, bis er von einer Person aufgenommen wird.
Will man nun also als hochfokussiertes „Scrum“ Team arbeiten und gleichzeitig den Staffelstabansatz nicht loslassen, führt dies das Experiment selbst ad absurdum.
Die Crux an Multitasking
1991 analysierte Gerald M. Weinberg in seinem Buch das Thema Multitasking.
Was einem Computer schon nicht gelingt ist für einen Menschen komplett unmöglich. Gleichzeitig an X Produkten gleichzeitig zu arbeiten, ohne einen wesentlichen Verlust in der eigenen Arbeitsfähigkeit zu spüren, wäre zu schön um wahr zu sein. In Workshops vergleiche ich diese Task Switches gern metaphorisch mit einer Schokoladenfabrik. In dieser wird einmal im Jahr die komplette Produktionsstraße angehalten, um die Formen von Weihnachtsmännern zu Schokoladenosterhasen zu tauschen. In diesem Zeitraum findet selbst keine Wertschöpfung statt. Ziel ist es diese Rüstzeiten so selten wie nötig durchzuführen. Aber genau diese Rüstzeiten haben auch wir, wenn wir zwischen verschiedenen Produkten hin und herspringen.
Während bei 2 parallelen Produkten „nur“ eine Blindleistung von 20% entsteht, sind es bei 4 parallelen Produktentwicklungen schon 60 %.
Zeit, die unproduktiv im Nichts verpufft. Genauso gut könnte man sich also einen teuren Experten einstellen, ihn Vollzeit bezahlen und ihm 5 Tage die Woche freigeben. Klingt nach einer guten Lösung? Eher nicht.
Welche Alternativen gibt es?
Aus meiner Sicht, ist es eine der Hauptaufgaben des Scrum Masters Effizienz in das effektive System zu bringen. Gemeinsam mit ihm eine Lösung zu erarbeiten und Experimente zu wagen, könnte also ein erster Schritt sein.
Auch ich durfte in ähnlichen Systemen wirken und teile gern mit euch meine erfolgreichsten Experimente:
Neue Mitarbeiter ausbilden
Anstatt einen Mitarbeiter mit speziellen Fähigkeiten zu zerreißen, kann es helfen neue Mitarbeiter in diesem Fachgebiet einzulernen und diese auf die verschiedenen agilen Teams zu verteilen.
Diese Experten können weiterhin dicht zusammen arbeiten und auch in einer Art Community of Practice gemeinsam wirken und sich weiterentwickeln.
Das „Traveler Pattern“
Statt zwischen mehreren Produkten hin und her zu springen und als Feuerwehrmann Feuer zu löschen, sieht das Traveler Pattern vor, den Experten in einem Sprint voll in einem Produkt zu fokussieren. Der Clou: Der Experte muss sich sozusagen die Hände auf dem Rücken fesseln. Statt also die benötigte Arbeit selbst zu tun, leitet er das entsprechende Team an, selbst diesen Skill zu erlangen und die benötigte Arbeit erledigen zu können.
Experten punktuell einbinden
Gerade wenn der Experte nicht tagtäglich, sondern nur in speziellen Situationen benötigt wird, kann eine punktuelle Unterstützung Sinn ergeben. Im Product Backlog Refinement könnte der Experte durch Aufzeigen von Fallstricken unterstützen. Im Sprint Planning könnte er dabei helfen ein PBI (Product Backlog Item) in kleinere machbare Tasks zu zerteilen und damit direkt seine Herangehensweise teilen.
Verantwortung über „Freigabe Ownership“
Gerade wenn man das Traveler Pattern ausprobiert hat, kann eine Kombination mit diesem Punkt einen Mehrwert stiften. Alle Teams bekommen prinzipiell die Möglichkeit (und Verantwortung) die betreffenden Tätigkeiten selbst zu machen. Der bisherige Experte behält sich jedoch vor, diese Tätigkeiten zu reviewen, Feedback zu geben und gegebenenfalls Änderungen zu verlangen. Auf diese Weise können sich die Teams noch mehr in die Thematik einarbeiten und diese Skills professionalisieren.
Selbstverständlich kann auch eine Kombination verschiedener Experimente Sinn machen.
Du hast das Gefühl, dass einzelne Teammitglieder genau dieses Problem haben?
Du findest unter den gegebenen Experimenten keines, welches du dir in deiner Situation vorstellen kannst?
Dann melde dich doch ganz unkompliziert zu einem kleinen Telefonat. Sicher finden wir zu Zweit eine passende Idee.