Kanban auf Scrum-Basis - ein Praxisbericht
Eintrag von Till am 10.11.2010
Fokussierung auf das Sprint-Ziel
ist einer der Erfolgsfaktoren von Scrum Teams. Voraussetzung hierfür ist, dass die Organisation
alle Anforderungen vor Sprintbeginn bereits kennt und deren Prioritäten für die Sprintdauer
stabil halten kann.
Die Realität
in stark business-getriebenen Organisationen sieht jedoch oftmals anders aus: Da muss beispielsweise regelmäßig im Portalbereich auf kurzfristig von Kunden beauftragte Kampagnen reagiert werden –
zeitnah und nicht erst zum Ende des folgenden Sprints. Hier würde reines Scrum unweigerlich zu Frustration auf Fach- und Entwicklungsseite führen.
Eine Lösung hierfür
kann die Kombination von Kanban und Scrum sein, wie wir sie neulich in einem Kunden-Team etabliert haben:
Am Kanban Board werden sowohl planbare Anforderungen, als auch unvorhersehbare, kurzfristig zu liefernde Anforderungen in
eigenen Swimming Lanes voneinander getrennt sichbar gemacht und getrackt.
Die Selected-Spalte für die "planbare" Swimming Lane wird alle zwei Wochen vom Product Owner befüllt
und gemeinsam mit den Entwicklern im Sprint Planning besprochen. Der Sprint-Forecast erfolgt auf Basis der Team Velocity der letzten Sprints.
Für die Selected-Spalte der "unvorhersehbaren" Swimming Lane jedoch gelten andere Regeln: neue Anforderungen hierfür müssen
im täglichen Product Owner Daily Scrum von den Stakholdern persönlich eingebracht und "verteidigt" werden. Landet danach eine solche Anforderung
tatsächlich sofort am Kanban Board, hat sie für das Entwicklungs Team oberste Priorität. Das bedeutet konkret, dass der erste
geeignete Entwickler, der frei wird, mit deren Umsetzung beginnt.
Kanban Board (Ausschnitt, vereinfacht)
Ein interessanter Effekt
nach Einführung dieses für alle Beteiligten transparenten Vorgehens für das Einsteuern unvorhersehbarer Anforderungen bestand darin, dass innerhalb weniger Sprints der Anteil
der kurzfristig beauftragten Anforderungen von anfangs über 40% auf unter 15% gesunken ist – bei erhöhter Zufriedenheit auf allen Seiten.
Hintergrundinfo zu Kanban
mit einem guten Vergleich zu Scrum von Henrik Kniberg und Mattias Skarin könnt ihr kostenlos bei InfoQ herunterladen.
Scrum begreifen mit LEGO
Eintrag von Till am 16.04.2010
Teilnehmer unserer Scrum Trainings
können nun den typischen Scrum Flow im wahrsten Sinne des Wortes begreifen.
Alles was wir hierfür brauchen, ist eine griffige Product Vision, einige LEGO Creator Packungen und gut eine Stunde Zeit.
Die Product Vision
lautet beispielsweise: Als Inselbesitzer möchte ich meine Insel bebauen.
Hieraus ergeben sich die Anforderungen: Ich benötige Schiffe und Fahrzeuge, um die Inselbaustelle zu versorgen und
für meine schnelle An- und Abreise möchte ich entsprechende Fluggeräte.
Der Product Backlog
wird anhand dieser Product Vision von den aus den Teilnehmern bestehenden Scrum Teams sebständig definiert und priorisiert.
Die Backlog Items sind unterschiedliche LEGO Creators, die aus den vorhandenen Packungen gebaut werden können.
Die Sprints
bestehen jeweils aus Sprint Planning, 5 Minuten LEGO Creators bauen, Sprint Review und Retrospective.
Durch das begleitende Erläutern der jeweils zugehörigen Scrum-Konzepte haben die Teilnehmer danach
den Scrum Flow nicht nur in der Theorie verstanden, sondern auch durch praktische Anwendung verinnerlicht.
Product- und Sprint-Backlog nach zwei Sprints
Aufgrund des positiven Feedbacks unserer Kunden
nach der Durchführung der LEGO Scrum Simulation werden wir dieses Konzept in unseren Scrum Trainings konsequent auf das Themengebiet agiles Anforderungsmanagement, -Schätzen und -Planen ausweiten.
Bumerang "messbare Mitarbeiterziele"
Eintrag von Till am 05.03.2010
Entwickelt wird in immer mehr Organisationen nach Scrum
und auch konsequent agiles Anforderungsmanagement trifft man erfreulicherweise zunehmend auch in sehr großen Projekten an. Das konsequente Leben agiler Prinzipien ist in diesen Organisationen ein wesentlicher Faktor für eine hohe Mitarbeiterzufriedenheit.
Ganz schnell vorbei mit den agilen Prinzipien
ist es dann oftmals, wenn erstmals nach der Einführung von Scrum die meist Personalabteilungs-getriebenen Mitarbeiter-Zielvereinbarungen anstehen.
Denn gerade in größeren Unternehmen hält sich hartnäckig die Mär,
man müsse den an der Softwareentwicklung beteiligten Mitarbeitern objektiv messbare Ziele mit monetärem Anreiz vorgeben, damit diese ordentlich und hart genug arbeiteten.
Dabei werden solche Ziele schnell zum Bumerang
für das Unternehmen, denn sie signalisieren den Mitarbeitern mangelndes Vertrauen und schaden der Selbstorganisation agiler Teams:
Um diese Risiken zu vermeiden,
empfiehlt es sich daher, rechtzeitig auf die Personalabteilung zuzugehen und den KollegInnen die oben aufgezeigte Problematik zu vermitteln.
Ziel sollte hierbei sein, individuelle Mitarbeiterziele zugunsten von Team- und Projekt-Zielen zu minimieren.
Idealerweise gibt es einen monatlichen Feedbacktermin zwischen Vorgesetztem und dessen Mitarbeitern, in dem ggf. auch die Ziele
der aktuellen Situation angepasst werden können.
| Messbares Ziel | Möglicher Bumerang-Effekt | |
|---|---|---|
| Velocity | => | Team schätzt tendenziell mehr Story Points, die Qualität der agilen Planung sinkt. |
| Erreichung Sprint-Ziel | => | Team plant Sprints übervorsichtig, die Produktivität sinkt. |
| Aufwand [h] / Story Point | => | Team schätzt tendenziell mehr Story Points und plant Sprints übervorsichtig. |
| Anzahl Bugs in Produktion | => | Team testet mehr, als nötig wäre, um gesteckte Qualitätsziele zu erreichen - zu Lasten neuer Funktionalität |
Mike Cohn – Succeeding with Agile
Eintrag von Till am 20.11.2009
Wo andere Werke zu Scrum oftmals aufhören
fängt Mikes neuestes Werk erst so richtig an. Es sollte in der Tat, wie Tim Lister in dessen Vorwort treffend bemerkt, zu einer Art "Hudson Bay Start" werden für jedes agile Projekt!
Ein Buch aus dem realen Leben
ist Succeeding with Agile, in dem ich mich mit meinen eigenen Erfahrungen und alltäglichen Herausforderungen wiederfinde. Auch wirklich knifflige Probleme werden detailliert behandelt und differenziert mit konkreten Lösungsvorschlägen unterlegt - die sich übrigens allesamt in mindestens einer Situation in Mikes Tätigkeit als Scrum Coach bewährt haben.
Das Fehlen euphorischer Lobpreisungen auf Scrum
fiel mir besonders positiv auf. Mike macht statt dessen unmissverständlich klar, dass zu einer Transition von einer klassischen hin zu einer agilen
Entwicklungsorganisation weit mehr gehört, als das Einhalten der Scrum Regeln: "Changing practices is one thing; changing minds is quite another".
Das wirklich besondere
an Succeeding with Agile: Es macht Mut - trotz der zahlreichen Fallstricke, die es aufzeigt! Anstelle Ken Schwabers dogmatischem "Don't change Scrum" Ansatz stellt Mike treffend fest: "there can be no end state in a process that calls for continuous improvement".
Für mich ist Succeding with Agile ein wahres Meisterwerk von einem Mann der Praxis.
Team Velocity vergleichen – eine gute Idee?
Eintrag von Till am 07.10.2009
Auf den ersten Blick bestechend
scheint die Möglichkeit, agile Teams untereinander anhand deren Velocity zu vergleichen und zu messen –
sind doch Vorgesetzte in großen Unternehmen oftmals auf der Jagd nach messbaren Größen für die dort zunehmend unvermeidlichen Mitarbeiter-Zielvereinbarungen.
Als absolut kontraproduktiv
und nicht nachhaltig stellt sich das Aufbauen von Druck über einen Velocity-Vergleich jedoch auf den zweiten Blick heraus.
Die Team-Velocity ist nämlich definiert durch die Anzahl Story Points, die das Team pro Sprint liefert, wobei
nur User Stories, also unmittelbar wertschöpfende, neue System-Funktionalitäten in Story Points zu schätzen sind.
Jede Investition eines agilen Teams in die essentielle Optimierung
der Entwicklungsprozesse und in Re-factoring würde dieses eine Team im Velocity-Vergleich folglich schlechter stellen.
Der Effekt liegt auf der Hand: die Bereitschaft der einzelnen Teams, in nachhaltige Entwicklung zu investieren,
sinkt – zum Nachteil der gesamten Entwicklungs-Organisation.
Ohne Velocity-Vergleich
lässt man der Selbstorganisation zwischen den Teams den notwendigen Freiraum.
Hierbei können sich sogar einzelne Teams herauskristallisieren, die besonderen Wert auf Verbesserungsmaßnahmen
im Sinne nachhaltiger Entwicklung legen und daher meist eine niedrigere Velocity erreichen
– zum Vorteil der gesamten Entwicklungs-Organisation.
Erfolgreiches Nearshoring mit "Integrated Scrum"
Eintrag von Till am 16.05.2009
Keinen Pfifferling verwettet
hätte ich bis vor kurzem auf den Erfolg eines beispielsweise zwischen München und Minsk verteilten Softwareprojekts
in einem komplexen und dynamischen Businessumfeld!
Entsprechend skeptisch war ich auch, als Jeff Sutherland auf dem 2008 Stockholm Scrum Gathering eine
Erfolgsstory mit mehreren Dutzend weltweit verteiten Scrum Teams vorstellte.
Trotz meiner Zweifel
packte mich der Ehrgeiz, als ich vor drei Monaten von einem Kunden gefragt wurde, ob ich nicht Lust hätte,
als Scrum Master ein Nearshoring Scrum Team aufzubauen. Die Beweggründe seitens des Kunden hierfür lagen in
der Hoffnung, die Entwicklungs-Organisation mit mehreren bestehenden Scrum Teams, die wir im letzten Jahr aufgebaut hatten,
bei Bedarf schnell und kostengünstig skalieren zu können. Schnell war uns klar, dass hierfür nur der von Jeff vorgestellte
"Integrated Scrum" Ansatz in Frage kam. Gesagt – getan starteten wir umgehend das Staffing über einen weißrussischen
Software Dienstleister.
Verblüfft auf der ganzen Linie
bin ich nach nunmehr einigen Sprints mit unserem deutsch-weißrussischen Scrum Team:
Zum einen darüber, dass dieses verteilte Team nach nur einer Woche Einarbeitung bereits im ersten Sprint
rund 70% der Produktivität der co-located Münchner Scrum-Teams an den Tag gelegt hat – mit seither steigender Tendenz.
Zum anderen, weil sich die Durchführung der verteilten Scrum Meetings als wesentlich einfacher als zuvor angenommen
herausgestellt hat.
Der Schlüssel zum Erfolg
mit unserem verteilten Scrum Team liegt aus meiner Sicht unter anderem in den folgenden Punkten:
Meinen Wetteinsatz
auf den Erfolg eines zwischen München und Minsk verteilten Softwareprojekts in einem komplexen und dynamischen Businessumfeld würde ich
mittlerweile natürlich deutlich erhöhen – die Beachtung der oben beschriebenen Erfolgsfaktoren vorausgesetzt!
- Etablierte, professionelle Scrum Entwicklungs-Organisation auf Auftraggeberseite bereits vor dem Start dieses Experiments
- Hartes Auswahlverfahren für alle Teammitglieder hinsichtlich social Skills, technischer Expertise und Englisch-Kenntnissen
- In den ersten beiden Wochen komplettes Team in München, um optimale Einarbeitung sicher zu stellen und persönliche Beziehungen aufbauen zu können
- Während der ersten Woche intensive Einführung in Architektur und Source Code
- Eintägiges Scrum Training für die zuvor Scrum-unerfahrenen neuen KollegInnen
- "Integrated Scrum" Ansatz, bei dem erfahrene Team Mitglieder von München aus mit den Minsker Nearshoring Team Mitgliedern in einem verteilten Scrum Team zusammenarbeiten
- Fortlaufend rotierender Besuch von Minsker Teammitgliedern in München
- Sämtliche Scrum Meetings werden gemeinsam über Video-Skype durchgeführt, wobei auf Meetingdisziplin noch mehr als sonst zu achten ist
- Skype für Voice und Chat auf allen Computern der Teammitglieder, um Kommunikationshürden zwischen den Daily Scrums minimal zu halten
- Zur Verfügung stellen komplett eingerichteter Entwickler-Laptops für alle Minsker Team Mitglieder
- Deutschsprachige Projekt-Koordinatorin des Nearshoring Dienstleisters auf Minsker Seite als zentrale Ansprechpartnerin für übergreifende Themen
Meinen Wetteinsatz
auf den Erfolg eines zwischen München und Minsk verteilten Softwareprojekts in einem komplexen und dynamischen Businessumfeld würde ich
mittlerweile natürlich deutlich erhöhen – die Beachtung der oben beschriebenen Erfolgsfaktoren vorausgesetzt!
redQueen Planning Poker Karten
Eintrag von Till am 02.02.2009
Agiles Schätzen
basiert auf der Erkenntnis, dass Schätzungen durch das Entwicklungsteam genauer sind, als Schätzungen einzelner.
Eine clevere und beliebte Methode für's Schätzen im Team ist das von Mike Cohn erfundene Planning Poker: Jedes Teammitglied hält
verdeckt ein Kartendeck mit Schätzzahlen. Nachdem die zu schätzende User Story vorgestellt
und kurz inhaltlich im Team diskutiert wurde, zeigen auf Kommando alle gleichzeitig jeweils eine Karte mit ihrer
individuellen Schätzung. Hierdurch ist gewährleistet, dass jede einzelne Schätzung unbeeinflusst erfolgt.
Die beiden Teammitglieder mit der höchsten und der niedrigsten Schätzung verteidigen nun ihre Schätzungen.
In der nächsten Pokerrunde werden sich die Schätzungen annähern und das Team einigt sich auf eine konkrete Schätzzahl.
Gepokert wird nicht um Manntage,
sondern um Story Points – die relative Größe einer User Story. Um den mit größer werdenden User Stories
zwangsläufig auch ungenauer werdenden Schätzungen Rechnung zu tragen, sind die Werte der Planning Poker Karten
an die Fibonacci Folge angelehnt und tragen die Werte 0, 1, 2, 3, 5,
8, 13, 20, 40, 100 und ?. 0 Story Points werden
für User Stories vergeben, die keinen oder nahezu keinen Aufwand für das Entwicklungsteam bedeuten. Für den Fall,
dass ein Teammitglied keine Ahnung von der Größe hat, oder die Größe 100 übersteigt,gibt es noch die ?-Karte.
Meist deuten Werte größer 20 darauf hin, dass die User Story in mehrere kleinere, besser schätzbare aufgeteilt werden sollte.
redQueen Planning Poker Karten
sind auch in großen Sitzungsräumen von weitem erkennbar und zeichnen sich durch weitere, praktische Details aus.
redQueen Kunden erhalten das Kartenspiel mit 5 Decks à 11 Karten auf Anfrage gratis und allen weiteren
Interessenten senden wir es gerne zum aktuellen Selbstkostenpreis zu!
Gepokert wird nicht um Manntage,
sondern um Story Points – die relative Größe einer User Story. Um den mit größer werdenden User Stories
zwangsläufig auch ungenauer werdenden Schätzungen Rechnung zu tragen, sind die Werte der Planning Poker Karten
an die Fibonacci Folge angelehnt und tragen die Werte 0, 1, 2, 3, 5,
8, 13, 20, 40, 100 und ?. 0 Story Points werden
für User Stories vergeben, die keinen oder nahezu keinen Aufwand für das Entwicklungsteam bedeuten. Für den Fall,
dass ein Teammitglied keine Ahnung von der Größe hat, oder die Größe 100 übersteigt,gibt es noch die ?-Karte.
Meist deuten Werte größer 20 darauf hin, dass die User Story in mehrere kleinere, besser schätzbare aufgeteilt werden sollte.
redQueen Planning Poker Karten
sind auch in großen Sitzungsräumen von weitem erkennbar und zeichnen sich durch weitere, praktische Details aus.
redQueen Kunden erhalten das Kartenspiel mit 5 Decks à 11 Karten auf Anfrage gratis und allen weiteren
Interessenten senden wir es gerne zum aktuellen Selbstkostenpreis zu!
Sprint Review: Vorsicht Falle!
Eintrag von Till am 21.01.2009
Im Sprint Review Meeting
führt das Scrum Team am Ende jedes Sprints dem Product Owner und weiteren Stakeholdern die neu entwickelte,
lauffähige Software vor. Die Vorbereitungszeit für diese Demo sollte zwar auf ein Minimum beschränkt werden.
Dennoch gilt es für das Scrum Team, einen professionellen Eindruck zu vermitteln und die zahlreichen Stolperfallen
wie etwa die folgenden zu vermeiden:
- System läuft nicht, weil vergessen wurde, dem Rest des Unternehmens aufgrund der bevorstehenden Demo Wartungsarbeiten am System zu untersagen
- Entwickler führt unglaublich schnell durch das System und vergisst vor lauter Konzentration, seinen Zuhörern mitzuteilen, was er da überhaupt tut
- Entwickler zeigt zunächst zügig die von ihm selbst entwickelte Funktionalität, gerät dann aber ins Stocken, weil er den dahinter liegenden, von einem anderen Teammitglied entwickelten Teil zuvor noch nie gesehen hat
Stockholm Scrum Gathering 2008
Eintrag von Till am 22.10.2008
Mit viel frischem Wind
kommen zwei Führungskräfte eines Kunden und ich zurück vom Stockholm Scrum Gathering.
Und frischer Wind tut jedem gut, der gerade eine komplette Entwicklungs-Organisation mit zahlreichen Teams
erfolgreich von Waterfall auf Scrum umgestellt hat und nun noch einige wirklich knifflige Herausforderungen lösen will.
Stockholm lockt mit vielfältigen Reizen
Dass sogar 35 Scrum Teams
erfolgreich zusammenarbeiten können, haben zwei Salesforce.com Mitarbeiter in einer sehr eindrucksvollen Präsentation
gezeigt.
Wie kann man innerhalb weniger Monate ein Wasserfall-getriebenes Unternehmen dieser Größe erfolgreich auf Scrum umstellen?
Nur mit absoluter Konsequenz, und dazu gehört auch das Buy-in der Unternehmensspitze von Anfang an. Und mit cleveren Moderationsmethoden,
um den selbstorganisierenden Informationsfluss zwischen allen Unternehmensbereichen zu unterstützen. So führt Salesforce
das Scrum of Scrums in Form von Open Space Sessions durch. Doch schaut euch die Slides selbst an, sie enthalten einige sehr wertvolle Einsichten!
Open Space Sessions
gaben den Rahmen für den zweiten Tag des Scrum Gatherings. Rund 500 Teilnehmer verteilten sich selbstorganisierend auf ebenfalls von Teilnehmern eingebrachte
Themen rund um Scrum. Wir moderierten eine bunt zusammengewürfelte, internationale Gruppe zum Thema "Wie sichern wir uns nachhaltige Unterstützung
im agilen Vorgehen seitens der Fachbereiche". Und auch hier zeichnete sich die selbe Erkenntnis ab, wie in der oben genannten Salesforce Präsentation:
Trainiere die Product Owner und deren Teams frühzeitig, intensiv und auf breiter Front!
Konferenzteilnehmer bringen ihre Themen in den Open Space
Nicht fehlen durften natürlich
die wie gewohnt mit unmissverständlichen Worten gesprochenen Vorträge der Scrum-Erfinder Jeff Sutherland und Ken Schwaber. Hier fiel u.a. die
von den beiden sehr hoch aufgehängte Messlatte für zu erwartende Effizienz-Steigerungen durch die Umstellung auf Scrum auf. Demnach sind
bis zu 30% Effizienzsteigerung am unteren Rand anzusiedeln ("Scrum Butts"), das ehrgeizige Ziel liegt jedoch bei nicht weniger als 400% ("Excellent Scrum").
Ken und Jeff beziehen Stellung zu Teilnehmerfragen
Zum Thema Scrum 2.0 gab es von Ken eine klare Abfuhr: "Don't change Scrum"! Aus der Erfahrung mit dem RUP, der auch einst angetreten war,
den Waterfall Approach abzulösen und in einem noch teureren, artefaktgetriebenen Prozess endete, habe man gelernt und Scrum bewußt leichtgewichtig gehalten.
Genau darin liege die Stärke von Scrum!
Mit Henrik Kniberg (Scrum and XP from the Trenches)
haben wir in dessen gelungener Session zum Thema Multi Team Sprint Planning angeregte Diskussionen geführt und fanden interessante Parallelen
zu meinen eigenen Erfahrungen (s. auch meinen Eintrag zum Thema vom 24.09.2008).
Stockholm ist ganz nebenbei bemerkt
eine geniale Stadt, die auch kulinarisch, architektonisch, kulturell und landschaftlich sehr viel zu bieten hat. Dieser Verantstaltungsort, gepaart mit interessanten Sessions
und vielen interessanten Gesprächen haben das Scrum Gathering 2008 für mich überaus lohnenswert gemacht und ich werde auf jeden Fall versuchen, beim nächsten europäischen Gathering
wieder dabei zu sein!
Merkmale erfolgreicher Scrum-Teams
Eintrag von Till am 12.10.2008
Idealerweise ist ein Scrum-Team Cross-functional
und interdisziplinär. Nur dann ist es autark in der Lage, am Ende des Sprints ein Stück
getestete und lauffähige Software zu liefern. Cross-functional bedeutet,
dass in einem Scrum-Team Know-how für allen beteiligten Technolgien (z.B. Java, SQL-Datenbanken, Siebel CRM, usw.)
sowie der Software-Module (Front-End, Middle-tier, Datenbank, usw.) vorhanden ist.
Interdisziplinär bedeutet, dass Analyse-, Architektur-,
Entwicklungs- und QA-Skills im Team vertreten sein müssen und auch nicht-funktionale Anforderungen wie z.B.
operational Requirements vom Team verstanden und implizit berücksichtigt werden.
Die oftmals übliche Unterteilung
der Teams nach Technologien bzw. Software-Modulen bei der Einführung von Scrum beizubehalten,
ist eine der sichersten Methoden für den Misserfolg!
Denn kein Scrum-Team kann hier ohne Abhängigkeiten zu den anderen Teams sein Sprint-Ziel erreichen,
Eskalationen und Schuldzuweisungen zwischen den Teams sind vorprogrammiert.
Skill-Schwerpunkte
sind natürlich auch in Cross-functional Scrum-Teams erlaubt und unverzichtbar. Doch jedes Team-Mitglied
muss bereit sein, auch Aufgaben ausserhalb seines Skill-Schwerpunkts zu übernehmen.
Zugegebenermaßen kann die
von vielen nicht-agilen Entwicklungsorganisationen forcierte Spezialisierung der Mitarbeiter ein ernsthaftes Problem
beim Wechsel auf Cross-functional Teams darstellen.
Reine Datenbank-Entwickler beispielsweise tun sich unter Umständen
schwer, von heute auf morgen den Java-Experten unter Beachtung der vewendeten Design-Patterns kompetent zu Hand zu gehen.
Zugleich fürchten diese Kollegen vielleicht Manipulationen an "ihrem" Datenbankschema durch vermeintlich
in Sachen Datenbanken inkompetente Java-Entwickler.
Vertrauen in die Selbstorganisation
von Scrum-Teams ist auch hier wieder einmal der Schlüssel zum Erfolg. Voraussetzung für das Gelingen ist wohlgemerkt
ein hohes Skill-Niveau und die Bereitschaft aller Scrum-Team Mitglieder, den bisherigen Horizont zu erweitern.
Doch Organisationen, deren Mitarbeiter diese Eigenschaften nicht erfüllen, hatten schon zuvor ein ernsthaftes
Problem und sollten sich vielleicht auf den Grundsatz weniger ist mehr besinnen.
Gleichzeitig gilt nach meiner Erfahrung, dass in einem Scrum-Team der Know-how Transfer sprunghaft ansteigt:
Die konsequente Betonung des Team-Ergebnisses anstatt der Leistung einzelner fördert implizit die
Unterstützung schwächerer Kollegen im Team!
Anmerkung: All das ist natürlich noch lange kein Garant für eine gute und konsistente
Architektur bei parallel an einem Software-Produkt arbeitenden Scrum-Teams. Wie sich diese
Anforderung bewerkstelligen läßt, werde ich demnächst in einem eigenen Blog-Eintrag beleuchten.
Zwei typische Beispiele
aus meiner Praxis bei der Umstellung ehemals nach Software-Modulen getrennter Teams
zu Cross-functional Teams sollen euch Mut machen,
auch in eurer Organisation neue Wege zu gehen:
Ein Datenbank-Experte ohne Java Know-how befürchtet
zunächst, nicht ausreichend ausgelastet zu sein. Auf mein Nachfragen erfahre ich, dass die Datenbank-seitigen Aufwände
in letzter Zeit ohnehin rückläufig waren. Eine berechtigte Befürchtung also, die jedoch nicht auf Scrum und die Umstellung auf
Cross-functional Teams zurückzuführen ist, sondern auf die aktuelle Enterprise-Architektur. Da mir die Social-Skills und Pro-Aktivität des betreffenden Kollegen auffallen,
schlage ich ihn als Scrum-Master vor. "Sein" Team legt daraufhin vom ersten Sprint an eine hohe
Velocity an den Tag und die wenigen anfallenden Datenbank-Aufgaben können zusätzlich zu seiner Scrum-Master Rolle von ihm übernommen werden.
Eine QA-Expertin sieht anfangs keine Aufgaben zu Beginn des Sprints – schließlich gibt es da noch nichts zu testen.
Doch schon nach kurzer Zeit erkennt das Team Ihre analytischen Fähigkeiten und sie übernimmt fortan die funktionale
Feinabstimmung mit dem Product Owner jeweils nach Sprint-Beginn. Bis dann noch die Testfälle mit Unterstützung der
Java-Entwickler im Team definiert wurden, sind die ersten User Stories bereits umgesetzt und können nahtlos getestet werden.
Die Auslastung der Team-Mitglieder
liegt auch im besten Cross-functional Scrum-Team weder bei konstanten 100%, noch ist sie perfekt gleichmäßig verteilt.
Sollte wirklich einmal für ein Team-Mitglied zu wenig oder zu viel Arbeit anfallen,
kommt das aber beim Daily Scrum zur Sprache und das Team überlegt sich gemeinsam eine Lösung.
Machen wir uns nichts vor:
Kein noch so genialer Projektmanager im nicht-agilen Projektumfeld vermag seine Teams
konstant und völlig gleichmäßig auszulasten. Nur bekommt er das oftmals nicht mit,
weil die Quote an Mitarbeitern nicht-agiler Teams, die sich vor Ablauf der ihnen für die
Erledigung Ihrer Aufgabe zugedachten Zeit freiwillig für mehr Arbeit melden,
eher gering ist (s. auch Parkinson's Law).
In solchen Teams gibt es keinen selbsorganisierenden Faktor –
schließlich ist das Planen und Organisieren dort der Job des Projektmanagers!
Wie Themen auf mehrere Scrum-Teams verteilen?
Eintrag von Till am 24.09.2008
Die Antwort auf diese rhetorische Frage
kann im agilen Kontext selbstverständlich nur lauten: "Durch die Scrum-Teams selbst"!
Alternativ können auch der Product Owner und die Scrum Master
vor dem Sprint Planning versuchen, die vermeintlich optimale Themen-Team Zuordnung vorzunehmen,
doch werden sie dabei kaum so clever sein, wie alle Scrum-Teams zusammen.
Zudem vermittelt diese Vorgehensweise den Scrum-Teams das Gefühl, Themen "von oben" verordnet zu bekommen,
was dem Prinzip der Selbstorganisation widerspricht.
Ganz ohne Chaos
und weitgehend selbstorganisierend lassen sich Themen mit folgendem Ansatz
sogar auf drei oder mehr gemeinsam an einem Product Backlog arbeitende Scrum-Teams verteilen:
Voraussetzung ist die Bündelung inhaltlich verwandter User Stories zu Themen. Das Sprint Planning
startet mit allen Teammitgliedern in einem ausreichend großen Raum (vielleicht gibt es ja einen Clubraum?) und der
Product Owner stellt die am höchsten priorisierten Themen kurz vor. Danach geben wir jedem Scrum-Team 10 Minuten Zeit
zur Identifikation der Themen, die es gerne umsetzen würde. Die Teams besprechen dabei intuitiv die für das jeweilige Thema benötigten Skills
und werden sich dieses nur dann zuordnen, wenn sich sich ihm gewachsen fühlen.
Nun entsendet jedes Scrum-Team ein bis zwei Mitglieder, womit wir bei 3 Scrum Teams eine Runde von maximal 6 Personen haben.
Moderiert von einem der Scrum-Master stellen nun die Team-Delegierten in einer Timebox von 20 Minuten ihre Themenwahl vor,
eventuelle Überschneidungen und Konflikte werden diskutiert und aufgelöst.
Die restlichen Teammitglieder dürfen zuhören, aber nicht an der Diskussion teilnehmen (!).
In nur 30 Minuten
haben wir bei dieser Vorgehensweise eine für alle Team-Mitglieder transparente Themenverteilung und
jeder kennt das gesamte Themenspektrum aller Teams. Da typischerweise nicht in jedem Sprint alle Themen
neu sein werden, reduziert sich die benötigte Zeit oftmals auf weniger als 20 Minuten.
Danach gehen die Scrum-Teams einzeln zu ihren Scrum-Wänden, besprechen die User Stories ihrer Themen im Detail
mit dem Product Owner bzw. den Business Stakeholders und definieren schliesslich den Sprint Backlog.
Update vom 10.10.2008
Bei neuen und unerfahrenen Scrum-Teams kann es durchaus hilfreich sein und halte ich es für legitim,
wenn die Scrum Master im Vorfeld auf Themenebene die erforderlichen Skills
und deren ungefähre Verteilung auf den Gesamtaufwand grob analysieren und ggf. mit (verhandelbaren!)
Vorschlägen für die Themen-Team Zuordnung ins Sprint Planning starten.
User Role Modelling vor dem Schreiben der User Stories
Eintrag von Till am 05.09.2008
Beste Erfahrungen mache ich seit langem
mit dem User Story Template
Als <Benutzer> möchte ich <Aktion>, damit <Grund für Aktion>
Die guten Gründe für die Verwendung dieses Templates erklärt Mike Cohn auf sehr anschauliche Weise in seinem Blog.
Damit das auch wirklich gut funktioniert, gilt es jedoch vor dem erstmaligen Erfassen von User Stories, die Benutzer-Rollen sorgfältig zu definieren.
Für User Stories geeignete Benutzerrollen
könnten bei einem Web-System beispielweise Web-Shop Kunde, aber auch interne System-Benutzer wie Content Management System Benutzer sowie Reporting-Benutzer sein.
Eine mögliche User Story wäre hier zum Beispiel:
[1] Als Web-Shop Kunde möchte ich mit Kreditkarte bezahlen können, damit meine Bestellung schnellst möglich versendet werden kann
Einmal hatte ich den Fall,
dass ein sehr großes Fachseiten-Team ohne vorheriges User Role Modelling
zahlreiche User Stories niedergeschrieben hat. Dabei kamen viele Benutzer-Rollen ins Spiel, die teilweise zu nicht wünschenswerten User Stories führten, z.B.:
[2] Als Finanzverantwortlicher möchte ich, dass beim Kauf im Web-Shop die Gültigkeit der Kreditkarte geprüft wird
Während die Information, dass nur gültige Kreditkarten aktzeptiert werden sollen, durchaus wertvoll ist, wurde hier offenbar der Anforderer (Finanzverantwortlicher)
mit dem Benutzer (Web-Shop Kunde) verwechselt. Oder soll die Gültigkeit der Kreditkarte etwa nur dann geprüft werden, wenn der Finanzverantwortliche selbst im Web-Shop einkauft?
Eine bessere Möglichkeit
für eine User Story wäre in diesem Fall:
[3] Als Web-Shop Kunde möchte ich, dass die Gültigkeit meiner Kreditkarte online geprüft wird, damit ich bei Nichtgültigkeit eine alternative Zahlungsmethode angeben kann
In den meisten Fällen lassen sich Anforderungen auf diese Weise in gute User Stories gießen.
Alternativ hierzu können Anforderungen, für die unser Template nicht so recht passen mag, einfach als Constraint an die zugehörige User Story angehängt werden.
Wäre eine online-Prüfung der Kreditkarte und damit User Story [3] in unserem Beispiel technisch nicht möglich, dann würde ich als Contraint zu User Story [1] vermerken:
[1-c1] Die Gültigkeit der Kreditkarte muss vor dem Versand geprüft werden
Daraus ergäbe sich eine weitere User Story, womit sich der Kreis schliessen würde:
[4] Als Web-Shop Kunde möchte ich per eMail benachrichtigt werden, wenn die nachgelagerte Gültigkeitsprüfung meiner Kreditkarte negativ war, damit ich erneut mit einer alternativen Zahlungsmethode bestellen kann
Gerade bei der Neueinführung
agilen Anforderungsmanagements achte ich seit dieser Erfahrung besonders darauf, zu allererst ein User Role Modelling Workshop mit allen Beteiligten
durchzuführen. Danach sollten neue Benutzer Rollen nur nach erneuter Absprache im Fachseiten-Team hinzugefügt werden,
um jeglichem Wildwuchs vorzubeugen und identische Benutzer-Rollen über den gesamten Product Backlog konsistent benannt zu haben.
Plädoyer für Scrum-Zettelwände
Eintrag von Till am 12.08.2008
Die Definition des Sprint Backlog
ist ein für alle Beteiligten äußerst anstrengendes Unterfangen. Bei einer Sprintlänge von zwei Wochen
dauert das Herunterbrechen bereits verstandener User Stories in Tasks und das Schätzen der Tasks auf
Stundenbasis zwischen 2 und 3 Stunden. Oft geht diesem Sprint Planning 2 noch ein 2-stündiges
Sprint Planning 1 voraus, in dem die User Stories zwischen Team und Product Owner diskutiert
und auf Basis von Story Points geschätzt werden.
Ein elektronischer Sprint Backlog
scheint hierbei auf den ersten Blick verlockend. Gängige Scrum Tools bieten eine nahtlose Integration von
Product Backlog, Sprint Backlog mit einzelnen Tasks samt Aufwands-Tracking bis hin zu vielfältigen
Reporting Funktionen wie z.B. automatisch generierten Burn-down Charts. Und verteilten Scrum-Teams (die es jedoch,
wenn möglich, zu vermeiden gilt) erleichtern derartige Tools den Informationsaustausch ungemein.
Im Meeting sitzt jedoch häufig
ein Team-Mitglied hinter dem Laptop und ist weitgehend in die Bedienung des Tools vertieft.
Das restliche Team sitzt bevorzugt mit Blick in Richtung der Projektionsfläche des Beamers und klinkt sich
aufgrund akuter Müdigkeit immer wieder mental aus. Die für das Sprint Planning so wichtigen Diskussionen zwecks
gemeinsamem Verständnis der Tasks, deren geschätzten Aufwänden und des zugrunde liegenden Designs kommen
nicht so recht in Gange. Im darauf folgenden Sprint müssen schließlich regelmäßig vergessene Tasks hinzugefügt und
Schätzungen nach oben korrigiert werden, was zuletzt zum Verfehlen des Sprint Goals führen kann.
Ganz anders bei einer Scrum-Zettelwand,
denn da läuft das Sprint Planning 2 ungefähr so: Teammitglieder schreiben die User Stories auf große Karten
und hängen diese an die Scrum-Wand. Alle stehen im Halbkreis zusammen und wem ein Task einfällt, der darf ihn selbst auf
einen Post-it schreiben und dazuhängen. Die Team-Mitglieder haben Blickkontakt zueinander und als Scrum Master
habe ich es wesentlich leichter, das ganze Team in die Diskussion einzubeziehen.
Typische Scrum-Wand mit Tasks für einen zwei-wöchigen Sprint
Auch in den Daily Scrum Meetings
bietet diese von Unwissenden oft belächelte "Zettelwirtschaft" die selben Vorteile: Jedes Teammitglied hängt
seine Tasks selbst von "New" über "In Progress" nach "Done" bzw. trägt die verbleibenden Restaufwände ein.
Und da alle stehen, kann auch keiner der Kollegen während des Meetings heimlich weiterprogrammieren ;-)
Mein Credo
lautet daher ganz klar: Lasst euch die unschlagbaren Vorteile der hoch kommunikativen Scrum-Zettelwand nicht entgehen!
Wenn ihr auf einen elektronischen Sprint Backlog nicht verzichten könnt, dann würde ich auf jeden Fall den Mehraufwand
einer "doppelten Buchführung" in Kauf nehmen.
Product Backlog oberste Priorität beim Scrum Set-up
Eintrag von Till am 29.07.2008
Ist die Entscheidung für Scrum gefallen
und die Personalfrage für die Scrum-Rollen Product Owner, Scrum Master und Team geklärt,
stellt sich die Frage, welches der nun anstehenden Themen wir nun mit oberster Priorität angehen.
Vor dem Aufsetzen der obligatorischen Scrum-Meetings
widme ich mich erstmal voll und ganz dem Product Owner und unterstütze ihn mit Rat und Tat beim Aufsetzen des Product Backlog.
Von der initialen Qulität des Product Backlog hängt nämlich der gesamte Verlauf der weiteren Scrum-Einführung ab! Qualität heißt
hier konkret: Die Backlog-Items sind in Form von User Stories formuliert und nach Geschäftswert priorisiert.
Außderdem achte ich auf einen Mindestfüllstand, damit dem frisch gebackenen Scrum Team nicht gleich nach den ersten Sprints
die Arbeit ausgeht (ja, das habe ich tatsächlich schon erlebt!).
Beim Schreiben der User Stories
lasse ich den Product Owner zunächst nicht allzu weit in's Detail gehen. Sobald die Vision im Product Backlog klar erkennbar ist,
beginnen wir sofort mit den sogenannten Product Backlog Groomings, in denen das Scrum Team mit dem Product Owner über jede einzelne
User Story spricht, bis ein gemeinsames Verständnis über die angeforderten Funktionen erlangt wurde.
Sehr große User Stories – die sogenannten Epics – brechen wir direkt im Meeting auf kleinere Stories herunter,
bis deren Größe vom Team geschätzt werden kann und die Umsetzung jeder einzelnen Story nicht länger als ein paar Tage dauert.
Nun ist der erste praktische Schritt zur Scrum-Einführung vollzogen und wir können uns in den ersten Sprint stürzen!
