METALOG® Trainingspreis Bronze 2020

Agil statt instabil!

Gewinnerin des METALOG Trainingspreises in Bronze ist die Firma key4competence vertreten durch Annemike Salonen mit dem Konzept „Agil statt instabil“. Sie überzeugte die Jury durch einen besonders kreativen Einsatz des Tools SysTeam im Kontext von Projektmanagement und hier insbesondere beim Thema iteratives Vorgehen als wichtiges Element agiler Methoden.

Der Rahmen

Training „Flexibel im Projektmanagement: Agile und klassische Methoden clever kombinieren“ 1-tägiges Präsenztraining
Ziele Seminarziel
Das Projektteam hat einen guten Überblick über agile Ansätze im Projektmanagement und ist in der Lage, diese mit dem klassischen Ansatz clever zu kombinieren („Hybrides Projektmanagement“)

Ziel der Interaktion mit Metalog SysTeam
  • Charakteristika und Erfolgsfaktoren agiler Zusammenarbeit erlebbar machen
  • Das iterative Vorgehen agiler Ansätze erfahren und erkennen, wann iteratives Vorgehen dem sequentiellen Vorgehen des klassischen Projektmanagements überlegen ist
Gruppe Erfahrene ProjektmanagerInnen, die aktuell nach dem klassischen, phasenorientierten Ansatz vorgehen
Eingesetztes Tool SysTeam
Wann eingesetzt Zur Hälfte des Trainings, nach der Mittagspause. Zu diesem Zeitpunkt ist das Basiswissen zum agilem Projektmanagement bereits vermittelt: zugrundeliegende Werte, Prinzipien, Techniken und Methoden (insbesondere SCRUM). Die Interaktion soll für den Nachmittag darauf vorbereiten: Was ist in der praktischen Anwendung zu beachten? Zudem soll es verdeutlichen, bei welcher Art von Projekten / Fragestellungen im Projekt sich der Einsatz agiler Prinzipien und Techniken wie z.B. das iterative Vorgehen eignet.

Geplanter Zeitrahmen: 30 Minuten

METALOG training tools im Gesamtprozess

Inszenierung - Die Teilnehmer finden nach der Mittagspause folgendes Set-up vor:
Aufbau:

  • Das Spiel wird für drei Teams „Rot“, „Grün“, „Blau“ vorbereitet
  • Ideale Teamgröße: 3 Personen je Team
  • Pro Team drei Spielfiguren unterschiedlicher Größen, farblich gekennzeichnet
  • Eine „Sperrzone“ in der Mitte des Tisches
  • Die Platte ist gut ausbalanciert. Es ist für die Spieler nicht unmittelbar ersichtlich, dass die Platte lose aufliegt

Anweisungen:

  1. Die Zeichnung oben rechts bietet den TeilnehmerInnen eine gute Orientierung zur Lösung. Die Erfahrung hatte gezeigt: Ohne die Zeichnung wird die Aufgabe häufig schwer verstanden oder es dauert in der Anfangsphase zu lange.
  2. Obwohl in der Anweisung ein Hinweis enthalten ist, dass die Platte instabil ist, wird es häufig überlesen und in der anschließenden Planung des Vorgehens nicht berücksichtigt.

Durchführung:

  • Häufig erkennen die TeilnehmerInnen erst beim Anheben der ersten Spielfigur, dass die Platte instabil ist und wie (!) instabil sie ist. Das vorher meist klassisch geplante Vorgehen wird dann schnell über Bord geworfen: „Dann probieren wir es jetzt einfach Mal aus. Und entscheiden dann, Schritt für Schritt, den nächsten Zug….“ => intuitiv wird das Grundprinzip iterativen Vorgehens angewandt!
  • Zur Rollenverteilung innerhalb der Teams kommt oft die Rückfrage: „Müssen wir alle mal eine Figur bewegt haben?“ Meine Antwort: „Das steht nicht in den Spielregeln“. Denn es entspricht dem agilen Vorgehen, dass sich die Teammitglieder (außer der klar definierten Rollen wie „SCRUM Master“ oder „Product Owner“) im Projekt selber die Aufgaben / Rollen suchen.
  • Ich musste bei dem hier beschrieben, finalen Set-up nie intervenieren. Ein einziges Mal fiel die Platte. Dann wurde das Spiel entsprechend der Regeln neu gestartet.

 

Zum Transfer werden folgende Reflexionsfragen zur Verfügung gestellt:

Bild mit den Transfer-Fragen

Transfer / Brücken in den Alltag

SysTeamAgiler Projektalltag
Aufgrund der Ungewissheit, wie die Platte reagiert, ist schnell klar, eine detaillierte Vorabplanung ist nicht sinnvoll. Erfolgreich ist, den nächsten Schritt an das zuvor erzielte Zwischenergebnis anzupassen / darauf aufzubauen. So ist es bei Projekten mit hohem Neuigkeitscharakter oder sehr ungewissen Rahmenbedingungen auch. Dann ist die aufwendige, detaillierte Vorabplanung - wie sie klassische PM-Ansätze vorsehen - umsonst. Satt dessen nähert man sich beim iterativen Vorgehen („Sprints“ bei SCRUM) dem Optimum schrittweise an.
Wichtig ist sicherzustellen, dass alle ein klares, gemeinsames Zielbild haben. Wenn nicht allen klar ist, auf welches (Zwischen-)Ergebnis man hinarbeitet, entsteht bei diesem Vorgehen Chaos! So ist es im agilen Projektmanagement auch. Vor jedem Sprint wird das zu produzierende Endergebnis besprochen (Sprint-Ziel). Die Backlog Items dienen dazu, das Sprint-Ziel zu konkretisieren.
Erfolgreich konnte die Aufgabe nur in der Zusammenarbeit aller Sub-Teams und im ständigen kommunikativen Austausch gelöst werden. Das hat den TeilnehmerInnen verdeutlicht, warum es z.B. bei SCRUM verpflichtend ist, sich in täglichen Daily-Standup-Meetings auszutauschen, während im klassischen Projektmanagement oft wöchentliche oder gar monatliche Meetings ausreichen.
Auch die physische Nähe der drei Sub-Teams war für den Erfolg der Zusammenarbeit entscheidend. Sie schaffte Transparenz, erlaubte schnelle Rückmeldung und Reaktion. Im Idealfall sitzt das Team in agilen Ansätzen physisch zusammen. Ist das nicht möglich, werden die Daily-Standups digital, immer mit eingeschalteter Webcam durchgeführt.
In der Übung kommt es öfter zu Situationen, wo eine vorher in einem der Dreiecke geplante Figur nicht mehr passend erscheint, da sie zu schwer / leicht ist und die Platte zum Kippen bringen würde. Dann ergeben sich neue Optionen, für die man offen sein und die man erkennen muss. Der agile Wert, der agilen Ansätzen zugrunde liegt: „Die Reaktion auf Veränderung ist wichtiger als das Befolgen eines Plans“ wurde so verinnerlicht. Heißt auch: Veränderungen werden als fester Bestandteil des Projektes und als Chance – nicht als „Störfaktor“ - gesehen!
Viele Gruppen kommen zu der Erkenntnis: Einen klassischen Projektleiter braucht es bei dem Vorgehen nicht. Das beste Ergebnis wird im Austausch auf Augenhöhe, mit Respekt und Vertrauen erzielt. Es braucht aber Personen, die auf die Einhaltung der Regeln achten. Genau das entspricht dem Rollenverständnis bei SCRUM. SCRUM ist hierarchielos. Es gibt drei definierte Rollen. Der SCRUM Master achtet auf die Einhaltung der SCRUM Regeln. Das Development Team organisiert sich selber.
Wichtig ist bei diesem Vorgehen die Transparenz und ständige Reflexion: Wo stehen wir im Projekt? Welche Erfahrungen haben wir bisher gemacht? Was ist gut gelaufen, was hat nicht funktioniert Genau das wird in SCRUM durch regelmäßige Retroperspektiven am Ende jedes Sprints sicher gestellt!
Manchmal braucht es von dem Greifer Mut, die Figur anzuheben, auch wenn die Platte sich bedrohlich senkt. Dann müssen alle hinter ihr / ihm stehen. Mut ist einer der fünf Werte nach den beiden Vätern von SCRUM, den das SCRUM Team mitbringen sollte. Genau so wie Commitment.

 

Eine mögliche Musterlösung…