Flexibilität statt starrer Regeln: Projektmanagement mit Scrum bei MASSIVE ART

Agiles Projektmanagement umfasst unterschiedliche Methoden, die vor allem auf Flexibilität und Anpassungsfähigkeit setzen. Dabei werden das adaptive Planen sowie die schnelle Abstimmung im Team unterstützt. Scrum bricht mit den Regeln des klassischen Projektmanagements und setzt auf Selbstorganisation, Flexibilität, Dynamik und tägliche Meetings, in denen die Teammitarbeiter ihre Aufgaben abstimmen. Im Mittelpunkt von Scrum steht das selbstorganisierte Entwicklerteam. 

Die Produktentwicklung wird in Scrum in klar abgegrenzte Intervalle – bei MASSIVE ART sind dies zweiwöchige Sprints – aufgeteilt. Während dieser Zeit wird dem Produkt eine neue Funktionalität hinzugefügt oder die vorhandene Funktionalität verbessert. Sollten sich während eines Sprints die Anforderungen ändern, werden diese neu geplant, kommen wieder in den sogenannten Backlog, um dann für den kommenden Sprint geplant zu werden. Am Ende jedes Sprints muss das Team Software oder Software-Komponenten liefern, die für sich allein lauffähig ist (Produktinkrement) – auch wenn man die weitere Produktion einstellen würde.

Dabei gibt es nur wenige Regeln, die sich auf drei Rollen, drei Artefakte, fünf Zeremonien und fünf Values beziehen.

Product Owner

Der Product Owner erstellt die konkrete Produktvision. Zudem ist es seine Aufgabe, fachliche Anforderungen an das Produkt zu stellen und diese zu priorisieren. Beim Product Owner handelt es sich immer um eine Einzelperson.

Entwicklungsteam

Das Entwicklungsteam organisiert sich selbst und verantwortet die Lieferung der Produkteigenschaften in der Reihenfolge, die vom Product Owner festgelegt wurde. 

Scrum Master

Der Scrum Master ist nicht der Projektleiter. Er ist vielmehr dafür verantwortlich, dass Scrum funktioniert und hat eine Art Moderatorenrolle inne. Das Gelingen der Kommunikation innerhalb des Teams und mit dem Product Owner liegt in seinem Aufgabenbereich, genauso wie die Moderation von Meetings. Zudem schirmt er das Team von Störungen von außen ab – etwa von zusätzlichen Aufgaben außerhalb des Product Backlogs.

Neben den drei zentralen Rollen gibt es auch noch die Stakeholder, also den Auftraggeber (im Scrum Customer genannt), die Anwender oder User, die das fertige Produkt verwenden sollen und das Management, das für die Rahmenbedingungen verantwortlich ist, beispielsweise für Räume, Maschinen und Ressourcen.

Product Backlog

Der Product Backlog ist eine Sammlung von Anforderungen (Requirements). Er wird ständig weiterentwickelt und vom Product Owner gepflegt, der die Einträge ordnet und priorisiert.

Sprint Backlog

Aus dem gesamten Anforderungskatalog wird eine Auswahl an Anforderungen getroffen, die innerhalb eines Sprints bearbeitet werden sollen. Daraus leitet sich dann die Funktionalität des nächsten Produktinkrements ab.

Product Increment

Am Ende jedes Sprints steht ein funktionsfähiges Zwischenprodukt – das Produktinkrement.

Sprint Planning

Im Sprint Planning wird der nächste Sprint, also die nächste Projektetappe geplant. Dabei werden die Anforderungen in konkrete Aufgaben (Tasks) zerlegt. Diese sollten innerhalb eines Tages bearbeitet werden können. Das Ergebnis ist der Sprint Backlog.

Daily Scrum

Am Morgen eines jeden Arbeitstages trifft sich das Team zu einem maximal viertelstündigen Meeting, dem Daily Scrum. Es bietet die Möglichkeit, sich einmal am Tag mit allen Teammitgliedern auszutauschen. Jeder erklärt kurz, welche Aufgaben er seit dem letzten Meeting erledigt hat, welche Aufgabe als nächstes ansteht und welche Hindernisse es aktuell gibt. Tauchen Probleme auf, die sich nicht innerhalb einer Viertelstunde lösen lassen, werden diese an den Scrum Master übergeben.

Sprint Review

Am Ende eines jeden Sprints steht ein Sprint Review durch das Entwicklungsteam. Dabei wird das Zwischenprodukt überprüft und der Product Backlog, falls notwendig, angepasst. Zusätzlich wird das Feedback von Product Owner und Stakeholdern eingeholt, die Zielerreichung überprüft und nächste Schritte besprochen.

Sprint Retrospective

Bei der Retrospektive geht es nicht um eine Überprüfung des Produktinkrements, sondern um die Arbeit des Projektteams, um sie kontinuierlich zu verbessern.

Product Backlog Refinement

Der Product Owner organisiert, konkretisiert und aktualisiert den Product Backlog im sogenannten Product Backlog Refinement.

Im Kern basiert Scrum also auf einer inkrementellen Vorgehensweise, der Organisation von Entwicklungsabschnitten und Meetings in vordefinierten Zeitabschnitten (Time-Boxes) und der Erkenntnis, dass ein funktionierendes Produkt wichtiger ist als eine dreihundertseitige Spezifikation.

Commitment

Ein wesentlicher Aspekt in Scrum ist, dass sich das Team darauf verständigt, innerhalb einer jedes Sprints ein bestimmtes Ergebnis zu erzielen. Dahinter steht die psychologische Erkenntnis, dass Selbstverpflichtung die Wahrscheinlichkeit erhöht, dass gefasste Pläne auch umgesetzt werden.

Focus

In Scrum soll vermieden werden, dass wir durch uns selbst oder durch andere vom eigentlichen Sprintziel abgebracht werden und Arbeiten erledigen, die dem Sprint-Ziel nicht dienlich sind. Oder um es mit den Worten des agilen Manifests zu sagen: Die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essenziell.

Openness

Der Wert der Offenheit spiegelt sich in zweierlei Aspekten wider: In der Bereitschaft des Einzelnen, sich auf neue Praktiken Techniken und Denkweisen einzulassen, diese auszuprobieren und so vielleicht zu neuen Erkenntnissen zu gelangen. Andererseits in einem transparenten Umgang mit Informationen – ganz gleich ob es um Anforderungen, Hindernisse oder den Projektfortschritt geht.

Respect

Scrum ist Teamarbeit. Für eine effektive Zusammenarbeit ist gegenseitiger Respekt eine Grundvoraussetzung. 

Courage

Agilität bedeutet Veränderung – um sich den daraus ergebenden Herausforderungen und Risiken zu stellen, braucht es Mut. Dasselbe gilt für Selbstorganisation: Das Team muss regelmäßig Entscheidungen treffen: Zum Beispiel was in einem Sprint erledigt werden kann und was nicht. Natürlich müssen auch die Konsequenzen der Entscheidungen getragen werden.

Das Cynefin-Framework erklärt auf sehr verständliche Weise warum Projekte ab einer gewissen Größe agile Prozesse erfordern. Im Kern geht es bei Cynefin darum Situationen oder Systeme zu verstehen und richtig darauf zu reagieren. Die Grundlage bildet die Einordnung der Systemwahrnehmung in vier Felder, für die je nach Art des Systems jeweils ein Handlungsmuster empfohlen wird: Simple, Complicated, Complex und Chaotic. 

Wo würden Sie folgende Aktivitäten ins Cynefin Framework einordnen?

a) Ein Flugzeug fliegen

b) Einen Burger zubereiten

c) Kernschmelze unter Kontrolle bringen

d) Software entwickeln

e) Die Netzwerkverkabelung innerhalb eines Gebäudes erstellen

Hier geht's zur Auflösung