Für unsere internen Projekte und bei einigen Kunden setzen wir seit einiger Zeit auf die agile Methode Scrum . Um unser Wissen zu vertiefen haben wir deshalb letzte Woche mit 13 codecentricern und 2 Kollegen unseres Kunden OEV Online das ScumMaster Certification Training bei Xebia in Holland absolviert. Das Training wurde von Jeff Sutherland durchgeführt, einem der Erfinder von Scrum. Die Folien zum Kurs kann man auf Jeffs Webseiten frei herunterladen.
Das Training war mit Sicherheit eines der Besten, an dem ich teilgenommen haben. Jeff ist ein hervorragender Trainer und Erzähler und seine Ansichten und Methoden um Software Projekte erfolgreich durchzuführen sind durch geniale Einfachheit geprägt und basieren im Prinzip auf einer Reihe erprobter Best Practises, die in Scrum zusammengefasst wurden.
Es gibt schon genügend Bücher und Artikel zum Thema Scrum, so dass dieser Blog Eintrag nur die Highlights und Erkenntnisse aus dem Kurs zusammenfassen soll.
Was ist Scrum?
Scrum ist kein Entwicklungsprozess, sondern eine Methode um Projekte jeglicher Art zu organisieren. Jeff plant beispielsweise die Wochenende zusammen mit seiner Frau auf einem ScrumBoard. Beispiele von anderen Personen, die Ihre Wochenendplanung mit Scrum organisieren, finden sich auch bei Flickr. Bei codecentric nutzen wir Scrum neben den Software Projekten auch um unsere Marketing und Vertriebsaufgaben zu organisieren – dabei setzen wir auf kurze 2 Wochen Sprints. Die Produktivität und Transparenz ist dadurch stark verbessert worden. Ich werde mir auch ein ScrumBoard im Büro aufhängen, um meine eigenen Aufgaben zu strukturieren. Jeff empfiehlt für Software Projekte den Einsatz von Scrum zusammen mit eXtreme Programming , um einen agilen Entwicklungsprozess in Scrum einzuführen. Insbesondere die XP Praktiken wie Continuous Integration , Test-Driven-Development und Coding Standards werden von Jeff als Ergänzung zu Scrum empfohlen. Wir setzen intern und beim Kunden extensiv auf diese Praktiken und der bisherige Erfolg bestätigt uns diesen Weg weiter zu gehen.
Der Nokia Test
Laut Jeff denken viele Teams, dass Sie Scrum einsetzen, machen es aber in Wirklichkeit nicht. Es ist sehr wichtig, dass man Scrum im Ganzen einsetzte und nicht nur einzelne Best-Practises, um die „Lämpchen leuchten zu sehen“, wie es Jeff formuliert. Als Beispiel hierfür nannte er Nokia, die Scrum in weiten Teilen des Unternehmens eingeführt haben. Um zu testen, ob Scrum auch richtig verwendet wird, entwickelte er den so genannten „Nokia Test“. Der Test besteht aus 8 Fragen, die die Teammitglieder der Scrum Team beantworten müssen. Je nach Antwort können 1-10 Punkte je Frage erreicht werden. Nur wenn die durchschnittliche Punktzahl pro Frage > 6 ist, macht ein Team wirklich Scrum und kann eine entsprechende Produktivität erreichen. Für mich hat dieser Test gezeigt, dass man hart daran arbeiten muss wirklich Scrum in seinen Teams einzuführen und wir führen den Test gerade in unseren Teams durch, um Verbesserungspotentiale zu finden.
Velocity
Scrum misst die Produktivität des Teams in jedem Sprint in Form der so genannten Velocity. Während des Kurses wurde mir erst richtig bewusst, wie groß der Nutzen dieser Metrik ist. Die Velocity gibt an, wie viele Story Points ein Team oder ein Teammitglied in einem Sprint abgeschlossen hat. Nach wenigen Sprints sollte die Velocity eines Teams relativ konstant sein, so dass man eine hervorragende Planungsgrundlage hat. Wichtig ist, dass man eine Velocity findet, die das Team nicht überfordert – man spricht deshalb von einer „sustainable pace“. Die Velocity kann aber auch zu Konflikten führen, da sehr schnell aufgezeigt wird, wenn einzelnen Teammitglieder oder Teams keine Velocity haben und damit unproduktiv sind. Transparenz kann eben manchmal auch weh tun. Interessant war auch der Vergleich der Produktivität von großen Scrum Projekten und Projekten die das Wasserfallmodell anwenden. Auf Basis einer längeren Studie konnte eine mehr als 7x (!) höhere Produktivität bei den Scrum Projekten nachgewiesen werden. Nicht umsonst setzen also Firmen wie Google , MySpace und Yahoo! auf Scrum und erzielen damit laut Jeff hohe Produktivitätsgewinne.
Emergency Procedure
Jeff war Jet-Pilot bei der U.S. Air Force , weshalb er besonderen Wert auf eine Emergency Procedure legt, um nicht als „smoking hole in the ground“ zu enden. Merkt man in einem Sprint, das man die Ziele nicht erreichen wird, sollte man diese Prozedur anwenden. Wichtig ist dies frühzeitig zu machen, also maximal zur Halbzeit eines Sprints, weil man ansonsten nicht mehr „aussteigen“ kann. Die empfohlene Prozedur von Jeff lautet:
- Mache etwas anders.
- Hole Dir Unterstützung.
- Mache weniger.
- Stoppe den Sprint.
Der erste Schritt sollte also immer sein nach Wegen zu suchen die Aufgaben anders anzugehen. Laut Jeff gibt es immer mehrer Wege ein Ziel zu erreichen und möglicherweise befindet man sich auf dem falschen und längeren Weg. Der zweite Schritt ist einen externen Experten temporär ins Team zu holen, um die Velocity zu erhöhen. Der dritte Schritt ist Inhalte aus dem Sprint Backlog zu streichen, um doch noch eine lauffähige Software fertigstellen zu können, die „business value“ liefert. Bringen Schritte 1-3 nicht den gewünschten Effekt, muss der Spring gestoppt werden – besser man plant den Sprint neu, als das man als „Erdloch“ endet…
Money for Nothing – Change for Free
Angelehnt an den Dire Straits Songs Money for nothing , schlägt Jeff einen neuen Ansatz für Festpreisprojekte vor: Money for Nothing – Change for Free. Grundlegend bedeutet das, dass man sich mit einem Kunden darauf einigt, dass das Projekt vorher beendet werden kann, wenn der Kunden mit den implementierten Funktionen zufrieden ist. Laut Jeff liefert meistens schon wenig Funktionalität sehr viel Business Value und der Kunde spart viel Geld, wenn er nicht das ganze Projekt umsetzen muss. Vom eingesparten Betrag erhält der Dienstleister einen vereinbarten Anteil, weil er ja nun nicht mehr das gesamte Projekt umsetzen wird. Man erhält aus quasi „Money for Nothing“ und beide Seiten haben gewonnen – die klassischen Win-Win Situation. „Change for Free“ bedeutet, dass der Kunde Anforderungen jederzeit ändern kann, indem er geplante Anforderungen durch Neue mit gleichwertigem Aufwand tauscht oder in der Priorisierung ändert. Da sich laut Jeff mindestens 60% der Anforderungen während eines Projekts ändern, ist dies die einzige Möglichkeit eine hohe Kundenzufriedenheit zu erreichen. Change Management ist aus seiner Sicht nur ein Prozess um dem Kunden nicht das zu geben, was er eigentlich haben möchte – für mich eine interessante Meinung, die ein Umdenken bei uns erfordert.
Skalierbarkeit und verteilte Teams
Sehr interessant waren auch die Beispiele bezüglich verteilter und großer Team in Verbindung mit Scrum. Prinzipiell würde man meinen, dass Scrum nur für kleine und lokale Teams geeignet ist. Jeff hat dies eindrucksvoll an Hand von einigen Beispiele wiederlegt. Scrum skaliert sehr gut und man nutzt dafür virtuelle Teams und so genannter Scrum of Scrums. Bei verteilten Teams kann man Distributed Scrum einsetzen, ein Verfahren bei dem das Team zunächst in einem Sprint zusammen und danach in getrennten Lokationen arbeitet. Eine Verteilung der Teams im Verhältnis 50:50 ist so ohne Verlust der Produktivität möglich. Xebia arbeitet so erfolgreich in großen Projekten mit Ihrer indischen Niederlassung zusammen und hat dies auch durch zahlreiche Statistiken belegt. Xebia hat dabei aber nicht nur die konstante Produktivität, sondern auch eine konstante Qualität nachgewiesen. Für uns ist das ein Beweis dafür, dass wir auf dem richtigen Weg sind. Ende Oktober startet unsere Niederlassung in Doboj, Bosnien und Herzegowina , in der wir Nearshoring Projekte auf Basis von Distributed Scrum durchführen werden.
Neben dem hervorragenden Inhalt war auch die Lokation an einem holländischen Kanal sehr gut gewählt, so dass wir in den Pausen in schöner Atmosphäre weiter diskutieren konnten.
Wir und unsere Kunden sind auf jeden Fall auch im November bei Jeffs Kurs dabei und zertifizieren einige Kollegen die dieses mal nicht teilnehmen konnten.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Mirko Novakovic
21.2.2014 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Mirko Novakovic
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.