Unternehmen haben es heutzutage mit einem komplexen und sich schnell änderndem Geschäftsumfeld zu tun. Durch die fortlaufende DigitalisierungWas bedeutet Digitalisierung?Digitalisierung ist im Allgemeinen die Umformung von analogen… Mehr müssen sie stets auf neue Bedingungen und Wettbewerber reagieren und schneller reifende Geschäftsmodelle etablieren. Um diesen komplexen Anforderungen gerecht zu werden, wird vermehrt auf ein agiles Projektvorgehen gesetzt.
Wir sind überzeugt: Kein Projekt ohne Steuerung!
Agilität ist in den Köpfen vieler Manager mit dem Bild verknüpft, dass alles von ganz alleine läuft: Die Mitarbeiter führen und organisieren sich selbst mit Scrum, Kanban oder ähnlichen Methoden und Performance-Messungen und Kontrolle sind überflüssig. Das mag in Teilen sogar richtig sein, aber wir sind uns sicher, dass dennoch eine zentrale Steuerung und Kontrolle notwendig ist. Warum? Bei der Steuerung geht es darum die Zusammenarbeit im Projektteam zu koordinieren und kontinuierlich zu verbessern. Die Führung legt hier den verbindlichen Rahmen fest, in dem die Teammitglieder agieren. Sollte nun dieser Rahmen nicht festgelegt sein, dann kommt es im Team zu Unsicherheiten, Abstimmungsschwierigkeiten und unnötiger Mehrarbeit. Resultat: Unzufriedenheit soweit das Auge reicht! Darum ist es absolut notwendig, eine gute Steuerung zu etablieren, die die nötige Orientierung für die Projektbeteiligten bietet. Die Pluspunkte lauten:
- Klare Aufgaben- und Rollenverteilungen
- Selbstständiges Arbeiten
- Definierte Rahmenbedingungen
- Kurze Kommunikationswege
- Regelmäßige Feedbackschleifen
- Die Produkt-Vision als gemeinsam definiertes Ziel!
Agil, agiler, am agilsten: Scrum als Projektmanagement-Methode
Die agile Projektmanagement-Methode „Scrum“ basiert auf wenigen und einfachen Regeln, drei definierten Rollen und täglichen Meetings. Scrum ist ein sich wiederholender Prozess, der sich aus mehreren zeitlich festgelegten Sprints zusammensetzt, um das Projektziel (z.B. Fertigstellung eines Produktes) zu erreichen. Den Ursprung findet Scrum tatsächlich in der Softwareentwicklung. Doch schnell wurde klar, dass diese flexible und dynamische Vorgehensweise ebenfalls für andere Projektanwendungsfälle nützlich sein kann. Auch wir bei ISR nutzen Scrum in unseren Kundenprojekten, denn wir sind richtige #Scrumfans.
Die drei Scrum-Projektrollen
Der Product Owner (PO) spielt eine wesentliche Rolle in Scrum und ist nicht mit dem klassischen Projektmanager zu verwechseln. Der PO vertritt die Interessen der externen Stakeholder des Projektes (z.B. Kunden, Anwender) und bindet wichtige Stakeholder mit ein, ohne sich dabei in seiner Entscheidungsautonomie beeinflussen zu lassen. Zu seinen wichtigsten Aufgaben zählt die Erstellung einer Produkt-Vision – also die Idee des Produkts oder der Lösung, die der Auftraggeber vorantreiben möchte, um für den Endnutzer einen Mehrwert zu generieren. Zudem erarbeitet er mit den Stakeholdern die Businessanforderungen, die er in Form eines initialen Produkt-Backlogs ausformuliert. In Abstimmung mit dem Entwicklungsteam werden dann Arbeitspakete definiert und priorisiert. Fazit: Der PO hat also viel Verantwortung was die Umsetzung und den Erfolg des Projektes angeht.
Im Gegensatz zum PO, trägt der Scrum-Master die Verantwortung für den gesamten Scrum-Prozess. Seine Hauptaufgaben liegen in der Beseitigung von Hindernissen, der Förderung einer guten Zusammenarbeit im Team und der Beschaffung notwendiger Ressourcen. Außerdem ist er der kompetente Ansprechpartner für Außenstehende und stellt sicher, dass alle Regeln des agilen Projektmanagements eingehalten werden. Fazit: Der Scrum-Master ist dafür zuständig, eine reibungslose Arbeit des Entwicklungsteams zu garantieren und den Sprint zu überwachen.
Als dritte und letzte Scrum-Rolle sind die Mitglieder im Development-Team (DEV-Team) zu nennen, ohne die das Scrum-Projekt nicht realisierbar wäre. Das Entwicklungsteam führt die operativen Tätigkeiten entlang der individuellen Kompetenzen durch, organisiert alle Aufgaben eigenständig und arbeitet auf Augenhöhe zusammen, denn hier gibt es keine Hierarchien.
Abbildung 1: Die zentrale Rolle des Product Owners
Fünf Schritte zum Erfolg: Der ausgeklügelte Scrum-Prozess
Am Anfang eines jeden Projektes steht eine Produkt-Vision. Diese grobe Vorstellung vom Produkt definiert den Auftrag, der durch das Scrum-Projekt bearbeitet werden soll. Die Produkt-Vision wird dann in Story Cards übertragen, in denen einzelne Elemente, Funktionen und Merkmale des Produktes beschrieben werden. Der darauf folgende Scrum-Prozess kann in fünf Schritte gegliedert werden.
Aus den zusammengetragenen Anforderungen des POs und den Story Cards wird das Product Backlog zusammengestellt. Das ist eine Sammlung von Funktionen und Merkmalen, die das Produkt haben soll.
Im Sprint Planning findet die Planung der anstehenden Aufgaben und die Formulierung des Sprint-Ziels für den als nächstes anstehenden Sprint statt. Daraus erstellt das Scrum-Team einen Sprint Backlog.
Im Daily Scrum findet ein kurzer Austausch zwischen den Projektmitarbeitern statt, in dem jeder auf folgende Fragen eingeht: Was habe ich seit dem letzten Daily Scrum gemacht? Was habe ich bis zum nächsten Daily Scrum zu tun? Welche Probleme gibt es?
Jeder Sprint endet mit einem Sprint-Review-Meeting, in dem das Projektteam dem PO die Ergebnisse vorstellt. Unter Beachtung der Besprechungen im Sprint Review kann der nächste Sprint mit Prozessschritt 2 starten. Es folgen so viele Sprints, bis das Produkt entwickelt und das Projekt abgeschlossen ist.
Die Sprint Retrospective ist ein gesondertes Treffen, bei dem der Sprint im Plenum besprochen wird. Jeder kann Feedback zu der empfundenen Zusammenarbeit, den Abläufen und der verwendeten Werkzeuge geben. Learnings werden festgehalten und für die nächsten Sprints angewandt.
Abbildung 2: Scrum Framework
Projektbeispiel: ISR wendet Scrum gerne in Kundenprojekten an
Genug Theorie! Um zu sehen, wie agiles ProjektmanagementWas ist Projektmanagement?Projektmanagement umfasst sämtliche – oft standardisierte – Aufgaben,… Mehr in der Realität gelebt werden kann, sehen wir uns nun ein konkretes aber anonymisiertes Beispiel aus einem unserer Kundenprojekte an, bei dem mit Scrum gearbeitet wurde.
Theoretisch benötigt es immer einen PO und einen Scrum-Master. In unserem Projektbeispiel fehlt der PO der Kundenseite. Kein Problem, denn diese Aufgaben wurden dann einfach vom Scrum-Master übernommen. Dieser hat zusammen mit den Projektmitarbeitern des Kunden und dem DEV-Team die Anforderungen aufgenommen, abgestimmt und bewertet. Mit Definition of Ready (DoR), Definition of Done (DoD) und Akzeptanzkriterien wurden die Anforderungen so verfeinert, dass sie letztlich in einen Sprint aufgenommen werden konnten.
Die genannten Schritte erfolgten in zwei Meetings. Im ersten Meeting, dem Backlog-Refinement-Meeting, mit dem PO und dem DEV-Team wurden die initialen Anforderungen überarbeitet. Die Tagesordnungspunkte lauteten:
- Zusammentragung der fachlichen und technischen Hintergründe des Projektteams
- Erkennung von Zusammenhängen
- Verfeinerung der Akzeptanzkriterien
- Aufwandsschätzung durch Entwickler
Im zweiten Meeting, dem Sprint-Planning-Meeting, mit dem PO, dem Scrum-Master und dem DEV-Team wurde das Sprintziel vorgestellt und Verständnisfragen geklärt. Danach einigte sich das DEV-Team auf die Menge von Stories, die im Sprint bearbeitet werden können. Hieraus bildete sich das Sprint Backlog.
In 3-wöchigen Sprints arbeitete dann das DEV-Team die im Sprint eingeplanten Stories ab. Während dieser Zeit tauschten sich die Entwickler im Daily-Scrum-Meeting über den Arbeitsfortschritt und die anstehenden Aufgaben aus.
Nach Sprintabschluss wurde dem Kunden im Sprint-Review-Meeting vorgestellt, wie die einzelnen Tickets – also einzelne Aufgabe, die zu erledigen waren – umgesetzt wurden. Dies geschah in unserem Beispielprojekt durch einen stellvertretenden Entwickler, könnte aber auch durch den jeweiligen Umsetzer vorgestellt werden. Ein wichtiger Meilenstein in diesem Meeting war die Abnahme der DoD durch den PO.
Im letzten Meeting, dem Sprint-Retrospective, diskutierte der Scrum-Master mit dem DEV-Team und dem PO was gut gelaufen ist und was ggf. noch optimiert werden kann. Die Maßnahmen zur Verbesserung wurden aufgenommen und in den kommenden Sprints eingeplant, um eine kontinuierliche Verbesserung zu ermöglichen. Mit dieser Methode konnten im letzten Sprint neben den neuen Features auch Stories umgesetzt werden, die die Performance des Systems verbesserten. Für das DEV-Team haben wir an einer Story für eine bessere Strukturierung der Release-Notes gearbeitet, um die Qualität der Deployments weiter zu verbessern.
Haben Sie Interesse an agilen Methoden?
Wenn Sie nun neugierig geworden sind und ebenfalls Ihre Projekte agil umsetzen wollen oder wenn Sie noch Fragen haben – melden Sie sich einfach, wir freuen uns auf einen Austausch mit Ihnen!
Angelina Jordan
Account Manager
Business Process Automation
angelina.jordan@isr.de
+49(0)151 422 06 942
