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\u00fchrung dieser f\u00fcr uns neuen Methode machen konnten und res\u00fcmieren, ob sich dieser Schritt gelohnt hat.<\/p>\n
Manche von Ihnen werden \u2013 wenn Sie z. B. als Softwareentwickler in einem modernen Unternehmen besch\u00e4ftigt sind \u2013 tagt\u00e4glich mit Scrum zu tun haben, w\u00e4hrend vermutlich viele von Ihnen nichts mit diesem Begriff anzufangen wissen. Vor allem f\u00fcr Zweitgenannte wird der nun folgende Textabschnitt von Interesse sein, da dieser eine kurze Einf\u00fchrung in das Thema geben soll. Der letzte Abschnitt dieses Textes d\u00fcrfte auch f\u00fcr die Scrum-Kenner unter Ihnen relevant sein, wenn Sie sich f\u00fcr Gambio und dessen Entwicklungst\u00e4tigkeit interessieren.<\/p>\n
Was ist Scrum und wof\u00fcr ist es gut?<\/strong><\/p>\n Scrum kommt, wie die meisten in der Softwarebranche etablierten Termini, aus dem Englischen und bedeutet \u00fcbersetzt ‚Gedr\u00e4nge‘. Verwiesen wird hierbei auf den Spielzug des Gedr\u00e4nges 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\u00dfteil der durchzuf\u00fchrenden Entwicklungsprojekte zu komplex ist, um sich im herk\u00f6mmlichen Sinne und von vornherein vollst\u00e4ndig planen zu lassen. Jeder, der einmal mit der Entwicklung gr\u00f6\u00dferer Softwareprojekte zu tun hatte, wird dieses Kernproblem kennen. Aufgrund der Komplexit\u00e4t von Softwareprojekten und dem herk\u00f6mmlichen Anspruch, die zu Anfang gesteckten Ziele in jedem Fall zu erreichen, kommt es h\u00e4ufig dazu, dass das Endprodukt dem Kunden gar nicht gef\u00e4llt \u2013 womit nat\u00fcrlich viel Arbeitskraft fehlinvestiert wurde. Um genau dies zu vermeiden, organisiert Scrum den Entwicklungsprozess daher anders, n\u00e4mlich 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\u00e4sentiert wird, sondern kleinere fertige Teile jeweils bereits nach k\u00fcrzeren Zeitabschnitten gezeigt und bewertet werden. So wird die Arbeit des Entwicklerteams regelm\u00e4\u00dfig \u00fcberpr\u00fcft und angepasst, sodass am Ende die Produktqualit\u00e4t h\u00f6her ist als nach einem auf herk\u00f6mmliche Weise bearbeiteten Softwareprojekt.<\/p>\n Wie funktioniert Scrum?<\/strong><\/p>\n Scrum sieht fest verteilte, obligatorische Rollen und klar definierte Regeln vor, deren konsequente Anwendung f\u00fcr das Gelingen vonn\u00f6ten ist.<\/p>\n So gibt es im Vorhinein festgelegte Entwicklungsintervalle, die immer gleich lang sein m\u00fcssen. Diese so genannten Sprints dauern zwischen einer und vier Wochen. Das Ziel eines Sprints ist eine auslieferbare Software-Funktionalit\u00e4t, die bereits getestet und integriert ist, sodass sie dem Kunden pr\u00e4sentiert werden kann.<\/p>\n Wer geh\u00f6rt zum Scrum-Team?<\/strong><\/p>\n Ein Scrum-Team besteht aus insgesamt f\u00fcnf bis zehn Mitgliedern.<\/p>\n 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 \u00fcbernimmt. Das Entwicklerteam sollte interdisziplin\u00e4r besetzt sein, damit es ohne externe Hilfe arbeiten kann. Es darf w\u00e4hrend eines Sprints nicht gest\u00f6rt werden, damit es sich ganz auf seine Arbeit konzentrieren und den Zeitplan einhalten kann. Die Entwickler treten bei Scrum grunds\u00e4tzlich als Team auf \u2013 daher werden sowohl positive als auch negative Ergebnisse immer auf das Team als Einheit und niemals auf ein einzelnes Mitglied zur\u00fcckgef\u00fchrt.<\/p>\n Bei Scrum gibt es keinen klassischen Projektleiter; es gibt jedoch einen Product-Owner, der f\u00fcr 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\u00fcr R\u00fcckfragen zur Verf\u00fcgung. 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\u00fcr, dass die Kundenw\u00fcnsche bei der Entwicklung ber\u00fccksichtigt werden; sein oberstes Interesse gilt jedoch der Wirtschaftlichkeit des Produktes f\u00fcr das eigene Unternehmen. Vor diesem Hintergrund ist er derjenige, der dem Team zu Beginn eine klare Produktvision mitteilt und die Priorit\u00e4ten der zu entwickelnden Softwareeigenschaften festlegt.<\/p>\n Eine weitere Rolle nimmt der ScrumMaster im Scrum-Team ein. Dessen Aufgabe ist es, Scrum zu etablieren und daf\u00fcr zu sorgen, dass es richtig angewandt wird. Dabei unterst\u00fctzt er das Entwicklerteam und sch\u00fctzt es insbesondere vor \u00e4u\u00dferen Einfl\u00fcssen, die deren Arbeit st\u00f6ren k\u00f6nnten. Zudem fungiert der ScrumMaster als Schnittstelle zwischen Entwicklerteam und Product-Owner und sorgt f\u00fcr einen guten Informationsfluss zwischen ihnen. Au\u00dferdem \u00fcbernimmt er bei allen Scrum-Meetings die Rolle des Moderators.<\/p>\n Neben den soeben erl\u00e4uterten drei internen Rollen gibt es noch drei externe Rollen, die f\u00fcr Scrum wichtig sind (die allerdings im urspr\u00fcnglichen Scrum-Modell nicht definiert waren), n\u00e4mlich: Management, Customer und User. Auf diese drei wird aufgrund des begrenzten Rahmens hier nicht n\u00e4her eingegangen.<\/p>\n Welche Arbeitsmittel werden genutzt?<\/strong><\/p>\n In Scrum gibt drei unterschiedliche Zeremonien, die in Form von regelm\u00e4\u00dfigen Meetings zu feststehenden Zeiten abgehalten werden. Hierbei werden haupts\u00e4chlich Ziele festgesetzt bzw. Ergebnisse besprochen.<\/p>\n Zudem wird \u2013 je nach Rolle \u2013 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\u00f6rfaktoren festh\u00e4lt, die das Entwicklerteam an seiner Arbeit gehindert haben, um an deren Beseitigung arbeiten zu k\u00f6nnen. Auf die einzelnen Zeremonien und Artefakte soll in diesem Rahmen nicht weiter eingegangen werden; Literaturvorschl\u00e4ge f\u00fcr eine umfassendere Lekt\u00fcre finden Sie am Ende des Artikels.<\/p>\n Was f\u00fchrte Gambio zu Scrum?<\/strong><\/p>\n Unser Unternehmen Gambio \u2013 und damit nat\u00fcrlich auch unsere Entwicklungsabteilung \u2013 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\u00e4ufe zu bringen, haben wir beschlossen, Scrum einzuf\u00fchren und zu testen, ob es uns als Arbeitsmodell \u00fcberzeugen kann.<\/p>\n Nach l\u00e4ngerer theoretischer Auseinandersetzung mit dem Modell und einigen \u00dcberlegungen, wer welche Rolle einnehmen soll, haben wir vor einigen Wochen dann unseren ersten Sprint gehabt. Und wir k\u00f6nnen nun konstatieren, dass es sich tats\u00e4chlich gelohnt hat, Scrum einzuf\u00fchren.<\/p>\n Aber schauen wir doch noch einmal kurz zur\u00fcck, um den interessierten Lesern einen kleinen Einblick in unsere ersten Gehversuche mit Scrum zu gew\u00e4hren.<\/p>\n Wie liefen die Sprints?<\/strong><\/p>\n Inzwischen haben wir drei Sprints durchgef\u00fchrt, von denen ich im Folgenden kurz berichten werde.<\/p>\n 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\u00f6rungen als auch krankheitsbedingte Personalausf\u00e4lle das Vorankommen der Arbeiten beeintr\u00e4chtigten. 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\u00fcr den n\u00e4chsten Sprint festgelegt.<\/p>\n Im zweiten Sprint gab es \u00e4hnliche St\u00f6rfaktoren wie im ersten, wobei dar\u00fcber hinaus das anstehende Service Pack ein Hindernis darstellte. Obwohl dies in Scrum eigentlich nicht erlaubt ist, hat das Team \u2013 in Einverst\u00e4ndnis aller Beteiligter \u2013 den laufenden Sprint daher um ein paar Tage verl\u00e4ngert und konnte so das Sprintziel letztendlich doch noch erreichen.<\/p>\n Der dritte Sprint war insofern ein besonderer, als dass es hier erstmals um die Entwicklung einer Schnittstelle f\u00fcr einen externen Customer, n\u00e4mlich einer Partnerfirma von uns, ging. Wurde das Vorankommen dieses Mal nicht durch Krankheitsf\u00e4lle beeintr\u00e4chtigt, so zeigten sich hier vor allem Schwierigkeiten in der Planung zu Beginn des Sprints. Da die Umf\u00e4nge der einzelnen Arbeitspakete im Vorfeld nicht sauber abgesch\u00e4tzt werden konnten, kam es auch hier zu einer Zeitknappheit. Durch das Ableisten von \u00dcberstunden konnte am Ende das Sprintziel dennoch erreicht werden.<\/p>\n Res\u00fcmierend l\u00e4sst sich festhalten, dass in unseren bisherigen Sprints vor allem Unsicherheiten bei der B\u00fcndelung der Arbeitspakete sowie bei der Einsch\u00e4tzung des ben\u00f6tigten Zeitaufwands dazu f\u00fchrten, dass das jeweilige Sprintziel nicht (oder nur durch Sprintverl\u00e4ngerung oder \u00dcberstunden) erreicht werden konnte. Daher zog das Team bereits nach dem ersten Sprint aus dem Problem der Zeitknappheit die Lehre, sich k\u00fcnftig einen Zeitpuffer fest miteinzuplanen.<\/p>\n Weiter erwies sich das Einhalten der strengen Vorgaben f\u00fcr die Meetings, die n\u00e4mlich nach Scrum einen bestimmten Zeitrahmen nicht \u00fcberschreiten d\u00fcrfen, als problematisch. So fiel es vor allem morgens schwer, die Daily Scrums (d. h. die t\u00e4glichen Meetings) in maximal einer Viertelstunde abzuhalten. Nach und nach scheint hier jedoch durch das t\u00e4gliche Ritual mit stets gleichen Rahmenbedingungen eine Gew\u00f6hnung stattzufinden, sodass es allm\u00e4hlich immer weniger schwerf\u00e4llt, in den Meetings mit der knappen Zeit auszukommen.<\/p>\n Was gef\u00e4llt uns an der neuen Arbeitsweise?<\/strong><\/p>\n Obwohl Scrum f\u00fcr alle Beteiligten eine immense Umstellung im gesamten Arbeitsablauf bedeutet und w\u00e4hrend der Sprints mit viel Stress einhergeht, konnten wir schon nach kurzer Zeit bemerken, welche Vorteile Scrum bringt.<\/p>\n Zu nennen sind hier vor allem die Flexibilit\u00e4t bei der Planung, die \u00fcberschaubaren Arbeitsabschnitte, die klaren Abl\u00e4ufe sowie der offene und konstruktive Umgang mit St\u00f6rfaktoren, die die Arbeit des Teams beeintr\u00e4chtigen.<\/p>\n Dar\u00fcber hinaus konnten wir die Behauptung verifizieren, dass die Mitarbeiterzufriedenheit bei Scrum h\u00f6her als bei herk\u00f6mmlichen Arbeitsabl\u00e4ufen 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\u00fchl von Sicherheit bekommen. Durch das gemeinsame K\u00e4mpfen darum, das selbst definierte Sprintziel zu erreichen, wird die Motivation und das Teamgef\u00fchl gest\u00e4rkt. Auf dem Weg zum Ziel k\u00f6nnen sich die einzelnen Entwickler Hilfestellungen geben, was sich wiederum positiv auf das Teamgef\u00fchl auswirkt. Indem das Team eine Einheit bildet, in der doch jeder seine eigene Aufgabe erf\u00fcllt, wird das Wir-Gef\u00fchl gest\u00e4rkt, ohne dass daf\u00fcr die Individualit\u00e4t zur\u00fccktreten m\u00fcsste. Dadurch, dass die Aufgaben zu kleineren Arbeitspaketen geb\u00fcndelt und die Arbeitsfortschritte visualisiert werden, wird der Arbeitstag transparent und erh\u00e4lt Struktur, was wiederum die Arbeitsbereitschaft steigert.<\/p>\n Welche Firmen arbeiten noch mit Scrum?<\/strong><\/p>\n Vor allem in Amerika arbeiten bereits etliche Unternehmen aus der Technik-Branche mit Scrum. Hierzu geh\u00f6ren 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).<\/p>\n 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\u00fchrung von Scrum (siehe: http:\/\/borisgloger.com\/2009\/01\/26\/scrum-in-deutschland).<\/p>\n Literatur:<\/strong><\/p>\n Ken Schwaber: „Agiles Projektmanagement“<\/p>\n Roman Pichler: „Agiles Projektmanagement erfolgreich einsetzen“<\/p>\n