Schließen

Scrum

Nutzt die Stärken von Scrum mit unseren Profi-Tipps

Was ist Scrum?

Scrum ist ein Framework, das die Zusammenarbeit in Teams unterstützt. "Scrum" steht im Rugby für "Gedränge" – und genau wie ein Rugbyteam, das für das große Spiel trainiert, sind Teams mit Scrum in der Lage, durch Erfahrungen zu lernen, sich bei der Problembehebung selbst zu organisieren sowie ihre Erfolge und Niederlagen zu reflektieren, um sich kontinuierlich zu verbessern.

Scrum von Atlassian wird meist von Softwareentwicklern genutzt, doch das Prinzip und die gewonnenen Erkenntnisse treffen auf alle Arten von Teamwork zu. Darin liegt einer der Gründe, weshalb Scrum so beliebt ist. Scrum wird oft als ein agiles Projektmanagement-Framework beschrieben und umfasst Meetings, Tools und Rollen, die gemeinsam das Strukturieren und Managen der Teamarbeit unterstützen.

In diesem Artikel erklären wir euch mithilfe des Scrum-Leitfadens und David West, CEO von Scrum.org., wie ein klassisches Scrum-Framework aufgebaut ist. Außerdem stellen wir Beispiele vor, in denen unsere Kunden von diesem Standard abweichen, um die Lösung ganz ihren eigenen Anforderungen anzupassen. Dazu wird uns Megan Cook von Atlassian, Group Product Manager für Jira Software und früher Agile Coach, in unserer Agile Coach-Videoreihe ihre Tipps und Tricks verraten:

Scrum articles

[CONTINUED]

Das Framework

Viele denken, Scrum und Agile seien dasselbe, da sich bei Scrum alles um kontinuierliche Verbesserungen dreht – eines der Kernprinzipien von Agile. Jedoch handelt es sich bei Scrum um ein Framework zur Bewältigung von Aufgaben, während Agile eine Denkweise beschreibt. Man kann als Einzelner nicht wirklich "agil werden". Die Hingabe des gesamten Teams ist nötig, um einen neuen Denkansatz zur Wertschöpfung für den Kunden zu finden. Doch ein Framework wie Scrum kann euch helfen, diese neue Denkweise zu verfolgen und deine tägliche Kommunikation sowie deine täglichen Aufgaben auf Agile-Grundsätze auszurichten.

Scrum ist ein heuristisches Framework, denn es basiert auf kontinuierlichem Lernen und einer stetigen Anpassung an sich ändernde Faktoren. Es berücksichtigt, dass Teams zu Beginn eines Projekts noch nicht alles wissen können und sich erst durch Erfahrung weiterentwickeln. Scrum ist so aufgebaut, dass sich Teams neuen Bedingungen und Benutzeranforderungen ganz von selbst anpassen können. Durch den flexiblen Prozess, der das Festlegen neuer Prioritäten erlaubt, sowie kurze Release-Zyklen können Teams fortlaufend dazulernen und sich verbessern.

Das Scrum-Framework | Atlassian Agile Coach

Scrum gibt zwar eine Struktur vor, ist jedoch kein völlig starres System. So kann die konkrete Umsetzung des Frameworks an die individuellen Anforderungen eines Unternehmens angepasst werden. Es gibt viele Theorien darüber, welche konkreten Arbeitsweisen Scrum-Teams zum Erfolg führen. Atlassian unterstützt agile Teams nun seit mehr als zehn Jahren bei der Bewältigung ihrer Aufgaben und wir haben die Erfahrung gemacht, dass eine klare Kommunikation, Transparenz sowie eine Hingabe für kontinuierliche Verbesserung stets im Mittelpunkt stehen sollten, gleich welches Framework ihr nutzt. Alles andere bleibt euch überlassen.

Scrum-Artefakte

Beginnen wir mit den drei Artefakten in Scrum. Artefakte werden von uns erstellt, wie ein Tool zum Lösen eines Problems. Diese drei Artefakte in Scrum sind das Produkt-Backlog, das Sprint-Backlog und ein Inkrement, dessen Ziel ihr selbst bestimmt. Es gibt 3 Bezugspunkte, auf die ein Scrum-Team immer wieder zurückkommt und an denen es im Laufe der Zeit arbeitet.

  • Das Produkt-Backlog ist die Hauptliste mit den zu erledigenden Aufgaben. Sie wird vom Product Owner oder Produktmanager verwaltet. Diese dynamische Liste an Features, Anforderungen, Verbesserungen und Fehlerbehebungen fließt in den Sprint-Backlog ein. Das ist im Grunde genommen die "To-do-Liste" des Teams. Auf das Produkt-Backlog wird fortlaufend zurückgegriffen und es wird ständig neu priorisiert. Die Verwaltung übernimmt der Product Owner, denn wenn wir Erkenntnisse gewinnen oder sich der Markt verändert, sind manche Aufgabenelemente womöglich nicht mehr relevant oder Probleme lassen sich auf andere Weise lösen.
  • Unter dem Sprint-Backlog versteht man eine Liste an Elementen, User Storys oder Fehlerbehebungen, die ein Entwicklerteam zur Implementierung im aktuellen Sprint-Zyklus auswählt. Vor jedem Sprint entscheidet das Team im Sprint-Planungsmeeting (auf das wir später eingehen), an welchen Elementen aus dem Produkt-Backlog es in einem Sprint arbeiten will. Ein Sprint-Backlog kann flexibel sein und sich während eines Sprints weiterentwickeln. Das grundlegende Sprint-Ziel jedoch – d. h. was das Team mit dem aktuellen Sprint erreichen will – muss erfüllt werden.
  • Inkrement (oder Sprint-Ziel) ist das nutzbare Endprodukt, das aus einem Sprint hervorgeht. Wir bei Atlassian präsentieren das "Inkrement" normalerweise bei einer Demo am Sprint-Ende, in der das Team zeigt, was es in dem Sprint zustande gebracht hat. Vielleicht habt ihr das Wort "Inkrement" noch nie gehört. Damit gemeint sind oft die Aufgaben, die ein Team erledigen will, ein Meilenstein, ein Sprint-Ziel oder gar eine Vollversion oder ein ausgeliefertes Epic. Das hängt ganz davon ab, was ein Team erreichen möchte und welche Sprint-Ziele es festgesetzt hat. Beispielsweise beschließen manche Teams, ihren Kunden am Ende jedes Sprints einen Release bereitzustellen. Ihr angestrebtes Ziel lautet also "ausliefern". Für andere Teams ist dieses Ziel womöglich unrealistisch. Nehmen wir an, ihr arbeitet an einem serverbasierten Produkt, das ihr nur einmal im Quartal an den Kunden ausliefern könnt. Trotzdem könnt ihr zweiwöchige Sprints festlegen und es euch zum Ziel setzen, bereits einen Teil der Version, die ihr am Schluss als Ganzes ausliefern wollt, abzuschließen. Doch je länger ein Software-Release dauert, umso höher ist das Risiko, dass die Software misslingt.

Wie ihr seht gibt es viele Varianten, selbst bei den Artefakten, die euer Team für sich bestimmen kann. Daher ist es wichtig, offen zu bleiben für die Entwicklung neuer Wege, auch die zur Handhabung eurer Artefakte. Vielleicht habt ihr euch ein Ziel gesetzt, das für euer Team stressige Korrekturarbeiten mit sich bringt. Dann müsst ihr einen Schritt zurückgehen und euer Ziel neu definieren.

Profitipp

Ihr solltet mit eurem Framework so flexibel umgehen wie auch mit dem Produkt. Nehmt euch die nötige Zeit für Überprüfungen und falls nötig auch für Anpassungen. Erzwingt nichts, nur um Konsistenz zu wahren.

Scrum-Zeremonien oder -Ereignisse

Zu den bekannteren Komponenten des Scrum-Frameworks gehören eine Reihe von aufeinander folgenden Ereignissen, Zeremonien oder Meetings, die Scrum-Teams regelmäßig durchführen. Wir beobachten große Unterschiede zwischen den Zeremonien verschiedener Teams. Zum Beispiel finden manche Teams diese Zeremonien mühsam und monoton, während andere Teams Zeremonien als notwendige Überprüfung nutzen. Wir empfehlen euch, zunächst zwei Sprints lang alle Zeremonien durchzugehen und erst danach zu entscheiden, was ihr übernehmt. Ihr könnt dann eine kurze Retrospektive durchführen, um herauszufinden, was ihr anpassen müsst.

 

Wir stellen euch die wichtigsten Zeremonien vor, die Scrum-Teams nutzen können:

  1. Organisation des Backlogs: Für dieses Ereignis, das auch Backlog-Grooming genannt wird, ist der Product Owner verantwortlich. Der Product Owner ist vor allem dafür zuständig, dass das Produkt sich der Produktvision entsprechend entwickelt, und markt- und kundenbezogene Veränderungen zu verfolgen. Dazu führt er eine Liste, in der Feedback von Benutzern und dem Entwicklerteam eingetragen werden. So können Prioritäten festgelegt und die Übersicht bewahrt werden, damit eine Bearbeitung der Punkte zu gegebener Zeit möglich ist. Mehr über die sinnvolle Pflege eines Backlogs erfahrt ihr hier.

  2. Sprint-Planung: In diesem Meeting werden die durchzuführenden Aufgaben (der Umfang) während des aktuellen Sprints vom gesamten Entwicklerteam geplant. In diesem Meeting, das vom Scrum Master geleitet wird, legt das Team das Sprint-Ziel fest. Der Sprint wird dann durch konkrete User Storys aus dem Produkt-Backlog ergänzt.  Diese Storys sind immer auf das Ziel ausgerichtet und werden vom Scrum-Team gemeinsam festgelegt, damit sie während des Sprints implementierbar sind.

    Am Ende des Planungsmeetings sollte jedem Scrum-Teammitglied klar sein, was die Auslieferung des Sprints umfassen kann und wie der Inkrement ausgeliefert werden kann.

  3. Sprint: Ein Sprint ist der tatsächliche Zeitraum, in dem das Scrum-Team am Abschluss des Inkrements arbeitet. Typischerweise dauert ein Sprint zwei Wochen. Manche Teams finden einwöchige Sprints besser zu bewältigen und wieder andere legen einen Monat fest, um ein wichtiges Inkrement auszuliefern. Dave West von Scrum.org empfiehlt, Sprints umso schneller abzuschließen, je komplexer die Aufgaben und je mehr Unbekannte vorhanden sind. Doch das liegt ganz bei eurem Team. Wenn etwas nicht funktioniert, solltet ihr euch nicht davor scheuen, Änderungen vorzunehmen. In dieser Zeit kann der Umfang der Aufgaben wenn nötig gemeinsam von Product Owner und Entwicklerteam neu bestimmt werden. Das ist der Knackpunkt des erfahrungsbasierten Ansatzes von Scrum.

    Alle Ereignisse – von der Planung bis hin zur Retrospektive – finden während des Sprints statt. Wenn ein zeitlicher Rhythmus für einen Sprint festgelegt wurde, muss dieser über die gesamte Entwicklung hinweg beibehalten werden. So können Teams aus ihren Erfahrungen lernen und diese Erkenntnisse auf geplante Sprints anwenden.

  4. Tägliche Scrums oder Stand-up-Meetings: Darunter versteht man ein tägliches, sehr kurzes Meeting, das praktischerweise immer zur selben Zeit (meist morgens) und am selben Ort stattfindet. Viele Teams wollen das Meeting auf 15 Minuten beschränken. Das soll jedoch nur zur Orientierung dienen. Man spricht auch von einem "täglichen Stand-up-Meeting", was verdeutlicht, dass die Besprechung wirklich nur sehr kurz sein sollte. Im täglichen Scrum soll jeder im Team auf denselben Stand gebracht werden, sich auf das Sprint-Ziel ausrichten und einen Plan für die nächsten 24 Stunden entwickeln.

    Das Stand-up-Meeting bietet Gelegenheit, Bedenken zu äußern, die beim Erreichen des Sprint-Ziels und bezüglich Hindernissen bestehen.

    Eine gängige Methode für Stand-up-Meetings sieht vor, dass jedes Teammitglied drei Fragen zum Erreichen des Sprint-Ziels beantwortet:

    •      Was habe ich gestern gemacht?
    •      Was will ich heute tun?
    •      Gibt es irgendwelche Hindernisse?

    Wir haben jedoch beobachtet, dass viele schnell dazu neigen, einfach ihre Kalendereinträge für den gestrigen und den kommenden Tag vorzulesen. Der Grundgedanke hinter Stand-up-Meetings ist jedoch, dass keine Gespräche aufkommen, die in täglichen Besprechungen störend sind, damit das Team sich auf die Aufgaben des restlichen Tages konzentrieren kann.  Wenn sich das Meeting also zum reinen Kalendervorlesen wird, scheut euch nicht, für Schwung zu sorgen und kreativ zu werden.

  5. Sprint-Review: Am Ende des Sprints kommt das Team in einer informellen Sitzung zusammen, um sich eine Demo des Inkrements anzusehen oder den Inkrement unter die Lupe zu nehmen. Das Entwicklerteam präsentiert die Backlog-Elemente, die jetzt erledigt und für Feedback von Stakeholdern und Teamkollegen freigegeben sind. Der Product Owner entscheidet, ob der Inkrement releast wird, was in den meisten Fällen aber auch geschieht.

    In diesem Review-Meeting überarbeitet der Product Owner zudem den Produkt-Backlog basierend auf dem aktuellen Sprint. Das Ergebnis kann dann in die nächste Sprint-Planungssitzung einfließen. Begrenzt den Sprint-Review für einen einmonatigen Sprint auf maximal vier Stunden.

  6. Sprint-Retrospektive: Bei einer Retrospektive dokumentiert und diskutiert das Team darüber, was in einem Sprint, einem Projekt, bei bestimmten Personen oder Beziehungen, bei Tools oder auch bestimmten Zeremonien funktioniert hat und was nicht. Das soll dem Team die Möglichkeit geben, sich nicht auf Misserfolge, sondern auf Erfolge zu konzentrieren und herauszustellen, was beim nächsten Mal besser laufen muss.

Drei wesentliche Rollen für den Erfolg von Scrum

In einem Scrum-Team sind drei Rollen erforderlich: Product Owner, Scrum Master und Entwicklerteam. Und da Scrum-Teams funktionsübergreifend sind, umfasst das Entwicklerteam neben den Entwicklern auch Tester, Designer, UX-Spezialisten und Betriebstechniker.  

Der Scrum-Product Owner

Product Owner sind verantwortlich für ihr Produkt. Sie konzentrieren sich darauf, Geschäfts-, Kunden- und Marktanforderungen zu analysieren und dann die für das Entwicklerteam anstehenden Arbeiten entsprechend zu priorisieren. Aufgaben effektiv arbeitender Product Owner:

  • Entwickeln und Managen des Produkt-Backlogs
  • Enge Zusammenarbeit mit dem Unternehmen und dem Team, um sicherzustellen, dass alle die Aufgabenelemente im Produkt-Backlog verstehen
  • Klare Anweisungen an das Team, welche Features als Nächstes ausgeliefert werden sollen
  • Entscheidung, wann das Produkt ausgeliefert werden soll, mit Tendenz zu einer häufigeren Auslieferung

Der Product Owner ist nicht immer der Produktmanager. Product Owner konzentrieren sich darauf, sicherzustellen, dass das Entwicklerteam den für das Unternehmen größtmöglichen Wert schafft. Außerdem sollte der Product Owner unbedingt eine Einzelperson sein. Kein Entwicklerteam braucht unterschiedliche Anweisungen von mehreren Product Ownern.

Der Scrum Master

Scrum Master sind innerhalb ihres Teams für das Gelingen von Scrum verantwortlich. Sie coachen das Team, den Product Owner und das Unternehmen in Bezug auf den Scrum-Prozess und suchen nach Wegen, dessen Umsetzung abzustimmen.

Ein effektiv arbeitender Scrum Master hat ein tief gehendes Verständnis für die vom Team ausgeführten Aufgaben und kann dem Team helfen, seine Transparenz und seinen Auslieferungsprozess zu optimieren. Als Hauptvermittler plant er die erforderlichen Ressourcen (sowohl Personal als auch Logistik) für die Sprint-Planung, die Stand-up-Meetings, den Sprint-Review und die Sprint-Retrospektive ein.

Das Scrum-Entwicklerteam

Scrum-Teams sind echt produktiv. Sie sind verantwortlich für nachhaltige Entwicklungsverfahren. Effektive Scrum-Teams arbeiten eng an einem gemeinsamen Standort zusammen und haben für gewöhnlich fünf bis sieben Mitglieder. Die Größe des Teams könnt ihr zum Beispiel mit der bekannten "Zwei-Pizza-Regel" von Jeff Bezos, dem CEO von Amazon, ausloten: Ein Team sollte sich zwei Pizzas teilen können.

Die Teammitglieder verfügen über unterschiedliche Kompetenzen und schulen sich gegenseitig, um durch Personen verursachte Engpässe bei der Auslieferung der Aufgaben zu verhindern. Erfolgreiche Scrum-Teams sind in der Lage, sich selbst zu organisieren, und gehen ihre Projekte mit einer klaren "Wir"-Haltung an. Alle Mitglieder des Teams unterstützen sich gegenseitig, um einen erfolgreichen Scrum-Abschluss sicherzustellen.

Das Scrum-Team steuert die Planung für jeden Sprint. Die Mitglieder analysieren, wie viel Arbeit sie ihrer Meinung nach im Verlauf der Iteration abschließen können, basierend auf ihrer bisherigen Velocity. Eine feste Länge der Iteration gibt dem Entwicklerteam wichtiges Feedback zum Schätzungs- und Auslieferungsprozess, was wiederum ihre Prognosen über die Zeit zunehmend präzisiert.

Scrum, Kanban und Agile

Das Agile-Framework Scrum ist so bekannt, dass Scrum und Agile oft fälschlicherweise für ein und dieselbe Lösung gehalten werden. Doch es gibt auch andere Frameworks, wie etwa die sehr beliebte Alternative Kanban. Manche Unternehmen wählen auch ein hybrides Modell aus Scrum und Kanban, das "Scrumban" oder "Kanplan" genannt wird und einen Kanban mit einem Backlog bezeichnet.  

Sowohl in Scrum als auch in Kanban lässt sich der Fortschritt der Arbeit z. B. mit dem Scrum Board oder dem Kanban Board visuell nachverfolgen. Beide Frameworks stellen die Effizienz heraus und teilen komplexe Aufgaben in kleinere, besser handhabbare Blöcke auf. Sie unterscheiden sich jedoch in ihrem Ansatz diesbezüglich.

Scrum legt einen Schwerpunkt auf kleinere Iterationen mit einer festen Dauer. Sobald die Zeit für einen Sprint abgelaufen ist, werden die Storys oder Einträge des Produkt-Backlogs bestimmt, die während dieses Sprint-Zyklus implementiert werden können. In Kanban werden jedoch die Anzahl der Aufgaben oder die laufenden Arbeiten (WIP-Grenze), die im aktuellen Zyklus zu implementieren sind, zuerst festgelegt. Die Zeit, die zur Implementierung dieser Features benötigt wurde, wird dann im Nachhinein berechnet.

Kanban ist weniger strukturiert als Scrum. Abgesehen von der WIP-Grenze kann das Framework frei ausgelegt werden. Scrum hingegen sieht mehrere kategorische Konzepte vor, die im Rahmen der Implementierung erzwungen werden, wie etwa Sprint-Reviews, Retrospektiven, tägliche Scrums etc. Außerdem ist ein funktionsübergreifendes Vorgehen vorgegeben, was bedeutet, dass Scrum-Teams beim Erreichen ihrer Ziele nicht von externen Kollegen abhängig sind. Der Aufbau eines funktionsübergreifenden Teams ist jedoch nicht ganz einfach. In diesem Punkt lässt sich Kanban einfacher anpassen. Jedoch ermöglicht Scrum eine grundlegende Änderung des Denkansatzes und der Arbeitsweise von Entwicklerteams.

Was spricht für Scrum?

Das Scrum-Framework selbst ist einfach. Regeln, Artefakte, Ereignisse und Rollen sind leicht verständlich. Sein Ansatz ist nur teilweise festgesetzt und hilft sogar, Unklarheiten im Entwicklungsprozess zu beseitigen. Dabei haben Unternehmen zugleich genügend Raum, um ihren eigenen Akzent zu setzen.

Scrum ist durch die Aufteilung komplexer Aufgaben in gut handhabbare User Storys ideal für schwierige Projekte geeignet. Die klare Abgrenzung von Rollen und geplanten Ereignissen sorgt für Transparenz und fördert ein kollektives Verantwortungsgefühl im gesamten Entwicklungszyklus. Dank zügiger Releases bleibt das Team motiviert und die Zufriedenheit der Kunden ist sichergestellt, da Benutzer bereits innerhalb kurzer Zeit Fortschritte erkennen können.

Jedoch muss das Entwicklerteam Zeit zur Einarbeitung einplanen, vor allem dann, wenn sie es gewohnt waren, mit einem typischen Wasserfallmodell zu arbeiten. Kleinere Iterationen, tägliche Scrum-Meeting, Sprint-Reviews und das Bestimmten eines Scrum Masters sind Konzepte, die neue Teams womöglich mit einem grundlegenden kulturellen Wandel konfrontieren.


Die langfristigen Vorteile machen jedoch den lernintensiven Einstieg wett. Die erfolgreiche Entwicklung komplexer Hardware- und Softwareprodukte in verschiedenen Branchen und Sektoren macht Scrum auch für euer Unternehmen zum attraktiven Framework.

 

Claire Drumond
Claire Drumond

Claire Drumond ist Marketingstrategin, Sprecherin und Texterin für Atlassian. Sie hat zahlreiche Artikel verfasst, die auf Trello- und Atlassian-Blogs erschienen sind, und wirkt regelmäßig an Veröffentlichungen auf Medium mit, darunter HackerNoon, Art+Marketing sowie PoetsUnlimited. Auf Technologiekonferenzen weltweit spricht sie über Agile, das Aufbrechen von Silos und den Aufbau von Empathie.
Twitter: @claire_drumond // Medium: @cdrumond

Up Next
Sprints