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.