Agiles Projektmanagement Projekte mit Scrum flexibel zum Erfolg führen

Ganz ohne Regeln kommen auch Scrum und andere Methoden des agilen Projektmanagements nicht aus. Doch es sollen sehr wenige und sehr einfache Regeln sein, die maßgeblich dafür sind, dass das Projektteam die gemeinsamen Ziele erreicht. Entscheidend ist, dass ein Team beim agilen Projektmanagement sich selbst organisieren kann und auch darf und dass es interdisziplinär zusammengesetzt ist, sodass unterschiedliche Kompetenzen zusammenkommen.

Wichtig sind die Rollen, die Akteure einnehmen müssen. Es gibt bei Scrum drei davon:

• der Produkteigner (Product Owner)
• der Scrum-Master
• das Mitglied im Projektteam

Der Produkteigner vertritt die Anwender des Produkts oder die Stakeholder des Projekts. Das sind alle, die betroffen sind und ein Interesse am Erfolg des Projekts haben. Wenn eine neue Software oder IT-Lösung im Unternehmen eingeführt wird, sind das die Nutzer, denn sie wollen reibungslos mit ihren Programmen arbeiten. Bei Produkten sind es die Produktmanager, die als Stimme der Kunden auftreten. Er sollte wissen, was die Kunden schätzen. Aber auch das Marketing, der Vertrieb und der Kundendienst können spezifische Anforderungen artikulieren.

Der Scrum-Master (Project-Master) ist vor allem Moderator und Dienstleister für das Projektteam. Er sorgt dafür, dass Hindernisse im Umfeld des Teams beseitigt werden. Er beschafft die notwendigen Ressourcen und ist Ansprechpartner für Außenstehende. Er hilft dem Team bei methodischen Problemen und stellt sicher, dass die Regeln des agilen Projektmanagements eingehalten werden.

Das Projektteam sollte zwischen fünf und zehn Mitarbeiten umfassen. Sie organisieren alle Aufgaben selbst. Es gibt im Team keine Hierarchie. Jeder hat dieselben Rechte und Pflichten, aber durchaus unterschiedliche Kompetenzen. Alle Fachbereiche, die zur Lösung beitragen, sollten vertreten sein. Wichtig ist, dass alle Teammitglieder freiwillig dabei sind. Sie sollten sich ihre Projekte selbst aussuchen können. Das setzt Vertrauen der Manager und Verantwortungsbewusstsein der Mitarbeiter voraus.

Neben den Rollen ist es vor allem der Prozess, der kennzeichnend ist für Scrum. Am Anfang steht dabei eine Produkt-Vision; eine Idee des Produkts, die die Geschäftsleitung als Auftraggeber des Projekts vorantreiben will und die auch den Anwendern einen Nutzengewinn bringt. Mit diesem Auslöser startet ein Projekt nach Scrum mit den folgenden Schritten:

1. Aus dieser ersten, aber anschaulichen und verständlichen Vision lassen sich die einzelnen Elemente und Merkmale des Produkts ableiten, die zu entwickeln sind. Das sind die konkreten Anforderungen und einzelne Funktionalitäten, die in sogenannten Story Cards in den Worten der Anwender formuliert werden – nicht im Jargon der Techniker. Damit wird auch sichtbar, welche Ressourcen das Projekt braucht (Qualifikationen im Projektteam und grober Aufwand für die Umsetzung).
2. Aus diesen Anforderungen des Produkteigners wird ein sogenanntes Produkt-Backlog zusammengestellt. Das ist eine Sammlung sämtlicher Funktionen und Merkmale, die das Produkt haben soll. Am Anfang ist diese Zusammenstellung noch grob, doch im Projektverlauf wird sie immer genauer.
3. Im nächsten Schritt werden Prioritäten vergeben. Welche Elemente und Funktionen sind am wichtigsten im Sinne von: Das sichert die Zufriedenheit der Anwender essenziell. Andere Anforderungen sind nicht so wichtig, können aussortiert werden, werden mit anderen zusammengelegt, sind technisch nicht realisierbar oder werden verschoben. Sie werden dann bei der Überarbeitung oder bei der Erweiterung des Produkts behandelt (schnelle Release-Wechsel).
4. In einer ersten Besprechung zur Sprint-Planung werden die Rahmenbedingungen abgesteckt: Wo und wann kann sich das Team regelmäßig (täglich!) treffen? Was sind die Teilziele für die entsprechende Funktion und Aufgabe? Wie soll der allgemeine Aufbau aussehen? Was sind die Meilensteine? In welche Teilaufgaben, sogenannte Sprints, lässt sich das Projekt untergliedern? Auf welche Details oder Besonderheiten ist zu achten? Welche Konventionen und Schnittstellen sind einzuhalten?
5. Die Aufgaben oder Tickets werden im sogenannten Sprint-Backlog aufgeführt. Das ist gewissermaßen der Maßnahmenplan und der Arbeitsvorrat für das Entwickler-Team für den nächsten Arbeitszyklus (Sprint). Jedes Teammitglied übernimmt eigenverantwortlich einzelne Aufgaben oder ein Ticket (Verpflichtungserklärung).
6. Im Sprint arbeiten die Teammitglieder an ihren Aufgaben.
7. Während eines täglichen, 15-minütigen Treffens, dem sogenannten Scrum, berichtet jeder der Reihe nach: Was er seit dem letzten Scrum gemacht hat, was er bis zum nächsten Scrum tun wird und was ihn bei seiner Arbeit behindert. Der Scrum-Master muss diese Hindernisse aufgreifen und helfen, dass sie beseitigt werden. In einem Sprint-Burndown-Chart wird sichtbar gemacht, wie das Projekt voranschreitet.
8. Jeder Sprint wird durch ein Sprint Review Meeting abgeschlossen. Das Team stelle die Ergebnisse dem Produkteigner vor. Er muss sie akzeptieren und abnehmen. In gesonderten Treffen können auch die Teammitglieder ihre Zusammenarbeit überprüfen und festhalten, was intern verbessert werden sollte (Lernprozess!).
9. Sind alle Sprints durchlaufen, wird das fertige Produkt an den Produkteigner geliefert. Das Projekt kann abgeschlossen werden.

Bei Scrum werden alle Aufgaben auf einer Tafel festgehalten (Task-Board). Dort wird sichtbar, was noch ansteht, was gerade in Bearbeitung ist und was schon fertig ist. Für manche Zwecke ist das zu knapp.

Deshalb raten die Experten von it-agile, das sogenannte Kanban-Board einzusetzen. Es macht sehr anschaulich, in welcher Phase sich ein Ticket gerade befindet. Es bildet die Wertschöpfungskette des Projekts ab. Dabei werden nur so viele Tickets für die Bearbeitung freigegeben, wie vom Projektteam bearbeitet werden können. Geht es an einer Stelle nicht voran, stauen sich dort die Tickets. Es wird schnell sichtbar, wo der Engpass liegt und was getan werden kann. Eilige Tickets können vorgezogen werden. So steuert das Team die Aufgabenverteilung und den Arbeitsfluss völlig selbstständig.

Das Burndown-Chart ist eine einfache Abbildung, die sichtbar macht, ob das Projekt im ursprünglich vereinbarten Zeit- und Kostenrahmen bleibt. Oder ob Budget oder Zeitplan angepasst werden müssen. Durch die täglichen Treffen können diese sehr aktuell geführt und Korrekturmaßnahmen sehr schnell eingeleitet werden.