Unternehmer und Geek

Schlagwort: Scrum

  • Holacracy Meets Scrum

    Das Meeting eskaliert. Die Entwickler sind frustriert. Zeit wird mit warmer Luft vergeudet. Diskussionen drehen sich im Kreis und verstricken sich in kleinen Details. So in etwa lässt sich das letzte Grooming Meeting beschreiben.

    So kann es nicht mehr weitergehen, aber wie sonst? Es gib anscheinend zu viele starke und vor allem unterschiedliche Meinungen. Grooming ist noch nicht fertig, alle sind frustriert. Jetzt ist guter Rat teuer.

    Und doch so einfach. Nicht dass die Entwickler böse Absichten hätten oder gar demotiviert sind und einfach stören wollen. Im Gegenteil: Es steckt viel Herzblut und Elan drin. Zu viel? Holacrazy bietet Hilfe.

    Weg mit der freien Diskussion

    Damit solche Leute dennoch zielführend miteinander diskutieren können, bedarf es einer strikten Moderation. Holacrazy gibt für die Moderation des Governance Meeting einen genauen Prozess vor:

    1. Präsentieren
    2. Fragen stellen
    3. Reaktionen
    4. Anpassen
    5. Einwände
    6. (Schätzen)

    Der fast perfekte Prozess für ein Grooming aber auch für ein Planning II.

    Präsentieren
    Der Product Owner (PO) stellt die Story kurz und knapp dem Team vor.

    Fragen stellen
    Das Team kann Fragen stellen. Jede Frage ist präzise formuliert. Eine Frage endet mit einem Fragezeichen. Ist es keine Frage, schreitet der Moderator sofort ein. Der PO beantwortet Fragen und darf bei Bedarf auf das Wissen von anderen Teammitglieder zurückgreifen.

    Reaktionen
    Reaktionen dürfen persönlich sein. Gefällt mir, gefällt mir nicht. Es ist allerdings keine Diskussion und es werden auch keine Fragen mehr gestellt. Reaktionen haben normalerweise ein Ausrufezeichen am Satzende.

    Anpassen
    Basierend auf den Fragen und den Reaktionen hat der PO jetzt die Möglichkeit die Story noch anzupassen. In Praxis findet diese Anpassung laufend statt.

    Einwände
    Jetzt dürfen Einwände kommen. Bei den Einwänden geht es nicht um die «Umsetzungsfähigkeit» sondern um die «Sinnhaftigkeit» einer Story. Es könnte durchaus sinnvoll sein, ein paar Kriterien aufzustellen, welche einen gültigen Einwand Charakterisieren: Bsp: Story falsch geschnitten aufgrund von xyz, Story kann bereits mit xyz Prozess durchgeführt werden etc.

    Schätzen
    Zu guter letzt kann die Story jetzt noch geschätzt werden.

    Wichtig ist der Moderator. Eine Diskussion, wo jeder wild durcheinander Meinungen, Argumente und Fragen in die Runde wirft findet nicht statt und müssen ausserhalb des Meetings diskutiert werden. 

    Meetingsleitfaden fürs Planning II

    Auf fürs Planning II ist dieser Prozess geeignet, allerdings mit einer kleinen Abwandlung: Nicht der PO stellt etwas vor sondern der Entwickler. 

    Der Reihe nach stellt ein Entwickler eine Story vor und wie er diese umzusetzen gedenkt. Dabei wählt er die Story, wo er am meisten Wissen hat und wo er den grössten Bedarf an gemeinsamen «Entwicklungsverständnis» sieht. 

    Dieser Modus hat dem Team geholfen, effizient, zielstrebig und vor allem ohne Kollateralschäde durch die regelmässigen Scrum Meetings durchzukommen.

    Sicher ist diese Vorgehensweise nicht für alle Teams geeignet. Sie mögen als einengend und Kindergarten scheinen. In dem Fall bitte nicht umsetzen. Für andere Teams hingegen kann es ein guter Ausgangspunkt für eine geordnete Diskussion sein. 

  • Das erwartet dich am 3 tägigen Scrum Master Kurs

    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:

    1. Visualisiere
    2. Limitiere den Work in Progress (WIP)
    3. Manage Flow
    4. Mache Prozessregeln sichtbar
    5. Implementiere Feedback Loops
    6. 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.