Scrum 16.09.2010, 06:00 Uhr

stark im Team

Leadership und Collaboration statt Command und Control: Für diese veränderte Denkweise in der Software-Entwicklung steht Scrum. Ein derart radikaler Perspektivenwechsel braucht jedoch seine Zeit - und engagierte Verfechter.
Ralph Jocham ist Change Agent bei Zühlke Schweiz Scrum ist zurzeit der populärste Prozess in der Software-Entwicklung - neu ist er jedoch nicht. Der aus dem Mannschaftssport Rugby entlehnte Begriff (auf Deutsch: Gedränge) wurde 1986 von den Autoren Takeuchi und Hirotaka geprägt. Sie bezeichneten damit eine neue, agile Produktentwicklungstechnik, die auf der engen, überlappenden Zusammenarbeit aller Teammitglieder beruht. Ken Schwaber und Jeff Sutherland stellten die weiterentwickelte Methode dann 1995 an der Entwicklerkonferenz OOPSLA (Object Oriented Programming, Systems, Languages & Applications) der Öffentlichkeit vor.

Was ist Scrum?

Scrum ist ein empirisches Management-Framework für komplexe Projekte. Der Prozess schreibt keine Software-technischen Praktiken vor. Der Product Owner als Personifizierung des Return on Investments (ROI) hat das Recht, über das «Was» zu entscheiden. Wie das «Was» in eine auslieferbare Software (Potential Shipable Product Increment) umgesetzt wird, ist dem Team überlassen. Zentrales Element des Prozesses ist der «Sprint», die Scrum-Bezeichnung für die Umsetzung einer Teilentwicklungsphase (Iteration). Vor jedem Sprint werden die Anforderungen, die während des Sprints umgesetzt werden sollen, vom Product Owner dem Team vorgestellt. Das Team entscheidet, wie viele der hochprioren Anforderungen es umsetzen kann. Das Ergebnis ist der Sprint Backlog; eine Taskliste. Der Sprint Backlog gehört dem Team und darf im Lauf eines Sprints nur vom Team adaptiert werden. Alle Anforderungen werden vom Product Owner im Product Backlog gepflegt und sind mit absteigender Priorität angeordnet. Dieser Product Backlog ist dynamisch und soll vom Product Owner laufend den neusten Erkenntnissen angepasst werden.

Umdenken erforderlich

Scrum hat das Potenzial, die Software-Entwicklung zu revolutionieren. Diese agile Methode in eine Firma einzuführen, ist jedoch alles andere als trivial. Oft ist zu hören: Scrum funktioniert nicht! Der Prozess scheint auf den ersten Blick einfach, seine Umsetzung erfordert aber einen kulturellen Wandel im Unternehmen und die professionelle Gestaltung wichtiger Software-technischer Disziplinen. In vielen Scrum-Projekten wird die geforderte Produktqualität (Definition of Done) zum definierten Sprintende jedoch nicht erreicht. Woran liegt das? Scrum baut auf den drei Werten Transparenz, Inspektion und Adaption auf. Ob diese Werte gelebt werden, überprüft das Team im täglichen Scrum Meeting, im Sprint Review und in der Retrospective nach jeder Iteration mit einer aktiven Feedback-Kultur (siehe Grafik). Ist die Produktqualität ungenügend, wird dies spätestens im Sprint Review bei der Überprüfung der Defintion of Done sichtbar. Es liegt daher in der Eigenverantwortung des Scrum-Teams, das vom Scrum Master unterstützt und gefördert wird, die Problempunkte zu adressieren und zu beseitigen. So können zum Beispiel Extreme-Programming-Praktiken wie Test Driven Development, Pair Programming, Refactoring oder Continuous Integration eingeführt werden.

Au

s Fehlern lernen

Eine typische Ursache mangelnder Produktqualität ist die ungenügende Überprüfung der Done-Kriterien. Infolgedessen werden keine korrigierenden Massnahmen getroffen und strukturelle Probleme im Projekt verschleppt. Langfristig führt dies zu negativen Konsequenzen für die Sprint-Dynamiken und die Qualität der Software. Erfolgreiche Teams straucheln vielleicht für einen bis zwei Sprints, landen aber dank ihrer aktiven Feedback-Kultur immer wieder auf den Beinen. Diese «Hyperproductive Scrum Teams», wie Jeff Sutherland sie nennt, nutzen Scrum als Management-Framework und kombinieren dieses mit Extreme Programming als Lieferant für Software Engineering Best Practices. Wie das in der Praxis zu bewerkstelligen ist, vermittelt www.scrum.org aufgrund der Erfahrungen aus den letzten 15 Jahren in speziellen Kursen, etwa im Professional Scrum Developer (PSD). Innerhalb von fünf Tagen wird in vier Mini-Sprints der Prozess vorgestellt und unter realistischen Bedingungen gelebt. Die Teilnehmer entwickeln zum Beispiel Features mit XP-Praktiken wie Pair Programming, Test Driven Development, Mocking etc.

Scrum in der Schweiz

In der Schweiz wird im Gegensatz zu den USA noch wenig Agilität in Software-Projekten angewendet. Kein Pionier der Scrum-Bewegung zu sein, hat jedoch Vorteile: Dank eines Jahrzehnts Erfahrung werden agile Prozesse und deren Wechselwirkungen inzwischen besser verstanden. Seit 2010 ist der Damm jedoch gebrochen. Die Schweiz bietet sich für Scrum geradezu an: Viele Firmenstrukturen sind «klein, aber fein», im Vordergrund stehen nicht klassische Kommandostrukturen, sondern Teamarbeit und Kollaboration. Auch das Informatikstrategieorgan des Bundes (ISB) unterstützt diese Arbeitsweise, indem es Hermes (eine Methode, um ICT-Projekte einheitlich und strukturiert durchzuführen) für agiles Vorgehen öffnet. Das ISB arbeitet mit Expertengruppen daran, den Ansatz weiterzuentwickeln.

Fazit: Mut zum Team

Scrum steht für eine völlig neue Denkweise, die akzeptiert, dass Software-Entwicklung nicht definiert, sondern empirisch ist. Eine Denkweise, die nicht auf Command and Control, sondern auf Leadership and Collaboration aufbaut. Entscheidungen, die ein Projektteam ohne Einfluss des Managements fällt, bieten erhebliches Potenzial. Einigen Managern fällt es schwer, dies zu akzeptieren. Doch die Erfolge von Google und anderen ehemaligen Start-ups, die in wenigen Jahren unser Weltbild verändert haben, sprechen für sich. Solche Kraftakte sind nur in einem Kollektiv mit gefordertem und bemächtigtem Teamgeist zu erreichen. Das Management muss sich als Servant Leader - nach dem Motto «führen heisst dienen» - neu erfinden.
Scrum-Leitlinien

Agile Manifesto

Die führenden Köpfe der agilen Software-Entwicklung haben 2001 in Salt Lake City das Agile Manigesto entworfen (http://agilemanifesto.org ). Dessen wichtigster Grundsatz: «Wir entdecken bessere Wege, Software zu entwickeln, indem wir dies selbst praktizieren und anderen dabei helfen, es zu tun.» Folgende Werthaltungen sind dabei zentral:

- Eingehen auf Änderungswünsche hat Vorrang vor striktem Befolgen der Planung
- Individuen und Interaktionen haben Vorrang vor den Prozessen und Werkzeugen
- Funktionsfähige Software hat Vorrang vor ausgedehnter Dokumentation
- Die Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen

Definition of Done

Die Definition of Done ist das Abnahmekriterium, das jedes Product Backlog Item erfüllen muss, bevor es als erledigt betrachtet werden kann und bevor der Projektfortschritt verbucht werden darf. Je nach Domäne kann diese Definition mehr oder weniger umfassend sein.

Typische Punkte einer Definition of Done sind etwa:

- implementiert
- Akzeptanzkriterien des Product Owners erfüllt
- Code Review, wenn nicht pair-programmiert
- dokumentiert
- automatische Unit-Tests
- automatische Integration-Tests
- Quality Assurance Sign Off

Empirical Prozess Control

Empirische Prozesse beruhen auf regelmässigen Kontrollen, um den Status zu inspizieren und darauf zu reagieren. Transparenz, Inspektion und Adaption sind die drei Säulen von Scrum. Diese sind umgesetzt in:

- Product Backlog, Sprint Burndown, Release Burndown: Transparenz im Prozess
- Daily Scrum: Inspektion und Adaption für das Team
- Sprint Review: Inspektion und Adaption für Product Owner, Stakeholder, das Team und weitere Beteiligte
- Retrospective: Inspektion und Adaption für das Team
Ralph Jocham



Das könnte Sie auch interessieren