Scrum, ein reines Softwareentwicklungs-Framework? Falsch. Mit Scrum werden heutzutage revolutionäre Autos gebaut (watch THIS), Radioprogramme geplant oder komplexe Airline-Fusionen umgesetzt. Scrum = Chaos? Falsch. Scrum ist hochstrukturiert, kann als Minimalframework nur ganz oder gar nicht angewendet werden, basiert aber gleichzeitig auf dem Prinzip sich selbst organisierender Teams und adaptiver Prozesskontrolle. Scrum, etwas für eigenbrötlerische Entwickler? Falsch. Scrum ist komplett auf den Business Nutzen ausgerichtet und das nicht nur in der Planungsphase. Scrum = Schlechtes Design? Falsch. Scrum heisst in erster Linie besseres Design, da es im Gegensatz zu klassischen Wasserfallmodellen jederzeit dazu fähig ist, sich an die Umwelt anzupassen.

Willkommen in der Realität

Gemäss der kürzlich veröffentlichten ’State of Agile’-Studie benützen 88% der befragten Unternehmen agile Methoden (zu diesen Unternehmen gehören auch Apple und Google), wobei Scrum mit 73% die am meisten benutzte agile Methode darstellt. Was im angelsächsischen Raum bereits mehr Mainstream wie Radikalität ist, rollt im deutschsprachigen Raum jetzt erst richtig an. Ist Scrum also das Erfolgsrezept für jedes Projekt? Natürlich nicht. Der agile Scrum-Ansatz ist noch längst nicht für jedes Projekt geeignet, und was die Studie verschweigt: Viele agile Projekte scheitern. Gemäss aktuellen Untersuchungen zwar immer noch viel weniger häufig wie klassische Wasserfall-Projekte (um den Faktor Drei), dennoch scheint Scrum die Unternehmen vor vielfältige und neue Probleme zu stellen. Dies zeigt für mich vor allem eines: Scrum ist zwar sehr einfach zu verstehen, aber extrem schwierig anzuwenden. Scrum verändert die Kultur eines Unternehmens und erfordert eine andere Einstellung aller Beteilgten. Dazu aber später.

Was ist Scrum?

Scrum gibt es schon lange. Die Ursprünge von Scrum liegen im japanischen Lean Management („The Toyota Way“, sehr empfehlenswertes Buch). Scrum wurde ursprünglich  für High-Perfoming Teams konzipiert, welche gegenüber klassischen Wasserfall-Teams 5-10 Mal höhere Effizienz und Qualität erbringen sollen. Als Projektmanagement Framework basiert Scrum auf einem empirischen, inkrementellen und iterativen Ansatz. Dies aufgrund der Erfahrung, dass komplexe Entwicklungsprozesse nicht von Anfang an vorhersagbar sind. Scrum lässt sich auf alle Arten von Projekten und Programmen anwenden, für die Erstellung von Produkten, Services oder sonstigen Resultaten, unabhängig vom Grad der Komplexität und der Branche. Scrum basiert auf einer Reihe von Prinzipien (Dies sind: Empirical Process Control, Self-Organization, Value-based Prioritization, Time-boxing & Iterative Developement) und dem Scrum-Flow, welcher sich wie folgt zusammenfassen lässt:

1. Der Prozess beginnt mit dem Stakeholder Meeting, in dem ausgehend vom Business Case die Projekt Vision erstellt wird
2. Daraus resultiert ein priorisierter Produkt Backlog, welcher die Business Anforderungen in Form von User Stories dokumentiert
3. Jeder Sprint beginnt mit einem Sprint Planning Meeting, in welchem hochpriorisierte User Stories (value-based) für die Aufnahme in den Sprint diskutiert werden (Resultat: Sprint Backlog)
4. Ein Sprint dauert i.d.R zwischen 1-6 Wochen, am Ende steht jeweils ein potentiell lieferbares Ergebnis (Neues Produkt/Service oder Inkrement)
5. Während dem Sprint werden tägliche Stand-Up Meetings, sog. Daily Scrums durchgeführt, in welchen der Fortschritt kommuniziert wird und Hindernisse aus dem Weg geräumt werden (Max 15. Minuten)
6. Am Ende des Sprints findet das Sprint Review Meeting, in dem den Stakeholdern eine Demonstration des Produkts gemacht wird.
7. Der Produkt Owner akzeptiert das Resultat nur, wenn die vordefinierten Acceptance Kriterien erfüllt sind. Der Produkt Backlog Log wird danach aktualisiert.
8. Der Sprint Zyklus endet mit dem Sprint Retrospect Meeting, in dem Prozessverbesserungen für den kommenden Sprint diskutiert werden.

Wer im IT Service Management zuhause ist, wird hier unweigerlich an den CSI-Approach erinnert (Kontinuierlicher Verbesserungsprozess mit seinen Feedbackschleifen). Scrum ist quasi die Zwillingsbruder von CSI, aber in einem anderen Universum.
Hier ein beeindruckendes Beispiel, wie Scrum in der Automobilbranche angewendet wird: (Klicken Sie diesen Link, falls das folgende Video in ihrem Browser nicht sichtbar ist)::

Nun zu den Rollen. Scrum kennt drei Kernrollen:

• Den Produkt Owner: Er repräsentiert die ‚Voice of the Customer‘, ist verantwortlich für den ROI und die Priorisierung des Product Backlogs. In der radikalsten Form wurde dies bei Apple praktiziert: Es gab nur einen Produkt Owner: Steve Jobs
• Den Scrum Master: Er agiert als ‚Facilitator‘ für den Scrum Prozess, räumt Hindernisse aus dem Weg (-> Impediment Log) und beschützt das Scrum Team vor negativen Einflüssen
• Das Scrum Team: Es implementiert primär. Das Scrum Team muss immer cross-functional sein (keine Spezialisierung), selbst-organisiert und idealerweise mit eine durchschnittliche Teamgrösse von 4.6,… ok…zwischen 3-9 Personen. Interessant dazu: Brooks Law (Adding manpower to a late project makes it later)

Ein Scrum Projekt kann übrigens auch aus mehreren Scrum Teams bestehen (Die Kaskadierung erfolgt dann über sog. ‚Scrum of Scrums‘). Yahoo beispielsweise hat 200 global verteilte Scrum Teams, welche zeitweise am gleichen Projekt arbeiten.

Und Tools? In Scrum ist eines von zentraler Bedeutung: Das Scrum Board. Alles was es dazu braucht, ist ein Whiteboard, Stifte und ein paar Post-It‘s. Hier ein elektronisches Tool zu verwenden wäre der absolute Killer, das Scrum Board muss für jeden Scrum Team Member gut sichtbar sein (Transparenz) und dient als wichtigstes Hilfsmittel im Daily Standup Meeting (Fortschritt, Feedback). Im folgenden Bild das Scrumboard, das jetzt hinter mir hängt (Hinweis: Nachdem dieser Blog veröffentlicht ist, kann ich ein Post-It nach rechts verschieben 🙂 :

Reicht dies nun, damit Scrum funktioniert? Nicht ganz….

Wasserfall mit Scrum ist immer noch Wasserfall. Radikales Umdenken ist gefragt

Haben Sie auch schon Projekte erlebt, welche blind Prozesse befolgen, brav Projekt-Dokumente produzieren und dabei voll an die Wand fahren? Ich schon. So ein Szenario ist übrigens auch mit dem Scrum-Prozess denkbar. Viele Unternehmen schreiben sich heutzutage ‚Agil‘ auf die Fahne, geändert hat sich aber nichts (in Scrum heisst dies ‘ScrumButt‘, von ‘Yes, Scrum…but…’). Es ist problematisch, wenn man versucht, nur einzelne Aspekte von Scrum umzusetzen. Scrum funktioniert als Minimalframework nur ganz oder gar nicht und ein ‘Excellent Scrum‘ (d.h. eine messabre jährliche Umsatzsteigerung von 400%) erfordert einen Kulturwandel und eine Änderung der Einstellung aller Beteiligten. Am besten kommt das für mich im Agilen Manifesto zum Ausdruck, welches 2001 u.a. von Ken Schwaber und Jeff Sutherland, den Erfindern von Scrum geschrieben wurde und folgende vier Kernpunkte enthält:

• Individuen und Interaktionen gelten mehr als Prozesse und Tools
• Funktionierende Programme gelten mehr als ausführliche Dokumentationen
• Die stetige Zusammenarbeiten mit dem Kunden steht über den Verträgen
• Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans

Die Konsequenzen auf klassische Organisationen sind umwälzend:

• Die Unternehmen-Hierarchie verflachen
• Aufstiegsmöglichkeiten um klassischen Sinn entfallen zum Teil. Menschen beginnen sich über Arbeitsinhalte zu definieren statt über ihren Job Title
• Die Veranwortungsbereiche aller Beteiligten und der verbliebenen Führungspositionen verändern sich stark. Neu: Scrum (of Scrum) Master, Product Owner und Scrum Team.

Scrum: The Way Teams work

Oft wird übersehen, dass Scrum auch ein Instrument ist, um die Zusammenarbeit in Teams und über Teams hinweg zu organisieren und daraus motivierte und erfolgreiche Teams zu machen, wie man Sie z.B. bei Google, Faceboock und anderen High-Performing Unternehmen antrifft. Das ist für mich der Kern von Scrum und stellt für mich auch dessen Mehrwert gegenüber anderen (Wasserfall- und agilen) Frameworks dar. Ein Aspekt davon ist Selbst-Organisation, welche eines der Geheimnisse für eine herausragende Team-Performace ist (Klicken Sie diesen Link, falls das folgende Video in ihrem Browser nicht sichtbar ist):

Der Weg zu Scrum

Wie weiter? Überlegen Sie sich, in Ihrem Unternehmen Scrum einzuführen oder Ihre bestehende Scrum Performance zu verbessern? Aufgrund der dazu nötigen Veränderungen auf Organisations- und Verhaltensebene ist dies oft ein langer Weg. Sie können jedoch einen Grundstein legen mit der richtigen Ausbildung.

Die Glenfis AG ist seit 1.1.2014 ein R.E.P., ein offiziell registrierter Education Partner von Scrum Study. Scrum Study ist einer der drei Organisations-Autoritäten (neben Scrum.org und Scrum Alliance), welche offizielle Scrum-Zertifikate und Trainingsprovider-Akkreditierungen anbieten können.

Als erstes Seminar haben wir bereits den Scrum Master mit dem Zertifikat „Scrum Master Certified (SMC®)“ entwickelt und ausgeschrieben. Das erste öffentliche Seminar findet am 14.-15. April 2014 in Zürich statt. Anmeldungen nehmen wir sehr gerne bereits heute entgegen.

Die weiteren Seminare für Agile Expert Certified oder Scrum Product Owner Certified werden aktuell entwickelt und in den nächsten Monaten aufgeschaltet.