In unserem Buch „Scrum – kurz & gut“ beschreiben wir ein Schalenmodell agiler Produktentwicklung, das die Rolle von Scrum im Lebenszyklus eines Produkts verortet. Dieses Schalenmodell haben Rolf Dräther und ich auf dem Karlsruher Entwicklertag vorgestellt und im Rahmen einer Fishbowl diskutiert.
Die Mechanik des agilen Projektmanagement-Frameworks Scrum ist schnell beschrieben: drei Rollen, vier Meetings und drei Artefakte. Das Kennen und Beherrschen dieses Instrumentariums reicht aber nicht aus, um mit Scrum wirklich erfolgreiche Projekte durchzuführen. Ein agiles Wertesystem erschließt den Menschen in Scrum-Projekten neue Handlungsmöglichkeiten, fördert Innovation und eine ergebnisorientierte Arbeitsweise. Außerdem muss ein Scrum-Projekt in die wertschöpfenden Prozesse der Produktentwicklung eingebettet werden. Und schließlich gibt es neben den Kernelementen von Scrum noch weitere Methoden, Prinzipien und Praktiken, die sich in den vergangenen zehn Jahren im praktischen Einsatz bewährt haben. Die Summe dieser Aspekte und Perspektiven ergibt ein Ökosystem, in dem ein Produkt gut gedeihen kann. Unser Schalenmodell ist ein Versuch, dieses Ökosystem zu beschreiben. Ausgehend vom Produkt haben wir in unserem Vortrag das Schalenmodell (Halb-)Schale für (Halb-)Schale entwickelt. Anschließend baten wir die Teilnehmer in einer 20-minütigen Fishbowl um ihre Meinung.
Das obige Foto zeigt unser Schalenmodell, annotiert mit den Erkenntnissen aus der Fishbowl-Diskussion. Sehr lange und intensiv wurde über die untere Hälfte des Modells diskutiert. Hier sind die Teamaspekte beschrieben, von den Entwicklungstechniken bis hin zur Zusammenarbeit zwischen agilen Teams. Die zentrale Frage war (wie so oft): wie kommt man zu einem agilen Team? Schafft man lediglich den Rahmen, oder sucht man die „Richtigen“ aus? Was tun mit Menschen, die nicht eigenverantwortlich arbeiten wollen? Gut gefallen hat mir der Vorschlag, wie man das aus dem Scrum Guide verbannte Commitment wieder einführen kann: als Selbstverpflichtung zum Engagement im Entwicklungsteam. Leichter gesagt als getan…
Aber auch die Management-Halbschale unseres Modells wurde diskutiert (berechtigte Frage aus dem Publikum: warum muss diese oben stehen, und die Team-Halbschale unten?). An der Schnittstelle zwischen „agiler Insel“ und nicht agilem Organisationsumfeld kamen Alibi-Pläne zu Einsatz, der Wert guter User Stories wurde betont und mit der Frage verknüpft, wie man einen Product Owner dazu befähigen kann, seiner anspruchsvollen Rolle gerecht zu werden.
Spannend auch die Frage, ob man Agilität lediglich als Arbeitsmethodik betrachten kann und darf, oder ob es sich zwangsläufig um eine innere Einstellung und Geisteshaltung handelt, die sich nicht auf das Arbeitsleben beschränken lässt. Anders gefragt: kann eine Entwicklern oder ein Entwickler nur zwischen 9 und 17 Uhr agil sein? Ich glaube, dass das nicht geht, freue mich aber über Gegenargumente – z.B. als Kommentar auf diesen Blogartikel.