Das agile Framework der SCRUM-Methode einfach erklärt.
Bestimmt haben Sie schon von Firmen gehört, die agil arbeiten und für ihre Projekte SCRUM nutzen. Aber wissen Sie auch, was genau das beinhaltet? Was SCRUM überhaupt bedeutet und wann es sinnvoll ist? Falls Sie an der ein oder anderen Stelle noch unsicher sind, wird dieser Beitrag Ihnen hoffentlich weiterhelfen. Denn wir gehen die wichtigsten Eckpunkte, Definitionen und Leitgedanken durch, die der SCRUM-Methodik zugrunde liegen:
Der folgenden Beitrag erklärt:
Definition und Methodik: Was ist SCRUM?
SCRUM bezeichnet ein Projektmanagement-Framework, das von der klassischen Hierarchie eines Aufgaben verteilenden Projektleiters abweicht und stattdessen auf den agilen Werten Mut, Offenheit, Fokus, Respekt und Engagement beruht. Wie diese Werte aktiv gelebt werden, wird offengelassen. Das gibt den Teammitgliedern, die mit SCRUM arbeiten, eine immense Freiheit. Ursprünglich wurde SCRUM vor allem im Bereich der Software-Entwicklung eingesetzt.
Mittlerweile ist es aber für alle Arten von Projekten beliebt. Tendenz steigend. Denn: Mit SCRUM bleiben Projektteams agil. Statt starrer Vorgaben und einmal festzementierter Abläufe gibt es Feedbackschleifen und Anpassungen an aktuelle Gegebenheiten – ein unschätzbarer Vorteil in unserer VUKA-Welt.
Da SCRUM als Framework gedacht ist, existieren keine feste Methoden oder Techniken, sondern ein loses Rahmenwerk. Dieser Rahmen – oder auch Frame – hilft nicht nur, komplexe Softwarelösungen zu entwickeln, sondern bei jeglichen vielschichtigen Problemen und Fragestellungen. SCRUM basiert auf Empirie und hängt maßgeblich vom Umgang mit Fehlern und den gemachten Erfahrungen ab.
Das Wort SCRUM kommt aus dem Englischen, genauer gesagt aus dem „Rugby-Lexikon“ und bedeutet „Gedränge“. Ähnlich wie bei einem Rugby-Spiel hängt der Erfolg eines Projektes von gutem Teamwork, einer klaren Kommunikation und der Akzeptanz des eigenen Unwissens ab: Wir können schlicht nicht mit Gewissheit sagen, wie ein Spiel ausgehen wird – dasselbe gilt bei Projekten.
1995 hat Ken Schwaber auf der Konferenz OOPSLA zum ersten Mal seine Gedanken zu SCRUM und agiler Softwareentwicklung veröffentlicht: „Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.“
Ersetzen Sie „Software“ durch jedes beliebige Projekt oder Produkt, an dem Sie und Ihr Team gerade arbeiten, und Sie haben es: Bei SCRUM geht es darum, zu jedem Zeitpunkt ein Ergebnis zu haben, das theoretisch veröffentlicht werden könnte, und dieses weiter und weiter agil zu verfeinern und zu verbessern.
Die Rollen im SCRUM
Ein SCRUM-Team ist idealerweise sechs bis neun Personen stark, von denen jede eine spezielle Aufgabe, auch Rolle genannt, innehat.
Der Product Owner
Der Product Owner (PO) vertritt die Interessen des Kunden. Er ist der Auftraggeber, möglicherweise sogar der Kunde selbst. Er hat das größte Interesse daran, ein qualitativ hochwertiges Produkt zu entwickeln, denn schließlich zahlt er die Rechnung. Zudem verwaltet er das Backlog (ich gehe weiter unten darauf ein, was das ist) und legt somit fest, in welcher Reihenfolge die Aufgaben erledigt werden müssen. Die wichtigsten Vorstellungen und Wünsche haben immer die höchste Prio, weil sie die größten Vorteile bringen. Er steht in regem Austausch mit den Stakeholdern, weiß, was diese sich wünschen, und gibt das ans Team weiter.
Der Scrum Master
Der Scrum Master (SM) unterstützt den Prozess. Er begleitet das Team, indem er darauf achtet, dass die SCRUM-Prinzipien angewandt und eingehalten werden und die Rahmenbedingungen, wenn nötig, optimiert. Zudem ist er für die Organisation der Meetings verantwortlich und kümmert sich um die Räumlichkeiten und die Bereitstellung von Soft- und Hardware. Er ist derjenige, der dafür sorgt, dass das Team ungestört arbeiten kann. Ein Scrum Master darf aber nicht mit einem Projektleiter verwechselt werden! Damit die Offenheit und Zusammenarbeit gefördert werden, kümmert sich der Scrum Master beispielsweise nicht um Personalangelegenheiten wie die Auswahl, Beurteilung und Entlohnung der Teammitglieder.
Dev Team Entwickler
Das Entwickler-Team kümmert sich schließlich, wie der Name bereits verrät, darum, dass das Produkt entwickelt wird, und ist dabei für jedes Stadium verantwortlich: Analyse, Entwurf, Entwicklung, Tests und Dokumentation. Es ist interdisziplinär aufgestellt und liefert die Ergebnisse am Ende eines Sprints. Die Teammitglieder sorgen dafür, dass das Produkt den Vorstellungen des Kunden entspricht. In den meisten Fällen besteht das Entwickler-Team aus drei bis neun Personen, die ihre Arbeit eigenverantwortlich organisieren.
Obwohl in einem SCRUM-Team jeder seine eigene Rolle ausfüllt, steht eine gute Zusammenarbeit immer an erster Stelle. Ein wichtiger Faktor für den Erfolg von SCRUM ist die Fähigkeit des Teams, sich selbst zu organisieren.
„Agilität bedeutet proaktives und antizipatives Handeln in einer kaum vorhersehbaren Umwelt.“ (Horst Wildemann)
Die Ereignisse in SCRUM
Die Ereignisse innerhalb eines SCRUM-Projekts werden auch Events genannt. Sie zeigen bereits ganz gut, wie sich ein Projekt gliedert und welche die Kernelemente sind:
Sprint Planning
Projekte in SCRUM werden in sogenannten Sprints (=kurze Entwicklungseinheiten) umgesetzt. Die Sprints dauern für gewöhnlich zwei bis vier Wochen, können aber durchaus auch kürzer oder länger sein. Dies entscheidet das SCRUM-Team gemeinsam.
Zu Beginn jedes Sprints gibt es ein Meeting, um zu planen, was innerhalb des Sprints umgesetzt werden soll. Das Entwicklungs-Team bestimmt die Art und Weise, auf die genau das geschehen kann. Die festgelegten Arbeitsschritte werden im Backlog festgehalten.
Daily Scrum
Während eines laufenden Sprints tauschen die Entwickler sich untereinander im „Daily“ aus. Dabei geht es vor allem darum, kurz zu illustrieren, woran jeder Einzelne am Vortag gearbeitet hat, was für den kommenden Tag ansteht und wo Hürden aufgetaucht sind, die die Sprintziele gefährden könnten. Das Daily sollte nie länger als 15 Minuten dauern und kann, um die lockere Atmosphäre zu untermalen, im Stehen abgehalten werden.
Sprint Retrospektive
Das letzte Sprint-Ereignis ist die Retrospektive, in der das gesamte Team zusammenkommt und reflektiert, was im vorangegangenen Sprint gut oder weniger gut funktioniert hat, wo Absprachen verändert, verbessert oder Tools ersetzt werden sollten. So wird sichergestellt, dass die Zusammenarbeit sich von Sprint zu Sprint iterativ verbessert.
"Scrum ist wie deine Schwiegermutter, es deckt all deine Fehler auf.“ (Ken Schwaber)
Abbildung: Scrum.org
Die Artefakte in SCRUM
Artefakte – das klingt ein wenig altertümlich und fast nach Schatzsuche. Und so ähnlich ist es auch. Die Artefakte in einem SCRUM-Projekt sind Dokumente, die definieren, was noch zu erledigen ist, um ein präsentationsfähiges (Zwischen-)Ergebnis zu erhalten. Wie bei den Rollen gibt es auch hier drei an der Zahl.
Product Backlog
Das Product Backlog wird vom Product Owner geführt und ständig aktualisiert. Hier sind die Anforderungen an das zu entwickelnde Produkt festgehalten. Um den Prozess agil zu halten und am Ende wirklich das bestmögliche Ergebnis bzw. Produkt zu haben, sind die Anforderungen nicht in Stein gemeißelt, sondern können sich stetig verändern; einige können komplett wegfallen, andere hinzukommen. Wichtig ist, dass sie den Prioritäten nach geordnet werden. Das Wichtigste immer zuerst.
Sprint Backlog
Aus dem Product Backlog werden zu Beginn eines Sprints jeweils die Anforderungen entnommen, die erledigt werden müssen. Im Sprint-Planning werden diese in konkrete Aufgaben übersetzte.
Product Increment
Das Product Increment ist das Zwischenergebnis, das am Ende eines Sprints vorliegt. Im besten Fall wurden alle Anforderungen des Sprints erfüllt.
Wie läuft ein Projekt nach SCRUM ab?
Hat sich das SCRUM-Team zusammengefunden, beginnt das eigentliche Projekt mit dem Product Owner. Dieser befüllt das Product Backlog mit dem Produktziel und den Anforderungen an das zu entwickelnde Produkt. Darauf folgt das erste Sprint Planning, das bei einem Vier-Wochen-Sprint acht Stunden dauert. Dort werden die Anforderungen aus dem Product Backlog bestimmt, die im folgenden Sprint vom Team umgesetzt werden sollen. Ein Sprint kann bis zu vier Wochen dauern, aber auch einwöchige Sprints sind durchaus üblich. Nach dem Sprint folgen Sprint Review und Sprint Retrospektive. Anschließend aktualisiert der Product Owner das Backlog und es geht mit dem nächsten Sprint weiter wie oben beschrieben.
“Agilität ist das Gegenteil von Planerfüllung, hat aber nichts mit Planlosigkeit zu tun. An die Stelle starrer Ziele treten viel mehr Visionen.” (Horst Wildemann)
Die 12 Prinzipien des agilen Arbeitens:
SCRUM basiert auf den agilen Werten und Prinzipien, die im agilen Manifest festgehalten wurden. Lesen Sie dazu auch meinen Beitrag zum Thema Agile Werte.
Im Folgenden sind die 12 Prinzipien, die dem Framework SCRUM zugrunde liegen, dargestellt:
„Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.“
„Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“
„Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.“
„Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.“
„Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.“
„Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“
„Funktionierende Software ist das wichtigste Fortschrittsmaß.“
Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.“
„Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.“
„Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.“
„Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbst organisierte Teams.“
„In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.“
Fehler bei der Anwendung des SCRUM-Frameworks
Obwohl das SCRUM-Framework unglaublich viele Freiheiten bietet und agiles Arbeiten gerade dadurch enorm erleichtert, gibt es einige Fehler, die man vermeiden sollte. Größtenteils liegen die darin begründet, genau diese Selbstbestimmung und -organisation des Teams wieder zu limitieren:
Team-Mitglieder kennen die agilen Werte und Arbeitsweisen nicht und wollen so nicht arbeiten: Die Mitglieder des Teams sollten grundsätzlich mit der agilen Arbeitsweise vertraut sein und diese auch annehmen. Ansonsten entstehen innere Hürden, die Motivation sinkt und Selbstorganisation wird verhindert.
Die Rollen sind unklar: Zwei Product Owner oder kein Scrum Master? Zu wenig ist genauso schlecht, wie zu viel. Es gibt einen Owner, einen Master und auch das Team selbst sollte nicht aus mehr als neun Personen bestehen. Darüber hinaus müssen die Rollen erfüllt werden. Nicht mehr, nicht weniger. Stakeholder sollten nur mit dem Product Owner sprechen und ihre Wünsche nicht „auf dem kurzen Dienstweg“ zusätzlich mit zwei oder drei Team-Mitgliedern teilen, die dann die Priorisierung durcheinanderbringen.
Mehrere Projekte gleichzeitig: Jedes Team-Mitglied sollte nur in einem Projekt involviert sein, um hier den vollen Impact bringen zu können.
Team-Mitglieder werden zu Ressourcen: Plötzlich gibt es doch wieder Anweisungen bezüglich Arbeitsort und -weise? Dann werden die Team-Mitglieder von Individuen zu Ressourcen. Agiles Arbeiten kann nicht stattfinden.
Das Team ist kein Team: Wenn aus dem Daily ein Weekly wird und daraus ein Bi-Weekly geht der Austausch der Team-Mitglieder verloren. Sie können nicht mehr flexibel reagieren, wissen nicht, woran gearbeitet wird oder gearbeitet werden sollte und das Projekt gerät ins Stocken.
Fazit und Zusammenfassung
Das agile Framework SCRUM bietet einen Rahmen, um produktives und „nach vorn gedachtes“, schnelles und flexibles Handeln in Unternehmen und Organisationen umzusetzen. Ob Teams umfassend und gemäß SCRUM-Guide arbeiten oder sich einzelner Elemente wie z. B. Sprints oder der Retrospektive bedienen – es geht um Iteration, Schnelligkeit, Anpassungsfähigkeit, Liefern und Kundenzentrierung. Eben genau das, was es in einer VUKA-Welt braucht, um nicht unterzugehen.
Sie wollen Ihr Unternehmen auf agile Beine stellen? Hier erfahren Sie mehr zu meinen Angeboten Organisationsentwicklung und Führungskräftetraining.