Scrum: 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.

weitere Artikel

» Von Ralph Jocham, 16.09.2010 06:00.

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.

Werbung

KOMMENTARE

Keine Kommentare

KOMMENTAR SCHREIBEN

*
*
*
*

Alles Pflichfelder, E-Mail-Adresse wird nicht angezeigt.

Die Redaktion hält sich vor, unangebrachte, rassistische oder ehrverletzende Kommentare zu löschen.
Die Verfasser von Leserkommentaren gewähren der IDG Communications AG das unentgeltliche, zeitlich und räumlich unbegrenzte Recht, ihre Leserkommentare ganz oder teilweise auf dem Portal zu verwenden. Eingeschlossen ist zusätzlich das Recht, die Texte in andere Publikationsorgane, Medien oder Bücher zu übernehmen und zur Archivierung abzuspeichern.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

MiniAds