Über Schweine und Hühner
A chicken and a pig are together when the chicken says, "Let's start a restaurant!" The pig thinks it over and says, "What would we call this restaurant?" The chicken says, "Ham n' Eggs!" The pig thinks it over and says, "No thanks, I don’t want to do that: I'd be committed, but you'd only be involved!"
Bei agil durchgeführten Projekten sind alle Beteiligten in die Umsetzung involviert. Wenn das Projekt schiefgeht, sind dies auch die armen Schweine, die nur allzu leicht zu Schinken verarbeitet werden könnten. Das Management, also die Hühner, können aber immer wieder neue Eier (Projektaufträge) legen. Wie kann man sehr stark involviert sein und trotzdem nicht „verbraucht“ werden? Und wozu sind eigentlich die Hühner gut?
Agiles Software-Projektmanagement
Im Februar 2001 trafen sich 17 Befürworter agiler Entwicklungsmethoden um über dieses Thema zu diskutieren, allesamt Persönlichkeiten aus dem Bereich der Softwareentwicklung und des IT-Projektmanagements. Ergebnis dieses Treffens ist das sogenannte agile Manifest bestehend aus vier Kernwerten und einem einzigen Ziel:
„We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.“
Zentrale Idee ist, während eines Projekts auf veränderte Anforderungen reagieren zu können. Dafür wurde der Begriff „agil“ gewählt. Es ist empirisch belegt, dass sich pro Monat auch bei sehr gut gemangten IT-Projekten ca. 1,5% bis 3% der Anforderungen ändern (sog. Requirements Creep). Wir sehen daher als logische Schlussfolgerung, dass Change Management wichtiger ist, als vor Projektstart 100% aller Anforderungen im Detail zu spezifizieren.
Die ursprüngliche Planung mit Arbeitspaketen und Projektablaufplänen wird im agilen Softwareprojektmanagement durch eine Ziel-, Nutzen- und Funktions- orientierte Planung abgelöst. Selbstverantwortliche und selbstorganisierte Teams sorgen dafür, dass letztendlich auch die nötigen Arbeitspakete im Detail geplant und umgesetzt werden. Aber eben erst just-in-time, wenn auch alle benötigten Informationen dafür vorhanden sind.
Abgerundet wird diese Art des agilen Arbeitens durch ein neues Rollenverständnis bezüglich Projektleitung und Management. In Scrum wird die Rolle der Projektleitung gleich auf mehrere Personen aufgeteilt: Scrum Master, Product Owner, Team und auch die Hühner übernehmen Verantwortung, die ursprünglich von einer einzelnen Personen wahrgenommen wurde. So können Fragen, Diskussionen und Konflikte offen ausgetragen werden und führen bei Projekten mit sportlichem Terminplan nicht zur Überlastung einer einzigen Person.
Der Schaden des Hype und typische Vorurteile
Leider führt Popularität von Neuem auch im Projektmanagement oft zur „me-too“ Falle: „Unser Mitbewerb verwendet Scrum, daher müssen wir das jetzt auch verwenden!“ Aber agiles Vorgehen passt nicht zu jedem Projekt, nicht zu jedem Team und schon gar nicht in jede Organisation. Agiles Arbeiten bedeutet eine neue, andere Team- und Unternehmenskultur zu leben, und zwar für Schweine und für Hühner. Die Hühner sollten permanent Eier legen und dafür sorgen, dass die Schweine beim Arbeiten nicht behindert werden. Die Aufgabe des Managements ist in agil organisierten Unternehmen genauso wichtig wie in klassischen Organisationsformen. Aber die Aufgaben verschieben sich, drehen sich am Projektbeginn quasi um (sog. „flip“).
Hier eignet sich unserer Erfahrung nach Scrum
nicht:
• bei zu kleinen Projekten oder zu kleinen Teams
• wenn die Teammitglieder mehrere Projekte gleichzeitig umsetzen sollen
• wenn Widerstand gegen eigenverantwortliches Arbeiten vorherrscht
• wenn man nur „ein bisschen agil“ arbeitet oder glaubt es zu tun
• wenn man Scrum (falsch) an Organisationen anpasst oder verändert
• wenn man die Rollen verändert oder kombiniert (Projekt Owner)
• wenn man sich Wunder in Feuerlöschprojekten erwartet
• wenn man nicht oder nicht adäquat testet
• wenn man laufend die Projektziele ändert
• wenn man denkt, man muss dann gar nicht mehr spezifizieren
• wenn der Kunde Scrum nicht akzeptiert
• wenn Manager sich in Teamentscheidungen einmischen
• wenn Manager ihrem Team nicht zuhören oder nicht vertrauen
• wenn man sich zu wenig Zeit für die Einführung nimmt
Unser Bezug zu agilem Arbeiten und zu Scrum
SCRUM ist einer der bekanntesten Vertreter des agilen Trends beim IT-Projektmanagement. Wir verfügen im Team über fünf zertifizierte Scrum Master (CSM), drei zertifizierte Scrum Product Owner (CSPO) und unterrichten agile Softwareentwicklung in Seminaren und an der Fachhochschule Technikum Wien.
Wenn Sie mehr über agiles Arbeiten und unsere Erfahrungen und Ansichten dazu erfahren wollen, schauen Sie einfach auf Kaffee und Kuchen bei uns vorbei.