Sybit agile | Ausgabe 8 1

Sei doch kein Scrum-Zombie!Marc Löffler, Projektleiter und Scrum Coach, Sybit GmbH Schon lange beschäftige ich mich damit, warum es Scrum-Teams gibt, die zwar alle Rituale streng einhalten und trotzdem nicht so recht vom Fleck kommen. Alle Meetings werden zum vereinbarten Termin durchgeführt, alle sind pünktlich und anwesend und doch läuft irgendetwas schief. Kann es sein, dass wir es hier mit einem Team von ein oder mehreren Scrum- Zombies zu tun haben? “Scrum-Zombies? Was ist denn das?” werden Sie fragen. Eigentlich ganz einfach. Ein Scrum-Zombie ist jemand, der (noch) nicht weiß, warum Scrum funktioniert und sämtliche Werte geflissentlich ignoriert. Aber gerade diese Scrum-Werte sind es, die einem Scrum-Team Leben einhau-chen. Hier zur Erinnerung die Werte in Scrum:

Ì Selbstverpflichtung (Commitment): Verpflichte dich, für die Erreichung der (Sprint) Ziele alles dir Mögliche zu tun.

Ì Offenheit/Transparenz (Openess): In Scrum herrschen totale Transparenz und Offenheit bezüglich des Projekts.

Ì Mut (Courage): Hab den Mut, dich zu engagieren, proaktiv zu agieren, offen zu sein und Respekt zu erwarten.

Ì Fokus (Focus): Mach deinen Job. Fokussiere deine ganzen Fähigkeiten darauf, die Arbeit zu machen, zu der du dich ver-pflichtet hast. Alles andere ist egal.

Ì Respekt (Respect): Jede Person hat ihre eigene Vergangen-heit, die sie zu dem Menschen gemacht hat, der sie heute ist. Es ist wichtig jede einzelne Person im Team zu respektieren.

Aber wie können wir als ScrumMaster oder Coach dem Team dabei helfen, diese Werte zu leben?

Inhalt: Seite 1: Sei doch kein Scrum-Zombie!Seite 2: Scrum in sehr kleinen TeamsSeite 4: Wie verwalte ich meine Stories?

agile Agile Softwareentwicklung im Fokus

Ausgabe 8Sybit agile

Sybit agile | Ausgabe 82

Daily Scrum

Ein häufiges Problem beim Daily Scrum ist, dass es zu einem reinen Reporting verkommt. Jedes Teammitglied erzählt aus-führlich, was es gestern gemacht hat und die eigentliche Pla-nung bleibt oft auf der Strecke. Schlimmer ist allerdings, wenn alle Teammitglieder in Zombie-Manier jeden Tag das Gleiche erzählen und das Daily Scrum somit jeglichen Sinn verliert. Um das zu vermeiden, gibt es ein paar kleine Tricks:

Ì Statt nur zu erzählen zeigen sie sich gegenseitig, an was sie am vorigen Tag gearbeitet haben. So wird das Ganze greifbarer.

Ì Verstehen Sie das Daily Scrum als “Mini Sprint Planning”. Im Daily Scrum geht es hauptsächlich darum, den nächsten sinn-vollen Schritt zu planen, um dem gemeinsamen Sprint-Ziel wieder ein Stück näher zu kommen.

Durch diese Tricks verliert das Daily Scrum seine Vorherseh-barkeit und erschwert somit Scrum-Zombies das Leben. Etwas ausführlicher habe ich das ganze Thema im Artikel “Daily Scrum – das meist unterschätzte Scrum Meeting” in der Ausga-be 07/2010 von Sybit agile behandelt.

Sprint Planning Oft wird im Sprint Planning eines der wichtigsten Dinge über-haupt vergessen: Das Einfordern der Verpflichtung des Teams, alles daran zu setzen, das eben beschlossene Sprint-Ziel zu erreichen. Die Teammitglieder verkommen zu hirnlosen Zom-bies, die nur noch das Sprint Backlog abnicken, ohne wirklich darüber nachzudenken, ob es überhaupt machbar ist. Die Folge: Stories werden nicht fertig oder es fehlt an Motivation, weil jeder denkt, dass die Ziele nicht erreichbar sind. Das kann ein ScrumMaster dagegen machen:

Ì Das Commitment jedes einzelnen Teammitglieds einfordern. Am besten schreibt man hierfür die Sprint-Ziele auf ein Flip-chart und lässt jeden darauf unterschreiben. Dieses Flipchart wird dann im Teamraum aufgehängt.

Ì Das Sprint Planning ist ein Design-Meeting. Dulden Sie keine Sprint Plannings, bei denen am Ende nicht bei den meisten Stories klar ist, wie genau diese implementiert werden sollen.

Ì Organisieren Sie etwas zu essen. Das Sprint Planning kann bis zu 8 Stunden dauern (bei 4-wöchigen Sprints). Sorgen sie dafür, dass etwas zu essen da ist und sie werden sehen, wie entspannt ein Sprint Planning ablaufen kann. Denn sinkt der Blutzuckerspiegel, sind die Zombies nicht mehr fern.

Sprint Review Schon mal erlebt, dass der ScrumMaster allein im Sprint Re-view saß und auf das Team gewartet hat? Ich schon. Das Ganze lässt sich folgendermaßen beheben:

Ì Proben Sie das Sprint Review einmal, bevor es ernst wird.

Ì Nutzen Sie das Daily Scrum, um die letzten Schritte vor dem Sprint Review zu besprechen.

Sprint Retrospektive

Retrospektiven von Scrum Zombies zeichnen sich dadurch aus, dass dauernd die gleichen Dinge auf den Tisch kommen oder die Aufgaben der letzten Retro nicht bearbeitet wurden. Um diese hirnlosen Retros zu vermeiden, können sie Folgendes versu-chen:

Ì Benennen Sie immer einen Verantwortlichen. Er muss diese Aufgabe nicht zwingend selbst erledigen, aber er stellt sicher, dass sie erledigt wird.

Ì Setzen Sie gemeinsam eine Deadline. Das funktioniert auch in agilen Teams hervorragend.

Ì Hängen Sie die Retroergebnisse sichtbar im Teamraum auf. Aufgaben, die länger als 2 Stunden dauern, sollten auch im Sprint Backlog erscheinen.

Fazit Leben Sie die Scrum-Werte als Team, geben sie ihren Scrum Meetings einen Sinn und gestalten sie sie so interaktiv wie mög-lich. Nur so werden sie zu einem guten Zombie-Jäger und Ihre Scrum-Implementierung ist nicht zum Scheitern verurteilt.

Marc Löffler ist Projektleiter und Scrum Coach bei der Sybit GmbH. Er ist Certified Scrum Professional (CSP) und hilft unseren Kunden, agile Vorgehensmodelle wie Scrum und Kanban in ihren Unternehmen zu etablieren und zu verbessern.

ZUM AUTOR

Marc Löffler

Scrum in sehr kleinen TeamsRolf Gehring, Projektmanager und ScrumMaster, Sybit GmbH

Scrum hat sich als ein Vorgehensmodell der Softwareentwick-lung bei Sybit in vielen Projekten etabliert und bewährt. Das Modell schlägt als ideale Teamgröße fünf bis maximal neun Teammitglieder vor. In der Praxis können jedoch durchaus andere Teamgrößen entstehen. Wird die empfohlene Teamgrö-ße erheblich überschritten, sind die Maßnahmen einfach: Man gründet ein zweites Team und harmonisiert sie in einem Scrum-Of-Scrums. Stehen jedoch nicht genügend Teammitglieder zur Verfügung und erlaubt das Projekt und der Zeitplan zudem die Durchfüh-rung mit deutlich weniger Mitgliedern, muss man gezwungener-maßen damit leben. In letzterer Situation fand ich mich vor kurzem wieder. Gemein-sam mit einem zweiten Entwickler sollte ein Kundenprojekt um-gesetzt werden. Der Projektumfang und die zeitlichen Rahmen-

Sybit agile | Ausgabe 8 3

bedingungen ließen es durchaus zu, in diesem kleinen Rahmen zu entwickeln. Die Frage, die sich stellte, war aber: „Macht es unter diesen Gegebenheiten Sinn, Scrum als Vorge-hensmodell einzusetzen?“

Inspect & Adapt: Verteilung der Scrum-Rollen Bekanntermaßen gibt es bei Scrum drei Rollen auszufüllen, den Product Owner, den ScrumMaster und das Team. Man muss kein mathematisches Genie sein, um zu erkennen, dass hier etwas nicht passt, denn 3 > 2. Es wurde also schnell klar, dass Inspect & Adapt in unserem Fall auch auf das Vorgehensmodell selbst anzuwenden ist. Aufgrund des Terminplans war es logisch, dass beide Mitglieder die Rolle des entwickelnden Teams einnehmen mussten. Der Luxus eines außen stehenden ScrumMasters, der selbst nicht mitentwickelt, war uns nicht vergönnt. Wir lösten dies wie folgt auf: Beide Entwickler schlüpften in die Rolle des ScrumMasters und pochten immer wieder auf die Einhaltung der Regeln. Abnahmen und Reviews wurden vom jeweils anderen aktiv ein-gefordert. Dies erforderte von beiden Mitgliedern ein hohes Maß an Disziplin.

Somit waren die Rollen des Teams und des ScrumMasters verteilt. Es fehlte nur noch die Rolle des Product Owners. Auf-grund des sehr guten Verhältnisses zum Kunden und dessen Bereitschaft, aktiv am Prozess teil zu nehmen, war es für uns naheliegend, den Kunden selbst zum Product Owner zu ernen-nen. Dieser war glücklicherweise schon mit Scrum vertraut und schätzte diese agile Arbeitsweise. Für uns eine ideale Situation. Ein besseres Feedback als durch die direkte Kopplung zum Kun-den kann man kaum bekommen.

Anpassung der Scrum-Methoden Doch alleine durch die Verteilung der Rollen ist Scrum noch lange nicht implementiert. Auch die weiteren Teile des Scrum-Frameworks müssen betrachtet werden. Die meisten Methoden und Artefakte konnten auch in dem kleinen Team unverändert übernommen werden. Wir entwickelten in zwei-wöchigen Sprints, denen jeweils eine Sprint-Planung voraus ging und ein Review sowie eine Retrospektive folgten. Es wurde ein Product-Backlog gepflegt und ein Sprint-Backlog war im Einsatz. Ledig-lich auf die Daily-Scrum-Meetings haben wir verzichtet. Sie waren einfach überflüssig, da wir an benachbarten Schreibtischen saßen und man in einem so kleinen Team sowieso permanent in Kontakt ist.

Fazit Der Einsatz von Scrum hat auch in unserem kleinen Team sehr gut funktioniert und es waren dieselben positiven Effekte zu spüren, wie sie auch in größeren Teams auftreten. Das Team war immer motiviert, es gab eine hohe Planungssicherheit und Transparenz im Projekt, der Kunde konnte frühzeitiges Feedback geben und war schließlich mit der Qualität zufrieden.

Der vermeintliche Overhead, den Scrum mit sich bringt und der oft gefürchtet wird, konnte auf ein vertretbares Maß reduziert werden und die Ergebnisse, die beispielsweise eine Sprint-Planung oder ein Review liefern, sind in kleinen Teams genauso wertvoll wie in großen. Eine besondere Herausforderung in

kleinen Teams ist es sicherlich, die Disziplin und die Einhaltung der Scrum-Spielregeln aufrecht zu halten. Insbesondere wenn es gut läuft, neigt man in kleineren Teams schneller dazu, die eine oder andere Regel zu vernachlässigen.

Es gibt also keinen Grund davor zurückzuschrecken, Scrum auch in sehr kleinen Projekten einzusetzen. Im Gegenteil, oft eigenen sich insbesondere kleinere Projekte gut dazu, Scrum kennen zu lernen, da man meist weniger Überzeugungsarbeit leisten muss. Andererseits steigen mit der Teamgröße sicherlich auch die Benefits die sich durch Scrum einstellen. Einige Randbedingungen, die im konkreten Fall sicherlich zum Erfolg beigetragen haben, will ich aber nicht unterschlagen. Zum einen war der Kunde sehr engagiert und nahm seine Rolle als Product Owner gewissenhaft wahr. Sowohl der Input zu den Sprint Plannings, wie auch die Tests und Abnahmen waren kons-truktiv und zielführend. Zum anderen hatte das Projekt mit nur vier Sprints eine sehr kurze Laufzeit, was keine Prozessmüdigkeit aufkommen lassen konnte (Stichwort Scrum-Zombies). Das Zweierteam konnte sich auch ohne ScrumMaster immer selbst an die Einhaltung der Spielregeln erinnern.

Rolf Gehring ist Projektmanager und Certified ScrumMaster (CSM) bei der Sybit GmbH. Im Bereich Media leitet er agile Festpreisprojekte für Mediatheken und Multimediaportale.

ZUM AUTOR

Rolf Gehring

Sybit agile | Ausgabe 84

© 2

011

Sybi

t Gm

bH ·

All

e R

echt

e vo

rbeh

alte

n · F

otos

:Flic

kr, F

otol

ia

Sybit GmbH Sankt-Johannis-Str. 1–5 D-78315 Radolfzell Tel. +49 (0) 7732 9508-0 info@sybit.de

Dr. Friedrich-Karl Koschnick ist promovierter Physiker. Er hat Erfahrung als Software-Entwick-ler und Entwicklungsleiter, ist CMMI-Assessor und zertifizierter ScrumMaster. Bei der Sybit GmbH ist er für das Qualitätsmanagement und für das Projekt-Controlling verantwortlich.

ZUM AUTOR

Dr. F. K. Koschnick

Wie verwalte ich meine Stories?Dr. F. K. Koschnick, Qualitätsmanagement, Sybit GmbH

Welcher Product-Owner hat es nicht schon erlebt: Man kommt an die Grenzen des Excel-Product-Backlogs beim Führen seiner Stories. Dabei geht es gar nicht so sehr um die Anzahl der Stories. Diese kann Excel zumindest bei kleinen und mittelgro-ßen Projekten gut verkraften, denn in solchen Projekten bleibt die Anzahl der Stories in der Regel zwei- oder dreistellig. Nein, es sind Dinge wie das Versionieren, die History und manchmal auch das gleichzeitige Bearbeiten des Product-Backlogs, die das Leben nicht unmöglich aber zumindest schwer machen.

Wäre die Alternative zu einem Backlog mit Excel eine Require-mentsdatenbank bzw. ein komplexes Requirements-Tool? Bei großen Projekten mit tausenden von Stories ist so eine Alter-native sicherlich sinnvoll. Bei kleinen oder mittleren Projekten jedoch wären die Kosten und der Aufwand, die man in solche Tools stecken müsste, gemessen am Projektbudget zu hoch. Im Folgenden einige Vor- und Nachteile von Excel und einem zentralen, datenbankgestützten Tool:

Vorteile von Excel: Ì Flexibilität Ì Sehr schnell und einfach zu bedienen

Nachteile von Excel: Ì Keine gleichzeitige Bearbeitung möglich Ì Gefahr von Versionenwirrwar Ì Keine Änderungshistorie

Vorteile eines zentralen Tools mit einer Datenbank: Ì Gleichzeitige Bearbeitung möglich (insbesondere, wenn auch der Kunde Zugriff haben soll) Ì Änderungs-Historie bzw. Versionierung Ì Zentrales Backup

Nachteile eines zentralen Tools mit einer Datenbank: Ì Teilweise sehr kompliziert zu bedienen Ì Es können hohe Lizenzkosten fällig werden

Fragt sich also, wie man die unbestreitbaren Vorteile von Excel mit den Vorteilen eines zentralen Tools kombinieren kann. Unsere Lösung: Man nutze Excel für die Anfangsphase des Projekts und dann einen Issue-Tracker als zentrales Product-Backlog im Projektverlauf. Die Daten müssen dann automati-siert von Excel auf das zentrale Product-Backlog übertragen werden können.

Unsere Excel-JIRA-Backlog Lösung Wir haben als Issue-Tracker den weitverbreiteten JIRA (Version 4.1) von Atlassian gewählt und diesen mit dem Plugin „Green-hopper“ für Scrum aufgerüstet. JIRA ist datenbankgestützt und unterstützt eine History. Mit dem Greenhopper-Plugin können Stories und Sprints angelegt und verschiedene Auswertungen auf der Basis von Burn-Down-Charts durchgeführt werden. Die Handhabung ist relativ einfach und ist nicht mit der Komple-xität eines schwergewichtigen Requirements-Tools behaftet. JIRA stellt einen Webservice zur Verfügung, den wir nutzen, um die Stories aus unserem Excel-Sheet zu importieren.

Unsere Vorgehensweise bei der Verwaltung von Stories geht nun in zwei Schritten vor sich:

1. In der Angebotsphase und in der frühen Phase des Projekts nach der Beauftragung wird ein Product-Backlog auf Excelbasis genutzt. In den meisten unserer Scrum-Projekte werden Stories schon in der Angebotsphase in diesem Excel gesammelt. Eine Quelle für die Stories kann beispielsweise ein Lastenheft vom Kunden sein. Für die Erstellung eines Angebots hat sich die Nutzung eines Product-Backlogs sehr bewährt. Es ist in der An-gebotsphase nicht zweckmäßig, ein Projekt in unserem Issue-Tracker anzulegen. Außerdem ist das Eintippen von Stories in Excel erheblich schneller.

2. Nach der Beauftragung und der ersten Überarbeitung der Stories werden diese aus Excel über die Webservice-Schnitt-stelle in den JIRA importiert. Dieser Vorgang kann je nach Anzahl der Stories einige Minuten dauern. Bei Importfehlern kann der Vorgang über das Excel-Product-Backlog rückgän-gig gemacht oder korrigiert werden. Nach dem erfolgreichen Import hat das Excel-Product-Backlog ausgedient. Es wird nach dem Import nur noch das Product-Backlog im Greenhopper/JIRA bearbeitet.

Übrigens finden Sie eine detaillierte Beschreibung des Excel-Product-Backlogs mit einem Link für den Download auf unserem Blog: http://blog.sybit.de/2011/02/wie-verwalte-ich-stories-2/