Agiles Projektmanagement

Agile Vorgehensweisen entstanden vor allem in der Softwareentwicklung, da hier eine hohe Innovationsgeschwindigkeit herrscht und das gewünschte Ergebnis meist weder durch den Kunden noch den Entwickler am Anfang klar definiert werden konnte. Daher gehört zu den Grundprinzipien des agilen Projektmanagements die Arbeit in kurzen Iterationszyklen. Bei klassischem Projektmanagement steht die Erfüllung von Termin- und Kostentreue sowie die Erfüllung eines definierten Leistungsumfangs im Mittelpunkt. Agiles Projektmanagement stattdessen fokussiert sich auf das entstehende Produkt und seine Akzeptanz durch den Nutzer. Daher ist der Nutzer im agilen Projektmanagement viel stärker in die Entstehung des Produktes eingebunden. Außerdem soll weniger Planung zu schnellerer Umsetzbarkeit, höherer Anpassungsfähigkeit und größerer Eigenverantwortlichkeit führen.
Im Folgenden wird Scrum vorgestellt. Es ist eines von mehreren spezifischen Frameworks, um agiles Projektmanagement durchzuführen. Nach den Inhalten über Scrum werden wir außerdem kurz auf das Kanban-Framework eingehen und Unterschiede zu Scrum herausstellen.

Was ist Scrum?

Scrum ist keine Methodik, sondern ein einfaches Framework für die effektive agile Zusammenarbeit von Teams an komplexen Produkten. Scrum besteht aus Rollen, Ereignissen, Artefakten und den Regeln, die sie miteinander verbinden. Das Framework nutzt die wissenschaftliche Methode der Empirie und ersetzt einen “programmierten algorithmischen Ansatz” durch einen “heuristischen, mit Respekt für Menschen und Selbstorganisation, um mit Unvorhersehbarkeit und der Lösung komplexer Probleme umzugehen.” Scrum setzt auf iterative, inkrementelle Zyklen, um Teams dabei zu unterstützen, aus der Empirie zu lernen.

Was sind die Rollen in einem Scrum-Team?

Das Scrum-Team besteht aus einem “Product Owner”, den Entwicklern und einem “Scrum Master”. Alle drei Rollen tragen Verantwortung für das Gelingen eines Projektes. Empfohlen sind 10 oder weniger Personen in einem Scrum-Team. Durch die verschiedenen Rollen werden verschiedene Aspekte in der Entwicklung eines neuen Produktes abgedeckt:

Der Product Owner priorisiert die Features (auch genannt User Stories) nach Kundennutzen und Umsetzungsaufwand in Zusammenarbeit mit den Entwicklern vor der Umsetzung. Der “Product Owner” ist für das “Product Backlog” verantwortlich – einschließlich seines Inhalts, seiner Verfügbarkeit und seiner Anordnung. So werden die Entwickler nicht mit Arbeit überfordert und die Kunden erhalten die Features zuerst, das sie sich am meisten wünschen. Dabei ist die Kommunikation einer der wichtigsten Fähigkeiten eines “Product Owners”.

Das Scrum Team ist ein kleines, cross-funktionales, selbstorganisiertes Team. Selbstorganisiert meint in diesem Zusammenhang, dass das Team intern entscheidet, wer was, wann und wie macht. Funktionsübergreifende Teams verfügen über alle erforderlichen Kompetenzen, um die Arbeit zu erledigen, ohne von anderen, die nicht zum Team gehören, abhängig zu sein. Der Fokus des Scrum-Teams ist es, die vom “Product Owner” priorisierten Features bestmöglich umzusetzen.

Der “Scrum Master” legt den Fokus auf die reibungslose Durchführung, die Versorgung des Teams mit den notwendigen Ressourcen sowie die schnellen Umsetzung der Features, sodass Kunden schnellstmöglich Zugang zu den neuen Features erhalten und das Scrum-Team durch einen kontinuierlichen Austausch mit den Kunden lernen kann. Der Scrum Master organisiert u. a. das “Scrum Planning” und den “Daily Scrum”, den “Scrum Review” und die “Scrum Retrospective”.

Was sind die "Scrum Events"?

  • Vorgeschriebene Ereignisse werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die nicht in Scrum definiert sind, zu minimieren. Alle Ereignisse sind mit einem Zeitlimit versehen. Sobald ein Sprint beginnt, ist seine Dauer festgelegt und kann nicht verkürzt oder verlängert werden. Die verbleibenden Events können immer dann enden, wenn der Zweck des Events erreicht ist. Dadurch wird sichergestellt, dass eine angemessene Zeitspanne aufgewendet wird, ohne Verschwendung im Prozess zuzulassen. Die Scrum-Events sind:

 

Sprint

Jeder Sprint kann als ein Projekt mit einem Zeithorizont von maximal einem Monat betrachtet werden. Wie Projekte werden Sprints dazu verwendet, etwas zu erreichen. Jeder Sprint hat ein Ziel, was gebaut werden soll, einen Entwurf und einen flexiblen Plan, der den Bau, die Arbeit und das resultierende Produktinkrement leitet.

Ein Sprint ist ein Zeitfenster von einem Monat oder weniger, in dem ein “fertiges”, brauchbares und nach Scrum freigegebenes Produktinkrement (siehe Abschnitt “The Scrum Artifacts” → “Increment”) erstellt wird. Sprints haben eine konsistente Dauer über die gesamte Entwicklungsarbeit hinweg und beginnen unmittelbar nach dem Abschluss des vorherigen Sprints. Während des Sprints werden

  • keine Änderungen vorgenommen, die das Sprint-Ziel gefährden würden,
  • die Qualitätsziele werden nicht verringert, und
  • der Umfang des Sprint kann zwischen dem Product Owner und den Entwicklern geklärt und neu verhandelt werden, wenn neue Erkenntnisse vorliegen.

 

Sprint Planning

Die im Sprint durchzuführende Arbeit wird beim “Sprint Planning” geplant. Dieser Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum-Teams erstellt. Das “Sprint Planning” ist auf maximal acht Stunden für einen einmonatigen Sprint festgelegt. Bei kürzeren Sprints ist die Veranstaltung in der Regel kürzer. Der “Scrum Master” stellt sicher, dass die Veranstaltung stattfindet und dass die Teilnehmer ihren Zweck verstehen. Der “Scrum Master” weist das Scrum-Team an, es innerhalb der Timebox zu halten. Die Sprint-Planung beantwortet die folgenden Fragen:

  • Was kann in dem aus dem kommenden Sprint resultierenden Inkrement geliefert werden (Sprint Goal)?
  • Warum wollen wir dieses Ziel erreichen?
  • Wie wird die Arbeit, die für die Lieferung des Inkrements erforderlich ist, erreicht werden (Kapazitäten, etc.)?

Das “Sprint Goal” ist ein für den Sprint festgelegtes Ziel, das durch die Umsetzung des “Product Backlogs” erreicht werden kann. Es gibt den Entwicklern eine Anleitung, warum es das Inkrement erstellt. Es wird während der Sprint-Planungssitzung erstellt. Das “Sprint Goal” gibt den Entwicklern eine gewisse Flexibilität hinsichtlich der im Sprint implementierten Funktionalität. Während die Entwickler arbeitet, haben sie das “Sprint Goal” immer im Hinterkopf.

 

Daily Scrum

Der “Daily Scrum” ist ein tägliches, 15-minütiges Treffen der Entwickler, um sich abzustimmen und einen Plan für die nächsten 24h zu erarbeiten. Außerdem wird die Arbeit der letzen 24h betrachtet. “Daily Scrums” verbessern die Kommunikation, machen andere Meetings überflüssig, identifizieren Entwicklungshindernisse, die beseitigt werden müssen, zeigen und fördern schnelle Entscheidungen und verbessern den Wissensstand des Entwickler. Dies ist ein wichtiges Inspektions- und Anpassungsmeeting. Die Struktur des Meetings wird von den Entwicklern festgelegt und kann auf unterschiedliche Weise durchgeführt werden, wenn es sich auf den Fortschritt in Richtung des Sprint-Ziels konzentriert. Einige Entwickler werden Fragen verwenden, andere werden eher diskussionsbasiert sein.

Der “Scrum Master” stellt sicher, dass die Entwickler das Meeting haben, aber die Entwickler sind für die Durchführung des “Daily Scrum” verantwortlich. Der “Scrum Master” weist die Entwickler an, das “Daily Scrum” innerhalb des 15-Minuten-Zeitrahmens zu halten. Das “Daily Scrum” ist eine interne Besprechung für die Entwickler. Wenn andere anwesend sind, sorgt der “Scrum Master” dafür, dass sie das Meeting nicht stören.

 

Sprint Review

Am Ende des Sprints wird ein “Sprint Review” abgehalten, um das Inkrement zu inspizieren und das “Product Backlog” bei Bedarf anzupassen. Während des “Sprint Reviews” arbeiten das Scrum-Team und die Stakeholder zusammen, um zu sehen, was im Sprint gemacht wurde. Basierend darauf arbeiten die Teilnehmer heraus, welche Dinge als nächstes getan werden könnten, um den Wert zu optimieren. Dies ist ein informelles Treffen, kein Status-Meeting –und die Präsentation des Inkrements ist dazu gedacht, Feedback zu erhalten und die Zusammenarbeit zu fördern.

Bei einmonatigen Sprints ist dies ein höchstens vierstündiges Treffen. Bei kürzeren Sprints ist die Veranstaltung normalerweise kürzer. Der “Scrum Master” stellt sicher, dass die Veranstaltung stattfindet und dass die Teilnehmer ihren Zweck verstehen. Der “Scrum Master” weist alle Beteiligten darauf hin, dass es innerhalb des Zeitrahmens bleibt.

Das “Sprint Review” umfasst die folgenden Elemente:

  • Zu den Teilnehmern gehören das Scrum-Team und wichtige Stakeholder, die vom “Product” Owner eingeladen werden.
  • Der “Product Owner” erklärt, welche Product-Backlog-Elemente “erledigt” wurden und was noch nicht “erledigt” ist.
  • Die Entwickler besprechen, was während des Sprints gut gelaufen ist, auf welche Probleme es gestoßen ist und wie diese Probleme gelöst wurden.
  • Die Entwickler demonstrieren die Arbeit, die es “erledigt” hat und beantwortet Fragen zum Inkrement.
  • Der “Product Owner” legt den aktuellen Stand des “Product Backlog” dar und projiziert wahrscheinliche Ziel- und Liefertermine basierend auf dem bisherigen Fortschritt (falls nötig).
  • Die gesamte Gruppe arbeitet gemeinsam daran, was als nächstes zu tun ist, sodass der “Sprint Review” wertvollen Input für die nachfolgende Sprintplanung liefert.
  • Überprüfung, wie sich der Markt oder der potenzielle Einsatz des Produkts verändert haben könnte, was als nächstes zu tun ist
  • Überprüfung des Zeitplans, des Budgets, der potenziellen Fähigkeiten und des Marktes für die nächsten voraussichtlichen Releases von Funktionalität und Fähigkeiten des Produkts.

Das Ergebnis des “Sprint Reviews” ist ein überarbeitetes “Product Backlog”, das die wahrscheinlichen “Product Backlog”-Elemente für den nächsten Sprint definiert. Das “Product Backlog” kann auch insgesamt angepasst werden, um neuen Möglichkeiten gerecht zu werden.

 

Sprint Retrospective

Die “Sprint Retrospektive” ist eine Gelegenheit für das Scrum-Team, sich selbst zu überprüfen und einen Plan für Verbesserungen zu erstellen, die im nächsten Sprint umgesetzt werden sollen.

Die “Sprint Retrospektive” findet nach dem “Sprint Review” und vor der nächsten “Sprint Planung” statt. Bei einmonatigen Sprints ist dies ein höchstens dreistündiges Meeting. Bei kürzeren Sprints ist die Veranstaltung in der Regel kürzer. Der “Scrum Master” stellt sicher, dass die Veranstaltung stattfindet und dass die Teilnehmer ihren Zweck verstehen. Dies ist die Gelegenheit für das Scrum-Team, sich zu verbessern, und alle Mitglieder sollten anwesend sein.

Während der “Sprint Retrospektive” bespricht das Team:

  • Was ist im Sprint gut gelaufen?
  • Was könnte verbessert werden?
  • Was werden wir uns im nächsten Sprint vornehmen zu verbessern?

Der “Scrum Master” ermutigt das Scrum-Team, seinen Entwicklungsprozess und seine Praktiken zu verbessern, um ihn für den nächsten Sprint effektiver und angenehmer zu gestalten. Während jeder “Sprint Retrospektive” plant das Scrum-Team Möglichkeiten, die Produktqualität zu erhöhen, indem es die Arbeitsprozesse verbessert oder die Definition von “fertig” anpasst, wenn dies angemessen ist und nicht im Konflikt mit Produkt- oder Organisationsstandards steht.

Am Ende der “Sprint Retrospektive” sollte das Scrum-Team Verbesserungen identifiziert haben, die es im nächsten Sprint umsetzen wird.

Was sind die "Scrum Artifacts"?

Die Artefakte von Scrum stellen Arbeit oder Wert dar, um Transparenz und Möglichkeiten zur Überprüfung und Anpassung zu bieten. Die von Scrum definierten Artefakte sind speziell darauf ausgelegt, die Transparenz von Schlüsselinformationen zu maximieren, damit jeder das gleiche Verständnis des Artefakts hat. Die Scrum-Artefakte sind:

Product Backlog:

In Scrum werden Features aus der Sicht des Kunden formuliert, z. B. nach dem Schema: Als [Position] brauche ich [Feature], sodass ich [Vorteil]. Diese so formulierten Features nennt man User Stories. Alle “User Stories” werden im “Product Backlog” gespeichert. Der “Product Backlog” ist damit die Wunschliste der Kunden. Der “Product Owner” ist für das “Product Backlog” verantwortlich, einschließlich seines Inhalts, seiner Verfügbarkeit und seiner Anordnung. Ein “Product Backlog” ist nie vollständig. Bei seiner frühesten Entwicklung werden die anfänglich bekannten und am besten verstandenen Anforderungen festgehalten. Der “Product Backlog” ist dynamisch; er ändert sich ständig, um zu ermitteln, was das Produkt braucht, um angemessen, wettbewerbsfähig und nützlich zu sein. Dies ist ein fortlaufender Prozess, bei dem der “Product Owner” und die Entwickler gemeinsam an den Details der “Product Backlog”-Elemente arbeiten.

 

Sprint Backlog

Der “Sprint Backlog” ist das Set von “Product Backlog”-Elementen, die für den Sprint ausgewählt wurden, sowie ein Plan für die Lieferung des Produktinkrements und die Realisierung des Sprint-Ziels. Das “Sprint Backlog” ist eine Vorhersage der Entwickler darüber, welche Funktionalität im nächsten Inkrement enthalten sein wird und welche Arbeit erforderlich ist, um diese Funktionalität in einem “Done”-Inkrement zu liefern. Das “Sprint Backlog” macht alle Arbeiten sichtbar, die die Entwickler als notwendig identifizieren, um das Sprint-Ziel zu erreichen. Um eine kontinuierliche Verbesserung zu gewährleisten, enthält es mindestens eine Prozessverbesserung mit hoher Priorität, die im vorherigen Retrospektiv-Meeting identifiziert wurde. Das “Sprint Backlog” ist ein Plan, der so detailliert ist, dass Änderungen im Fortschritt im “Daily Scrum” nachvollzogen werden können. Die Entwickler modifizieren das “Sprint Backlog” während des Sprints. Nur die Entwickler können ihren “Sprint Backlog” während eines Sprints ändern.

 

Increment

Ein Inkrement ist die Summe aller “Product Backlog”-Elemente, die während eines Sprints fertiggestellt werden, und der Wert der Inkremente aller vorherigen Sprints. Am Ende eines Sprints muss das neue Inkrement “fertig” sein, d. h. es muss sich in einem brauchbaren Zustand befinden und der Definition des Scrum-Teams von “fertig” entsprechen. Wenn ein “Product Backlog”-Element oder ein Inkrement als “Done” bezeichnet wird, muss jeder verstehen, was “Done” bedeutet, um Transparenz zu gewährleisten. Aus diesem Grund wird klar definiert, wann ein Item aus dem “Sprint Backlog” als fertig abgeschlossen gilt. Der Zweck jedes Sprints ist es, Inkremente von potenziell freigebbarer Funktionalität zu liefern, die der aktuellen Definition des Scrum-Teams von “Fertig” entsprechen. Entwickler liefern in jedem Sprint ein Inkrement der Produktfunktionalität. Dieses Inkrement ist brauchbar, so dass ein “Product Owner” entscheiden kann, es sofort freizugeben. Wenn die Definition von “Fertig” für ein Inkrement Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen alle Entwickler sie mindestens befolgen.

Kanban vs. Scrum

„Kanban“ ist ein alternatives Framework zur Durchführung von agilem Projektmanagement. Wie bei „Scrum“ steht auch hier eine iterative Entwicklung des Produkts und kontinuierliches Feedback durch den Nutzer im Vordergrund.
Im Wesentlichen unterscheidet sich das „Kanban“ vom „Scrum“ durch den “Product Backlog”. Bei „Kanban“ gibt es keinen regelmäßigen Sprint-Zyklus, in dem ausgewählte Funktionen entwickelt werden – stattdessen wird über ein Kanban-Board geregelt, wann eine weitere Funktion entwickelt. Dies geschieht, wie bei „Kanban“ in der Logistik durch einen Pull-Mechanismus der wirkt, wenn das Entwicklerteam eine Funktion implementiert hat und neue Aufgaben benötigt. Eine anschauliche Erklärung wird in folgendem Video geliefert: