Emendare
  • Agile Unternehmensberatung
    • Methode
    • Prinzipien
  • Agile Coaching
  • Agile Workshops
  • Agile Training
    • Agile – Grundlagen Training
    • Agile Führung – Grundlagen
    • Agile Führung – Advanced
    • Scrum Master – CSM
    • Scrum Master – A-CSM
    • Scrum Master – CSP-SM
    • Scrum Master Mikro Trainings
    • Agiles Produkt Management – CSPO | A-CSPO | CSP-PO
  • Agiles Arbeiten
    • Was ist Scrum?
    • Was macht ein Scrum Master?
    • Was macht ein Product Owner?
    • Agile Führung – Was macht eine Agile Führungskraft?
    • Dialogische Unternehmenskultur
  • Unser Team
  • Suche
  • Menü Menü

Agil in mehreren Projekten gleichzeitig arbeiten? Kein Problem!…

Agile Brainfood, Allgemein, Mensch
Stress

… 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.

Gerald M. Weinberg - Multitasking

Gerald M. Weinberg – Multitasking

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.

24. August 2021/von Veit Richter
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
  • Per E-Mail teilen
Das könnte Dich auch interessieren
wir sind alle besondere coaches Scrum verstehen leichtgemacht
Was machen wenn der Scrum Master krank ist Was, wenn einmal der Scrum Master krank ist?
Illustration zu drei Kanban Flight Levels Kanban Flight Levels
Scrum Gathering Agilität erleben zwischen Wiener Schnitzel und Kaiserschmarrn
ein extralanges Daily Scrum mit planlosen Teilnehmern Daily Scrum from Hell
Definition of Done Definition of Done – Motivationshilfe oder notwendiges Übel?
Array
Veit Richter
Veit Richter
Agile Coach

Gerne begleite ich Ihre Teams sowohl beim Lernen agiler Praktiken, als auch auf ihrem Weg zur High-Performance. Dabei unterstütze ich sie mit pragmatischen Lösungsstrategien und biete neben meiner Skalierungserfahrung auch Impulse zum Entfesseln positiver Kräfte.

veit.richter@emendare.de

Alle Beiträge von Veit Richter

Letzte Beiträge des Autors

Array
  • Haben „Technische User Stories“ eine Existenzberechtigung?
  • Die Hamburger Methode – technischen Umfang beschränken
  • Was, wenn einmal der Scrum Master krank ist?
  • 1,2 oder 4 Wochen? Wie lang sollte ein Sprint eigentlich sein?
  • Magische Burnup Charts und wo sie zu finden sind

Kontakt

Emendare GmbH & Co. KG
Karlstraße 87
76137 Karlsruhe

Tel.: +49 (0)721 170 280 08
Email: info@emendare.de

Service

Trainingsbuchung

Impressum

Datenschutzerklärung

Allgemeine Geschäftsbedingungen

Mehr von Emendare

Nachhaltigkeit bei Emendare

Dem Scrum Master die Bildübertragung wegzunehmen fühlt sich an,…Veit Richter Grundgedanken zum Agilen Coaching – Drei Coachingvorannahmen
Nach oben scrollen