Scrum in der Praxis: Ein Team startet durch

//SEIBERT/MEDIA setzt auf Agile und Scrum ist in vielen unserer Projekte längst die Regel. Doch die Etablierung von Scrum geht nicht "von jetzt auf gleich", sondern erfordert ein Umdenken in vielerlei Hinsicht: neue Methoden, unbekannte Prozesse, eine ganz andere Arbeit und Kommunikation im Team. Dies ist der persönliche Bericht eines Teammitglieds mit Blick auf die Scrum-Methoden und die Stadien des Team Buildings.

Einführend sei deshalb noch einmal kurz auf das Modell des Teambildungsprozesses in der Software-Entwicklung nach Bruce Tuckman verwiesen, das vier Phasen kennt:

  • Forming: Die Orientierungsphase, in der das Team sich gegenseitig und die neuen Methoden kennenlernt.
  • Storming: Die Konfrontationsphase, in der sich jedes Teammitglied positioniert.
  • Norming: Die Phase, in der die Regeln gemeinsam abgesteckt werden.
  • Performing: Die Phase, in der das Team eingespielt ist und ein Höchstmaß an Produktivität erzielt.

Nun aber zu meinen Erinnerungen und einem Zwischenfazit.

Forming

Zum Team gehörten von Anfang an drei Entwickler, zwei Designer und ein technischer Experte als Berater aus einem anderen Team, der uns auf dieser technischen Neulandbegehung unterstützen soll. Gleich zu Beginn sind wir auch räumlich zusammengerückt und haben ein gemeinsames Büro bezogen (Entwickler, Berater und Product Owner), was von allen positiv aufgenommen wird. Lediglich die Designerinnen sind im gewohnten Abteilungsbüro geblieben. Unser Team hat sich sogar einen Namen gegeben, cool.

Drei Projekte, ein Board

Von vornherein war klar: Zwischen unseren Projekten gibt es thematische Ähnlichkeiten und technische Verzahnungen. Daher kam und kommt es auch zu Überschneidungen in der Teamstruktur der Einzelprojekte. Alle drei Projekte hat ein Product Owner unter seine Fittiche genommen, er ist in erster Linie für die Priorisierung der User Stories zuständig.

Häufig ist jedes dieser drei Projekte mit mindestens einer Story im Sprint am Start, gelegentlich vereinnahmt aber auch ein einzelnes Projekt den gesamten Sprint.

Eine besonders große Herausforderung ist von Beginn an die Umsetzung der Maxime "Jeder macht alles" gewesen: Jedes Teammitglied hat ein Projekt, das ihm besonders am Herzen liegt, und sieht sich immer wieder versucht, sich vorwiegend um die Arbeiten an diesem Steckenpferd-Projekt zu kümmern.

Da dadurch aber auch oft die Priorisierungen der Stories ignoriert (und damit die Sprint-Ergebnisse gefährdet) werden, haben wir uns zum radikalen Umdenken entschlossen: Es sind nun maximal die Top 3 der noch offenen Stories gleichzeitig in Bearbeitung. Teilweise längere Bearbeitungszeiten, mehr Fragen und eine intensivere Zusammenarbeit sind die Resultate dieses Vorgehens - aber auch und vor allem die Beseitigung von Wissensinseln. Gerade dieses Vorgehen wurde aber stets wieder diskutiert, denn in den Augen mancher Teammitglieder überwiegen hier die Nachteile. Letztendlich ist uns aber die mittelfristige Beseitigung der Wissensinseln besonders wichtig, so dass wir bisher trotzdem an diesem Vorgehen festhalten.

Wer ist eigentlich der Scrum Master?

Die nächste Herausforderung: Die Bestimmung eines Scrum Masters. Die meisten unserer Kollegen waren anfangs ja noch selbst mitten in der Scrum-Ausbildungsphase und konnten nicht einfach in diese anspruchsvolle Rolle schlüpfen.

Nur eine Person hat über eine ausreichende Expertise verfügt und musste diesen Part übernehmen. Doch schnell wurde die starke Auslastung zum Problem. Es half nichts: Ein anderer, inzwischen extra zum Scrum Master geschulter Kollege wurde ernannt - und leider bald in andere Projekte abgezogen. Na prima, nach wenigen Sprints hatte unser Team also den dritten Scrum Master, der mehr oder weniger von vorne beginnen musste.

Diese Lösung ist bis jetzt aber angenehmerweise von Dauer. Inzwischen ist der Scrum Master auch zum Organisator geworden, er plant die Meetings, kümmert sich um die Kalendereinträge, dokumentiert die Meetings wo nötig usw. – wie eine richtige Teamsekretärin. 😉 Uns ist natürlich bewusst, dass das nicht die eigentlichen Aufgaben des Scrum Masters sind und er diese nach und nach an uns abgeben wird.

Meetings, Meetings, Meetings

Daily Scrum
Seit "Agile" auf der Tagesordnung steht, ist das Daily Scrum Bestandteil der täglichen Arbeit. Wir treffen uns jeden Tag am Board, die Teammitglieder tauchen mal mehr, mal weniger pünktlich auf. Die Termine variieren von Sprint zu Sprint, in der Regel kommen wir aber am frühen Nachmittag zusammen. Aktuelle Uhrzeit ist 13:30 Uhr. Zu dieser Zeit ist jedes Teammitglied im Büro und verfügbar.

Im Daily Scrum haben wir von Anfang an mit verschiedenen Möglichkeiten experimentiert: Bei einer Variante beantwortet jeder im Team alle Fragen der Reihe nach, bei einer anderen treten alle gleichzeitig ans Board, hängen Zettel und Karten im wilden Durcheinander um und erklären danach einzeln das Doing. In der Retrospektive besprechen wir dann anschließend, welche Variante uns am meisten zusagt.

Wir mussten und müssen uns allerdings nicht selten gegenseitig auf die Timebox hinweisen, damit Gespräche nicht zu sehr in Details abgleiten und zeitlich aus dem Ruder laufen. Es gibt ja noch mehr zu tun als sich zu besprechen.

Sprint Planning
Das Planungsmeeting hat zwei Teile, die Beschätzung und den Task-Breakdown, findet zumeist montags statt und ist auf zwei Stunden angesetzt.

Inzwischen haben wir mehrere Methoden zur Beschätzung ausprobiert, insbesondere das sog. Estimation Game hat sich als ziemlich leistungsfähige Methode erwiesen. Eine Herausforderung besteht jedoch immer in der Klassifizierung der Größe (in Storypoints, SP) und der Vergleichbarkeit.

Anhand unserer Teamgeschwindigkeit kann man ganz gut sehen, dass es bisher immer einige Herausforderungen im Zusammenhang mit Beschätzung oder Umsetzung gab. 🙂

Mittlerweile haben unsere Sprints jeweils explizit ausformulierte Sprint-Ziele, die von den Inhalten der Stories etwas gelöst sind – Das hilft enorm, sich aufs Wesentliche zu fokussieren. Wenn klar ist, dass wir eine Story nicht schaffen werden, streichen wir diejenige aus dem Sprint, die dem Sprint-Ziel am wenigsten oder gar nicht dienlich ist. Das ist allerdings erst einmal vorgekommen.

Unsere Sprints haben übrigens auch Namen. Wir haben uns recht unverfänglich für die heimischen Baumarten entschieden, der erste Sprint hieß "Ahorn". Wenn wir im Sprint "Zirbelkiefer" angelangt sind, überlegen wir uns ein neues Namensschema, aber bis dahin ist noch etwas Zeit.

Review
Jeden zweiten Donnerstag zum Ende des Sprints versammeln wir uns für eine Stunde zum Review-Meeting: anfangs nur zur Vorstellung der Umsetzungen im Team, später auch zusammen mit externen Beteiligten. Allerdings werden externe Verantwortliche nur bei einem der drei Projekte dazugeholt, die Ergebnisse der beiden anderen Projekte führen wir im Review nur dem Team und dem Product Owner vor. Der Akzeptanz dieses Meetings im Team hilft das leider wenig, ließ sich bisher aber auch nicht ändern.

Wie sollte es anders sein: Früh hat sich in diesem Zusammenhang die Technik als hakelig herausgestellt – Externe Teilnehmer müssen per Skype integriert werden, Desktop-Sharing-Sitzungen sind zu realisieren. Das haben wir inzwischen aber ganz gut im Griff.

Leider blicken wir hier auch auf einige etwas weniger angenehme Momente zurück: Nach einem schweißtreibenden Sprint meinte der Stakeholder lapidar, dass das Feature wieder entfernt werden müsse, ein anderes Mal zeigte er sich enttäuscht, dass es ja gar nichts Neues gäbe (weil er die Layout-Entwürfe schon kannte und die Umsetzung eben exakt so aussah). In unserem allerersten Review-Meeting verweigerte der Product Owner die Vorführung einer fast kompletten Story, die nur bis auf wenige Details unfertig war. Klar hat er sich eigentlich richtig verhalten, denn alles, was nicht fertig ist, existiert praktisch für den Kunden nicht. Uns als unerfahrenen Scrum-Teammitglieder hat das aber schon zugesetzt.

Protokolle führen wir live im Firmenwiki, Nacharbeiten an den Stories sind in aller Regel bis zum Start des nächsten Sprints (zumeist Montags) abgeschlossen (oder werden in diesen aufgenommen).

Retrospektive
Dem Review-Meeting folgt stets die Retrospektive. Die erste war arg knapp auf eine Stunde angesetzt, heute planen wir zwei Stunden ein. Wir starten mit einer Sicherheitsabfrage der Form “Auf einer Skala von eins bis fünf: Wie frei meinst Du in dieser Runde sprechen zu können?” und bekommen so ein Gefühl dafür, wie offen wir in der Retrospektive tatsächlich miteinander umgehen. Es folgt eine "Aufwärmfrage", die zumeist auf den Gesamteindruck des vergangenen Sprints abzielt. Beliebt dabei sind Analogien wie z.B. Wetterlagen, Tiere etc.

Im anschließenden Stadium, der Datensammlung, beantworten wir zunächst sechs Fragen zu unserem Prozess und dem Sprint, die Antworten (von eins bis fünf) visualisieren wir mithilfe einer Antwortmatrix und erhalten so ein aktuelles Bild des Teams. Da wären z.B. folgende Fragen: "Wie zufrieden bist Du mit dem Board?", "Wie zufrieden bist Du mit den Tasks?", "Wie sicher bist Du im Umgang mit Scrum?", "Hat sich die Vorbereitung des Reviews verbessert?".

Daraus ermitteln wir schließlich eine Plus/Delta-Tabelle, sammeln also alles, was gut lief und was wir verbessern sollten. Durch eine Clusterung (Markierung der uns am wichtigsten erscheinenden Pukte) definieren wir dann die Diskussionsthemen.

Die Retrospektive schließen wir immer mit "Trys" ab, also mit konkreten Maßnahmen, die wir ausprobieren wollen, um eine Verbesserung zu erzielen. Meiner Erfahrung nach gehen diese mit der Zeit häufig etwas verloren, eine Fokussierung auf ganz wenige Trys (maximal drei) pro Sprint erscheint mir hier sinnvoll. Auch "Keeps" und "Drops", also Bewährtes und Abzuschaltendes, haben wir eigentlich immer definiert. In unseren Retrospektiven ist die Delta-Spalte in der Regel deutlich besser gefüllt als die Plus-Spalte.

Neuerdings probieren wir mit unserem Scrum Master im Rahmen der Datensammlung die sog. Sprint-Timeline aus. Ich bin gespannt, wie es damit weitergeht!

Ganz am Anfang haben wir auch das kollektive Loben ausprobiert. Das bedeutet, dass jeder mindestens ein anderes Teammitglied für irgendetwas lobt, und soll dazu beitragen, auch hitzige oder frustrierende Meetings zu lockern und positiv zu beenden. Allerdings haben wir damit ohne Absprache wieder aufgehört und bislang hat sich auch noch niemand darum bemüht, die Lobrunde zu reanimieren. Wahrscheinlich ist das hauptsächlich eine Frage der Mentalität: Lobhudeleien (auf Knopfdruck) sind in unseren Breitengraden eher unüblich und wirken befremdlich. Auf eine Art eigentlich auch schade.

Man liest ja häufig, dass die Retrospektive das wichtigste Meeting im Scrum-Prozess sei. Auch Joachim Seibert, der Agile und Scrum bei uns eingeführt hat und vorantreibt, hat die Bedeutung der Retrospektive ausführlich hervorgehoben. Ich stimme zu: Ich habe die Retrospektiven bisher immer als sehr wertvoll, spannend, reinigend und Verkrampfungen lösend erlebt. Wann sonst hat man die Gelegenheit, offen und unter sich zu diskutieren sowie sein Handeln immer wieder neu zu prüfen?

Storming

Das zweite Stadium des Teambildungsprozesses ist die Storming-Phase, die auch wir intensiv durchlebt haben und nach wie vor durchleben. In ihr wird bei uns vieles in Frage gestellt – und zwar oft grundsätzlich. Vor allem hier waren und sind Diskussion und Meinungsaustausch teils sehr kontrovers. Wobei: Kontrovers wurden und werden eigentlich immer nur der Prozess und die Projektstruktur diskutiert, über "Kleinigkeiten" wie z.B. offene Fenster, schmatzende Kollegen, unkommentierten Code etc. erhitzen sich die Gemüter erstaunlicherweise weniger.

Aber man merkt eben durch solche Diskussionen, dass nicht jeder so richtig von Scrum überzeugt ist und dafür auch seine Argumente hat. Wir arbeiten zwar nicht gegeneinander, reiben uns aber besonders bei Grundsatzfragen immer wieder aneinander. Manchmal ist die Diskussion des Prozesses an sich schon etwas ermüdend ...

Norming

Ein wirkliches Thema ist Norming bei uns bislang im Grunde nicht: Im Hinblick auf die Arbeitsweise an sich gibt es eigentlich kaum Differenzen. Stattdessen konzentrieren wir uns zunächst noch auf den Kompetenzaufbau und die Angleichung unserer Skills.

Inspect & Adapt

Inspect & Adapt bedeutet regelmäßige Verbesserung schon während des Projektablaufs: Wir betrachten ständig das Projekt und die Ergebnisse sowie unsere Zusammenarbeit kritisch und denken über Möglichkeiten nach, noch besser und effektiver zusammenzuarbeiten. Inspect & Adapt wird bei uns insbesondere vom Product Owner vorangetrieben, und in diesem Rahmen hat unser Team bereits etliche hochinteressante Dinge ausprobiert:

  • Erstellung einer Definition of Done
  • Backlog-Pflege-Meetings (neudeutsch: "Backlog Grooming", ein Mal pro Woche eine Stunde)
  • Pair Programming bzw. Coaching zu festen Zeiten
  • Coding-Katas mit den Entwicklern
  • Sprint-Ende-Bericht
  • Thumb Voting
  • Umgang mit Task Tracker (JIRA)

Fazit

Bislang haben wir sieben Sprints gemeistert. Ich denke, wir befinden uns in Sachen Teambildung am Beginn der Norming-Phase, fallen auch immer mal wieder ins Storming zurück. Scrum "funktioniert", ist aber schwierig, wenn noch nicht alle im Team aus Überzeugung dabei sind. Man braucht schon einen längeren Atem und sollte nicht allzu schnell robuste Ergebnisse im Hinblick auf Teambildung, Prozessdefinition und Entwicklung erwarten – Alles ist im Fluss. 🙂

Die Selbstverantwortung und die vielen dadurch entstehenden Diskussionen finde ich recht auf- und anregend, manchmal auch sehr anstrengend. Die Möglichkeiten der regelmäßigen Justierung (Inspect & Adapt) sind indes tatsächlich sehr mächtig und machen das Team besonders flexibel, was ich als ungemeine Bereicherung empfinde! Die vielen Post-its und Zettel im Büro machen mich dagegen manchmal nervös. Mir persönlich sind aufgeräumte digitale Versionen von Board und Backlog lieber, auch hier experimentieren wir noch.

Nicht zu vergessen: Theoretisch funktioniert das Zusammenspiel zwischen dem klassischen Scrum und JIRA/Greenhopper prima. Ein ordentliches Maß an Disziplin ist aber schon erforderlich, um die agilen Projekte auch immer lückenlos digital abzubilden und die Synchronisation von analogem und digitalem Board stets sicherzustellen.

Ich möchte an dieser Stelle dem ganzen Team, dem Product Owner und dem Scrum Master für die bisherige Zusammenarbeit danken und freue mich auf alles, was noch kommt.

Weitere Informationen

Haben Sie Fragen zu Scrum? Möchten Sie Agilität in Ihrem Unternehmen einführen? Planen Sie ein Software-Projekt und möchten sich agile Vorgehensweisen zunutze machen? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Mit mehr als 20.000 Stunden Projekterfahrung in internen und externen Projekten mit agilen Entwicklungsmethoden gehört //SEIBERT/MEDIA zu den erfahrenen und größten Anbietern für Scrum in Verbindung mit den Atlassian-Tools JIRA/Greenhopper und Confluence in Deutschland. Gerne helfen wir Ihnen bei der Etablierung agiler Prinzipien und Verfahren – sprechen Sie uns einfach unverbindlich an. Weiterführende Informationen finden Sie auch auf unserer speziellen Seite zum Thema Agilität in Unternehmen.

Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
Die Scrum-Meetings und ihre Bedeutung
Agile Projekte und Scrum in der Praxis: Elemente, Nutzen, Tools, Hürden
Confluence und JIRA im Scrum-Sprint nutzen


Mehr über die Creative-Commons-Lizenz erfahren

In dieser Jira-Schulung lernen erfahrene Projektleiter, IT-Admins, Scrum Master und Agile Coaches, wie sie Projekte in Jira administrieren und verwalten können.
ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

One thought on “Scrum in der Praxis: Ein Team startet durch”

  1. Ein sehr ausführlicher und sehr offener Bericht. Vielen Dank auch für die Herausstellung der teils schwierigen Situationen, die bewältigt werden müssen. Eine Scrum-Einführung ist anspruchsvoll, kann dafür aber auch äußerst lohnenswert sein.

Schreibe einen Kommentar