Die Größe einer User Story

Die Größe einer Story zu schätzen ist bei der Einführung von SCRUM in einem Unternehmen immer eine große Herausforderung für die Team-Mitglieder. Schließlich ist man Jahrelang darauf getrimmt worden eine Aufwandsabschätzung in Personentagen abzugeben. Und das konnte natürlich jeder nur für seine Kernkompetenz tun. Nun sollen plötzlich alle Teammitglieder, die ja aus unterschiedlichen Disziplinen zusammengewürfelt wurden, zu einer gemeinsamen Aussage kommen. Um dies zu erreichen muss das “Bauchgefühl” einer jeden Disziplin zu einem gemeinsamen Verständnis “geeicht” werden ohne dabei zu sehr ins Detail der jeweiligen Kompetenzen gehen zu müssen.

Mir wurde die Bedeutung der “Größe” einer Story folgendermaßen erklärt:

Zwei Bergwanderer unterhalten sich: Der eine war letztes Wochenende auf einem Gipfel, den der Zweite noch nie erklommen hat. Der erste erklärt: die Wanderung war etwa doppelt so “groß” wie die Besteigung des Bergs XY den sie ja beide zusammen vor kurzem erstiegen haben.

Ohne genau erklärt zu bekommen warum die Wanderung des unbekannten Bergs anscheinend mehr Anstregung gekostet hat kann der zweite Bergsteiger sich nun ein gutes Bild über die Besteigung des unbekannten Gipfels machen, obwohl ihm keinerlei Details bekannt gegeben wurden wie z.B. höhe des Bergs, Strecken die eine Seilsicherung erfordern, ein Geröllfeld o.ä.

Genau so geht man in SCRUM mit den “Größen” einer Userstory um: wir vergleichen das “Bauchgefühl” über Stories, die allen Teammitgliedern aus der Vergangenheit bekannt sind und setzen diese in einfache Relationen wie zum Beispiel ”Halb so groß” oder ”Doppelt so groß”.

Selbstorganisation ist das größte Impediment

Nachdem ich nun in über einem halben dutzend Teams bei der Einführung von Scrum die Rolle des ScrumMasters einnehmen durfte bin ich mir sicher, dass nicht wie üblicherweise angenommen der Umstieg vom V- oder Wasserfallmodell auf die agilen Methoden die größten Probleme darstellt. Große Schwierigkeiten dagegen bereitet die Anpassung der Denkweise der Teammitglieder bzgl. der vorher gelebten Linienführung und der nun plötzlich von ihnen erwarteten Selbstorganisation.

Die vor der Scrumeinführung so ersehnte Freiheit entpuppt sich sehr schnell als große Pflicht, die nicht von einem Tag auf den anderen in die Köpfe der agilen Neulinge eingetrichter werden kann. War es doch in der reinen Linienführung so einfach: Jemand hat einem gesagt was man tun muss. Man tat dies und die Welt war in Ordnung. Natürlich war man meistens mit den von oben vorgegebenen Entscheidungen nicht einverstanden und man konnte seinen Frust mit Kollegen beim Tratsch in der Kaffeeküche ordentlich kommunizieren.

Anders beim Scrum:

  • Böse Produktowner versuchen einen zu mehr Arbeit zu überreden – und man muss Nein! sagen wenns zu viel wird. Keiner steuert mehr die Menge der Arbeit, das muss das Team entscheiden!
  • Keiner gibt einem einen Prozess zur Qualitätserreichung vor, nur noch das Qualitätsziel. Das Team muss selbst Massnahmen erarbeiten und ergreifen um die nötige Qualität zu erreichen
  • Überhaupt: Niemand mehr ausserhalb des Teams wird sich zuständig fühlen für die Entwicklungs-Infrastruktur. Hier muss das Team sowohl in Spezifikation als auch in der Implementierung selbständig tätig werden.

Die ScrumBox (oder die drei T’s)

Scrum-Beginner stellen sich oft die Frage wieso denn das Commitment nach dem Planning I meeting stattfinden muss. Es wäre doch viel besser ein Commitment erst
abzugeben wenn man sich detailiert mit dem Design beschäftigt hat, also nach dem Planning II. Aus Entwicklersicht ist dieser Vorschlag durchaus berechtigt. Aus Scrumsicht nicht: wird das Design nicht bereits durch die Box beschränkt wird dies sich negativ auf das Commitment auswirken. Ist die Box vorher (also nachdem im Planning I verstanden wurde was geliefert werden soll) vorgegeben so wird sich das Design nach der Box, also dem Team (KnowHow), den Tools (vorhandene Architektur, Frameworks, Libraries) und v.a. der Zeit (es muss ja nach dem Sprint geliefert werden) richten.

If it hurts, do it more often!

Meines Wissens nach hat Martin Fowler diesen Ausspruch geprägt. Diese Wahrheit kommt einem gerade im Agilen Umfeld immer wieder unter. Von den Newbies kommt dann oft der Einwurf, dass SM vielleicht doch nicht für ScrumMaster steht ;-) .

Was Fowler hier im Context der Continous Intgeration aber eigentlich meint, ist, dass man Tätigkeiten, die mühsam sind (die weh tun), häufiger tun sollte damit diese den Schrecken verlieren. Wenn also z.B. die Migration nach einem Vierteljahr Entwicklung zwei Wochen Wahnsinn für alle Entwickler bedeutet, so könnte ein tägliches Integrieren kleiner Softwarehäppchen wahrscheinlich so einfach erfolgen, dass kein Mensch mehr darüber sprechen würde. Fowler spricht dann auch davon ein Non Event zu schaffen.

Gründe an denen die Scrum Einführung scheitern kann

Allgemein

  • es wird nicht nach dem Gesunden Menschenverstand gehandelt, sondern an alten Gewohnheiten festgehalten.
  • das Management agiert nicht nach den Scrum-Regeln obwohl es die Einführung von Scrum befürwortet, meist sogar befohlen hat.
  • der Scrum-Takt kann nicht sauber gefahren werden z.B. wegen zu vieler anderer Termin/Verpflichtungen der Mitarbeiter, zu wenig Räumlichkeiten/Resourcen
  • Personen, welche eigentlich gar nicht involviert sind, erheben das Wort oder geben Kommandos (Talking Chickens)

Fehler vom Scrum Master

  • er weist Zeiten und Aufgaben zu, fordert Entscheidungen
  • er führt kein priorisiertes Impediment Backlog
  • er degradiert zur Sekretärin des Teams
  • er schafft es nicht, das Team im Scrum-Rahmen zu halten
  • er erzeugt (nur) Transparenz für’s Management anstelle (auch) Transparenz für’s Team

Fehler vom Product Owner

  • er ist ständig unerreichbar
  • er hat keine Vision, Businessplan, Release Roadmap
  • er vernachlässigt das Backlog, d.h. stellt schlechte oder unvollständige Stories ins Backlog, es gibt Arbeiten die gar nicht im Backlog stehen
  • es ergeben sich ständig Änderungen des Sprint Backlogs während dem Sprint
  • er liefert zu viele Antworten statt Fragen zu stellen, oder/aber er kann zu wenige Fragen beantworten

Fehler beim Qualitätsverständnis

  • Die Definition of Done wird nicht eingehalten bzw. vom Team nicht gelebt
  • Team nicht vollständig in den Planungs-Meetings, und/oder Product Owner nicht anwesend.
  • Entwickler gehen davon aus, dass die QA die Fehler findet
  • QA nicht Teil vom Team
  • Integration-Tests / End2End-Tests werden ans Sprintende (oder darüber hinaus) verschoben

Fehler vom Team

  • das Team agiert nicht selbständig
  • festgefahrene Rollen, kein Wissenstransfer
  • Diktatoren im Team
  • das Team ist auf Kritik von außen angewiesen, anstatt durch Retrospektive Selbstverbesserungsmassnahmen durchzuführen
  • persönliche Ziele stehen vor den Teamzielen
  • Aufgaben werden zugewiesen
  • es wird sich nicht gegeneinander geholfen, nicht einander zugehört
  • der Spaß kommt zu kurz