Scrum ist die meistgenutzte Form agilen Arbeitens in Organisationen.
Entsprechend stellen sich die Fragen, was Scrum so besonders oder anders als andere agile Methoden macht? Und worum geht es bei Scrum eigentlich? Worauf kommt es an?
Um diese Fragen zu beantworten, möchte ich meine Erfahrungen und Erkenntnisse aus einem zweitägigen Seminar zum Professional Scrum Master reflektieren und mit meinem Wissen aus gruppendynamischer Praxis und selbststeuernden Teams verknüpfen.
Zunächst ein kurzes Wrap-up zum geschichtlichen Hintergrund und Framework. Scrum wurde 1995 von Ken Schwaber und Jeff Sutherland aufbauend auf den Erkenntnissen des Lean Developments von Toyota in den 1990ern für die agile Softwareentwicklung konzipiert. Damit ist Scrum eines der ältesten Konzepte des derzeitig boomenden Marktes für agiles Arbeiten. Scrum selbst versteht sich vornehmlich als ein Framework das Rahmenbedingungen für agiles Arbeiten schafft. Dabei hebt es sich von anderen agilen Arbeitsmethoden vor allem durch seine konzeptionelle Einfachheit und Flexibilität ab, die es zum einen schnell erklärbar und zum anderen vielseitig einsetzbar machen. Mittlerweile wird Scrum nicht mehr ausschließlich nur in der Softwareentwicklung eingesetzt, sondern auch in der Produktentwicklung. Im Folgenden sind die wichtigsten Scrum Rollen und Prozesse dargestellt.
Jedes Scrum-Team besteht aus:
- einem Product Owner, der an der Software oder dem Produkt selbst nicht mitentwickelt, sondern verantwortlich ist, dass die Software alle notwendigen Kriterien erfüllt, die von Kunden und Unternehmen gewünscht werden.
- einem Scrum Master, der sich um die Einhaltung des Scrum-Prozesses kümmert. Dieser schafft Hindernisse aus dem Weg und vermittelt bei Konflikten innerhalb und außerhalb des Teams.
- einem Development Team bestehend aus 3-9 Entwicklern mit unterschiedlichen Qualifikationen. Diese machen die eigentliche Entwicklungsarbeit.
Kernelement des Scrum-Prozesses ist der Sprint, der zwischen einer und vier Wochen lang ist und indem ein funktionsfähiges Teilstück einer Software (Increment) entwickelt wird. Innerhalb des Sprints gibt es ein Planungsmeeting (Sprint Planing), eine Arbeitsphase mit täglichen Meetings (hier findet die eigentliche Entwicklungsleistung statt, mit Daily Scrums), eine Vorstellung der Ergebnisse für alle vom Projekt Betroffenen (Sprint Review) und eine Reflexion der Teamdynamik (Sprint Retrospective).
Hört sich eigentlich ganz einfach, ist in der Umsetzung aber sehr herausfordernd, wie sich auch in meinem Seminar zeigen sollte. Denn obwohl die Scrum Methodik kurz und bündig ist, birgt sie viele Stolpersteine.
Also, was macht Scrum letztlich so besonders und damit auch herausfordernd?
Scrum lebt vor allem davon, dass das Scrum-Team selbstorganisiert arbeitet. Das heißt, es trifft Entscheidungen, die es als Team oder das Produkt betrifft, selbst. Weiterhin soll ein Scrum Team alle Kompetenzen, die es für Entwicklung, Design und Testung der Software benötigt im Team haben, sodass es so wenig wie möglich auf externe Expertise angewiesen ist. Das spart Zeit und erhöht die Effizienz des Arbeitens.
In der Theorie einleuchtend, in der Praxis generiert es völlig neue und zum Teil auch nicht intendierte Herausforderungen. Gerade gemeinsam getroffene Entscheidungen stellen Teams vor eine soziale Herausforderung gruppendynamischer Natur. Denn um gemeinsam eine Entscheidung treffen zu können, müssen unterschiedliche Ansprüche und Vorstellungen verhandelt und miteinander in Einklang gebracht werden. Je unterschiedlicher die Teammitglieder in diesem Prozess sind (und Scrum-Teams sind auf Unterschiedlichkeit hin, ausgelegt), umso mehr Ansprüche gibt es und um so herausfordernder sind Einigungen im Prozess. Das erfordert neben einer sachlichen Kompetenz ein hohes Maß an Sozial- und Teamkompetenz, denn es wird in diesem Prozess notwendiger und gewünschter Weise zu Konflikten innerhalb des Teams kommen. Und wie jeder weiß, der in Team Entscheidung treffen muss, lässt sich in einem solchen Prozess Sache und Persönliches nicht immer leicht trennen. Zwar soll der Scrum Master in diesen Konflikten vermitteln, aber die reine Ausbildung zum Scrum Master, macht ihn zwar zum Experten für den Scrum Prozess, nicht aber zum Experten für die Vermittlung von Konflikten…
Somit hängt die erfolgreiche Prozessgestaltung maßgeblich von den sozialen und gruppendynamischen Kompetenzen des Teams und vor allem des Scrum Masters ab. Denn dieser muss sowohl den Prozess vor seinem Team vertreten als auch die internen Konflikte bearbeiten können. An dieser Stelle wird deutlich das die Einfachheit der Methode, durch die Komplexität des Sozialen seine Schwierigkeiten bekommt.
Allerdings fällt auf, dass alle agilen Arbeitsformen maßgeblich durch die soziale Komponente mitgestaltet werden, weshalb Scrum meiner Ansicht nach zurecht den Ruf des Klassikers genießt. Denn das Framework ist kurz und bündig, schnell eingeführt und generiert bei richtiger Anwendung die gewünschten Effekte – ein Klassiker eben.
Abschließend möchte ich noch meine Erfahrungen aus dem Professional Scrum Master Seminar reflektieren. Das Seminar hat vor allem in das Scrum Framework eingeführt, darüber hinaus aber noch auf die vielen Stolpersteine und die Bedeutung der sozialen Komponente bei der Umsetzung von Scrum aufmerksam gemacht. Es wurden ein Produktentwicklungsprozess in mehreren Sprints exemplarisch in kleinen Gruppen geübt, Coaching Sessions trainiert und typische Stolpersteine in der Gruppe besprochen. Somit war das Seminar eine sehr gute Vorbereitung für die tatsächliche Arbeit im Unternehmen mit Scrum. Für sämtliche Sozialkompetenzen, wenn diese nicht schon vorhanden waren, konnte das Seminar allerdings lediglich einen Samen setzen, der für die tatsächliche Umsetzung von Scrum noch wachsen muss.
