Was ist eigentlich Scrum?

Ein Beitrag von: Alexander Krause
Was-ist-eigentlich-Scrum

Bildnachweis: © www.berlin-bits.de

Über Scrum Master, das agile Manifesto & Co.

Die meisten Unternehmen bewegen sich heute in zunehmend unberechenbaren Umgebungen. Klassische Projektmanagement-Methoden geraten dabei an ihre Grenzen.

Um den Ansprüchen nach Flexibilität, Planbarkeit, Nutzerorientierung und Mitarbeitermotivation gerecht zu werden hat die IT-Branche nun auf „agile Methoden“ umgestellt. Auch viele andere Branchen beginnen agiles Vorgehen einzusetzen. Mit einem Anteil von 86% ist Scrum die meist genutzte agile Methode (Studie Status Quo Agile 2014).

Das Wort Scrum entstammt dem Rugby und bedeutet „angeordnetes Gedränge“. Das Team drängt sich um die Aufgabe. Richtung, Regeln und Rollen sowie Zeit und Ort sind festgelegt aber im Gedränge kommunizieren die Teammitglieder und planen jeden Spielzug der Situation entsprechend neu, so reagieren sie auf das jeweilige Umfeld und werden mit jedem Angriff besser.

Scrum ist ein Management-Framework. Ganze Unternehmen lassen sich nach diesem Prinzip organisieren: Inkrementell und vollständig werden kleine Arbeitspakete geschnürt und umgesetzt, zwischen den Umsetzungszyklen kann die Richtung jeweils justiert werden.

Die Stärke von Scrum ist, in dynamischen Umfeldern Stabilität zu erzeugen, die allgemeine Lieferfähigkeit (wieder) herzustellen und die Qualität der Ergebnisse kontinuierlich zu verbessern. Scrum löst dabei keine Probleme sondern schafft einen Rahmen, sodass die beteiligten Personen und Abteilungen ihre Probleme erkennen und größtenteils selbst lösen können.

Scrum ist kein Add-on für klassisches Projektmanagement sondern eine Alternative:

3 Rollen und 6 Meetings in einem regelmäßigen Takt, mehr braucht es nicht.

Wer sich auf den Weg macht, Scrum zu erkunden braucht Mut und Ausdauer. Scrum erzeugt einige „quick wins“, aber im Grunde geht es um eine Veränderung von Kultur und Haltung.

Das bedeutet vor allem für große Unternehmen, dass es ein Management und Aktionäre geben muss, die an einer nachhaltigen Entwicklung des Unternehmens interessiert sind und nicht nur kurzfristige Boni und Gewinne fokussieren. Der Werte- und Kulturwandel ist eine langwierige und anstrengende Arbeit und muss gewollt werden.

Professionelle und langfristige Begleitung ist dabei hilfreich.

Im Folgenden liest Du detailliert:

Kernelemente von Scrum

Flexibel, stabil und selbstorganisiert:

Scrum errichtet aus Rollen (Container für Verantwortlichkeiten), Meetings und Zeitfenstern einen festen Rahmen, der für kurze Entwicklungszyklen Stabilität garantiert. So wird in dynamischen Umgebungen ein Raum abgegrenzt, in dem Selbstorganisation möglich wird.

Empirische Prozessteuerung und Pull-Prinzip:

Scrum setzt konsequent den Deming-Cycle (Plan-Do-Check-Act-(Re)Plan…) ein. Mit jedem Zyklus steigt daher die Genauigkeit der Planung, zusätzlich kann jeder kommende Zyklus kurzfristig durch die gemachten Erfahrungen verbessert und bei geänderten Bedingungen neu ausgerichtet werden.

Die Mitarbeiter erhalten zur Planung eine priorisierte Anforderungsliste (was soll umgesetzt werden?) und entscheiden selbst, wie viel sie davon im kommenden Zyklus umsetzen werden (Pull-Prinzip). Es entstehen keine Warteschlangen (Staus), die das System überlasten und kollabieren lassen.

Verantwortung an die Menschen, die das Wissen haben:

Nach dem „ziehen“ der Aufgaben beraten die Mitarbeiter selbst, wie die Umsetzung aussehen wird. Diese Beteiligung und dieses Mitdenken ermöglicht einen Fokus auf Qualität und elegante Lösungen sowie auf das Teilen von Wissen. Das Verstehen des „Großen Ganzen“ und die Gelegenheit aktiv dazu beizutragen motiviert, denn Menschen wollen gute Arbeit liefern.

Regelmäßige Lieferung und Feedback:

Zum Ende eines jeden Zyklus werden Ergebnisse geliefert, diese Ergebnisse werden gezeigt um eine Rückmeldung zu erhalten, ob die Richtung der Arbeit immer noch stimmt. Danach findet eine Feedback-Runde statt, in dem sich das Team über die Arbeit unterhält und überlegt, wie die Arbeit im nächsten Zyklus noch besser organisiert werden kann.

Ein agiles Mindset:

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.“ Ersetze Software“ durch das Wort „Produkt“, damit es in jede Branche passt.

Danach heißt es im agilen Manifest von 2001:

  • Prozesse und Werkzeuge sind wichtig, aber Individuen und Interaktion sind wichtiger.
  • Umfassende Dokumentation ist wichtig, aber funktionierende Software ist wichtiger.
  • Vertragsverhandlungen sind wichtig, aber Zusammenarbeit mit dem Kunden ist wichtiger.
  • Das Befolgen eines Plans ist wichtig, aber das Reagieren auf Veränderungen ist wichtiger.

Weiterhin gilt das Prinzip der Freiwilligkeit: Erwachsene Menschen können selbst entscheiden in welcher Weise sie dem Unternehmen am besten dienen. Das bedeutet, dass zu Scrum und allen damit verbundenen Aktivitäten eingeladen wird. Wer sich selbst zur Teilnahme entschließt ist motiviert und wird stets sein Bestes geben.

Rahmen aus Verantwortlichkeiten: 3+3 Rollen

Das Scrum Team

Das gesamte Scrum-Team ist für die Lieferung zum Ende des Zyklus (auch Sprint genannt) verantwortlich! Das Scrum Team umfasst 5 bis 10 Personen und 3 Rollen. Rollen sind keine Positionen, d.h. sie werden nicht zugewiesen sondern freiwillig eingenommen.

Scrum Master und Product Owner sind laterale Führungskräfte. Das bedeutet, dass sie keinerlei disziplinarische Gewalt innehaben sondern sich andere Menschen entschließen, ihnen aufgrund der erworbenen fachlichen oder sozialen Anerkennung zu folgen.

Was-ist-eigentlich-Scrum

Bildnachweis: © www.berlin-bits.de

Rolle 1 – Entwickler / Mitarbeiter:

Die Expertengruppe, die die Umsetzung der Anforderungen plant und durchführt. In ihrer Verantwortung liegt die Qualität der Lieferung. Sie helfen dem Product Owner dabei die Anforderungen klein zu brechen und in „User Stories“ zu formulieren, zusätzlich schätzen sie den Umfang der beschriebenen Funktionalität in diesen Stories.

 Rolle 2 – Product Owner

Der Herr oder die Herrin über das Produkt ist für den Wert (Return on Investment) der Lieferung verantwortlich. Das bedeutet, dass der Product Owner die Produktvision mit gestaltet, Markt, Kunde und Technologie kennen muss und die sich daraus ergebenden Anforderungen in einer Liste (Product Backlog) entsprechend der Werthaltigkeit priorisiert.

Eine ernste Herausforderung in der Realität ist die Legitimation dieser Rolle, denn der Product Owner muss auch zu den Wünschen des Managements und der Kunden „Nein“ sagen dürfen. 

 Rolle 3 – ScrumMaster

Er oder sie ist Experte für Menschen und den Scrum-Prozess, die Verantwortung ist die Performance des gesamten Scrum Teams. Der ScrumMaster coacht alle Teammitglieder, also auch den Product Owner, und hilft ihnen selbst Lösungen für Störungen zu finden und umzusetzen. Probleme, die das Team nicht selbst lösen kann trägt er zur Lösung weiter in das Unternehmen hinein. Er verbreitet den „agilen Geist“ und treibt den Wandel im gesamten Unternehmen an.

Hinweis: Der ScrumMaster muss kein Programmierer / Entwickler / Experte für die Umsetzung sein. Er ist der Experte für Agilität und laterale Führung.

3 weitere Rollen außerhalb des Scrum Teams

Rolle 4 – Der Manager

Der Manager im Scrum Kontext ist ein Bereitsteller, Gastgeber und Organisator mit disziplinarischer Macht. Er schafft die Voraussetzungen für Arbeit, trifft Entscheidungen und widmet sich der Unternehmens-Startegie.

Er ist im regen Austausch mit dem Product Owner und dem ScrumMaster und lobt und wertschätzt alle Mitarbeiter regelmäßig, vor allem dann, wenn sie in seinen Augen etwas richtig machen.

 Rolle 5 – Der Kunde

Der Kunde ist der Finanzierer des Produkts, oft auch der Auftraggeber. Er weiß gelegentlich was er will, für welchen Nutzen er bezahlen möchte und lässt sich ansonsten vom Produkt Owner beraten. Oft gibt es in großen Unternehmen interne Kunden, die Anforderungen an andere Abteilungen aufstellen und die Umsetzung bezahlen.

 Rolle 6 – Der Nutzer

Dieser End-User (be)nutzt tatsächlich die gebaute Lösung / das Produkt. Nur wenige Unternehmen sind darauf ausgerichtet ihm tatsächlich einen Nutzen zu stiften. Durch die konsequente Formulierung der Anforderungen als User-Story rückt das Bedürfnis der Nutzer aber wieder stärker in den Fokus der Produktentwicklung.

 Im besten Fall ist ein Nutzer zum Ende eines jeden Entwicklungszyklus beim Scrum-Team, um die fertiggestellte Lieferung zu testen.

Rahmen und Taktgeber: Der Scrum Flow mit 6 Meetings

Strategische Ebene

Auf der strategischen Ebene findet wöchentlich ein Estimation-Meeting  zum Schätzen der kommenden Anforderungen statt. Es gibt unterschiedliche Verfahren, am häufigsten eingesetzt werden Planning Poker und Magic Estimation.

Der Product Owner präsentiert die demnächst anstehenden Anforderungen aus seiner priorisierten Liste (Product Backlog) sowie einige weitere Stories für die er eine Einschätzung der Umsetzer / Entwickler haben möchte. Geschätzt wird in „Story-Points“, diese sind die Grundlage für die Zeitplanung und zeigen an, welche Anforderungen ggf. noch in mehrere kleine User Stories zerbrochen werden müssen.

Das gesamte Scrum Team bekommt daher regelmäßig einen Eindruck des „Großen Ganzen“ und  sieht die Anforderungen langsam auf sich zukommen, noch bevor sie in die Umsetzung im Sprint (Entwicklungszyklus) gehen.

Taktische EbeneEin Sprint folgt dem Deming-Cycle (Plan-Do-Check-Act-(Re)Plan…) und dauert in der Softwareentwicklung meist 2 Wochen. Je schwieriger ein Projekt oder je chaotischer ein Umfeld ist, desto kürzer wird dieser Zyklus angesetzt und kann so bis auf einen Tag reduziert werden.

5 Meetings geben den Takt eines Sprints an.

Was-ist-eigentlich-Scrum

Photonachweis: © www.berlin-bits.de

 

Plan

 1) Sprint Planning #1: Was wird Gebaut? Festlegen der Anforderungen und des Sprintziels.

Der Product Owner präsentiert die Spitze des Product Backlogs, Story für Story wird die Entwicklergruppe gefragt, ob sie diese Anforderung umsetzten wollen und in das Sprint Backlog übernommen. Wenn die Entwickler das Gefühl haben genügend Ergebnisse für den Sprint versprochen zu haben, lehnen sie weitere Stories ab.

Dadurch wird erreicht, dass die Auslastung in einem gesunden Rahmen bleibt und die Umsetzer ihren Anspruch an die Qualität einhalten können.

 2) Sprint Planning #2: Wie wird Umgesetzt? Festlegen der Technologie.

Die Umsetzer beraten und planen, wie die angenommenen Stories nun konkret in den nächsten Tagen „gebaut“ werden sollen. Dabei werden verschiedene Lösungsmöglichkeiten besprochen, die Tasks (einzelne To-Do-Aufgaben) auf Haftnotizen notiert und an das Task-Board geklebt.

 Nach diesen beiden Meetings besteht Klarheit und Stabilität, was und wie in diesem Entwicklungszyklus umgesetzt wird.

Do

 3) Daily Scrum Meeting: Status und Tagesplanung.

An jedem Tag wiederholt sich der Deming-Cycle. Beim täglichen Treffen synchronisiert sich das Team und plant erneut die Arbeitszeit bis zum nächsten Daily Scrum Meeting:

Check – Was habe ich seit dem letzten Daily getan, was hat mich aufgehalten?

Act & Plan – Was kann ich anders machen? Was werde ich jetzt wie tun und wen brauche ich dafür?

Do – nach dem Treffen weiß jeder was wie zu tun ist und widmet sich der Umsetzung.

Check & Act

 4) Review: Feedback auf Produktebene.

Die fertigen Produktteile werden zum Abschluss des Sprints gezeigt, im besten Fall sind neben dem Product Owner auch Vertreter der Kunden und Nutzer dabei, um die Funktionalität zu testen und Impulse für die weitere Entwicklung zu geben. Zum nächsten Sprint Planning kann der Product Owner somit noch Anpassungen am Product Backlog vornehmen.

5) Retrospective: Feedback auf Teamebene.

Das einzige nicht-öffentliche Treffen des gesamten Scrum-Teams. Hier wird reflektiert, wie der letzte Sprint verlaufen ist und was im nächsten Zyklus verbessert werden kann. Dieses Meeting ist der Schlüssel für den kontinuierlichen Verbesserungsprozess.

Scrum Artefakte

Der Scrum Flow produziert diese Kern-Artefakte: Potentially Shippable Product Increment, Product Backlog und Sprint Backlog.

In einer erweiterten Sichtweise gibt es darüber hinaus diese Artefakte und „common practices“: TaskBoard, BurnDownChart, Definition of Done, Impediment Backlog, Produktvision und Release Plan.

Wichtig zum Verständnis des letzten Abschnitts dieses Artikels ist lediglich die Funktionsweise des Taskboards. Bitte schaue Dir dazu folgenden kurzen Erklärfilm an:

Warum fühlt sich Scrum gut an?

Zu allererst erzeugt Scrum einen Rahmen – einen Raum aus Stabilität und Verlässlichkeit –  der gefüllt werden kann. Sobald die Entwicklungszyklen etabliert sind und die Mitarbeiter gelernt haben, nicht zu viele Aufgaben in einen Sprint zu laden ist die Lieferfähigkeit wieder hergestellt: Jeder weiß, was wie zu tun ist und die Auslastung der Einzelnen und der Abteilungen ist auf ein gesundes Maß zurück gegangen, so dass wieder Qualität geliefert werden kann. Nun können auch aus Gruppen Teams werden.

Ein zweiter wichtiger Aspekt ist die regelmäßige Aktivierung des körpereigenen Belohnungssystems. Besonders das Daily Scrum Meeting birgt täglich das Potential Endorphin und Dopamin auszuschütten, da anspruchsvolle Aufgaben bewältigt werden und geschaffte Tasks „lustvoll“ in die Spalte DONE des Taskboards verschoben werden.

Zusätzlich erfahren die Mitarbeiter durch die Anerkennung und Wertschätzung ihrer Arbeit eine Statuserhöhung vor der gesamten Gruppe, dies fördert die Produktion von Serotonin. Fühlen sie sich darüber hinaus in der Gruppe geborgen wird auch Oxytocin produziert, welches das Zusammengehörigkeitsgefühl stärkt.

Das Stresshormon Cortisol dagegen wird weniger ausgeschüttet, so dass mit klarem Kopf gut gearbeitet werden kann.

Wie lange dauert’s bis das Unternehmen agil ist?

Mit der bloßen Einführung von Scrum als Prozess lassen sich bereits nach zwei bis drei Sprints erste Verbesserungen erreichen. Dies wird auch oft als „mechanical scrum“ bezeichnet. Nach einer anfänglichen Euphorie besteht jedoch die Gefahr, dass bei Problemen schnell wieder in alte Muster zurück gefallen wird.

Es braucht einen langen Atem und eine starke Führung, denn es geht um einen Kulturwandel im Unternehmen, es geht darum „mechanical scrum“ zu „professional scrum“ zu entwickeln: Was über Jahrzehnte gewachsen ist lässt sich nicht einfach in ein paar Wochen ändern.

Mitarbeiter sollen mitdenken, verstehen und Verantwortung übernehmen, Unsicherheit und Wandel als Chance begreifen sowie persönliches Wachstum und die geschäftliche Entwicklung lustvoll voran treiben. Die 5 Werte, die mit Scrum in Verbindung gebracht werden sind Courage, Openness, Respect, Focus & Commitment.

Um zu solch einer Haltung zu gelangen kann es Monate bis  Jahre dauern. Kontinuierliche Verbesserung dauert beständig an, daher ist es wichtig gemeinsam Richtungen und Zwischenziele festzulegen, regelmäßig zu prüfen, ob die Annahmen aus der Vergangenheit noch stimmen und jeden Erfolg zu feiern.

Der Weg ist weit, aber der mögliche Gewinn für alle Beteiligten enorm!

3
Hinterlasse einen Kommentar

avatar
3 Kommentar Themen
0 Themen Antworten
0 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
0 Kommentatoren
Letzte Kommentartoren
  Abonnieren  
neueste älteste meiste Bewertungen
Benachrichtige mich bei
Eva Schielein
Gast
Eva Schielein

Schöner Post! Werde ich meinen Kunden zeigen.
Viele Kunden fragen mich, ob Scrum Teams effizienter macht. Dann antworte ich „wenn sie es richtig umsetzen, schon.“
Und dazu gibt Alexander einen wesentlichen Hinweis: Wir haben es nicht mit einer weiteren Entwicklungsmethode zu tun, sondern erhalten ein Management Framework, das mit dazu beitragen kann, dass Organisationen sich erfolgreich neu erfinden.

Albrecht
Gast
Albrecht

Wie viele Managementsysteme vorher schon, wird m.E. auch Scrum vermutlich nur in einer überschaubaren kleinen Nische Einzug finden. Die Gründe dafür liegen für mich klar auf der Hand: 1. in oftmals inhabergeführten deutschen KMU könnte man derart innovative und mitarbeiterbezogene Veränderungen viel leichter umsetzen als in den überwiegend shareholdergeprägten und von angestellten Managern geführten Konzernen. 2. leider spricht man ausgerechnet in den KMU überwiegend deutsch, so dass derartige Konstrukte wie Scrum hauptsächlich nur in den fremdsprachlich geübten Jungmanager-Etagen Einzug finden könnten – also ausgerechnet dort, wo der kurzfristige Nutzen (für die Shareholder) am geringsten ist. Schade, dass wir unsere eigene… Weiterlesen »

ruynk
Gast
ruynk

@ Albrecht: In meinen Augen ist zwar Scrum ein Anfang, doch (lange) nicht das Richtige.
Ausserdem denke ich, dass wir eine deutsche Lösung brauchen.
An der arbeite ich zurzeit.

Verpasse keine neuen Beiträge und werde zum Experten der Neuen Wirtschaft

Geschrieben von

Blogauthor Alexander Krause intrinsify.me
Alexander Krause

Alex ist agiler Ruhestifter und Arbeitsweltverbesserer. Er hilft Menschen zu einer Richtung und selbstbestimmten Zusammenarbeit zu finden, um Produktentwicklung schneller, günstiger und freudvoller zu machen.

Erschienen am

Dienstag, 16. Juni 2015
X