Agile, XP, Lean, Scrum, Kanban und wie sie alle heissen. Ich vergrabe mich für 3 Tage in ein Kurszimmer, um mich im Detail mit Scrum zu befassen. Meine Scrum Erfahrung reicht bereits einige Jahre zurück.
Wir schreiben das Jahr 2009. Als Hochschulabsolvent und Programmierer darf ich einen frei gewordenen Platz in einer Scrum/Kanban Tagung ergattern. Es ist alles neu. Die Professoren haben es verpasst über das Wasserfall Modell hinaus zu schauen. Ich bin begeistert.
Obwohl es ein tägliches «sich-die-Beine-in-den-Bauch-Stehen» gibt, sind wir weit weg von Scrum: Teilpensen in verschiedenen Projekten, fehlender PO bzw. mangelnde Kompetenzen und mangelndes Verständnis für den Prozess.
Büchern und Blogs sei Dank, lese ich mich ein und langsam formen wir ein erstes richtiges Scrum Team.
Es sind 8 Jahre vergangen. In der Marketingabteilung eines Medizinischen Grosskonzerns war Scrum (noch) nicht anwendbar. Zu viel Politik, zu wenig Fokus, zu kleine Projekte, zu starre Vorgaben und Richtlinien des Konzerns.
Die 3 tägige Ausbildung soll die Erfahrung, das Halbwissen und offene Fragen ergänzen und mich in einen Scrum Master verwandeln. Dieser Post soll nicht Scrum erklären (dafür gibt es genügend andere Blogs und Videos, welche das viel besser tun), sondern meine Take Aways und Gedanken darlegen.
Was habe ich aus den drei Tagen mitgenommen
In der Kürze liegt die Würze. Daher hier die Key Learnings und Aha Momente aus dem Kurs:
- Das Team steht im Zentrum. Dazu gehört, das Entwicklungsteam, der Product Owner (PO) und der Scrum Master.
- Der Scrum Master ist der IT Sozialarbeiter.
- Entwicklungsteam ≠ Programmiererteam. Produktentwicklungsteam wäre der bessere Namen.
- Im Vergleich zu Kanban bietet Scrum einige fix fertige Elemente (bsp. Retro, Daily, Sprint Planning)
- Sprint Planning I bestimmt das Was, Sprint Planning II das Wie
- Architekturfragen werden im Sprint Planning II adressiert.
- Der Scrum Master ist für erfolgreiche, konstruktive Meetings verantwortlich
- Review Meeting ≠ Demomeeting, wo der PO zum Produkt nickt. Vielmehr ist es die Gelegenheit für die Stakeholder (sprich potentielle Kunden), das Produkt zu reviewen und Feedback zu geben.
- Das Tool der Wahl: Filzstift und Flipchart
- Scrum ist radikal, Kanban sanft
- Regeln für selbstorganisierende Team sichtbar machen
- Dazu einige Taktiken und Werkzeuge für das Leben als Scrum Master: [ROTI](http://boeffi.net/tutorials/roti-return-on-time-invested-wie-funktionierts/), [Daumen Voting](https://www.oose.de/blogpost/entscheiden-im-konsens-teil-3-thumb-voting-und-fist-to-five/) und Führen durch Fragen.
Obwohl ich im aktuellen Projekt nach Kanban arbeite, gibt es das eine oder andere aus Scrum, welches sich anwenden lässt. Daher meine Gedanken in aller Tiefe (ScrumBan ist übrigens ein offizieller Begriff).
Das Team im Zentrum
Damit ein Team im Zentrum stehen kann, muss es ein Team geben. Laut Wikipedia ist Team wie folgt definiert:
Der Anglizismus Team bezeichnet einen Zusammenschluss von mehreren Personen zur Lösung einer bestimmten Aufgabe oder zur Erreichung eines bestimmten Zieles.
In der Realität besteht unser Team aus 2 handvoll Kernteam Mitgliedern und einer Vielzahl von «Hobby Mitglieder». Auf den Sport übertragen: 7 Feldspieler und 5 Spieler, welche spielen wenn sie Lust und Zeit haben.
Massnahme ist einfach: Entweder bist du dabei oder nicht und jeder im Team weiss, wer Feldspieler ist und wer lediglich auf der Ersatzbank für Spezialeinsätze sitzt.
Der Scrum Master als Sozial Arbeiter
Geht es dem Team gut. Sind alle glücklich und können unbesorgt arbeiten. Falls nicht, ist mindestens die eigene Produktivität beeinträchtigt und wahrscheinlich auch die der Kollegen.
Massnahme: Regelmässigen Kontakt mit allen Teammitglieder. Spezifisch auf den Zahn fühlen, wie es läuft und wo der Schuh drückt.
Interessant die Antwort auf die Frage bezüglich der Arbeitsauslastung im Projekt. Sehr einfach mit Directpoll auch im Plenum anonym durchführbar.
Entwicklungsteam ≠ Programmiererteam
Den Name ist irreführend. Entwicklung beschränkt sich nicht auf Code sondern auf ein Produkt. Das Produkt kann eine Software, eine Kamera oder eine neues 5 Gang Menu sein. Spiel keine Rolle.
Daher soll sich auch ein Designer, Tester, Anforderungsmanager, Jurist, Architekt oder Koch damit identifizieren können.
Massnahme: Keine.
Bewährte Praktiken von Scrum *stehlen*
Die 6 Praktiken von Kanban sind:
- Visualisiere
- Limitiere den Work in Progress (WIP)
- Manage Flow
- Mache Prozessregeln sichtbar
- Implementiere Feedback Loops
- Führe Verbesserungen basierend auf Methoden und Modellen durch
Kanban gibt jedoch nicht vor, wie diese Praktiken konkrete umgesetzt werden sollen. Scrum hingegen ist sehr konkret: Es gibt Sprint Planning, Daily, Review und Retro. Alle Loops mit dem Ziel Feedback möglichst schnell zu erlangen. Viele davon funktionieren auch sehr gut in Kanban.
Massnahmen: Die Sprintplanning Sache wäre ein Gedanke wert, allerdings ist dieser noch nicht reif genug.
«Sprint Planning I» bestimmt das Was, «Sprint Planning II» das Wie
Zu meinen Scrum Zeiten gab es lediglich eine Sprint Planning Session, in welcher wir uns hauptsächlich um das «Was» kümmerten. Das Wie ging oftmals einfach irgendwie unter bzw. jeder fing dann mal an. In letzter Zeit kam somit auch immer mal wieder die Frage auf, wie man denn mit Architekturfragen umzugehen hat: Sprint Planning II eben. Damit habe ich auch bereits mein nächstes Aha Erlebnis beschrieben:
Architekturfragen werden im Sprint Planning II adressiert.
Der Scrum Master ist für erfolgreiche, konstruktive Meetings verantwortlich
Leider erlebe ich viel zu oft langweilige Meetings, wo ich gegen den Schlaf ankämpfen muss. Oftmals kommt es daher, dass jeder etwas dazu sagen möchte, aber nur beschränktes Wissen hat und anstatt die Leute einzeln abholt alle an einen runden Tisch holt. Das Grundproblem liegt daran, dass das Wissen zu verteilt ist und oftmals eine Kluft zwischen Wissen und Verantwortung klafft (ein fundamentales Problem von Management).
Der Klassiker. Das Meeting wird mit ein paar Slides eröffnet, um dann über das Problem und die Lösung zu diskutieren bzw. bis man aus dem Meeting Raum geworfen wird. Warum hier nicht kreativer Arbeiten?
Massnahme: Mehr Zeit in die Vorbereitung von Meetings stecken (und dafür weniger Meetings abhalten).
Review Meeting ≠ Demomeeting
Schon gar nicht wird hier dem PO gezeigt, wie cool die neuen Features sind und wie schnell die neue Lösung ist. Der PO ist teil des Teams und weiss das bereits vorher.
Im Review Meeting geht es darum, Feedback von richtigen Stakeholders einzuholen. Insofern muss ein Review Meeting nicht eine plumbe Demo sein, wo der Entwickler am Beamer ein paar Usecases durchspielt, sondern kann durchaus auch interaktiv sein: Zum Beispiel ein paar Computer hinstellen und die Stakeholders dazu einladen damit zu spielen und auch gleich Feedback zu geben.
wo der PO zum Produkt nickt.
-> Im Sprint haben wir ein «potentially shipable product» gemacht: Getestet und ohne Bugs!
Massnahmen: Keine
Scrum ist radikal, Kanban sanft
Kanban kann relativ sanft eingeführt werden. Der aktuelle Prozess wird nicht geändert sondern lediglich visualisiert. Scrum hingegen erfordert eine Umstellung. Entweder ich arbeite nach Scrum und halte mich an die paar Vorgaben und Rahmenbedingunen oder aber ich habe mein eigenes Framework.
Insofern schmerzt die Scrumeinführung wahrscheinlich mehr, dafür ist bei Kanban die Gefahr, dass es lediglich eine übergestülpte Hülle bleibt und dem Team vorgaukelt, dass es jetzt agil arbeitet.
Massnahmen: Keine
Regeln für selbstorganisierende Team sichtbar machen
Anstatt tausende von Regeln und Rahmenbedingungen irgendwo in einem Projekthandbuch, welches eh niemand liest zu führen, diese lieber auf ein Flipchart schreiben und aufhängen. Reicht ein Flipchart nicht, gibt es wahrscheinlich zu viele Regeln.
Entweder man hält sich an die Regeln oder man löscht/ändert die Regel wieder, setzt aber voraus: Der Scrum Master hält eine Auge drauf.
Massnahme: Regeln auf Flipchart visualisieren.
Das Tool der Wahl: Filzstift und Flipchart
IT schön und gut, doch ist Papier viel geduldiger. Anstatt Power Point Schlachten zu fechten können ein paar Flipcharts viel effektiver sein.
Massnahme: Think, Baby Think. Anstatt für jedes Meeting gleich ein leeres Powerpoint zu öffnen, die grauen Hirnzellen anwerfen und schauen, wie man das Thema sonst noch angehen könnte.
