Man stelle sich vor - man trainiert, arbeitet hart an sich, bereitet sich gut vor und dann kommt endlich der lang ersehnte Tag des Marathons, 42 km - los gehts! Man checkt immer wieder die Zeit, passiert die Zwischenstation, schaut sich um - wer ist vor mir, wer ist neben mir und dann, plötzlich ist der Zieleinlauf in Sichtweite - 5 sec. 4 sec. 3 sec. 2 sec. 1 sec - ZIEL! Der Blick zur Uhr - Enttäuschung und ziemlich genau das emfpand ich nach Abschluss des letzen Scrum Projekts.Um den getrübten Eindruck mit meinem Team zu teilen haben wir das thematisiert und – ich war völlig überrascht – das Entwicklerteam hatte einen weitaus positiveren Eindruck als ich. Das konnte ich kaum glauben und habe versucht herauszufinden, warum ich das anders sah.
Ich stellte dem Entwicklerteam die Frage, warum das Projekt rückblickend so positiv für Sie war. Die Erkenntnis - durch unserer Vorgehen wurde ein Prozess vorgeben, den man bislang vermisst hatte. Es wurden Code Reviews durchgeführt, Pair Programming, automatisiertes Testen, Don’t-repeat-yourselves und damit verbunden aktives Refactoring, Visualisierung der Arbeit mit deren aktueller Status, Wer macht Was im täglichen Meeting und vieles mehr. All das wurde positiv bewertet. Gut!
Fast schon überwältigt habe von den positiven Schwingungen musste ich mich also Fragen – warum empfandest Du das anders als das Team? Nun, ich musste nicht lange überlegen, fand eine Reihe Argumente Warum aber sah das Team das anders?
Ich realisierte, dass mein Team und ich nicht vom selben sprachen: Scrum und agil!
Was das Team in dem Projekt erstmals angewendet hat, waren verschiedene Praktiken aus eXtreme Programming (XP), und zwar iterativ. Scrum hingegen ist nach meiner Interpretation, eher ein Framework für agile Software Entwicklung, genauer: ein Management Modell für agiles Vorgehen und genau hier haben wir extreme Abstriche gemacht.
Wir hatten
keinen richtigen Product Owner, aber einen internen Projektleiter, der den Kunden „gespielt“ hat. (Proxy-Customer) Wir hatten
keinen ScrumMaster. Diverse
Scrum Rituale wurde, auch aufgrund der fehlenden Rollen und deren Aufgaben,
weggelassen. Es gab Arbeiten, die von Personen erledigt wurden, deren
Zugehörigkeit zum Team nicht gegeben war.
Subtrahiert man das alles von der Scrum Theorie, was bleibt dann übrig?
- Big Bang Delivery am Projektende, statt regelmässiges Feedback mit kurzen Release Zyklen
- Kein Feedback vom Kunden während der Realisierung, nur interner Input
- Keine Priorisierung der Arbeit , da keine wirkliche „Business Value“ Beurteilung
- Keine Früherkennung von „Fehlern“, da kein Feedback
- Kein ROI Bewertung während der Entwicklung, da kein Feedback
- Fragen und Abklärungen nur über Dritte, kein direkter Kundenkontakt
- Sequentielles, phasenorientiertes und teilweise unabgestimmtes Vorgehen
Kurz –das ist
nicht agil, das ist
kein Scrum!
Was haben wir daraus gelernt?
Bei den Software Entwicklern kommt XP und iteratives Vorgehen gut an, es macht ihnen Spass und Scrum ist kein Scrum, solange:
- kein "richtiger" Product Owner am Tisch sitzt und Scrum aktiv lebt
- nicht alle notwendigen Ressourcen „scrumisiert“ sind und sich zum Team bekennen
- solange man kein fixed time, fixed scope und fixed budget vorfindet
- wenn bereits (zeitlich) früher gelagerte Projektphase durchlaufen wurden, z.B. Analyse, Grobspezifikation, Detailspezifikation, Design, etc
Treffen die genannten Punkt zu,
- ist das Ökosystem nicht Scrum kompatibel
- kann man die Realisierung(-sphase) mit XP Praktiken empfehlen
Heute und morgen findet das namics.lab von Team Thomas in Diessenhofen statt. In kleinen Teams werden Dinge erarbeitet, die man schon immer mal machen wollte und im Arbeitsalltag nie Zeit gefunden hat. namics räumt den Mitarbeitern einen 2 Tage namics.lab ein, um genau das nachzuholen.
