Was Scrum und Spaceshuttles gemeinsam haben

Ein Blogeintrag von Ralph

Was Scrum und Spaceshuttles gemeinsam haben

Spricht man über agiles Arbeiten, wird Scrum oft im selben Atemzug erwähnt. Aber was ist eigentlich das Besondere an Scrum? Ist Scrum das Allheilmittel für Probleme in Projekten? Hat Scrum die Kraft die Zusammenarbeit grundlegend zu ändern? Und was bedeuten eigentlich die Begriffe, mit denen die Scrum-Begeisterten um sich werfen?

Wir sind davon überzeugt, dass die Zukunft des Arbeitens agil sein wird. Das kann verschiedene Formen annehmen und auf unterschiedliche Arten umgesetzt werden. In diesem Blogbeitrag möchten wir den Scrum-Prozess, Begrifflichkeiten, Schwierigkeiten und Vorteile beleuchten. Denn die agile Transition ist ein Thema, mit dem sich jedes Unternehmen früher oder später auseinandersetzen muss.



Bevor wir über des Scrum-Prozess reden können, muss erst mal ein Grundverständnis hergestellt werden. Denn Scrum ist nur ein Rahmenwerk. Für dessen Einsatz braucht es mehr als das Befolggen einer Anleitung. Es muss ein Grundverständnis in den Köpfen geschaffen werden. Ein Grundverständnis, welches die Notwendigkeit des agilen Arbeitens aufzeigt. Ein großer Fehler im Monstrum agile Transition, der früher oder später bei der Einführung agiler Arbeitsweisen passiert, ist die Einführung auf der falschen Ebene zu starten. Falsche Ebene?


Der goldene Kreis

Das Golden Circle-Konzept von Simon Sinek geht davon aus, dass es in jedem Unternehmen verschiedene Ebenen gibt.1 Der goldene Kreis hat drei Ebenen, von innen nach außen: “Warum”, “Wie” und “Was”. Der Kern des Golden Circle dreht sich um das “Warum”. Es geht also um die Motivation, die Vision für das, was umgesetzt wird. Aufbauend darauf geht es auf der zweiten Ebene um das “Wie”. Diese Ebene beschäftigt sich mit Strategien. Wie das “Warum“ in die Tat umgesetzt werden kann. Die äußerste Ebene befasst sich mit dem “Was”. Erst auf dieser Ebene geht es um Produkte und Services.

Wenn Unternehmen konkret nach dem Golden Circle gefragt werden, wird es oft ungenau. Die äußerste Ebene, das „Was“, können die meisten Unternehmen beantworten. Denn die Services und Produkte sind natürlich bekannt. Auch das „Wie“ ist vielen noch klar. Das ist der sogenannte USP - unique selling proposition. Also das Alleinstellungsmerkmal eines Unternehmens. Aber beim „Warum“ gibt es sehr selten eine klare Antwort. Hier geht es um die Vision, die Aufgabe eines Unternehmens. Eine nachhaltige Daseinsberechtigung, für die es Wert ist zu arbeiten. Und das schließt „Geld verdienen“ nicht ein. Das ist vielmehr ein Ergebnis aus der Umsetzung der Vision.

Das “Warum” ist die Motivation etwas am gesamten Konzept zu ändern. Und damit etwas Neues zu schaffen. „Wir schaffen Möglichkeiten, in dem wir die Welt bewegen“ heißt es von einer bekannten Plattform, die das Konzept Taxi neu erfindet. Ein bekannter Ferienwohnungsanbieter würde eine Vision á la „one day everyone can feel home anywhere“ verfolgen.




Aus der richtigen Ebene herausarbeiten

Aber was hast das Golden Circle-Konzept jetzt eigentlich mit Scrum zu tun? Eine Vision bzw. die klärende Frage nach dem “Warum?“ ist zentral, wenn im Unternehmen oder im Team Scrum eingeführt wird. Scrum ist dabei ein agiles Framework, also ein Grundgerüst, dass verwendet werden kann. Die Vision, das “Warum”, ist die Ebene, an der bei der Einführung von Scrum zuerst ansetzen sollte. Jede Person, die damit arbeitet, sollte wissen, weshalb plötzlich nach diesem Regelwerk gearbeitet wird. Generell gilt: Grundlage für agiles Arbeiten ist der gesunde Menschenverstand. Dies gelingt gut, wenn sich jede Person bewusst ist, dass die eigene Grundeinstellung wichtig ist. Denn diese fördert Weiterentwicklung und ein stetiges Lernen. Das bedeutet gleichzeitig, ohne die richtige Grundeinstellung macht auch Scrum nicht glücklich. Scrum bzw. agile Arbeitsweisen sollen die Fehler der klassischen Ansätze beheben. Diese entstehen zum Beispiel durch lange Planungen – durch gefühlt endlose Entwicklungs- und Testphasen. Und durch wenig Kundenkontakt.


Warum Scrum und nicht der klassische Ansatz?

Scrum basiert im Gegensatz zu theoretischen Annahmen der klassischen Ansätze aus Erfahrungswissen, gewonnen aus drei Säulen.

1. Säule: Transparenz
Es soll zu jeder Zeit Klarheit über den aktuellen Status herrschen. Klarheit, woran gerade gearbeitet wird. Klarheit, woran als nächstes gearbeitet wird. Klarheit, welche Aufgaben schon geschafft wurden.

2. Säule: Inspektion
Was kann verbessert werden? Durch transparentes Vorgehen wird die Möglichkeit geschaffen, ständig zu inspizieren, an welchen Stellen es Verbesserungspotential gibt. Auf Produkt-, Team- und Prozessebene.

3. Säule: Adaption
Wenn die Karten offen auf dem Tisch liegen und Verbesserungsmöglichkeiten identifiziert wurden, ist es wichtig, konkrete Maßnahmen zu formulieren. Diese müssen dann umgesetzt werden. So kann eine stetige Weiterentwicklung geschehen.

Letztendlich wird durch die Anwendung von Wissen das klassische Vorgehen ersetzt. Statt das Verfolgen eines fiktiven, langwierig erstellten Planes wird die aktuelle Faktenlage benutzt. Es ist wichtiger, mit der aktuellen Situation richtig umzugehen, als einen Plan durchzuziehen, der für 6 Monate angesetzt ist, aber nach 2 Monaten bereits hinfällig ist, da sich die Umstände geändert haben.




Wichtige Scrum-Begriffe

Sprint – mehr als eine olympische Disziplin
Scrum an sich arbeitet in kurzen Zyklen, sogenannten Sprints. Diese dauern nicht länger als vier Wochen. Am Ende dieses Sprints steht ein konkretes Ergebnis. Beispielsweise ein funktionierendes Produkt. Oder die funktionierende Erweiterung des Produkts, auch Inkrement genannt. Täglich berichtet sich das Team untereinander, ob es noch auf dem richtigen Weg ist. Es synchronisiert sich über den aktuellen Stand der Arbeit. Das geschieht durch das sogenannte Daily Scrum, einem 15-minütigem täglichen Austausch. Dieses Köpfe-Zusammenstecken hilft dabei, früh Probleme zu erkennen. Das können Abhängigkeiten oder Blocker sein. Für die Lösung solcher Hindernisse können dann frühzeitig Maßnahmen ergriffen werden. Am Ende eines Sprints findet eine sogenannte Retrospektive statt. Diese beleuchtet kritisch den Sprint, identifiziert Verbesserungsmaßnahmen und hilft auch Team-Building und Zusammenarbeit zu fördern.

Der Product Owner
Die Entwicklung eines Produktes funktioniert dadurch, dass Anforderungen ihrer Priorität nach in den einzelnen Sprints vom Team bearbeitet werden. In jedem Team gibt es einen Product Owner. Dieser stellt dem Team sein Backlog vor, also welche Anforderung als nächstes den größten Wert liefert. Der Product Owner ist sozusagen der Wert-Maximierer eines Produktes oder Projekts. Auch die Kommunikation zu Kunden und anderen Beteiligten (Stakeholder) kann von ihm übernommen werden. Das Konzept Scrum sieht aber vor, dass auch das Team am Ende eines Sprints direktes Feedback von Kunden und Stakeholdern bekommt. So kann sichergestellt werden, dass das entwickelte Produkt immer noch nach den Wünschen von Kunden und Stakeholdern entspricht.



Review - am Ende jedes Sprints
Damit das Produkt beständig nach der Vorstellung der Stakeholder entwickelt wird, gibt es den Sprint Review Termin. Dieser ermöglicht es dem Team direkt und in recht kurzen Abständen zu demonstrieren, welche neuen Anforderungen integriert wurden und gleichzeitig auch direkte und unverfälschte Rückmeldung zu bekommen. Das bedeutet, dass die Kommunikation mit den eigentlichen Nutzern regelmäßig stattfindet. Dadurch ist es dem Team möglich, schnell und flexibel auf neue Anforderungen und veränderte Situationen zu reagieren.

Zu Beginn eines jeden Sprints plant das Team zusammen mit dem Product Owner die Aufgaben für den nächsten Zyklus (=Sprint). Das heißt der Product Owner stellt vor, was umgesetzt werden soll. Das Team entscheidet dann eigenständig darüber, wie Anforderungen umgesetzt werden können. Durch diese Trennung zwischen Fachlichkeit und Technik können sich sowohl Product Owner als auch das Team auf ihre jeweiligen Domänen konzentrieren. Durch diese Multidisziplinarität kann das Wissen innerhalb eines Teams auf mehrere Schultern verteilt werden, da jedes Mitglied durchgehend am Alltag der anderen teilnimmt.

Der Scrum Master
Neben dem Product Owner gibt es auch noch den Scrum Master. Er hilft den Prozess einzuhalten. Und unterstützt das Team, sich kontinuierlich weiterzuentwickeln. Außerdem schützt und überwacht der Scrum Master den „Scrum Prozess“. So stellt er sicher, dass das Team möglichst selbstorganisiert arbeitet. Die Rolle bewegt sich zwischen Coach, Lehrer, Mentor und Prozessspezialist hin und her. Angetrieben von der Aufgabe, sich Stück für Stück überflüssig zu machen. Als dienender Anführer (servant leader) springt der Scrum Master aber auch für das Team in die Bresche und unterstützt es vor allem Hindernisse von außen beiseite zu schaffen.



Scrum ist kein Patentrezept
Wie oben schon erwähnt, ist es wichtig zu verstehen, dass Scrum kein Allheilmittel für schlechtes Projektmanagement ist. Scrum hilft auch nicht ohne viel Planung sehr gute Produkte umzusetzen. Scrum selbst löst die Probleme nicht. Scrum ist nur ein leicht verständliches und gut einführbares Mittel, um diese Probleme aufzuzeigen. Wer vor Scrum Schwierigkeiten hatte Projekte umzusetzen, wird diese Schwierigkeiten auch mit Scrum haben. Aber die Probleme können besser erkannt und mithilfe entsprechender Formate und Werkzeuge in konkrete Maßnahmen zur Verbesserung umgesetzt werden.

Agile Arbeitsweisen werden Stück für Stück klassische Herangehensweisen ablösen, so viel ist sicher. Dennoch sollte man sich vor der Einführung eines Frameworks wie Scrum immer die Frage stellen, warum man das möchte und auch darüber reflektieren, ob die eigenen Projekte oder Vorhaben auch dafür geeignet sind. Und hier schließt sich auch wieder der goldene Kreis. Mit dem “Warum?” steht und fällt jedes Projekt. Es geht nicht um Methoden, sondern darum, dass Prozesse effektiver umgesetzt werden. Es geht um die Vision. Darum, ein Produkt zu erschaffen oder eine Serviceleistung zu verbessern. Das “Warum” ist und bleibt die entscheidende Ebene.

Space Shuttle nach Scrum
Ich würde nicht empfehlen ein Space Shuttle nach Scrum zu bauen. Trotzdem ist das komplette Weltraumprogramm ein perfektes Beispiel für agile, iterative Arbeit. Vom Satelliten, über Tiere und Menschen in der Umlaufbahn, hin zu den Mondlandungen und zur ISS. Schritt für Schritt aus Erfahrung und neuen Fakten lernen und das nächste Vorhaben dadurch ein Stück besser machen. Empirisches Vorgehen hilft dabei auf dem richtigen Weg zu bleiben und sich nicht in falschen Planungen zu verlieren. Scrum ist der Werkzeugkasten, der auch unerfahrenen Teams hilft zum Ziel zu kommen.

Die vorgegebenen Regeln (Rollen, Termine, Artefakte) beantworten viele Fragen, die vor allem am Anfang aufkommen. Ich denke, das ist einer der Gründe, warum Scrum auch so beliebt ist. Um sich weiterzuentwickeln und auch Scrum anzupassen empfiehlt sich am Ende das Shu Ha Ri Prinzip2, abgeleitet aus der japanischen Kampfkunst. Das Prinzip lautet: Follow the rules, break the rules, be the rules. Finde deinen eigenen Scrum Prozess. Das passiert wie folgt:

Benutze Scrum, passe Scrum auf deine Bedürfnisse an und am Ende habt ihr euer eigenes Framework, das vielleicht kein Scrum mehr ist, aber euch auf dem Weg zum Ziel perfekt unterstützt.