Newsletter | Scrum und andere Hindernisse

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!

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.

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.

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.

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.

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.

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

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.

• Nächster Artikel: Code.Talks 2016 | Echte Innovation liefern
• Vorheriger Artikel: BASTA | Projektkommunikation