Experience. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen DIE WEICHEN RICHTIG STELLEN.

Transkript

1 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.54 september 2012 SCRUM DIE WEICHEN RICHTIG STELLEN Richtig eingestellte Parameter garantieren Produktivität und Effizienz

2 SCRUM: DIE WEICHEN RICHTIG stellen Richtig eingestellte Parameter garantieren Produktivität und Effizienz Mit der agilen und leichtgewichtigen Entwicklungsmethode Scrum werden grosse Softwareprojekte in Bezug auf Funktionalität, Projektdauer und Qualität besser beherrschbar. In der Praxis gelingt dies aber nur, wenn die grundlegenden Parameter durchdacht eingestellt werden. Unter anderem sind die Sprintlänge, die Teamgrösse sowie die Balance zwischen Funktionalität und Qualität erfolgsentscheidend. Von Bruno Heufelder und Michele Tedesco Agile Methoden zur Organisation und Steuerung von Software-Entwicklungsprozessen haben in den vergangenen Jahren massiv an Bedeutung gewonnen. Dabei erfreut sich unter den diversen Ansätzen vor allem Scrum einer wachsenden Beliebtheit. Grund für die zunehmende Verbreitung dieses äusserst schlanken Frameworks ist nicht zuletzt die Erkenntnis, dass auch eine sehr aufwändige Planung die Steuerungssicherheit bei klassischen Methoden häufig nicht verbessern kann. Während traditionelle Verfahren wie das Wasserfallmodell auf einen detaillierten Masterplan setzen, treten bei Scrum Faktoren wie Selbstorganisation, eine unmittelbare und rasche Nutzengenerierung, konstante Aktualitätsprüfung und -anpassung sowie die laufende Einbindung der Nutzer und auch der Auftraggeber in den Vordergrund (Abb. 1). Doch auch wenn lange Konzeptphasen sowie detaillierte Lasten- und Pflichtenhefte fehlen Scrum ist alles andere als planlos: Das Framework definiert ein festes Regelwerk mit eindeutigen Rollen sowie einem klaren und flexiblen Ablauf, der sich zyklisch wiederholt. Das Scrum-Framework verdankt seine Beliebtheit in erster Linie seiner bestehenden Einfachheit Doch so schnell erlern- und einsetzbar die Prinzipien der Rahmenstruktur auch sind gerade bei komplexen Projekten gilt es, einige wichtige Parameter richtig zu setzen. DIE optimale SPRINTLäNGE Im Zentrum von Scrum steht das sich selbst organisierende Projektteam, das in enger Abstimmung mit dem Auftraggeber, dem Product Owner, in zuvor festgelegten Zeitintervallen Teilaufgaben umsetzt. Erklärtes Ziel dieser sogenannten Sprints ist es, lauffähige Funktionen oder Module hervorzubringen. Scrum empfiehlt eine Sprintdauer von einer bis vier Wochen. Doch gerade in grossen und komplexen Softwareprojekten besteht eine Tendenz zur maximalen Sprintlänge. Dies erlaubt zwar die Einplanung von genügend Zeitpuffern, macht aber nicht selten den grössten Vorteil von Scrum nämlich die Flexibilität zunichte: Die Feedbackschleifen verlängern sich und mit ihnen auch die Reaktionszeiten. Zudem müssen sich die Teammitglieder für die Fehlerkorrektur immer wieder in ältere Themen einarbeiten. Auch neue Anforderungen oder Prioritäten, die sich in Grossprojekten oftmals in kurzen Abständen verändern, sorgen für Verzögerungen. Eine vorausschauende und vor allem verlässliche Planung wird in der Folge immer schwieriger. Bei schnellen Change-Management- Zyklen ist darum eine kürzere Sprintdauer von beispielsweise zwei Wochen optimal. Sie ermöglicht es, Hindernisse und Änderungen durch einzelne Stakeholder früher zu berücksichtigen. Zudem zwingt sie sowohl den Product Owner wie auch das Team zu einer klaren Fokussierung auf das aktuelle Ziel.

3 scrum Im Zentrum von Scrum steht das sich selbst organisierende Projektteam, das in enger Abstimmung mit dem Auftraggeber, dem Product Owner, in zuvor festgelegten Zeitintervallen Teilaufgaben umsetzt. Erklärtes Ziel dieser sogenannten Sprints ist es, lauffähige Funktionen oder Module hervorzubringen.

4 Abb. 1: Scrum Prozessübersicht Ready Done Team Customer Daily Stand-up Product Backlog Sprint Planning Meeting Sprint Backlog (Priorities) 1 4 Weeks Sprint Review Potentially shippable Sprint Product Owner Scrum Master Sprint Retrospective Scrum empfiehlt eine Sprintdauer von einer bis vier Wochen. Doch gerade in grossen und komplexen Softwareprojekten besteht eine Tendenz zur maximalen Sprintlänge. Dies erlaubt zwar die Einplanung von genügend Zeitpuffern, macht aber nicht selten den grössten Vorteil von Scrum nämlich die Flexibilität zunichte: Die Feedbackschleifen verlängern sich und mit ihnen auch die Reaktionszeiten. Zudem müssen sich die Teammitglieder für die Fehlerkorrektur immer wieder in ältere Themen einarbeiten. Auch neue Anforderungen oder Prioritäten, die sich in Grossprojekten oftmals in kurzen Abständen verändern, sorgen für Verzögerungen. Eine vorausschauende und vor allem eine verlässliche Planung wird in Folge immer schwieriger.

5 scrum Die ideale TeaMGRöSSE Ein zweiter entscheidender Erfolgsfaktor ist die Teamgrösse. Das Framework sieht ein maximal neunköpfiges Team vor, das stets interdisziplinär besetzt wird, damit es alle fachlichen Anforderungen autonom realisieren kann. Ist das Team zu klein, fehlen oft die notwendigen Kompetenzen, um alle Aufgaben optimal umzusetzen. Übersteigt die Teamgrösse hingegen das empfohlene Maximum, sind Probleme auf der Kommunikationsebene praktisch vorprogrammiert. Die einzelnen Mitglieder können sich nicht mehr intensiv genug miteinander austauschen und die Entscheidungsfindung zieht sich in die Länge. Damit besteht auch die Gefahr, dass der Fokus auf die jeweiligen Iterationsziele verloren geht. feature versus QuaLITät Budgetzwänge, immer kürzere Time-to- Market-Zyklen und technische Komplexität gehören zum Alltag von Entwicklungsprojekten. Sie stehen damit zwangsläufig im Spannungsfeld zwischen Funktionsum- fang und Qualität. Oft kommt es zu einem Kräftemessen zwischen dem Product Owner, der die umgehende Umsetzung neuer Features oder Anforderungen einfordert, und dem Entwicklungsteam, das in der Regel ein hochwertiges, den sogenannten «Definitions of Done» entsprechendes Produkt abliefern will. Wenn einem System neue Funktionalitäten in Form von Prototypen und nur auf kurzfristigen Nutzen hin ausgerichtet hinzugefügt werden, häufen sich die sogenannten technischen Schulden an: Durch mangelndes Softwaredesign, unzureichendes oder fehlendes Testing, unsauberen Code oder unbeabsichtigte Komplexität entsteht mit der Zeit ein immer instabileres System, das im schlimmsten Fall die gesamte weitere Entwicklung ausbremsen kann. Lösen lässt sich dieses Dilemma nur, wenn sich unter allen Beteiligten die Erkenntnis festigt, dass sich durch kurzfristige Umsetzungsstrategien ein Entwicklungsprojekt nicht beschleunigt. Die Erfahrung zeigt, dass am Ende des Tages die technischen Schulden samt Zinsen zurückbezahlt werden müssen, um ein sauberes, erweiterbares und wartbares System zu erhalten. Beispiel 1 DurchdaCHTE AufTEILUNG steigert ProduktivITät Die bereits weit fortgeschrittene Entwicklung eines komplexen Embedded Systems drohte sich zu verzetteln. Eines der involvierten Projektteams wuchs im Laufe der Zeit immer weiter und war zum Schluss grösser als von Scrum empfohlen. Dies hatte unter anderem zur Folge, dass Entscheidungsfindungen innerhalb des Teams immer mehr Zeit beanspruchten und es bei den täglichenscrum-meetings schwierig wurde, die vorgegebene Zeitspanne von 15 Minuten einzuhalten. Auf Empfehlung von Scrum-Spezialisten wurde die Mannschaft nach einer genaueren Analyse der Situation in zwei Teams

6 Ein entscheidender Erfolgsfaktor ist die Teamgrösse. Das Framework sieht ein maximal neunköpfiges Team vor, das stets interdisziplinär besetzt wird, damit es alle fachlichen Anforderungen autonom realisieren kann. Ist das Team zu klein, fehlen oft die notwendigen Kompetenzen, um alle Aufgaben optimal umzusetzen.

7 scrum mit jeweils einem eigenen Scrum-Master aufgeteilt. Indem sich die Teams weiterhin den Product Owner und den Product Backlog teilten, konnte die optimale Koordination zwischen ihnen erreicht werden. Der Product Backlog wird heute im Sprint Planning Meeting zwischen den Teams aufgeteilt. So kann sich jedes Unterteam besser auf seine jeweiligen Aufgaben fokussieren. Die täglichen Standup-Meetings sowie die Retrospektiven können nun in den kleineren Einheiten problemlos innerhalb der veranschlagten Zeit durchgeführt werden. Unter dem Strich hat das durchdachte Splitting die Effizienz und die Produktivität erhöht sowie gleichzeitig die Motivation der Mitarbeitenden gesteigert. Beispiel 2 verkürzung der SPRINTS verhin- DERT ArbeitsstaUS Nach eingehender Analyse der Situation wurde die Sprintlänge auf einen halben Monat gekürzt. Im Entwicklerteam warf dieser Schritt zunächst die Frage auf, wie die Tasks, die man vorher schon in einem Monat nicht umgesetzt hatte, nun in der Hälfte der Zeit abgearbeitet werden sollten. Doch rasch wurde der markante Effizienzgewinn der nunmehr verkürzten Zyklen offensichtlich: Zum einen schrumpfte die Dauer der Planungsmeetings auf unter vier Stunden. Zum anderen konnte das Team aufgrund der nun überschaubaren Zeitfenster und der erhöhten Transparenz sich wesentlich besser fokussieren sowie schneller und effizienter auf Unvorhergesehenes reagieren. Auf diese Weise wurden auch die abgegebenen Commitments realistischer und können heute weitgehend eingehalten werden, was die Planbarkeit des Gesamtprojekts entscheidend verbessert. In einem komplexen, auf mehrere Jahre ausgelegten Entwicklungsprojekt in einem Technologieunternehmen wurde in der Initialisierungsphase die Länge der Sprints auf einen Monat festgelegt. Mit der Zeit kristallisierte sich heraus, dass eine saubere Planung über diese Zeitspanne immer schwieriger wurde. Aufgrund der grossen Anzahl an User Stories, die es jeweils für das Sprint Backlog aufzubereiten galt, dauerten die Planungsmeetings acht Stunden und mehr. Es kam in der Folge zu Arbeitsstaus und immer grösseren Schwierigkeiten in der langfristigen Planbarkeit der Fortschritte. Das Entwicklerteam konnte seine Commitments, mit denen es sich jeweils nach den Sprint Planning Meetings zur Erfüllung der definierten Aufgaben verpflichtet hatte, immer öfter nicht einhalten. ERNI Innovation in Process and Technology Bruno Heufelder bruno.heufelder@erni.ch Beratertätigkeit: Scrum Master, Agile Coach, Projektleiter MicHEle Tedesco michele.tedesco@erni.ch Beratertätigkeit: Software Engineering, Scrum Project Management

8 IMPRESSUM Herausgeber ERNI Management Services AG Zürich Bern Baar Lausanne München Frankfurt Barcelona Bratislava Redaktion Adela Novotná, ERNI (Slovakia) s.r.o. Tel leserservice@erni.ch Lektorat Daniel Meierhans, inhalte.ch GmbH, Zürich Ruedi Häuptli, Sprachagentur Bahia, Salvador BR Konzept/Layout Dieter Nafzger, Katarína Beinrohrová Produktion von Ah Druck AG, Sarnen Auflage Expl. dt., 2500 Expl. en. Erscheint quartalsweise ISSN Copyright 2012 by ERNI Management Services AG Alle Rechte vorbehalten.

9

10