Читать книгу Agiler Kapitalismus - Timo Daum - Страница 14

Bei der Anwendung von Scrum sind nicht viele Vorarbeiten nötig, um ein Projekt zu starten – es kann ganz schnell losgehen. Zu Beginn werden – in Zusammenarbeit mit dem Kunden – nur die grobe Richtung und die zentralen Features des Projekts erarbeitet. Letztere werden in kleine Häppchen aufgeteilt, sogenannte user stories, also die Beschreibung von Softwarefunktionen oder Anforderungen aus Sicht des Endnutzers (use cases). Diese werden in einer nach Prioritäten geordneten Liste untergebracht, einer Art Gesamtkatalog aller umzusetzenden Features, dem Product Backlog. Am Beginn einer jeden Iteration (Sprint) steht jeweils ein Planungstreffen (sprint planning), zu dem das gesamte Team zusammenkommt. Als Sprint wird ein festgelegter Zeitraum bezeichnet, in dem bestimmte Arbeiten abgeschlossen und zur Überprüfung vorbereitet werden müssen – bei Scrum dauert ein Sprint zum Beispiel üblicherweise zwei bis drei Wochen.

Das Team – im agilen Kontext eine kleine Gruppe von Personen, die dem gleichen Projekt zugeordnet sind – schätzt den Umfang und Zeitbedarf der Aufgaben in Form von story pointsab. Story points stellen keine Zeitschätzung im strengen Sinne, sondern eine relative Einheit zur Aufwandsabschätzung dar (estimate), mit deren Hilfe die Schwierigkeit der Implementierung und der Zeitbedarf einer bestimmten Story eingeschätzt werden kann. Für die Behebung eines kleinen Bugs z. B. kann ein story point vergeben werden, für die Programmierung einer Suchfunktion derer zehn – das bedeutet zunächst nur, dass das Team schätzt, dass die Beseitigung des Bugs ein Zehntel der Zeit benötigt, die der Bau der Suchfunktion erfordern wird. Fehler bei der Schätzung einer konkreten Aufgabe stellen kein Problem dar, vorausgesetzt, das Team liegt auf lange Sicht im Durchschnitt mit seinen Einschätzungen richtig.

Beim sprint planning meeting, bei dem oft Klebezettel (postits) zum Einsatz kommen, die bestimmte Aufgaben repräsentieren, wählt das Team diejenigen Elemente aus dem Product Backlog aus, die im bevorstehenden Sprint anstehen. Diese bilden dann den Sprint Backlog, der idealerweise am Ende des Sprints leer geworden sein soll. Während des laufenden Sprints soll sich das Team, das meist aus fünf bis zehn Personen besteht, zum Daily Standup Meeting treffen, bei dem alle Teammitglieder einander über ihren jeweiligen Arbeitsfortschritt, aufgetretene Probleme und Hindernisse informieren. Eine populäre Einführung in Scrum beschreibt das Daily Standup Meeting als »Möglichkeit zusammenzuarbeiten, um sicherzustellen, dass jeder zu einem bestimmten Zeitpunkt das effektivste tut, was möglich ist«.¹³

Am Ende eines Sprints können alle story points, die während dieser Iteration abgeschlossen wurden, gezählt werden. Aus der Anzahl erledigter story points pro Zeiteinheit kann jederzeit der Leistungsdurchschnitt des gesamten Teams errechnet werden, die sogenannte velocity. Langfristiges Ziel ist es, dass diese velocity konstant bleibt, was die Leistungsfähigkeit des Teams für die Zukunft berechenbar macht. Gleichzeitig muss gewährleistet sein, dass das Team diesen Schnitt auch dauerhaft durchhalten kann, dann ist eine »nachhaltige Geschwindigkeit« (sustainable pace) erreicht. Ein weiteres Meeting steht am Ende eines Sprints an, das sprint review: Hier kann die Kundenseite bzw. der Auftraggeber das Ergebnis begutachten, hier wird zudem festgelegt, was als erledigt gilt und was nicht. Nicht zu verwechseln mit einem weiteren Meeting, dem retro, einem Feedback- und Optimierungsformat für das Team selbst. Bei der Retrospektive auf den zurückliegenden Sprint können die »Teammitglieder ihre Kooperationserfahrungen während der vergangenen Etappe reflektieren und Optimierungsvorschläge für die Arbeitsweise diskutieren«¹⁴.

Den klassischen Projektmanager, dessen Aufgabe es gewesen war, dem Team konkrete Arbeitsanweisungen zu erteilen und deren Umsetzung zu überwachen, gibt es nicht mehr. In seine Fußstapfen tritt bei Scrum der Product Owner, er bringt die Kundenperspektive ins Projekt hinein und ist im agilen Team für die Definition der Anforderungen und die Prioritätensetzung zuständig. Er schreibt die user stories und erstellt sie im Backlog, dies kann in Zusammenarbeit mit anderen Teammitgliedern geschehen. Er weiß, welche Backlog-Elemente zu priorisieren sind, und trägt dafür Sorge, dass die Ergebnisse des Produktionsprozesses konzeptionell und technisch stimmig sind. Der Autor eines populären Agilitätsleitfadens, Andrew Stellman, beschreibt die neu eingeführte Rolle so: »Anstatt einen Plan zu diktieren, ihn dem Team zu übergeben und zu messen, wie gut das Team ihm folgt, arbeitet er jetzt mit dem Team zusammen, um herauszufinden, wie das Projekt am besten angegangen werden kann.«¹⁵

Felix S., Product Owner bei einer mittelgroßen Digitalfirma, beschreibt seine Rolle im Interview folgendermaßen: »Zu meinen Aufgaben gehört: Nutzertests vorbereiten, überlegen, wo soll es hingehen, Prototypen konzipieren, Hypothesen aufstellen, fragen, was wollen die Nutzer, wissen wir, wo es technisch und konzeptionell hingeht? Ich wollte die Chance, auf das Produkt einzuwirken. Was auch dazu gehört, ist immer noch, den Kunden zu erziehen, umzukrempeln – das gehört eben dazu.«

Neben dem Product Owner kommt noch der Scrum Master ins Spiel, er oder sie ist dafür verantwortlich, dass das Team nach agilen Werten und Prinzipien arbeiten kann. Stellman über die Rolle: Er oder sie »hilft dem Team, das Projekt in Iterationen aufzuteilen, verfolgt dessen Fortschritt auf einem task board, macht sich die Projektgeschwindigkeit und burndown charts zunutze, um die Menge an ausstehender Arbeit – die auf null »herunterbrennt«, wenn sie erledigt ist – tagesaktuell zu tracken, und hält alle auf dem Laufenden.«¹⁶ Scrum Master bei einer Digitalagentur Alina G. über ihre Rolle: »Ich bin dafür da, dass das Team gut arbeiten kann, ich beobachte das Team in seinen Verhältnissen, in seinen Kommunikationsweisen. Ich muss schauen, dass die Kultur hier in der Agentur sich entwickelt. Man hat auch ganz viel Community-Arbeit, Austausch mit anderen Scrum Mastern zu unseren Themen, Transfer schaffen, fragen: Was kann man da noch verbessern?«

Idealerweise arbeiten die Teams während der Sprints ohne Störungen von außen in einer Art agilem Sandkasten – in der Informatik bezeichnet sandbox (Sandkasten) einen definierten, gegen die Umgebung abgeschlossenen Bereich. Die Scrum Master räumen Hindernisse aus dem Weg, die Product Owner sorgen dafür, dass das Team in die richtige Richtung läuft. So entsteht ein Schutzraum, in dem die Teams weitgehend frei agieren, sich selbst organisieren und von der Außenwelt abgeschottet sind. Außerhalb des agilen Dreiecks zwischen Team, Product Owner und Scrum Master beginnt die raue Realität, hier findet sich eine weitere Rolle, von der eher seltener die Rede ist, der Business Owner. Sie ist keine eigentliche agile Rolle und befindet sich damit außerhalb der Lehrbuchpraxis von agilen Frameworks. Damit ist die Geschäftsführung oder das obere Management gemeint, also diejenigen, die letztlich geschäftliche und technische Verantwortung innehaben. In größeren Firmen sind sie oft auf einer Zwischenebene zwischen der Geschäftsleitung und den agilen Teams positioniert. Sie sind für die Leitung und Koordination einer Vielzahl agiler Teams zuständig und haben die Kapitalrendite des Unternehmens im Blick.

Rollen bei agilen Projekten (am Beispiel Scrum)