Scrum-Entwicklung bei Gambio – Einführung und erstes Fazit
Der folgende Artikel wird sich um das Thema ‚Scrum‘ drehen, womit eine bestimmte, agile Vorgehensweise im Projektmanagement bezeichnet wird. Da unsere Entwicklungsabteilung nun nach dieser Methode arbeitet, werde ich insbesondere darauf eingehen, welche Erfahrungen wir bei der Einführung dieser für uns neuen Methode machen konnten und resümieren, ob sich dieser Schritt gelohnt hat.
Manche von Ihnen werden – wenn Sie z. B. als Softwareentwickler in einem modernen Unternehmen beschäftigt sind – tagtäglich mit Scrum zu tun haben, während vermutlich viele von Ihnen nichts mit diesem Begriff anzufangen wissen. Vor allem für Zweitgenannte wird der nun folgende Textabschnitt von Interesse sein, da dieser eine kurze Einführung in das Thema geben soll. Der letzte Abschnitt dieses Textes dürfte auch für die Scrum-Kenner unter Ihnen relevant sein, wenn Sie sich für Gambio und dessen Entwicklungstätigkeit interessieren.
Was ist Scrum und wofür ist es gut?
Scrum kommt, wie die meisten in der Softwarebranche etablierten Termini, aus dem Englischen und bedeutet übersetzt ‚Gedränge‘. Verwiesen wird hierbei auf den Spielzug des Gedränges beim Rugby, das eine gute Teamarbeit voraussetzt und sorgsam einstudiert werden muss. Der daraus abgeleitete Begriff ‚Scrum‘ bezeichnet im hier forcierten Kontext ein bestimmtes Arbeitsmodell in der Softwareentwicklung, das 1993 zum ersten Mal als solches eingesetzt wurde. Bei diesem Modell wird davon ausgegangen, dass ein Großteil der durchzuführenden Entwicklungsprojekte zu komplex ist, um sich im herkömmlichen Sinne und von vornherein vollständig planen zu lassen. Jeder, der einmal mit der Entwicklung größerer Softwareprojekte zu tun hatte, wird dieses Kernproblem kennen. Aufgrund der Komplexität von Softwareprojekten und dem herkömmlichen Anspruch, die zu Anfang gesteckten Ziele in jedem Fall zu erreichen, kommt es häufig dazu, dass das Endprodukt dem Kunden gar nicht gefällt – womit natürlich viel Arbeitskraft fehlinvestiert wurde. Um genau dies zu vermeiden, organisiert Scrum den Entwicklungsprozess daher anders, nämlich agil. Der Vorteil von solchen dynamischen Prozessen besteht darin, dass das zu realisierende Produkt besser auf den Kunden abgestimmt werden kann, indem nicht ein finales Arbeitsergebnis am Ende des Projektes präsentiert wird, sondern kleinere fertige Teile jeweils bereits nach kürzeren Zeitabschnitten gezeigt und bewertet werden. So wird die Arbeit des Entwicklerteams regelmäßig überprüft und angepasst, sodass am Ende die Produktqualität höher ist als nach einem auf herkömmliche Weise bearbeiteten Softwareprojekt.
Wie funktioniert Scrum?
Scrum sieht fest verteilte, obligatorische Rollen und klar definierte Regeln vor, deren konsequente Anwendung für das Gelingen vonnöten ist.
So gibt es im Vorhinein festgelegte Entwicklungsintervalle, die immer gleich lang sein müssen. Diese so genannten Sprints dauern zwischen einer und vier Wochen. Das Ziel eines Sprints ist eine auslieferbare Software-Funktionalität, die bereits getestet und integriert ist, sodass sie dem Kunden präsentiert werden kann.
Wer gehört zum Scrum-Team?
Ein Scrum-Team besteht aus insgesamt fünf bis zehn Mitgliedern.
Eine zentrale Rolle nimmt das Entwicklerteam ein, das sich selbst organisiert. So entscheidet es autark, wie viele Arbeitspakete es in einem anstehenden Sprint zu erledigen hat und wer welche Aufgabe übernimmt. Das Entwicklerteam sollte interdisziplinär besetzt sein, damit es ohne externe Hilfe arbeiten kann. Es darf während eines Sprints nicht gestört werden, damit es sich ganz auf seine Arbeit konzentrieren und den Zeitplan einhalten kann. Die Entwickler treten bei Scrum grundsätzlich als Team auf – daher werden sowohl positive als auch negative Ergebnisse immer auf das Team als Einheit und niemals auf ein einzelnes Mitglied zurückgeführt.
Bei Scrum gibt es keinen klassischen Projektleiter; es gibt jedoch einen Product-Owner, der für das Produkt (die Software) und das Erreichen der wirtschaftlichen Ziele verantwortlich ist. Der Product-Owner arbeitet eng mit dem Entwicklerteam zusammen und definiert dessen Aufgaben. Dabei steht er dem Team für Rückfragen zur Verfügung. Als Produktverantwortlicher und Auftraggeber, der den Kunden letztendlich mit dem fertiggestellten Produkt begeistern soll, entscheidet der Product-Owner am Ende eines Arbeitszyklus, ob das Arbeitsziel erreicht wurde, oder nicht. Dies wird jedoch anhand zuvor von ihm und dem Entwicklerteam festgelegter Kriterien entschieden. Der Product-Owner sorgt dafür, dass die Kundenwünsche bei der Entwicklung berücksichtigt werden; sein oberstes Interesse gilt jedoch der Wirtschaftlichkeit des Produktes für das eigene Unternehmen. Vor diesem Hintergrund ist er derjenige, der dem Team zu Beginn eine klare Produktvision mitteilt und die Prioritäten der zu entwickelnden Softwareeigenschaften festlegt.
Eine weitere Rolle nimmt der ScrumMaster im Scrum-Team ein. Dessen Aufgabe ist es, Scrum zu etablieren und dafür zu sorgen, dass es richtig angewandt wird. Dabei unterstützt er das Entwicklerteam und schützt es insbesondere vor äußeren Einflüssen, die deren Arbeit stören könnten. Zudem fungiert der ScrumMaster als Schnittstelle zwischen Entwicklerteam und Product-Owner und sorgt für einen guten Informationsfluss zwischen ihnen. Außerdem übernimmt er bei allen Scrum-Meetings die Rolle des Moderators.
Neben den soeben erläuterten drei internen Rollen gibt es noch drei externe Rollen, die für Scrum wichtig sind (die allerdings im ursprünglichen Scrum-Modell nicht definiert waren), nämlich: Management, Customer und User. Auf diese drei wird aufgrund des begrenzten Rahmens hier nicht näher eingegangen.
Welche Arbeitsmittel werden genutzt?
In Scrum gibt drei unterschiedliche Zeremonien, die in Form von regelmäßigen Meetings zu feststehenden Zeiten abgehalten werden. Hierbei werden hauptsächlich Ziele festgesetzt bzw. Ergebnisse besprochen.
Zudem wird – je nach Rolle – mit insgesamt drei unterschiedlichen Artefakten gearbeitet, mit denen z. B. Entwicklungsergebnisse und -fortschritte visualisiert oder wichtige Punkte festgehalten werden. Der ScrumMaster nutzt ein Dokument, in dem er die Störfaktoren festhält, die das Entwicklerteam an seiner Arbeit gehindert haben, um an deren Beseitigung arbeiten zu können. Auf die einzelnen Zeremonien und Artefakte soll in diesem Rahmen nicht weiter eingegangen werden; Literaturvorschläge für eine umfassendere Lektüre finden Sie am Ende des Artikels.
Was führte Gambio zu Scrum?
Unser Unternehmen Gambio – und damit natürlich auch unsere Entwicklungsabteilung – sind in den letzten Jahren und Monaten immer weiter gewachsen. Auch die Baustellen innerhalb unserer eigenen Softwareentwicklung sind nicht weniger geworden. Um eine bessere Struktur in unsere Entwicklungsabläufe zu bringen, haben wir beschlossen, Scrum einzuführen und zu testen, ob es uns als Arbeitsmodell überzeugen kann.
Nach längerer theoretischer Auseinandersetzung mit dem Modell und einigen Überlegungen, wer welche Rolle einnehmen soll, haben wir vor einigen Wochen dann unseren ersten Sprint gehabt. Und wir können nun konstatieren, dass es sich tatsächlich gelohnt hat, Scrum einzuführen.
Aber schauen wir doch noch einmal kurz zurück, um den interessierten Lesern einen kleinen Einblick in unsere ersten Gehversuche mit Scrum zu gewähren.
Wie liefen die Sprints?
Inzwischen haben wir drei Sprints durchgeführt, von denen ich im Folgenden kurz berichten werde.
Unser erster Sprint verlief nicht optimal (wobei ‚optimal‘ hier schwierig zu definieren ist, angesichts der Tatsache, dass das Modell sogar vorsieht, Fehler zu machen, um diese zu entlarven), da sowohl technische Störungen als auch krankheitsbedingte Personalausfälle das Vorankommen der Arbeiten beeinträchtigten. Insgesamt wurden am Ende zwar gute Ergebnisse erzielt, jedoch wurde das Sprintziel nicht erreicht, da die Funktionen nicht einwandfrei liefen. Die festgestellten Bugs wurden dann als Arbeitspakete für den nächsten Sprint festgelegt.
Im zweiten Sprint gab es ähnliche Störfaktoren wie im ersten, wobei darüber hinaus das anstehende Service Pack ein Hindernis darstellte. Obwohl dies in Scrum eigentlich nicht erlaubt ist, hat das Team – in Einverständnis aller Beteiligter – den laufenden Sprint daher um ein paar Tage verlängert und konnte so das Sprintziel letztendlich doch noch erreichen.
Der dritte Sprint war insofern ein besonderer, als dass es hier erstmals um die Entwicklung einer Schnittstelle für einen externen Customer, nämlich einer Partnerfirma von uns, ging. Wurde das Vorankommen dieses Mal nicht durch Krankheitsfälle beeinträchtigt, so zeigten sich hier vor allem Schwierigkeiten in der Planung zu Beginn des Sprints. Da die Umfänge der einzelnen Arbeitspakete im Vorfeld nicht sauber abgeschätzt werden konnten, kam es auch hier zu einer Zeitknappheit. Durch das Ableisten von Überstunden konnte am Ende das Sprintziel dennoch erreicht werden.
Resümierend lässt sich festhalten, dass in unseren bisherigen Sprints vor allem Unsicherheiten bei der Bündelung der Arbeitspakete sowie bei der Einschätzung des benötigten Zeitaufwands dazu führten, dass das jeweilige Sprintziel nicht (oder nur durch Sprintverlängerung oder Überstunden) erreicht werden konnte. Daher zog das Team bereits nach dem ersten Sprint aus dem Problem der Zeitknappheit die Lehre, sich künftig einen Zeitpuffer fest miteinzuplanen.
Weiter erwies sich das Einhalten der strengen Vorgaben für die Meetings, die nämlich nach Scrum einen bestimmten Zeitrahmen nicht überschreiten dürfen, als problematisch. So fiel es vor allem morgens schwer, die Daily Scrums (d. h. die täglichen Meetings) in maximal einer Viertelstunde abzuhalten. Nach und nach scheint hier jedoch durch das tägliche Ritual mit stets gleichen Rahmenbedingungen eine Gewöhnung stattzufinden, sodass es allmählich immer weniger schwerfällt, in den Meetings mit der knappen Zeit auszukommen.
Was gefällt uns an der neuen Arbeitsweise?
Obwohl Scrum für alle Beteiligten eine immense Umstellung im gesamten Arbeitsablauf bedeutet und während der Sprints mit viel Stress einhergeht, konnten wir schon nach kurzer Zeit bemerken, welche Vorteile Scrum bringt.
Zu nennen sind hier vor allem die Flexibilität bei der Planung, die überschaubaren Arbeitsabschnitte, die klaren Abläufe sowie der offene und konstruktive Umgang mit Störfaktoren, die die Arbeit des Teams beeinträchtigen.
Darüber hinaus konnten wir die Behauptung verifizieren, dass die Mitarbeiterzufriedenheit bei Scrum höher als bei herkömmlichen Arbeitsabläufen ist. Unserer nun eigenen Erfahrung nach ist dies durch mehrere Faktoren, die bei Scrum eine Rolle spielen, bedingt: Es gibt klare Strukturen und festgelegte Zeiten, zu denen Aufgaben besprochen und erledigt werden, wodurch die Mitarbeiter ein Gefühl von Sicherheit bekommen. Durch das gemeinsame Kämpfen darum, das selbst definierte Sprintziel zu erreichen, wird die Motivation und das Teamgefühl gestärkt. Auf dem Weg zum Ziel können sich die einzelnen Entwickler Hilfestellungen geben, was sich wiederum positiv auf das Teamgefühl auswirkt. Indem das Team eine Einheit bildet, in der doch jeder seine eigene Aufgabe erfüllt, wird das Wir-Gefühl gestärkt, ohne dass dafür die Individualität zurücktreten müsste. Dadurch, dass die Aufgaben zu kleineren Arbeitspaketen gebündelt und die Arbeitsfortschritte visualisiert werden, wird der Arbeitstag transparent und erhält Struktur, was wiederum die Arbeitsbereitschaft steigert.
Welche Firmen arbeiten noch mit Scrum?
Vor allem in Amerika arbeiten bereits etliche Unternehmen aus der Technik-Branche mit Scrum. Hierzu gehören z. B. Microsoft, Google, Philips und Nokia. Auch Yahoo! setzt Scrum ein und berichtet, dass die Mitarbeiter in einer Umfrage angaben, dass die Teammoral sich verbessert habe (s. Deemer & Benefield 2006).
Auch in Deutschland scheint inzwischen der Trend weg von klassischen Arbeitsprozessen hin zu agilen Prozessen zu gehen. So plant der Versicherungskonzern Allianz offenbar die ganzheitliche Einführung von Scrum (siehe: http://borisgloger.com/2009/01/26/scrum-in-deutschland).
Literatur:
Ken Schwaber: „Agiles Projektmanagement“
Roman Pichler: „Agiles Projektmanagement erfolgreich einsetzen“
[…] Praxiseinsatz bei Gambio – blog.gambio.de/scrum-bei-gambio […]
Ich habe diesen Animationsfilm gefunden und erklärt Scrum einfach und gut: https://scrumguide.de/