... IT-Consulting, Aikido, Strategie und alles was mir sonst noch einfällt und nicht in mein englisches Blog passt...

Mittwoch, 20. Oktober 2010

Scrum? Das ist doch das mit den Kreisen!

Na Super!
Vielen Dank auch an die Marketing-Spezialisten...
(Die Titelzeile "Scrum? Das ist doch das mit den Kreisen!" ist ein reales Zitat von einem Networking-Treffen im Herbst 2010...)

Das einfache Bild (dass ja bekanntlich sogar auf einen Bierdeckel passt ist) hat sicherlich viel dazu beigetragen, Scrum und auch dem Gedanken agiler Prozesse ganz allgemein zu der heutigen Akzeptanz zu verhelfen.

Als "hilfreiche Vereinfachung um die Grundgedanken von Scrum zu transportieren" kann ich mit diesem Bild leben. Zur Einführung eines Scrum-basierten agilen Prozesses werden aber meiner Erfahrung nach doch einige Aspekte mehr benötigt.


("Standard"-Bild zu Scrum)

Die andere Seite - das Produkt ist nicht das einzige, was durch einen Scrum-basierten Prozess verbessert wird - wird zunehmend auch wahrgenommen, wie David Harvey in seinem Beitrag deutlich macht.


(David Harveys Bild zu Scrum )

Was David Harvey hier herausstellt ist die Tatsache, dass neben dem eigentlichen Produkt durch den Prozess selber auch noch ein Team und ein im Team gelebter, konkreter Prozess erzeugt werden, die sich auch mit jedem Inkrement verbessern.

Was man darüber hinaus aber nicht vergessen darf ist, ...

[Vorsicht, Analogie für Softwareentwickler, die Objektorientierung kennen]
dass Scrum so etwas ist wie eine abstrakte Klasse - man kann es nicht instantiieren ohne die spezifizierten Methoden zu implementieren - und wenn man die Implementierung nur in Form von leeren Stubs durchführt kann man auch kaum erwarten, dass die Instanz sinnvolle Arbeit leistet.

[Nach einer guten Analogie für BWL oder PMI Spezialisten suche ich noch, hier die schlechte]
dass Scrum nur den groben Bauplan vorgibt - wie bei einem "Standardhaus", welches man so auch nicht bauen kann ohne sich nicht zu entscheiden, wie man bei diesem konkreten Exemplar die Wände zieht, was für Treppen man einsetzt und wo welche Anschlüsse nun wirklich liegen sollen.

Das reale Bild - und auch hier sind noch nicht alle relevanten Details aufgeführt - sieht dann eher so aus wie diese konkrete Instanz eines Scrum-basierten Entwicklungsprozesses:

(um Missverständnisse zu vermeiden: Dies war eine konkrete Ausgestaltung für ein konkretes Team - bitte nicht verallgemeinern!






Was ich damit deutlich machen will ist folgendes:
Ja, auf einer abstrakten Ebene ist Scrum ganz einfach - genau so, wie beispielsweise ein Auto auf einer abstrakten Ebene ganz einfach ist: drei bis vier Räder, Motor, Getriebe, Bremsanlage, ein paar Schaltelemente und eine selbsttragende Karosserie, fertig ist das Auto. Aber der Unterschied zwischen einem Benz Patent-Motorwagen Nummer 1 und einem Tesla Model S (oder irgend einem anderen aktuellen Fahrzeug) liegt sicher nicht nur im unterschiedlichen Zeitgeschmack, was die Gestaltung der Speichen anbelangt.
Nein, es reicht nicht, wenn man sich den Bierdeckel nur lange genug anguckt. Wenn man eine auch nur halbwegs konkurrenzfähige Umsetzung des einfachen Konzeptes haben will, dann muss sich sich intensiv mit den Details auseinander setzen und auch bereit sein, diese von Generation zu Generation (oder in unserem Fall von Iteration zu Iteration) zu überdenken.

1 Kommentar:

cuchulin hat gesagt…

Hi Michael,
Man könnte aber auch noch Parallelen zur Evolutionsbiologie finden: Scrum hat den selbstverbessenderen Charakter zum Fit an die Umwelt. Dieser Fit wird durch die Methodik, die auf ein Team zugeschnitten sein muss, erreicht. Ein Teammitglied ist sowas wie ein Gen (in diesem Bild) Nur bestimmte Gene in bestimmter Interaktion (methodik) führen zu dem Phaenotyp = Produkt. Eine Iteration ist demnach eine Generation. Über die Zeit können Teammitglieder kommen oder gehen, Ähnlich von Genomen, die sich durch Rekombination ändern.

Genauso wie in der Evolution gibt es nicht die "beste" Lösung , sondern die für die Anforderung Passende.