Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
+49 (0) 351/850 33-0

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

In den letzten Jahren halten agile Methoden immer mehr Einzug in den täglichen Projektalltag. Die Motivation dahinter sind eine verbesserte und kostengünstigere Projektabwicklung sowie zufriedenere Kunden und motiviertere Mitarbeiter.

Das klingt alles wunderbar, aber ist dem wirklich so? In diesem Blogartikel möchte ich meine Erfahrungen mit der agilen Methode „Scrum“ mit euch teilen und freue mich natürlich über eure Erfahrungen, die ihr mir gern in den Kommentaren mitteilen könnt. Auf eine konkrete Erklärung, wie Scrum funktioniert, möchte ich an dieser Stelle verzichten, dazu findet man eine Vielzahl von guten Artikeln im Netz.

Agile – meine ersten Versuche anno 2012

Im Team hatten wir alle schon einmal von Scrum gehört: Einfache Regeln, wenige Rollen, kurze Feedback-Zyklen, Selbstorganisation und noch weitere Charakteristika, die sich bis dahin alle sehr gut anhören. Nun wollten wir dies auch in einem überschaubaren Projekt mal selbst ausprobieren.

Vor drei Jahren konnten wir mit Einverständnis des Kunden das erste agile Projekt starten. Wichtige erste Erfahrung – der Kunde muss an Board geholt und zugestimmt haben, denn wir agieren beim Scrum etwas anders als im klassischen Wasserfallmodel. Einerseits gibt es ein sehr viel höheres Maß an Transparenz, auf das sich das Projektteam und auch der Kunde einlassen muss. Andererseits ist der Austausch mit dem Kunden während des gesamten Projektes viel enger und regelmäßiger – also nicht nur zum Projektbeginn – wodurch wir zwingend einen Ansprechpartner beim Kunden benötigen, der auch Zeit für unsere Fragen hat.

Nach ein paar kleinen Vorbereitungen konnten wir in den ersten Sprint starten. Unsere Stories und Aufgaben für die laufenden Sprints haben wir eifrig auf Klebezetteln notiert und an ein Sprintboard an die Wand in unserem Projektzimmer geklebt (eine Methode, die in vielen Projektteams immer noch Gang und Gebe ist). Später sind wir dazu übergegangen, zumindest die Stories sauber auf kleinen Zetteln auszudrucken und an das Sprintboard zu heften. Die Burndown Charts wurden ebenso wie die Sprintboards im Projektzimmer an die Wand gemalt. So hatten wir immer einen Überblick, wie es um den aktuellen Sprint steht. Das alles war neu und immer aufregend. Jeder freute sich, wenn er wieder eine Aufgabe am Sprintboard einen Arbeitsschritt weiterkleben durfte.

Burndown Chart - Sprint 8

Nach jedem Sprint werden dem Kunden die Ergebnisse präsentiert (Sprint-Review). Hier wurde schon nach den ersten Sprints ein großer Vorteil unseres neuen Vorgehens deutlich: Der Kunde konnte uns direkt eine Rückmeldung zum präsentierten Stand der Entwicklung geben. Damit haben wir schon sehr früh erkennen können, ob die Akzeptanz der Endnutzer vorhanden ist und sich damit ein Projekterfolg andeutet – nicht erst am Ende der Umsetzung wie beim klassischen Vorgehen.

Da der Kunde nicht immer bei uns vor Ort sein konnte, zeigten sich schnell ein paar kleinere Herausforderungen. Wir mussten für unsere Sprint-Reviews dem Kunden Fotos unseres Sprintboards sowie des Burndown Charts schicken. Das war gar nicht so einfach, da der Kunde im Sprint-Review möglichst den letzten Stand sehen sollte. So mussten wir kurz vor Beginn des Meetings (oder auch mal während des Reviews) die Fotos erstellen und versenden.

Die Schattenseiten von Klebezettel und Whiteboard

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

  • direktes Feedback während der Entwicklung
  • schnelle Umsetzung der Anmerkungen in die laufende Entwicklung

Auch das Team profitiert vom näheren Kontakt zum Kunden. Es gehen eindeutig weniger Informationen zwischen Management- und Entwicklungsebene verloren, was insgesamt der Zufriedenheit und Kreativität des Teams zuträglich ist.

Dennoch gab es Dinge, mit denen wir in der schönen neuen agilen Welt nicht gerechnet haben und mit denen wir jetzt konfrontiert wurden. Den Punkt der ungefilterten Kommunikation des Kunden mit dem Entwicklerteam (vorrangig bei den Sprint-Reviews) möchte ich an dieser Stelle nicht weiter vertiefen. Man muss sich dem bewusst sein, dass hier zwei verschiedene Welten aufeinander treffen und miteinander kommunizieren müssen.

Der Schwerpunkt, auf den ich mich hier weiter konzentrieren will, bezieht sich auf die von uns verwendete Visualisierung der Sprintboards und Burndown Charts. So steckten wir beispielsweise sehr viel Zeit in die Erstellung der Klebezettel für die Stories und ebenso in die Erstellung der Aufgaben, die sich aus den einzelnen Stories für den Sprint ergaben. Die Zeichnung des Burndown Charts machte zwar Spaß, wenn man immer mal wieder ein paar Story Points als erledig kennzeichnen konnte, aber das wurde auch oft vergessen. Ein großes Problem bestand darin, dass die Klebezettel auch mal aktualisiert werden mussten, heruntergefallen sind oder durch einen Windstoß gar das gesamte Board vernichtet wurde. Wir hatten auch ein oder zwei Sprints dabei, wo der Platz für unsere geplanten Stories an der Wand einfach nicht mehr ausreichte.

Sprintboard - übervoll mit Stories

Das Ziel von Scrum, mehr Transparenz für alle Projektbeteiligte, konnten wir mit dem physischen Sprintboard oder dem physischen Burndown Chart nicht gewährleisten. Für den Kunden oder dem Product Owner, die nicht im Projektraum saßen, war es schwierig jederzeit zu sehen, welche Aufgabe sich in welchem Status befindet.

In unseren Retrospektiven haben wir die eben genannten Unschönheiten und auch andere Schwierigkeiten erkannt und auf die Agenda zur Verbesserung unseres Scrum Prozesses gehoben.

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

Für die Erfassung unserer Stories, Aufgaben und Bugs verwenden wir bereits seit langem JIRA. Die Arbeit mit JIRA war also allen Projektbeteiligten vertraut und hatte sich bewährt. Es lag demnach Nahe, dass wir uns im JIRA-Umfeld nach Lösungen zu unserem Problem umsahen. Recht schnell fanden wir mit dem Add-on „JIRA Agile“ (ab Version 7 „JIRA Software“) eine sehr gute Lösung zur Bewältigung unserer Probleme mit der physischen Visualisierung unseres Sprintboards und der Diagramme.

JIRA Agile bietet in der Planungssicht die Möglichkeit das Backlog zu pflegen, schnell neue Stories zu erstellen und die Planung neuer Sprints ist auch sehr einfach. Alle Projektbeteiligten finden zu jeder Zeit einen aktuellen Stand der einzelnen Stories und der Sprintplanung vor.

In der Sicht des Aktiven Sprints wird dem Nutzer ein Sprintboard angezeigt, wie wir es ursprünglich zur Visualisierung unserer Aufgaben an die Wand unseres Projektzimmers gezeichnet hatten. Das Sprintboard in JIRA ist ebenso in Spalten und Zeilen (Swimlanes) aufgeteilt. Jede Spalte, die individuell erstellt werden kann, repräsentiert einen Arbeitsschritt. Alle Aufgaben werden als kleine Kärtchen (die Analogie zu unseren Haftzetteln) dargestellt und wandern per Drag-and-drop über die einzelnen Spalten. Der Sprintfortschritt, welche Aufgabe sich in welchem Status befindet, kann von allen jederzeit abgerufen – auch vom Kunden, der nicht vor Ort sitzt. Ein sehr großer Vorteil des digitalen Sprintboards ist, dass die Klebezettel wegfallen. Änderungen sind auf einer digitalen Karte sofort sichtbar, so dass keine neue Karte erstellt werden muss, wie beim physischen Board. Es gibt ausreichent Platz auf dem digitalen Board und mit Filtern kann man sich auf die wichtigsten Dinge fokusieren.

Es werden mit JIRA Agile auch eine ganze Reihe von Berichten angeboten, die automatisch generiert werden. So kann man sich vom aktuellen Sprint ein Burndown Chart ansehen oder auch Sprint- oder Versionsberichte. Das schöne an den digitalen Berichten ist, dass sie nach einem Sprint immer noch vorhanden sind und man später nachvollziehen kann, wie die vergangenen Sprints gelaufen sind oder welche Stories dort bearbeitet und möglicherweise nicht abgeschlossen worden sind. Für die Sprintplanung bietet die JIRA Erweiterung sogar ein Velocity Chart an, mit der das Team verfolgen kann, wieviel Arbeit in den zurückliegenden Sprints geplant und abgeschlossen wurde. So kann man realistisch abschätzen, wie viel Story Points in künftigen Sprints vom Team erledigt werden 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 genossen und dieses Wissen nun schon in vielen Kundenprojekten erfolgreich anwenden können.

Seit 2015 bieten 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 interessierte Teilnehmer weitergeben und Ihnen zeigen, wie sie mit den JIRA Boards im Scrum oder auch nach der Kanban Methode arbeiten können.

Sie interessieren sich für eine Schulung? Hier erfahren Sie mehr: JIRA Agile für agile Teams 

Kommentar hinterlassen


Pin It on Pinterest