Im ersten Beitrag zum agilen Projektmanagement haben wir uns den Gründen für diese Managementform gewidmet und gezeigt, wie man mit Planner und Teams das Kanban-Modell abbilden kann. In diesem Beitrag soll es um die SCRUM Methode gehen.

SCRUM – Eine agile Projektmanagement-Methode

SCRUM ist keine Abkürzung für einen Begriff, sondern einfach ein Konzept für agile Projektmanagement-Techniken. Es wurde erstmalig 1986 im Artikel „The New Product Development Game“ erwähnt und beschreibt, wie ein Team komplexe Entwicklungsprozesse schneller realisieren kann, wenn das Team aus kleinen und sich selbst organisierenden Einheiten besteht. Also genau das, was wir in der heutigen schnelllebigen Zeit benötigen.

Manche agilen Methoden können vollständig ungeplant ablaufen. Beim Kanban können sich z.B. Kollegen selbstständig Aufgaben aus dem „Aufgabenkorb“ zuweisen und daran arbeiten. Der SCRUM Ansatz ist hingegen stärker prozessorientiert, sollte täglich überwacht und gesteuert sowie in eine strengen Leistungsmetrik integriert werden. Um das zu erzielen, wurden klare Rahmenbedingungen geschaffen.

Scrum-Rollen und Aufgaben:

• Produkt Owner
  Der Product Owner handelt im Interesse der Anwender des Produkts bzw. der Stakeholder eines Projekts. Folglich ist er für den Erfolg des Projekts verantwortlich und muss die fachlichen Anforderungen an das Projekt über den gesamten Projektzeitraum priorisieren, gegebenenfalls neue hinzufügen oder obsolete verwerfen.
• Scrum Master
  Als Scrum Master ist man verantwortlich, dass alle Prozesse korrekt eingehalten werden. Als eine Art Moderator sorgt er also dafür, dass das Team erfolgreich kommunizieren kann, schirmt es von externen Störungen ab und hilft bei methodischen Problemen, also räumt Hindernisse in der Teamarbeit aus dem Weg.
• Scrum Team
  Nicht mehr als fünf bis 10 Personen sollte das Scrum Team umfassen, welches das Produkt entwickelt. Jedes Mitglied sollte zielorientiert und somit aus eigenem Antrieb und selbstständig seine Aufgaben erledigen.

Als eine weitere, jedoch nicht zentrale Rolle der Scrum Methode können die Stakeholder betrachtet werden. Sie sind entweder a) die Auftraggeber, b) die Anwender, welche das Produkt am Ende nutzen sollen oder auch c) das Management des entsprechenden Projekts.

Scrum Artefakte:

Neben den Rollen sind die sogenannten Artefakte die drei Kernelemente im Scrum Prozess.

• Anforderungen
  Die Ziele der Auftraggeber (Stakeholder) werden als Anforderungen festgehalten und sollten als „User Stories“ beschrieben werden. Sie sollen bewusst nicht fachlich sein, damit der Anwendungsfall des Kunden im Fokus bleibt. Erst aus diesen Anforderungen werden die fachlichen Arbeitspakete im „Product Backlog“ abgeleitet.
• Sprint Backlog
  Arbeitspakete, welche die Merkmale und Funktionen des Produkts/Projekts beschreiben und als konkrete Aufgaben (teilweise mit Unteraufgaben) definiert sind, werden im Sprint Backlog gesammelt. Diese werden in den Sprints abgearbeitet.
• Product Increment
  Das Product Increment sind entweder teilfunktionale Versionen nach verschiedenen Sprints oder das fertige Produkt am Ende des Projekts.

Rollen und Artefakten sind Elemente eines gesamten Scrum Prozesses, der verschiedene Aktivitäten durchlaufen muss.

1. Anforderungen in Story Cards
2. Arbeitspakete im Produkt-Backlog
3. Prioritäten
4. Sprint-Planung
5. Aufgaben im Sprint-Backlog
6. Besprechungen im Scrum
7. Sprint Review Meeting
8. Sprint Retrospektive
9. Produkt Backlog Refinement
10. Projektabschluss

In diesem Zusammenspiel bieten Microsoft Teams und Planner die notwendigen Anwendungen, um ganz im Sinne eines Scrum-Masters die Prozessregeln einzuhalten und dabei erfolgreich zusammen zu arbeiten. Dies möchte ich folgendermaßen empfehlen.

Scrum Prozessaktivitäten mit Microsoft Teams und Planner

1. Anforderungen in Story Cards

   Rollen: Owner, Stakeholder
   Anwendung: Teams Channels, Notebook

Wie unter den Scrum Artefakten beschrieben, sollten die Anforderungen der Auftraggeber auf Merkmale und Funktionen konzentriert werden. Hilfreich ist dazu auch immer die Beschreibung als Anwendungsfall, um stets das Ziel des Projekts vor Augen zu haben. Dies reduziert die Gefahr der Fehlplanung, die gern ironisch dargestellt wird.

Quelle: https://www.slideshare.net/mcchan52/project-cartoon-how-projects-really-work

Für den ersten Schritt im Scrum empfehle ich Microsoft Teams. Die Story Cards, also einzelne Merkmale und Funktionen, können einerseits pro Kanal beschrieben werden (1). So können auch detailliertere Absprachen, Dateien und weitere spezifische Anforderungen (2) voneinander getrennt werden.

Alternativ kann auch die OneNote App verwendet werden, die sich sehr gut ins Teams integrieren lässt. Auch hier können dann die einzelnen Merkmale (a) und Anwendungsfälle (b) beschrieben werden. Ich persönlich würde die obere Variante bevorzugen, weil sie mehr Möglichkeiten (Chats, Likes, @Erwähnungen, Konnektoren, etc.) und Flexibilität bietet. Freunde und Spezialisten von OneNote sehen sicher auch die Vorteile der untere Variante.

2. Arbeitspakete im Product-Backlog

   Rollen: Owner
   Anwendung: Planner Karten

In Schritt zwei müssen nun die Anforderungen in fachliche Arbeitspakete übersetzt werden. Die Planner Aufgabenkarten sind die perfekte Lösung dafür. In ihnen können alle notwendigen Informationen festgehalten werden, wie bereits im Blog zur Kanban-Methode beschrieben.

3. Prioritäten

   Rollen: Owner
   Anwendung: Planner Labels

Als Vorbereitung auf Schritt vier, müssen zunächst die Aufgabenpakete nach Wichtigkeit oder Abhängigkeit priorisiert werden. Die Labels an den Karten erfüllen genau diesen Zweck.

4. Sprint-Planung

   Rollen: Owner, Team, (Master)
   Anwendung: Teams Meeting, Planner Buckets

In diesem Schritt geht es nicht nur darum, die einzelnen Aufwände der Arbeitspakete abzuschätzen und entsprechende Aufgaben einem Sprint-Abschnitt zuzuweisen. Besonders zu Beginn muss beispielsweise auch geklärt werden, wann und wo sich alle Projektmitglieder täglich treffen können, wie der allgemeine Projektaufbau aussehen soll, welche Teilziele und Meilensteine es gibt oder auf welche Details geachtet werden muss. Grundsätzlich geschieht dies zwischen Product Owner und Team. Als Moderator und für die methodischen Aspekte empfehle ich jedoch auch das Hinzuziehen des Scrum Masters.

Am Ende einer jeden Sprint-Planung sollten die einzelnen Arbeitspakete aus dem Product Backlog (1) dem jeweiligen Sprint (2) zugewiesen werden. Die Planner Buckets sind dafür die ideale Plattform. Sollte man sich für die Planung nicht persönlich treffen, so empfehle ich die Meeting Funktion (inkl. Video!) in Teams zu nutzen. Dabei kann entweder jeder die Aufgabenkarten selbst vor sich haben oder es wird obige Übersicht im Bildschirm geteilt.

5. Aufgaben im Sprint-Backlog

   Rollen: Team
   Anwendung: Aufgaben in den Planner Karten

Mit Schritt fünf beginnt nun die Arbeit an den Aufgabenpaketen, also ein Sprint. Dieser sollte in der Regel maximal ein bis vier Wochen dauern und durch tägliche Daily Scrum Meetings (siehe Schritt sechs – Besprechungen im Scrum) überwacht werden. Für eine detaillierte Fortschrittsplanung empfehle ich Arbeitspakete in einzelne (Teil-) Aufgaben zu zerlegen. Diese können innerhalb jeder Planner Aufgabenkarte definieren werden.

6. Besprechungen im Scrum

   Rollen: Master, Owner, Team
   Anwendung: Teams Meeting (Planner Karten Übersicht)

Teil des Scrum Ansatzes sind tägliche, maximal 15 Minuten andauernde Daily Scrum Abstimmungen. In diesem Schritt berichtet jedes Team-Mitglied, was es seit dem letzten Scrum gemacht hat, was es bis zum nächsten Scrum tun wird und was es bei seiner Arbeit behindert. Der Master kann hiervon notwendige Schritte ableiten, um diese Behinderungen aus dem Weg zu räumen.

Microsoft Teams bietet, besonders bei örtlich verteilten Teams, die perfekte Grundlage für solche Treffen. Wie bei Schritt vier (Sprint-Planung) kann jeder Teilnehmer während des Meetings die Aufgaben auf der Planner Kartenansicht selbst oder via Screensharing verfolgen. Aufgrund der sehr kompakten Zeitplanung in den Daily Scrums sollte man jedoch überlegen, ob dies notwendig ist oder auch nur die Audio- und Videoübertragung ausreichend ist.

7. Sprint Review Meeting

   Rollen: Master, Owner, Team, Stakeholder
   Anwendung: Teams Meeting (Planner Karten Übersicht)

Am Ende eines jeden Sprints sollte es eine Fortschrittskontrolle geben. Hierbei kann je nach Projekt und Produkt auch bereits ein (Teil-) Ergebnis (Release) fertig- und dem Auftraggeber vorgestellt werden. Dieser kann das Ergebnis dann annehmen, ablehnen, Feedback geben oder auch neue Anforderungen formulieren. Dies unterstreicht die Vorteile des agilen Projektmanagements, in dem man fortwährend auf geänderte Aufgaben reagieren kann.

Im Vergleich zu den kompakten Daily Scrums, empfiehlt sich in den Sprint Review Meetings die Planner Aufgabenkarten als visuellen Unterstützung der Besprechung zu nutzen. Dennoch sollten die Sprint Reviews maximal eine Stunde andauern.

Mit den hoffentlich zukünftig verfügbaren Berechtigungseinschränkungen je Teams-Kanal (siehe Microsoft User Voice) kann so auch ein „Externer Kanal“ mit dem Auftraggebern erstellt, Meetings abgehalten und Dateien geteilt werden, ohne das andere interne Dokumente verfügbar werden. Bis dahin ist aber auch die aktuelle Meeting-Funktion inklusive Telefoneinwahl eine optimale Möglichkeit, die Sprint-Reviews mit (externen) Auftraggebern abzuhalten.

8. Sprint Retrospective

   Rollen: Master, Team, (Owner)
   Anwendung: Teams Meeting (Teams Kanäle)

Neben dem Fokus auf das Projekt/Produkt im Sprint Review, sollte sich das Team gesondert treffen und den Arbeitsprozess besprechen. Dieser kann so kontinuierlich überprüft und verbessert werden.

Alternativ zu einem Treffen kann Feedback auch direkt in den Teams-Kanälen geäußert werden.

9. Product Backlog Refinement

   Rollen: Owner
   Anwendung: Planner Buckets

Aus den Ergebnissen aus Schritt sieben (Sprint Review Meetign) muss der Product Owner den Product Backlog organisieren und aktualisieren. Fertiggestellte Arbeitspakete sollen in Planner als abgeschlossen markiert und in den Product Log verschoben werden. Neue oder aktualisiert Aufgaben können im Product Backlog wieder aufgenommen oder direkt für den nächsten Sprint geplant werden.

10. Projektabschluss

    Rollen: Owner, Stakeholder
    Anwendung: Planner Buckets, Teams Meeting

Sind alle Sprints abgeschlossen, so kann das Projekt abgeschlossen bzw. das fertige Produkt an den Auftraggeber ausgeliefert werden. In Planner sollten dann alle Aufgabenkarten im Product Log als abgeschlossen markiert sein.

Weiterhin hat ein Product Owner dank einfacher Diagramme jederzeit den Überblick über seine Scrum Projekte und den Stand der darin enthaltenen Aufgaben.

Leider fehlt Planner derzeit noch eine Exportfunktion, um die Informationen in andere Formate zu transformieren oder zusätzliche Analysemöglichkeiten zu nutzen, wie zum Beispiel einen für Scrum häufig verwendeten Burn-Down-Chart.

Microsoft arbeitet unermüdlich an der Realisierung neuer Funktionen in Office 365 und Planner, so wurde kürzlich die Verknüpfung von Outlook Terminen mit Planner Aufgaben ausgerollt. Auch die Anbindung an weitere Office 365 Workstreams ist aktuell in Entwicklung, wie auf der Office 365 Roadmap Seite zu lesen ist.

Unabhängig von zukünftigen Entwicklungen ist Planner schon heute, besonders mit der einfachen Integration in Microsoft Teams, ein ideales Werkzeug für agiles Projektmanagement und dem Scrum Ansatz. Daher empfehle ich Unternehmen, die agile Arbeitsstrukturen etablieren möchte, Planner in Kombination mit Microsoft Teams besonders für kleine bis mittelgroße Projekte auszuprobieren.