Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Agile Methoden im Projektmanagement – vom ersten Versuch bis hin zur Scrum-Zertifizierung

In den letz­ten Jahren hal­ten agile Methoden immer mehr Einzug in den täg­li­chen Projektalltag. Die Motivation dahin­ter sind eine ver­bes­serte und kos­ten­güns­ti­gere Projektabwicklung sowie zufrie­de­nere Kunden und moti­vier­tere Mitarbeiter.

Das klingt alles wun­der­bar, aber ist dem wirk­lich so? In die­sem Blogartikel möchte ich meine Erfahrungen mit der agi­len Methode „Scrum“ mit euch tei­len und freue mich natür­lich über eure Erfahrungen, die ihr mir gern in den Kommentaren mit­tei­len könnt. Auf eine kon­krete Erklärung, wie Scrum funk­tio­niert, möchte ich an die­ser Stelle ver­zich­ten, dazu fin­det man eine Vielzahl von guten Artikeln im Netz.

Agile – meine ersten Versuche anno 2012

Im Team hat­ten wir alle schon ein­mal von Scrum gehört: Einfache Regeln, wenige Rollen, kurze Feedback-Zyklen, Selbstorganisation und noch wei­tere Charakteristika, die sich bis dahin alle sehr gut anhö­ren. Nun woll­ten wir dies auch in einem über­schau­ba­ren Projekt mal selbst ausprobieren.

Vor drei Jahren konn­ten wir mit Einverständnis des Kunden das erste agile Projekt star­ten. Wichtige erste Erfahrung – der Kunde muss an Board geholt und zuge­stimmt haben, denn wir agie­ren beim Scrum etwas anders als im klas­si­schen Wasserfallmodel. Einerseits gibt es ein sehr viel höhe­res Maß an Transparenz, auf das sich das Projektteam und auch der Kunde ein­las­sen muss. Andererseits ist der Austausch mit dem Kunden wäh­rend des gesam­ten Projektes viel enger und regel­mä­ßi­ger – also nicht nur zum Projektbeginn – wodurch wir zwin­gend einen Ansprechpartner beim Kunden benö­ti­gen, der auch Zeit für unsere Fragen hat.

Nach ein paar klei­nen Vorbereitungen konn­ten wir in den ers­ten Sprint star­ten. Unsere Stories und Aufgaben für die lau­fen­den Sprints haben wir eif­rig auf Klebezetteln notiert und an ein Sprintboard an die Wand in unse­rem Projektzimmer geklebt (eine Methode, die in vie­len Projektteams immer noch Gang und Gebe ist). Später sind wir dazu über­ge­gan­gen, zumin­dest die Stories sau­ber auf klei­nen Zetteln aus­zu­dru­cken und an das Sprintboard zu hef­ten. Die Burndown Charts wur­den ebenso wie die Sprintboards im Projektzimmer an die Wand gemalt. So hat­ten wir immer einen Überblick, wie es um den aktu­el­len Sprint steht. Das alles war neu und immer auf­re­gend. Jeder freute sich, wenn er wie­der eine Aufgabe am Sprintboard einen Arbeitsschritt wei­ter­kle­ben durfte.

Burndown Chart - Sprint 8

Nach jedem Sprint wer­den dem Kunden die Ergebnisse prä­sen­tiert (Sprint-Review). Hier wurde schon nach den ers­ten Sprints ein gro­ßer Vorteil unse­res neuen Vorgehens deut­lich: Der Kunde konnte uns direkt eine Rückmeldung zum prä­sen­tier­ten Stand der Entwicklung geben. Damit haben wir schon sehr früh erken­nen kön­nen, ob die Akzeptanz der Endnutzer vor­han­den ist und sich damit ein Projekterfolg andeu­tet – nicht erst am Ende der Umsetzung wie beim klas­si­schen Vorgehen.

Da der Kunde nicht immer bei uns vor Ort sein konnte, zeig­ten sich schnell ein paar klei­nere Herausforderungen. Wir muss­ten für unsere Sprint-Reviews dem Kunden Fotos unse­res Sprintboards sowie des Burndown Charts schi­cken. Das war gar nicht so ein­fach, da der Kunde im Sprint-Review mög­lichst den letz­ten Stand sehen sollte. So muss­ten wir kurz vor Beginn des Meetings (oder auch mal wäh­rend des Reviews) die Fotos erstel­len und versenden.

Die Schattenseiten von Klebezettel und Whiteboard

Die Motivation im Team war groß und auch der Kunde hatte schnell die Vorteile erkannt:

  • direk­tes Feedback wäh­rend der Entwicklung
  • schnelle Umsetzung der Anmerkungen in die lau­fende Entwicklung

Auch das Team pro­fi­tiert vom nähe­ren Kontakt zum Kunden. Es gehen ein­deu­tig weni­ger Informationen zwi­schen Management- und Entwicklungsebene ver­lo­ren, was ins­ge­samt der Zufriedenheit und Kreativität des Teams zuträg­lich ist.

Dennoch gab es Dinge, mit denen wir in der schö­nen neuen agi­len Welt nicht gerech­net haben und mit denen wir jetzt kon­fron­tiert wur­den. Den Punkt der unge­fil­ter­ten Kommunikation des Kunden mit dem Entwicklerteam (vor­ran­gig bei den Sprint-Reviews) möchte ich an die­ser Stelle nicht wei­ter ver­tie­fen. Man muss sich dem bewusst sein, dass hier zwei ver­schie­dene Welten auf­ein­an­der tref­fen und mit­ein­an­der kom­mu­ni­zie­ren müssen.

Der Schwerpunkt, auf den ich mich hier wei­ter kon­zen­trie­ren will, bezieht sich auf die von uns ver­wen­dete Visualisierung der Sprintboards und Burndown Charts. So steck­ten wir bei­spiels­weise sehr viel Zeit in die Erstellung der Klebezettel für die Stories und ebenso in die Erstellung der Aufgaben, die sich aus den ein­zel­nen Stories für den Sprint erga­ben. Die Zeichnung des Burndown Charts machte zwar Spaß, wenn man immer mal wie­der ein paar Story Points als erle­dig kenn­zeich­nen konnte, aber das wurde auch oft ver­ges­sen. Ein gro­ßes Problem bestand darin, dass die Klebezettel auch mal aktua­li­siert wer­den muss­ten, her­un­ter­ge­fal­len sind oder durch einen Windstoß gar das gesamte Board ver­nich­tet wurde. Wir hat­ten auch ein oder zwei Sprints dabei, wo der Platz für unsere geplan­ten Stories an der Wand ein­fach nicht mehr ausreichte.

Sprintboard - übervoll mit Stories

Das Ziel von Scrum, mehr Transparenz für alle Projektbeteiligte, konn­ten wir mit dem phy­si­schen Sprintboard oder dem phy­si­schen Burndown Chart nicht gewähr­leis­ten. Für den Kunden oder dem Product Owner, die nicht im Projektraum saßen, war es schwie­rig jeder­zeit zu sehen, wel­che Aufgabe sich in wel­chem Status befindet.

In unse­ren Retrospektiven haben wir die eben genann­ten Unschönheiten und auch andere Schwierigkeiten erkannt und auf die Agenda zur Verbesserung unse­res Scrum Prozesses gehoben.

Lösung – ein Software Tool für agiles Management

Für die Erfassung unse­rer Stories, Aufgaben und Bugs ver­wen­den wir bereits seit lan­gem JIRA. Die Arbeit mit JIRA war also allen Projektbeteiligten ver­traut und hatte sich bewährt. Es lag dem­nach Nahe, dass wir uns im JIRA-Umfeld nach Lösungen zu unse­rem Problem umsa­hen. Recht schnell fan­den wir mit dem Add-on „JIRA Agile“ (ab Version 7 „JIRA Software“) eine sehr gute Lösung zur Bewältigung unse­rer Probleme mit der phy­si­schen Visualisierung unse­res Sprintboards und der Diagramme.

JIRA Agile bie­tet in der Planungssicht die Möglichkeit das Backlog zu pfle­gen, schnell neue Stories zu erstel­len und die Planung neuer Sprints ist auch sehr ein­fach. Alle Projektbeteiligten fin­den zu jeder Zeit einen aktu­el­len Stand der ein­zel­nen Stories und der Sprintplanung vor.

In der Sicht des Aktiven Sprints wird dem Nutzer ein Sprintboard ange­zeigt, wie wir es ursprüng­lich zur Visualisierung unse­rer Aufgaben an die Wand unse­res Projektzimmers gezeich­net hat­ten. Das Sprintboard in JIRA ist ebenso in Spalten und Zeilen (Swimlanes) auf­ge­teilt. Jede Spalte, die indi­vi­du­ell erstellt wer­den kann, reprä­sen­tiert einen Arbeitsschritt. Alle Aufgaben wer­den als kleine Kärtchen (die Analogie zu unse­ren Haftzetteln) dar­ge­stellt und wan­dern per Drag-and-drop über die ein­zel­nen Spalten. Der Sprintfortschritt, wel­che Aufgabe sich in wel­chem Status befin­det, kann von allen jeder­zeit abge­ru­fen – auch vom Kunden, der nicht vor Ort sitzt. Ein sehr gro­ßer Vorteil des digi­ta­len Sprintboards ist, dass die Klebezettel weg­fal­len. Änderungen sind auf einer digi­ta­len Karte sofort sicht­bar, so dass keine neue Karte erstellt wer­den muss, wie beim phy­si­schen Board. Es gibt aus­rei­chent Platz auf dem digi­ta­len Board und mit Filtern kann man sich auf die wich­tigs­ten Dinge fokusieren.

Es wer­den mit JIRA Agile auch eine ganze Reihe von Berichten ange­bo­ten, die auto­ma­tisch gene­riert wer­den. So kann man sich vom aktu­el­len Sprint ein Burndown Chart anse­hen oder auch Sprint- oder Versionsberichte. Das schöne an den digi­ta­len Berichten ist, dass sie nach einem Sprint immer noch vor­han­den sind und man spä­ter nach­voll­zie­hen kann, wie die ver­gan­ge­nen Sprints gelau­fen sind oder wel­che Stories dort bear­bei­tet und mög­li­cher­weise nicht abge­schlos­sen wor­den sind. Für die Sprintplanung bie­tet die JIRA Erweiterung sogar ein Velocity Chart an, mit der das Team ver­fol­gen kann, wie­viel Arbeit in den zurück­lie­gen­den Sprints geplant und abge­schlos­sen wurde. So kann man rea­lis­tisch abschät­zen, wie viel Story Points in künf­ti­gen Sprints vom Team erle­digt wer­den können.

JIRA Software - Scrum SprintboardJIRA Software - Scrum Sprint Bericht eines abgeschlossenen Sprints

Certified ScrumMaster®

Nur kurze Zeit spä­ter habe ich dann eine Weiterbildung zum Scrum Master genos­sen und die­ses Wissen nun schon in vie­len Kundenprojekten erfolg­reich anwen­den können.

Seit 2015 bie­ten wir über die Communardo Academy Schulungen zu JIRA Agile an, in denen ich mich als Trainer betä­tige. So kann ich meine Projekterfahrungen direkt an inter­es­sierte Teilnehmer wei­ter­ge­ben und Ihnen zei­gen, wie sie mit den JIRA Boards im Scrum oder auch nach der Kanban Methode arbei­ten können.

Sie inter­es­sie­ren sich für eine Schulung? Hier erfah­ren Sie mehr: JIRA Agile für agile Teams 

Related Posts

Pin It on Pinterest