Читать книгу Wie Agilität gelingt - Katharina Maehrlein - Страница 22

Das Arbeiten im selbstorganisierten Scrum-Team stützt sich auf drei Rollen, die für den Arbeitsprozess verantwortlich sind: den Product Owner (PO), den Scrum Master (SM) und das Development Team (Devteam).

Der PO repräsentiert den Kunden und steht zu diesem und zu den Stakeholdern in engem Kontakt. Er ist für den wirtschaftlichen Erfolg verantwortlich und verfolgt die mit dem Kunden abgestimmte Ergebnisvision. Um diese umzusetzen, erstellt er das Product Backlog, eine nach Prioritäten sortierte Auflistung von Anforderungen des Kunden.

Der SM unterstützt das Devteam dabei, die Scrum-Prinzipien und -Regeln zu verstehen und so anzuwenden, dass die gemeinsame Arbeit im Team von den positiven Scrum-Effekten profitieren kann. Er hält dem Team den Rücken frei und sorgt dafür, dass sogenannte »Impediments« – wie beispielsweise hemmende Rahmenbedingungen – aus dem Weg geräumt werden, damit sich das Team auf die vereinbarten Ziele konzentrieren und pünktlich Ergebnisse in hoher Qualität abliefern kann.

Das Devteam ist ein crossfunktionales Team ohne hierarchische Strukturen mit drei bis neun Mitgliedern, das sich selbst organisiert. Es verpflichtet sich, eine bestimmte Anzahl der Aufgaben aus dem Product Backlog abzuarbeiten. Dabei entscheidet das Team selbst, wie viele Aufgaben es annehmen kann, damit diese bis zum Ende des nachfolgenden Sprints abgearbeitet werden können. Das Team entscheidet auch selbst, wie die vom PO »bestellten« Aufgaben bearbeitet werden. Die Arbeit ist durch Sprints von zwei bis maximal vier Wochen Länge getaktet, in denen die ausgewählten Aufgaben abgearbeitet werden. Jeder Sprint startet mit einem Sprint Planning, bei dem ein gemeinsames Verständnis über das Ziel des anstehenden Zyklus erarbeitet wird, die Vorgehensweise, wie die Aufgaben am besten zu lösen sind, zusammen festgelegt wird, die runtergebrochenen Einzeltasks für alle sichtbar im Sprint Backlog visualisiert werden und der Aufwand der Teilschritte abgeschätzt wird, um die Fortschritte zu messen. Anhand eines »Burndownchart« kann jeder jederzeit erkennen, wie der Stand der Arbeit ist und ob und wann das Ziel des Sprints erreicht sein wird. So kann auch frühzeitig erkannt werden, ob noch Platz für weitere Aufgaben ist, die dann zusätzlich aus dem Product Backlog gezogen werden.

Am Ende eines jeden Sprints wird dem PO ein »Inkrement«, ein Teilergebnis, geliefert und im Review gemeinsam mit den Stakeholdern begutachtet und Feedback eingeholt. In der ebenfalls am Ende eines jeden Sprints stattfindenden Retrospektive wird besprochen, wie die Zusammenarbeit noch effektiver werden kann, und aus diesem Meeting und dem Feedback aus dem Review mindestens eine Verbesserung identifiziert, die im nächsten Sprint umgesetzt werden soll.

Im Daily-Stand-up-Meeting werden täglich maximal 15 Minuten lang der Arbeitsfortschritt, die nächsten Aufgaben und gegebenenfalls Probleme besprochen.

All diese Meetings (Sprint Planning, Review, Retro, Daily) und der Sprint finden in sogenannten Time-Boxes statt, das heißt in vorgegebenen Zeiteinheiten, die nicht überschritten werden dürfen.

Scrum arbeitet in kurzen iterativen Intervallen, das heißt, am Ende eines Sprints beginnt sofort der nächste Sprint, in dem weitere Aufgaben aus dem Product Backlog abgearbeitet werden. So schließt sich der Kreis, bis die Ergebnisvision erreicht ist.

Im offiziellen »Scrum Guide« der beiden Scrum-Erfinder« Jeff Sutherland und Ken Schwaber – zwei derjenigen, die am agilen Manifest mitgearbeitet haben – finden Sie weitere Informationen. Es gibt ihn kostenlos und in viele Sprachen übersetzt unter www.scrumguides.org. Weitere konkrete Umsetzungsempfehlungen finden Sie auch im Buch »Die Scrum Revolution« von Jeff Sutherland. Zwar markig amerikanisch, aber plastisch und aufschlussreich.