Hallo,
die ersten Schritte in Scrum sind meistens schnell gemacht. Doch nach den ersten Iterationen werden Stolpersteine und Hindernisse sichtbar. Die neue Projektmethode gerät ins Stocken. Erste Zweifel werden laut. Genau deshalb heißt es: "Scrum is easy to learn, but difficult to master."
In diesem Newsletter haben wir Euch verschiedene Links für das Überwinden von agilen Hürden zusammengestellt.
Wir wünschen einen tollen Start in den Herbst!
Die Rolle des Scrum Masters könnte in Unternehmen nicht unterschiedlicher sein. Während sich einige mit der Organisation von Meetings, Notizen machen und Kaffee kochen beschäftigen, sind die anderen Sprachrohr und Beschützer oder Beschützerinnen des Teams. Sie räumen Hindernisse aus dem Weg, klären Konflikte und übernehmen die gesamte Arbeitsorganisation.
In seinem Beitrag "Scrum Masters - First, Do No Harm" erklärt Dwight Kingdon warum beide Ausprägungen für ein Team ungesund sind. Scrum Master, die hautpsächlich Kalender verwalten und das Team wenig inhaltlich begleiten, werden es schwer haben als Teil des Scrum-Teams wahrgenommen zu werden. Sie sind Verwalter und Verwalterinnen anstatt die Teamentwicklung aktiv voranzutreiben. Doch auch diejenigen, die sich zum "Scrum Papi" oder zur "Scrum Mutti" entwickeln, blockieren das Team. Sie übernehmen Konflitklösungen und beseitigen Hindernisse. Das Team lernt nicht eigenverantwortlich und selbstorganisiert mit Schwierigkeiten umzugehen. Die Teamentwicklung gerät ins Stocken.
Ein performantes Team zeichnet sich durch eine selbstverantwortliche Arbeitsweise aus, in der Hindernisse und Konflikte angesprochen und gelöst werden können. Als "dienende Leitung" ist es die vornehmlichste Aufgabe des Scrum Masters, das Team auf diesem Weg in die Performance zu begleiten und die Selbstorganisation aktiv zu unterstützen. Der Weg dorthin ist für alle Beteiligten anspruchsvoll und herausfordernd. Zwischen "unterstützen" und die "Lösung übernehmen" liegen manchmal nur wenige Taten.
Nicht selten werden bei der Reflexion der Teamentwicklung die Teamphasen von Tuckman genutzt. Auch bekannt als "Teamuhr" hilft uns das Modell eine Einordnung vorzunehmen. Neben den Teamphasen von Tuckman gibt es allerdings auch das "Team Performance Model" von Drexler und Sibbet, das Euch bei einer solchen Einordnung behilflich sein kann.
Das Teamphasen-Modell von Tuckman besteht aus vier Stufen (Forming, Storming, Norming und Performing). Zusätzlich gibt es die fünfte Stufe "Adjourning". Das "Team Performance Model" gliedert die Teamentwicklung in sieben Stufen. Sie geben einen detaillierten Überblick darüber, was das Team gerade bewegen könnte. Die Teamphasen nach Tuckman beschreiben Teamentwicklung unabhängig von Zeitalter und Generationen. Das "Team Performance Model" stellt einen konkreten Bezug zu Abläufen in Projekten her.Daniel Dubbel hat den Beitrag von David Knootz auf Inspect & Adapt ins Deutsche übersetzt.
Ein hochperformantes Team, in dem das gemeinsame Teamziel mehr wiegt als die Ziele einzelner. Das perfekte IT Team gibt es. Zumindest, wenn wir Greg Mooney in seinem Beitrag "Star Trek: The Ultimate IT Team" Glauben schenken.Live long and prosper!
Bis wir es geschafft haben, wie das Team der USS Enterprise zusammen zu arbeiten, gehen wir einen langen Weg. Wir müssen bisheriges Verhalten ablegen und neues Verhalten lernen. Wir versuchen die Dinge "richtig" zu machen. Der Scrum Guide und das Agile Manifest bieten eine grobe Anleitung.
Obwohl wir uns die größte Mühe geben, kommen wir um einige Stolpersteine nicht herum. "Inspect & Adapt" ist hier die richtige Antwort: Überprüft Euer Vorgehen und passt es an, sodass es wieder nützt. Mayflower hat 21 Agile Anti-Pattern zu Papier gebracht. Sie sollen Euch inspirieren die Prozesse in Euren Teams zu hinterfragen. Mit dabei sind auch mögliche Lösungsansätze. Aber nicht vergessen: wie immer gilt Trial & Error.
Das Daily Standup ist aus den meisten Scrum-Teams nicht wegzudenken. Teams, die mit Scrum starten, fällt es zu Beginn oft schwer, den Mehrwert der täglichen Viertelstunde zu erkennen. Eine häufige Konsequenz: Die Abschaffung des Daily Standups.
Dabei hat das Artefakt eine zentrale Aufgabe in der täglichen Zusammenarbeit. Es ist die tägliche Chance für "Inspect & Adapt". Es zeigt, ob das Sprintziel unter aktuellen Umständen zu erreichen ist. Zu dem gleichen Schluss kommt auch Ben Day in "5 Reasons why your daily Scrum is boring". Ein unnützes und langweiliges Daily StandUp ist nur ein Symptom. Die Ursachen hierfür liegen meist woanders. Es lohnt sich dort einmal genauer hinzuschauen. Besinnt Euch auf den Mehrwert des Daily StandUps. Schaut, wie ihr diesen wieder erlebbar machen könnt. Ein langweiliges Daily StandUp ist ein totes Daily StandUp.
Auch Retrospektiven gehören zu den Methodenbausteinen, die schnell langweilig werden können. Unter zeitlichem Druck gehören sie zu den ersten die abgeschafft werden.
Scrum ist eine empirische Prozesssteuerung. Das heißt, wir lernen aus unseren Erfahrungen. Unser Verhalten passen wir entsprechend an. Die Retrospektiven sind der Lernhebel. Ohne Retrospektiven fehlt uns das Steuerungselement für Inspect & Adapt. Retrospektiven in Form von "Jammerrunden" bringen uns nicht weiter. Das Ziel sind funktionierende Retrospektiven mit umsetzbaren Ergebnissen. Es geht darum mit einer Retrospektive alle Probleme der Zusammenarbeit zu eliminieren. Es geht darum in kleinen Schritten Anpassungen vorzunehmen. "Just do it" und "Lasst uns mal mutig sein!" sind die Orientierungspunkte in jeder Retrospektive. Was aber tun, wenn in der Retrospektive Schweigen herrscht und Schwierigkeiten nicht benannt werden? Luis Gonçalves erklärt in seinem Blog-Artikel "Agile Retrospective Facilitator" wie wichtig es ist als Moderatorin oder Moderator mit gutem Beispiel voranzugehen.
Ist Scrum eigentlich die richtige Antwort? Und was ist gemeint, wenn über "Agile" gesprochen wird? Am Anfang steht oft die Suche nach einer neuen (funktionierenden) Projektmethode. Scrum ist in diesem Zusammenhang sehr präsent. Zahlreiche positive Erfahrungsberichte zeigen, dass es funktionieren kann. Nach der Einführung von Scrum stoßen Teams und Organisation meist an neue Hindernisse.
Ein typisches Hindernis ist die Arbeit in Sprints. Das Einhalten der festgelegten Iterationen fällt schwer. Es gibt unplanbares Tagesgeschäft. Die Anforderungen ändern sich oder die UserStorys sind zu groß. Die einfache Lösung: "Scrum geht bei uns nicht, wir machen jetzt Kanban". Dort wird ohne feste Iterationen gearbeitet. Ad-hoc Plannings bieten die Möglichkeit Prioritäten zu verändern.
Durch den Wechsel von Scrum zu Kanban wird der Arbeitsprozess an die vorhandenen Symptome angepasst. Die Ursachen werden nicht bearbeitet. Insgesamt gilt: Die eine perfekte Projektmethode gibt es nicht. Scrum und Kanban bieten jeweils eigene Vorteile und Nachteile. Je nach Projekt muss die Entscheidung Für und Wider einer Projektmethode neu getroffen werden. Das schreibt auch Serge Shimanovsky in seinem "Kanban vs. Scrum vs. Agile - Part 1: Which PMI framework to choose?". Er stellt die Unterschiede zwischen Scrum und Kanban einfach dar. Die weiterführenden auch sehr lesenswerten Teile findet ihr hier (Part 2) und hier (Part 3).
Für einen ersten Einstieg in die "Agilität" bauen Teams in unseren "Agilen Basisschulungen" die Stadt "Agilo". In mehreren Sprints entsteht anhand von UserStorys eine Legostadt. Mit dabei sind unter anderem ein Rathaus, ein Linienbus und ein mobiler Eiswagen. Die Teams erleben die unterschiedlichen Artefakte und Rollen von Scrum. Eine spannende Alternative könnte auch der Bau mehrerer Sterne-Menüs sein.Möglich ist es zumindest, wie nobu_tary hier beweist. Dies nur zum Schmunzeln.
... mehr auf judithandresen.com/termine
Die Anmeldung zu unseren Workshops + Trainings kann über die Webseite judithandresen.com erfolgen.
Meldet euch, wenn Ihr unternehmensinterne Workshops oder Vorträge plant. Wir unterstützen euch gerne!
Melde Dich, zum Newsletter der BERATUNG JUDITH ANDRESEN an. Wir informieren Dich regelmäßig über aktuelle Angebote der BERATUNG JUDITH ANDRESEN und lesenswerte Inhalte im Netz.