Der Paradigmenwechsel im Projekt- und Produktmanagement - eine Einführung

Transkript

1 Scrum Der Paradigmenwechsel im Projekt- und Produktmanagement - eine Einführung (ursprüngliche Version erschienen in: Informatik Spektrum, 33/2/2010, S ) Scrum ist heute der De-facto-Standard in der agilen Softwareentwicklung. 1 In den letzten Jahren hat sich das Verständnis von Scrum als Methode des Projektmanagements grundlegend verändert. 2 Anders als tatsächliche agile Entwicklungsmethoden wie XP oder FDD ist Scrum eine reine Management-Rahmenmethode. Scrum macht keine Vorgaben, wie Software entwickelt werden soll, sondern bereitet das Feld für mehr Kommunikation und bessere Zusammenarbeit im Team und zwischen Team und Kunde. Daher ist Scrum mit jeder gängigen Softwareentwicklungsmethode kombinierbar. Das Besondere an Scrum ist, dass es einen Weg aufzeigt: Den Weg, wie dysfunktional arbeitende Teams, Abteilungen oder ganze Organisationseinheiten und Firmen agil und lean gemanagt werden können. In den meisten Fällen wird Scrum zunächst auf Team- oder Projektebene als Projektmanagementmethode eingesetzt. Dabei bleibt es für einige Unternehmen. Andere gestalten im Laufe der Zeit ihre gesamte Organisation mit Scrum. Was oft mit einem oder wenigen Teams beginnt, kann der Anstoß zur Organisationsentwicklung sein. Agile Methoden der Softwareentwicklung Adaptive Software Development Agile Datawarehousing Crystal Dynamic System Development Method Extreme Programming Feature Driven Development Software Expedition Universal Application Usability Driven Development Die Ursprünge von Scrum liegen in den 1990er-Jahren. Alistair Cockburn, James Coplien, Jim Highsmith, Ken Schwaber, Je ff Sutherland, Kent Beck u.a. hielten im Agile Manifesto ( fest, was sie in ihrer Praxis beobachtet hatten: Kleine Entwicklungsteams, in denen die Teammitglieder dank ihrer generalistischen Skills und O ffenheit verschiedene Aufgaben übernehmen können, liefern Softwareapplikationen schneller, e ffektiver und mit höherer Qualität als große Teams. Der Softwarehersteller VersionOne erhebt seit einigen 1 Agile Softwareentwicklung ist der Oberbegri ff für den Einsatz von Agilität in der Softwareentwicklung. (...) Agile Softwareentwicklung versucht mit geringem bürokratischen Aufwand und wenigen Regeln auszukommen. (siehe Wikipedia) 2 Der Begri ff Scrum stammt aus dem Artikel The New New Product Development Game von Hirotaka Takeuchi und Ikujiro Nonaka. Darin verwenden sie für die crossfunktionale Teamarbeit bei der Neuentwicklung von Produkten das Bild des Scrum, einer Freistoßsituation im Rugby.

2 Jahren die Verbreitung von agilen Methoden. 84% der Umfrageteilnehmer in Nordamerika und Europa gaben 2012 an, dass in ihrem Unternehmen agile Entwicklung eingesetzt wird. 3 Eine auf deutsche Unternehmen konzentrierte Studie der Hochschule Koblenz zeigt, dass sich vor allem Scrum seit 2008 verbreitet hat und aus Sicht der Anwender die Erfolgsquote agiler Methoden um ein Vielfaches höher liegt als jene der klassischen Methoden. 4 Ein Paradigmenwechsel Das Spannende an Scrum ist der wissenschaftliche und erprobte Hintergrund. Was vordergründig einfach erscheint, ist das Ergebnis von Empirie und das interessanterweise aus dem Bereich der traditionellen Fertigung. Obwohl wir es in der Softwareentwicklung hauptsächlich mit immateriellen, von Wissensarbeitern gefertigten Gütern zu tun haben, greifen die Erkenntnisse und Prinzipien des Toyota Production Systems (TPS), kombiniert mit jenen des Knowledgemanagements. Scrum und das TPS beruhen auf den gleichen Vorgehensweisen: 1. Kleine, selbstorganisierte und crossfunktionale Teams, deren Teammitglieder verschiedene Aufgaben durchführen können. 2. Plan, Do, Check, Act - der Deming-Cycle als kontinuierlicher Verbesserungsprozess 3. One-Piece-Flow - es ist immer nur ein Teil in Arbeit 4. Ständiges Eliminieren von Waste, in Scrum als Impediments bezeichnet 5. Pull-Prinzip statt Push-Prinzip Vor allem mit dem kontinuierlichen Liefern von fertigen, nutzbaren Software-Inkrementen am Ende einer Entwicklungs-Iteration, des Sprints, bricht Scrum gänzlich mit traditionellen Ansätzen des Projektmanagements. Scrum steigert die Produktivität Anwender von Scrum berichten immer wieder von erheblichen Produktivitätssteigerungen - das hängt direkt mit den oben genannten Prinzipien zusammen. Sie berichten neben vielen anderen Aspekten vor allem von zufriedeneren Mitarbeitern, höherer Codequalität und besserer Transparenz über den Stand der Produktentwicklung. In den Anfängen von Scrum hatten wir dazu hauptsächlich Berichte aus den USA. Ein sehr spektakuläres Beispiel ist das Sentinel -Projekt des FBI, das mit Scrum vor einem völligen Debakel gerettet werden konnte. Beim Scrum Gathering 2009 in Stockholm präsentierte Steve Green die Ergebnisse von Salesforce.com: Verbesserung der Produktivität (= Zahl der entwickelten Funktionalitäten) um 568%, Steigerung der Lieferungen von 3 VersionOne Komus 2012

3 Funktionalität pro Entwickler um 38% innerhalb eines Jahres. Mittlerweile kommen die guten Nachrichten aber auch aus Deutschland. So arbeitet zum Beispiel Immobilienscout24 seit 2008 mit Scrum. Heute setzen die Entwicklungsteams dort in wesentlich kürzerer Zeit doppelt so viele Funktionalitäten als vor vier Jahren um. 5 Was sind die Gründe für solche Produktivitätssteigerungen? Wenn crossfunktionale Teams gemeinsam am Produkt arbeiten, wird dabei automatisch Wissen geteilt. Außerdem finden Abstimmungen sofort statt. Die Teammitglieder können sich auf eine Aufgabe und ein Projekt fokussieren. Scrum-Teams brauchen keine aufwändige Verwaltung und Kontrolle. Der sonst übliche, vielfache Overhead kann also entfallen. Es gibt klare Verantwortlichkeiten. Konflikte und Probleme werden früher erkannt, besprochen und entschieden. Es fällt sehr schnell auf, wenn etwas nicht zum angepeilten Ergebnis führt. Fehler können daher schnell und somit kostengünstiger korrigiert werden. Das sind nur einige der Gründe. Generell lässt sich sagen, dass Scrum dysfunktionale Strukturen und Abläufe aufdeckt und der ScrumMaster dafür sorgt, dass diese sofort beseitigt werden. Die Anwendung der Prinzipien 1. Kleine, selbstorganisierte Teams Ein Scrum-Team besteht im Idealfall aus sieben Personen: dem ScrumMaster, dem Product Owner und einem fün öpfigen Entwicklungsteam. Aus der eigenen Praxis kann ich bestätigen, dass diese hoche ffektiv sind, weil sie nach dem klassischen Prinzip der self-directed work teams, den autonomen Arbeitsgruppen, gebildet sind. Alle Mitglieder des Entwicklungsteams sind in der Lage, mehrere Arbeiten im Arbeitsprozess durchzuführen und organisieren ihre Aufgaben vollständig selbst. Der ScrumMaster ist nicht Teil des Entwicklungsteams. Er organisiert die Rahmenbedingungen, damit das Scrum-Team so e ffizient wie möglich arbeiten kann. Der Product Owner steuert das Team aus fachlicher Sicht. Er entscheidet, was wann vom Team umgesetzt werden soll. Er macht aber keine Vorgaben, wie das Produkt erstellt werden soll. Neben den drei Rollen, die das Scrum-Team bilden - ScrumMaster, Product Owner und Entwicklungsteam - definieren wir auch die Umgebung des Scrum-Teams. Dazu zählen die drei Rollen Manager, Customer und User. 5 Zeitler 2011

4 Der ScrumMaster als Rolle managt die Grenzen des Scrum-Teams. Er beschützt es vor äußeren Einflüssen und sorgt dafür, dass der Scrum-Prozess von allen eingehalten wird. Um Scrum richtig zu implementieren, arbeitet er auch mit dem Management an produktivitätssteigernden Verbesserungen. Als Person ist der ScrumMaster eine Führungskraft ohne disziplinarische Verantwortung. Das Team unterstützt er bei der Selbstorganisation, indem es die formale Autorität, alle notwendigen Ressourcen und Informationen bekommt. Dazu gehört aber auch, das Team in seinem Verantwortungsgefühl für das zu Liefernde zu stärken. Der Product Owner als Rolle entwirft die Produktvision, also die zugrunde liegende Produktidee. Er erstellt das priorisierte und geschätzte Product Backlog, also die Liste der Funktionalitäten, die zu erarbeiten sind. In seine Verantwortung fällt die Profitabilität der Produktentwicklung - er stellt sie sicher, indem er streng auf den Return-on-Investment achtet. Als Person ist er ein Visionär. Er führt die Produktentwicklung strategisch und beantwortet dem Entwicklungsteam fachliche Fragen. Das Team als Rolle ist verantwortlich für die Lieferung des Produkts, die technische Umsetzung, die Qualität des Gelieferten und die Einschätzung, was es tatsächlich liefern kann. Als Personen, als Teammitglieder, organisieren sie sich so, dass sie alles Versprochene liefern können. Dazu führen sie alle Arbeiten gemeinsam aus und erhöhen ständig ihre Produktivität. Der Manager als Rolle setzt die organisatorischen Rahmenbedingungen. Als Person kann das der Head of Development sein, der Regeln darüber aufstellt, wie zu entwickeln ist. Der Customer als Rolle bezeichnet den Auftraggeber. Der User als Rolle gibt das Feedback zur erstellten Funktionalität. Als Person nutzt er das Produkt. 2. Der Deming-Cycle und Scrum Im Zentrum von Scrum, als Mindset zum professionellen Entwickeln von Produkten, steht die kontinuierliche Verbesserung. Daher ist der Scrum-Flow als eine Folge von Meetings zu sehen, um den von Dr. W. Edwards Deming entworfenen Zyklus Plan-Do-Check-Act zu implementieren. Der Sprint wird vom strategischen Planungsprozess umrahmt. Der Product Owner konkretisiert kontinuierlich die Produktvision, aktualisiert und repriorisiert das Product Backlog und arbeitet mit dem Entwicklungsteam an der sprintübergreifenden Release-Planung. Dazu dienen ihm vor allem zwei Meetings: das Estimation Meeting und das Business Value Estimation Meeting.

5 3. Der One-Piece-Flow Während des Sprints erarbeitet das Entwicklungsteam die zu liefernde Funktionalität konsequent in der priorisierten Reihenfolge. Im Idealfall arbeiten alle Teammitglieder dabei immer an genau einer Funktionalität. Ziel ist es, eine Funktionalität nach der anderen zu liefern. Maintenance- Aufgaben, zum Beispiel die Fehlerbehebung während des Sprints, werden sofort erledigt. Ungeplante, neue Funktionalitäten werden ins Product Backlog gegeben und im nächsten Sprint erledigt. 4. Lösen von Impediments Probleme, sogenannte Impediments, die beim Erstellen der Funktionalitäten auftreten, werden vom ScrumMaster möglichst sofort behoben. 5. Das Pull-Prinzip Beim Pull-Prinzip steuert nicht mehr die Produktionskapazität den Ausstoß der Produktion, sondern einzig der tatsächliche Bedarf an einem Produktteil. Mit diesem Prinzip hat Toyota die gesamte Automobilindustrie revolutioniert. In Scrum wird dieses Prinzip beim Managen von Projekten gelebt: Das Product Backlog wird vom Product Owner basierend auf den Markterfordernissen priorisiert. Technische Machbarkeit spielt bei der Priorisierung der Funktionalitäten eine untergeordnete Rolle. Das Entwicklungsteam entscheidet im Sprint Planning 1, wie viel Funktionalität es liefern wird. Done Entscheidend ist: Am Ende eines Sprints hat das Entwicklungsteam potenziell nutzbare Funktionalität zu liefern. Das heißt: Keine weiteren Arbeiten sind notwendig, um diese Funktionalität an den End-User zu übergeben. Diese Vorgabe muss an die jeweiligen Entwicklungsbedingungen angepasst werden. Deshalb wird zwischen dem Entwicklungsteam und dem Product Owner der Level of Done vereinbart. Der ScrumMaster arbeitet mit dem Team daran, diesen laufend zu erweitern. Im Idealfall wird am Ende des Sprints an den End-User ausgeliefert. Mittlerweile gibt es Scrum-Teams, die nicht nur am Ende des Sprints fertige Software ausliefern, sondern dem Kunden und End-User kontinuierlich, schon während des Sprints neu entstandene Funktionalität bieten.

6 Die Meetings auf strategischer Ebene Im Estimation Meeting erarbeitet das Team gemeinsam mit dem Product Owner ein erstes Grundverständnis über die zu liefernde Funktionalität und schätzt die Größenordnung. Anders als im klassischen Projektmanagement wird dabei nicht der Aufwand geschätzt, sondern der Funktionsumfang. Im Business Value Estimation Meeting werden die Product Backlogs unterschiedlicher Abteilungen gegeneinander priorisiert. Auf diese Weise kann jedes Team an den jeweils wichtigsten Inhalten arbeiten. Im ScrumMasters Weekly besprechen die ScrumMaster aller Teams wichtige Änderungen, identifizieren Impediments auf organisatorischer Ebene und vereinbaren die Lösungsmaßnahmen. In den Knowledge Domain Meetings tre ffen sich die Spezialisten der Teams, zum Beispiel die Datenbankentwickler, um fachliche Richtlinien zu erstellen. Die Meetings auf taktischer Ebene Im Sprint Planning 1 analysiert das Entwicklungsteam die zu liefernde Funktionalität. Wenn das Entwicklunsgteam weiß, wie die Funktionalität aussehen soll, wird vom Scrum-Team (also Entwicklungsteam & Product Owner) die Auswahl getro ffen, was geliefert wird. Im Sprint Planning 2 entsteht die klare Vorstellung darüber, wie die jeweilige Funktionalität zu implementieren ist. Das tägliche Meeting, das Daily Scrum, macht für alle deutlich, was bereits geleistet wurde und was sich jeder Einzelne für den heutigen Tag vornimmt. So entsteht ein Bild der gesamten Leistung als Team, die mit Hilfe eines Task- oder Scrumboards auch visualisiert wird. Auf diese Weise wird für alle sichtbar, wer woran arbeitet, ob es Abstimmungsbedarf gibt, ob irgendwo Probleme auftreten und ein Kollege Unterstützung braucht. Arbeiten mehrere Scrum-Teams an einem Produkt, tre ffen sich die Mitglieder der Entwicklungsteams täglich zum Scrum of Scrums (SoS). Die Teams identifizieren und klären darin die technischen Abhängigkeiten. Die Product Owner bilden das Product Owner Team. Sie tre ffen sich täglich im Product Owner Daily Scrum (PODS) für die Koordination auf der Großprojektebene.

7 Im Sprint Review lassen die Teammitglieder den End-User mit der erstellten Funktionalität experimentieren. Der Product Owner und der ScrumMaster nehmen jede dabei entstehende Idee in das Product Backlog auf. Die Sprint Retrospektive ist ein Meeting für das Entwicklungsteam und den ScrumMaster. Dabei klären sie, wie die Produktivität weiter gesteigert werden kann - zum Beispiel durch das Ausräumen bestimmter Impediments. Scrum im großen Umfeld Zunächst wurde Scrum hauptsächlich auf Teamebene praktiziert. Mittlerweile wurden aber Praktiken entwickelt, um mit Scrum auch Projekte mit mehreren hundert Personen, Abteilungen oder sogar ganze Unternehmen steuern zu können. Dabei werden synchronisierte Sprint Plannings mit bis zu 15 Teams gleichzeitig, SoS mit bis zu 60 Teilnehmern, virtualisierte Daily Scrums und Sprint Reviews im Road-Show-Style durchgeführt. Organisationen setzen Scrum ein, wenn Teams an unterschiedlichen Standorten gemeinsam an einem Produkt arbeiten. Die Arbeiten von Je ff Sutherland zeigen, dass mit Scrum die Produktivität der Softwareentwicklung linear mit der Anzahl der Scrum-Teams wachsen kann. Möglich ist das vor allem, wenn alle Beteiligten in der Organisation die Wirkweise von Scrum verstehen und den Paradigmenwechsel leben. Literatur Beck, K.; Andres C. (2004): Extreme Programming Explained. Embrace Change. 2nd edition. Addison-Wesley Professional, Boston. Cockburn, A. (2006): Agile Software Development. The Cooperative Game. 2nd edition. Addison-Wesley Professional, Boston. Cohn, M. (2006): Agile Estimating and Planning. Prentice Hall Professional Technical Reference. Upper Saddle River, NJ. Coplien, J.O. (1994): Borland Software Craftmanship. A New Look at Process, Quality and Productivity. Software Production Research Department AT&T Bell Laboratories. Orlando. Cutmull, E. (2008): How Pixar fosters Collective Creativity. Harvard Business Review 9, p Derby, E.; Larsen, D. (2006): Agile Retrospectives. Making Good Teams Great. Pragmatic Bookshelf. Raleigh, Dallas. Fisher, K. (2000): Leading Self-Directing Work Teams. McGraw-Hill, New York. Gloger, B. (2013): Scrum. Produkte zuverlässig und schnell entwickeln. Hanser, München. Green, S. (2009): A Year of Living Dangerously. How Salesforce.com delivered Extraordinary Results through a Big Bang Enterprise Agile Revolution. Salesforce.com, Scrum Gathering Stockholm. Komus, A. (2012): Status Quo Agile. Verbreitung und Nutzen agiler Methoden. Eine Studie des BPM-Labors der Hochschule Koblenz. Juli 2012.

8 Liker, J. (2003): The Toyota Way. McGraw-Hill. New York, Chicago, San Francisco. Takeushi, H.; Nonaka I. (1996): The New New Product Development Game. Harvard Business Review, January-February Schmidt, R. (2008): Praktiken des Programmierens. Zur Morphologie von Wissensarbeit in der Softwareentwicklung. Zeitschrift für Soziologie 37 (4). S Schwaber, K. (2004): Agile Project Management with Scrum. Microsoft Press, Redmond. Schwaber, K. (2007): The Enterprise and Scrum. Microsoft Press, Redmond. Sutherland J.; Downey, S.; Granvik, B. (2009): Shocl Therapy. A Bootstrap for Hyperproductive Scrum. agile, 2009 Agile Conference, p VersionOne (2012): 7th Annual State of Agile Development Survey. Zeitler, N. (2011): Die Scrum-Erfahrungen bei ImmobilienScout;