Das Scrum-Team als Kern im agilen Projektmanagement

Der Scrum Guide benennt drei Rollen für agiles Arbeiten: Product Owner, Scrum Master und Entwicklungsteam (Scrum Team).

Mehr braucht es nicht in der schlanken und flexiblen Arbeitswelt, um neue Services oder Produkte zu entwickeln. In meinem Beitrag verwende ich den Begriff Scrum-Team, um die Rolle des Entwicklerteams zu beschreiben.

Für die Abgrenzung von dessen Tätigkeiten sind die Aufgaben der anderen Rollen an dieser Stelle grob skizziert:

Product Owner

Hauptaufgabe des Product Owner ist, Mehrwert für den Kunden zu schaffen. Er ist für die Gestaltung des Produktkerns verantwortlich. Sein wichtigstes Werkzeug ist das Product Backlog, in dem er User Storys, Epics und Tasks sammelt.

Der Product Owner sollte darauf achten, für das Scrum-Team stets verfügbar zu sein, um Antworten über die Ausgestaltung des neuen Produktes oder Services schnell zu liefern. So können die Mitglieder des Scrum-Teams ohne Unterbrechungen weiterarbeiten.

Scrum Master

Der Scrum Master hilft dem Product Owner beim Formulieren der Einträge in das Backlog. Als Servant Leader sorgt er dafür, dass sich das Team selbst organisieren kann und unterstützt es mit Rat und Tat, insbesondere wenn das agile Arbeiten neu für es ist.

Auf den Säulen Transparenz, Überprüfung und Anpassung ruht das agile Wertesystem. Es hilft den Beteiligten, eine Antwort auf die Frage „Wie sollte etwas sein?“ zu finden.

Dieses ständige Ausprobieren, Reflektieren und Verbessern ist der Kern des agilen Arbeitens und damit wesentliches Unterscheidungsmerkmal gegenüber der Arbeitsweise traditioneller Teams.

Der Scrum Guide weist darauf hin, dass das Team die Werte Selbstverpflichtung, Mut, Fokussierung, Offenheit und Respekt nicht nur kennen, sondern auch leben muss, um seine Ziele erreichen zu können.

Selbst organisiertes Scrum-Team

Das wohl wichtigste Merkmal eines Scrum-Teams ist die Selbstorganisation. Sobald der Product Owner mit dem Product Backlog den Kurs vorgegeben hat, liegt es am Scrum-Team, die Realisierung zu organisieren. Niemand, auch nicht der Scrum-Master, wird ihm vorschreiben, wie es beim Fertigstellen der Anforderungen vorgehen will.

Das Scrum-Team wählt auch die passenden Werkzeuge aus, überwacht selbst den Fortschritt der Arbeiten, reflektiert Vor- und Nachteile seiner Arbeit und leitet selbstständig Verbesserungsmaßnahmen ein. Das setzt ein Arbeiten im oben beschriebenen Wertesystem voraus.

Das Scrum-Team muss gut eingespielt sein, um sein Potenzial voll entfalten zu können. Jeder muss wissen, was er zu tun hat, und darauf vertrauen, das sein Nachbar genau den gleichen Anspruch verfolgt.

Doch die Selbstorganisation trifft bei unerfahrenen Scrum-Teams an ihre Grenzen. Der PMBOK Guide des Project Management Institute (PMI) schreibt im Kapitel X3.3.3, dass „Junior-Teams, die an hochgradig adaptiven Projekten arbeiten, Coaching und Abteilungszugehörigkeit brauchen, bevor sie diesen Grad an Eigenverantwortung erreichen“.

Gruppengröße

Zur Selbstorganisation zählt auch die Wahl der passenden Gruppenstärke sowie die Zusammensetzung des Teams. Eine Gruppengröße zwischen fünf und neun Mitgliedern hat sich als praktisch erwiesen.

Damit ist das Scrum-Team groß genug, um die Arbeit innerhalb eines Sprints zu bewältigen, und klein genug, um Informationen ohne Reibungsverluste auszutauschen. Die Gruppenmitglieder sollten aus unterschiedlichen Fachbereichen kommen. Welche das genau sind, legt das Sprint- und Projektziel fest. So können die Teammitglieder aus den Fachbereichen Softwareentwicklung, Architektur, Produktentwicklung, Sicherheit, Design oder Redaktion kommen.

Arbeitsort

Idealerweise arbeiten alle Kollegen in einem Büro. So können sie sich schnell austauschen. Idealerweise arbeitet auch der Product Owner in diesem Raum. Dann kann er schnell Klarheit schaffen bei Fragen zur Ausgestaltung des Produktkerns.

In vielen Unternehmen setzt sich das mobile Arbeiten immer mehr durch. Doch auch wenn das Scrum-Team im Homeoffice arbeitet, ist das oberste Ziel, Informationen fließen zu lassen und Missverständnisse in der Kommunikation zu vermeiden.

Soft Skills

Die Mitglieder des Scrum-Teams sollten teamfähig, gut organisiert, konfliktfähig, flexibel, kreativ und kommunikationsstark sein.

Hauptaufgabe des Scrum-Teams ist es, ein fehlerfrei funktionierendes Produkt oder einen fehlerfrei funktionierenden Service nach den Vorgaben des Product Owner abzuliefern.

Sprint Planning Meeting

Vor dem Start des Sprints präsentiert der Product Owner die wichtigsten Funktionen, die er nach dem Sprint umgesetzt sehen will.

Das Scrum-Team schätzt deren Realisierungsaufwand ein und fügt gegebenenfalls weitere, inhaltlich dazu passende Anforderungen aus dem Backlog ein. Es ist durchaus möglich, dass dadurch niedriger priorisierte User Storys nach oben rutschen.

Doch wenn sie im Zuge der Umsetzung für das gewünschte Feature mit erledigt werden können, ist das eine sinnvolle Vorgehensweise. Für die Sprint-Planung verordnet sich das Team einen festen zeitlichen Rahmen (Time Boxing), um sich nicht in endlosen Debatten zu verlieren. Ein frisches Sprint Backlog markiert das Ende der Planungen.

Aufwände schätzen

Planning Poker ist eine etablierte Vorgehensweise, um den Arbeitsaufwand in einem Sprint einschätzen zu können.

Daily Scrum

Das Scrum-Team trifft sich täglich zum Daily Scrum Meeting. Damit alles reibungslos abläuft, kümmert sich der Scrum Master um dessen Organisation. Damit hält er dem Scrum-Team den Rücken frei, sodass dieses sich auf sein Kerngeschäft, das Entwickeln, konzentriert. Für das Scrum-Team und den Scrum Master ist die Anwesenheit Pflicht, der Product Owner ist gern gesehen, doch ein Rederecht hat er nicht.

Sprint Review Meeting

Sobald der Sprint beendet ist, präsentiert das Srum-Team die fertig gestellte Arbeit. Eingeladen sind Product Owner, Scrum Master und Stakeholder. Dieses informelle Treffen ist kein Status-Meeting, sondern es dient den Teilnehmern zur Klärung, welche Funktionen als „fertig“ und welche als „offen“ zählen. Die gesamte Gruppe überlegt, wie sie weiter machen will, und fixiert die Änderungen in einem überarbeiteten Product Backlog.

Sprint Retrospective

Mit der Retrospective, das zwischen dem Sprint-Review und dem nächsten Sprint stattfindet, blickt das Scrum-Team in den Rückspiegel.

In dem etwa dreistündigen Meeting legt es seine Zusammenarbeit auf die Waage, prüft, ob die Arbeitsabläufe hilfreich und wirkungsvoll waren, und ob die Werkzeuge und Methoden passend ausgewählt wurden. Aus den gesammelten Erfahrungen leitet es ganz konkrete Maßnahmen für eine bessere Zusammenarbeit ab.

Scrum-Artefakte

Zu den drei Artefakten, wie sie der Scrum Guide beschreibt, gehören: Product Backlog, Sprint Backlog und Inkremente (z.B. Burn-Down-Chart).

Abschließend möchte ich darauf hinweisen, dass das Scrum-Team, entgegen den Projektmitgliedern des traditionellen Projektmanagements, keine Lastenhefte schreibt. Die Wünsche der Kunden und die der zukünftigen Nutzer sind im Product Backlog in Form von Epics oder User Storys enthalten.