Der Scrum-Guide beginnt die Definition von Scrum mit folgendem Satz:
"A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value."
Das ist erstmal ein relativ abstrakter Satz, der aber einige Begriffe enthält, die wir uns genauer anschauen wollen:
- Framework: Bei Scrum handelt es sich erstmal um ein Framework, das mit Leben gefüllt werden will. Nur weil man jetzt Retrospektiven macht, wird ja nicht automatisch alles besser, man muss dann schon selbst die identifizierten Probleme lösen.
- People: Die sind ja auch schon ein zentraler Punkt im Agilen Manifest ("Individuals and interactions over processes and tools") und hier geht es dann auch in erster Linie um Kollaboration und Selbstorganisation.
- Complex & Adaptive: Es geht hier nicht um die Lösung trivialer Problemstellungen die man standardisiert und automatisiert abhandeln kann, sondern um Herausforderungen die dynamische Märkte wie zum Beispiel im Tech- und Telco-Umfeld stellen. Hier kann man nicht sechs Monate im Voraus planen, sondern muss einen Plan regelmäßig an die neuen Gegebenheiten anpassen.
- Productively & Creatively: Es geht nicht darum einfach möglichst viel Code zu schreiben und schneller zu tippen, sondern man muss sich genau überlegen was man tut, damit der höchste Produktivitätsgewinn erreicht wird. Da die Lösung nicht bekannt ist, muss mit einer gewissen "Kreativität" an deren Entwicklung herangegangen werden.
- Highest possible value: Es sollen die Produkte und Features entwickelt werden, die für das Unternehmen beziehungsweise den Kunden Werte generieren.
Im Scrum-Guide geht es dann weiter mit:
"Scrum is:
- Lightweight
- Simple to understand
- Difficult to master"
Leichtgewichtig, ja - einfach zu verstehen, auch - es gibt Sprints, ein Entwickler-Team, einen Scrum Master, einen Product Owner und dann noch eine Handvoll Meetings. Soweit so gut. Aber schwierig zu meistern? Auf dem Papier klingt es erstmal so einfach, aber ab einem gewissen Punkt merkt man in der Praxis dann, dass es doch schwieriger ist als am Anfang gedacht.
Scrum ist - wie oben bereits erwähnt - erst einmal nur ein leichtgewichtiges Framework, das man selbst mit Leben füllen muss. Aus Entwickler-Sicht ist die Einführung von Scrum mittlerweile zumeist positiv, da Selbstorganisation, cross-funktionale Teams und eine direkte Zusammenarbeit vieles vereinfachen. Doch an die Grenzen stößt man zumeist an der Organisation um das Scrum-Team herum. Es wird häufig vergessen, dass es bei Scrum um mehr geht, als nur um die Entwickler, die jetzt agil und iterativ arbeiten. Sondern es geht um das ganze Unternehmen.
Das klassische Mindset mit den typischen Rollen wird in der Praxis bei der Einführung von agilen Methoden meist beibehalten. Diese bekommen aber, um der Scrum-Welt zu genügen, einfach ein neues Label. So wird im Zuge der Einführung von Scrum aus dem Projektmanager der Scrum Master und aus dem Analysten der Product Owner. Aber die Aufgaben unterscheiden sich deutlich. Der Projektmanager muss in seiner neuen Rolle viele der Verantwortlichkeiten zum Beispiel an das Entwickler-Team abgeben und seine Rolle ist eher moderierend und unterstützend als bestimmend. Der Analyst hingegen muss nun nicht mehr (nur) Dokumente produzieren, sondern ihm obliegt primär die Verantwortung über das Product Backlog und die Werte, die geliefert werden sollen. Er muss dafür sorgen, dass das gesamte Team die Items im Backlog versteht und dass das Backlog so priorisiert ist, dass die (Business-) Ziele erreicht und entsprechende Werte geliefert werden. Das geht meist deutlich über den alten Verantwortungsbereich hinaus. Vielfach endet der Product Owner somit als Proxy zwischen den eigentlichen Stakeholdern und er verwaltet mehr schlecht als recht das Backlog.
Durch die starke organisatorische Trennung von Fachseite und Entwicklung ergeben sich meist noch weitere Probleme. Es ist eben nicht damit getan, ein paar Power-Point-Slides per Mail zu verschicken und zu hoffen, dass schon das richtige herauskommen wird. Ziel sollte es dagegen sein, dass das Produkt ganzheitlich betrachtet und entwickelt wird und zwar ohne unzählige Übergaben und Abteilungsdenken. Diese machen die Bewertung des Gesamterfolges auch nahezu unmöglich, da am Ende jeder nur auf seine Ziele schaut und lediglich lokal optimiert wird. Das Entwicklungsteam wird somit zum Beispiel nur am Durchsatz gemessen, aber es erfolgt keine Betrachtung des dadurch generierten Business-Value, obwohl das auch eine gute Idee sein könnte.
Mit der immer stärkeren Öffnung der Märkte und der somit größer werdenden Konkurrenz, gibt es auch immer stärker den Bedarf deutlich schneller reagieren zu müssen. Seien es geänderte oder neue Anforderungen vom Kunden oder ein neuer Mitbewerber im Markt. Scrum erlaubt es mit seinem iterativen Vorgehen in kurzen Sprints sehr schnell auf geänderte Situationen zu reagieren. Hier nützt es allerdings nichts, wenn nur ein kleiner Teil des Unternehmens so arbeitet und der andere Teil mit einem 3-Monats-Wasserfall alles blockiert. Es wird immer wichtiger zu verstehen, dass Scrum nicht nur etwas ist, was Entwickler machen, sondern was unternehmensweit Sinn macht.
Bei der Einführung beziehungsweise Weiterentwicklung von Scrum im Unternehmen gibt es also viele Herausforderungen, wichtig ist aber, dass man die zentralen Punkte und Ziele nicht aus den Augen verliert:
- Lösung der organisatorischen Probleme (Scrum auf allen Ebenen)
- Die Scrum-Teams so cross-funktional aufsetzen, dass sie alle notwendigen aufgaben im Team umsetzen können
- eigenverantwortliches & selbstorganisiertes Arbeiten der Teams
- klare Verantwortlichkeiten in den einzelnen Rollen (Product Owner, Scrum Master & Dev. Team)
- offenes Feedback & kontinuierliche Weiterentwicklung
- Orientierung am Business-Value/Kundennutzen & ein dem entsprechend priorisiertes Backlog
