Die Pyramide der Agilität

"Wir haben Scrum durch Kanban abgelöst"

"Seit wir eXtreme Programming durch Scrum abgelöst haben […]"
"Wir arbeiten nicht mit agilen Methoden sondern nach CMMI"

Sätze, die mich immer wieder verblüffen - zutiefst.

Die "Pyramide der Agilität" oder das "Agile Dreieck" sind Begriffe, die sich bei einigen Kollegen und mir über die letzten Jahre etabliert haben um das miteinander der Methoden zu beschreiben - nicht umsonst schreibt beispielsweise David J. Anderson - einer der wichtigsten Protagonisten von Software-Kanban "Kanban is not a Process"!

Aus meiner Sicht sind die agilen Methoden im Idealfall Bausteine, die zusammen eine Pyramide bilden können, in der die unteren Ebenen die oberen Ebenen stützen und die oberen Ebenen Erkenntnisgewinne für die unteren Ebenen generieren.

Um diese Sichtweise ein wenig zu illustrieren, hier meine grafische Einordnung der wichtigsten agilen (und eines nicht agilen) Schlagworte innerhalb dieser Pyramide.

Dilettierender Amateur - erstrebenswert, aber selten

Aus der Reihe: Ich glaube nicht, dass dieses Wort bedeutet, was Du glaubst, das es bedeutet...

Wir brauchen Profis und keine Amateure und Dilettanten!

Ach ja?

Wenn wir z.B. die Feinstarbeit betrachten, mit der ein Amateur-Modell-Flugzeugbauer (also jemand, der aus Liebe zur Sache Modell-Flugzeuge baut) sein Modell lackiert und z.B. dagegen stellen wie die meisten professionellen Anstreicher mit den Stellen einer Wand umgehen die "sowieso niemand sieht" (also Leute, die ihre Arbeit rein professionell, ohne Liebe an der Sache machen) stellen wir wahrscheinlich einen deutlichen Unterschied fest.

Hatte ich den Freund erwähnt, der zum fünften Mal in drei Jahren die Handwerker wegen des Schimmels an der Decke im Haus hat?

Die Worte Amateur und Dilettant stammen beide von Bezeichnungen für Leute, die Dinge tun, an denen sie sich Erfreuen. Der Profi kennzeichnet sich vom Wortstamm her vor allem dadurch, dass er (oder sie...) die jeweilige Tätigkeit "nur für das Geld" durchführt und auch die klangliche Nähe von Profi und Profit ist keineswegs ein Zufall.

Sind Sie sicher, dass Sie mehr Profis in ihrem Team brauchen?

Mehr zum Thema "Wer seine Arbeit gerne macht, macht sie auch besser" ist auch in dem spannenden (englischen) Beitrag von Daniel Pink zu finden der sich vor allem um intrinsische Motivation dreht.

Dilettant - Herkunft:
Im 18. Jahrhundert aus italienisch dilettante → it = „Kunstliebhaber“ entlehnt, das das Substantiv zu dilettare → it „erfreuen“ ist; dieses geht auf gleichbedeutend lateinisch delectare → la zurück. Strukturell ist es eine Ableitung zum Stamm des Verbs dilettieren mit dem Derivatem (Ableitungsmorphem) -ant.

Quelle: Wiktionary, Dilettant

Amateur - Herkunft:
Lehnwort des 17. Jahrhunderts aus dem französischen amateur → fr mit der Bedeutung „Kunstliebhaber“, [...]; seit dem 19. Jahrhundert in der heutigen Bedeutung, dass jemand etwas nicht berufsmäßig tut. Das französische „amateur“ wiederum geht auf das lateinische Substantiv amator (dt.: der Liebhaber, der Verehrer) zurück. Dieses Wort leitet sich von dem lateinischen Verb amare (dt.: lieben) her.[1]

Quelle: Wiktionary, Amateur

Professionell - Herkunft:
beruflich ♦ aus frz. professionnel „berufs-, gewerbsmäßig“, zu frz. profession „Bekenntnis, Erklärung; Beruf, Stand“, aus lat. professio, Gen. -onis, „öffentliche Erklärung, Bekenntnis; das (offiziell angegebene) Gewerbe, Geschäft“, zu lat. profiteri „sich öffentlich zu einem Fach, Beruf bekennen“,

Quelle: Wissen.de

Vielen Dank an einen sehr geschätzten Amateur in vielem der mich auf diese Betrachtung der Worte aufmerksam machte.

Cross functional Team - Bereichsübergreifend?

Eines der Konzepte, die aus dem TPS (Toyota Production System) ganz deutlich in die agile Welt transportiert wurden, ist das Konzept des "cross functional teams".

Aber was bedeutet "cross functional" hier eigentlich?

Ich glaube nicht, dass das Wort bedeutet, was viele denken

Die gute Praxis des "cross functional teams" wird von den meisten der agilen Prozesse in der einen oder anderen Form empfohlen oder gefordert, aber sind diese Teams wirklich im Sinne des TPS "cross functional"? Laut dict.cc wird "cross functional" mit funktionsübergreifend übersetzt, en.bab.la hingegen schlägt auch noch bereichsübergreifend vor. Das sind andere Konzepte als sie in vielen IT-Teams genannt werden. Alleine die Unterscheidungsseiten der deutschen und englischen Wikipedia bieten 13 bzw. 11 unterschiedliche Interpretationen zum Begriff "Funktion" - welche sind bei den agilen Entwicklungsteams verbreitet?

(Zu) schmales "cross functional"?

Datenbankentwickler, Spezialisten für serverseitige Programmierung und ein paar Profis im Bereich Benutzer-Interaktion. Vielleicht noch ein bisschen Webservice, REST und BPEL Know-how. Und spätestens wenn noch ein paar Betriebsleute eingebunden sind, scheinen alle Funktionen im Team verfügbar zu sein.
Fertig ist das "cross functional" Team?
Sicherlich sind Teams, die in diesem Sinne Funktionsübergreifend sind eine Form von "cross functional", die weitaus besser zu den aktuellen Herausforderungen in der Software passen als die teilweise immer noch vorhandenen separaten Client- und Server-Teams.

Aber reicht das aus?

Ein breiterer Denkansatz zu "cross functional"

Ganz anders das bereichs- und disziplinübergreifende Team, das die Aufgabe bekam das Auto zu entwerfen, das heute der Toyota Prius ist. Hier kamen nicht nur Motor-Spezialisten, Getriebe- und Beleuchtungssspezialisten mit Innenraum-Designern und Spenglern zusammen, hier war das – grade mal 10 Personen umfassende – Team ebenso mit Marketingleuten, Buchhaltern und Einkäufern besetzt, wie mit Technikern.

Quelle: leider fragwürdige, persönlich Unterhaltung, ungefähr 2003

Unabhängig davon, ob es nur eine schöne Geschichte ist, oder eine leider viel zu schlecht für Suchmaschinen optimierte reale Fallstudie - für mich ist der Gedanke absolut schlüssig:

Wir ziehen heutzutage die Grenzen des Teams oft an ungünstigen Stellen - "cross functional" sollte nicht heissen "IT-ler aller Art" sondern "Ein Team mit dem Know-how aus allen beteiligten Bereichen - auch mit IT-lern und Informatikern"

XP mit seinem Kunden im Team (On-Site Customer) geht da schon einen guten Teil des Weges, aber wirklich funktionsübergreifende und bereichsübergreifende Teams können nicht aus einer Funktion - oder einem Bereich alleine aufgebaut werden - sie müssen tatsächlich auch Bereichsübergreifend aufgebaut werden.

Das technisch "cross functional" aufgestellte Team ist meiner Ansicht nach mal wieder Notwendig, aber nicht hinreichend.

Cheers
   Michael

Vom Beamen und von Meetings - Science Fiction "im Enterprise"

Manchmal scheint in Unternehmen der Größenklasse "Enterprise" vergessen werden, dass die Beamer, die man zu den Besprechungsräumen buchen kann, nichts mit dem – ebenfalls "beamen" genannten – Ort-zu-Ort-Versetzen aus dem Raumschiff "Enterprise" in "Star Trek" zu tun haben.

Wie ich zu dieser Einschätzung komme?

Natürlich aus den Kalendern und Termineinladungen.

10:00 - 11:00 Vertriebsmeeting in Haus 1
11:00 - 12:00 Design-Sitzung in Haus III
12:00 - 13:00 Besprechung kanonisches Datenmodell Haus IIV
13:00 - 13:30 Strategie-Abstimmung beim Lunch im Freigelände
13:30 - 14:00 Präsentation beim Vorstand (42. Etage Hochhaus)

Da nach meiner Erinnerung selbst das Beamen bei Star-Trek ein paar Sekunden in Anspruch nahm, ist mir völlig unklar, wie irgendjemand die Phantasie entwickeln kann, das ein solcher Terminplan funktionieren kann.

Strategie für Meeting-Einladungen

"Krumme" Zeiten für die Einladungen - z.B. 11:05 bis 11:40 - und ein konsequentes Einhalten beider Endpunkte als Einladender.

Warum solch exakte Angaben?

Einerseits ist es leichter von Meeting zu Meeting zu kommen, andererseits ist es unwahrscheinlicher, dass noch jemand ein Meeting direkt auf Stoß davor plant. Und schließlich werden bei solch exakten Uhrzeiten von den meisten Lesern geringere Toleranzen angenommen.

Scrum Master? Coach? Selbstorganisation?

Heute im Chat - Nur leicht anonymisiert und mit Freigabe des Chatpartners:

• "Ein Freund": Ich finde, die Rolle des Scrummasters wird oft unterschätzt.
• ich: ?
• "Ein Freund": So nach dem Motto, den brauche man ja nicht weil selbstorganisiert.
• ich: Jo - beliebte Fehlinterpretation
  Allerdings geht es ja nicht um den Scrum-Master in der Defintion des Scrum-Guide Meiner Ansicht nach gibt es die entsprechende Rolle in jedem methodischen Ansatz zur Softwareentwicklung - mal ist es der XP-Coach, mal der Scrum Master und mal einfach der Coach
• "Ein Freund": Und wenn die Rolle nicht besetzt ist, kommt sowas bei raus wie bei uns.
• ich: Yep - leider ist das so. Und das ist eines der größten Probleme von Scrum
  Vor allem, wenn die Unternehmen ihre Probleme mit "Scrum" lösen wollen
  Deshalb ist XP m.E. auch nicht so erfolgreich - da wird von vornherein zu deutlich gesagt, dass man viel Disziplin braucht und das es wirklich schwer ist etc.

Passt gut zu meiner aktuellen Kritik an Scrum:
Wenn man Scrum auf die so plakativ z.B. in Scrum in one Minute beschriebenen 3 x 3 Elemente reduziert fehlt auf einmal sehr viel.
Scrum kann aus meiner Erfahrung sehr gut ein Element auf dem Weg zu funktionierenden Projekten sein, aber in dieser über-minimalistischen Form, ohne Praktiken und ohne Details, meiner Ansicht nach keinesfalls das einzige Element.

Meine 2 cent:

Auch wenn ich sehr wenig von "der Deutschen liebstem Sport *" verstehe, so bin ich mir doch sehr sicher, dass es nicht reicht, das veraltete WM-System durch die Viererkette zu ersetzen - die Spieler brauchen sicherlich auch noch andere Fähigkeiten und Fertigkeiten um siegreich zu sein und viele davon dürften direkt mit dem Medium mit dem sie umgehen – dem Ball – und dessen Nutzung innerhalb des neuen Konzeptes zu tun haben.
Und vor allem sind mehr als die elf Personen auf dem Platz beteiligt - sonst müsste ja nicht immer der Trainer gehen, wenn die Mannschaft verliert.

Ähnliches bei der Softwareentwicklung im Hinterkopf zu haben ist sicherlich keine schlechte Idee.

[Gleiches gilt natürlich für Software-Kanban, obwohl es sich dabei ja ohnehin nicht um einen Prozess handelt, sondern um eine Methode zur Prozessverbesserung... wie auch schon David Anderson sehr deutlich machte auch wenn man diesen Beitrag heute nur noch in den Yahoo!-Groups archiven und nicht mehr auf Davids eigener Website findet.]

---

*(gemeint ist hier übrigens Fußball. Wenngleich der vor allem angeguckt wird, während der tatsächlich aktiv ausgeübte Sport Nummer Eins laut der Augsburger Allgemeinen das Radfahren ist.)

Technische Unfähigkeit bei Konzernen, Folge n+1 (Flinkster und Deutsch Bahn)

Disclaimer: Ich weiss, dass es kindisch ist, diesen Eintrag zu schreiben, aber da ich schon gerade dabei war, mich aufzuregen...

Schon mal versucht einen Flinkster Vertrag online abzuschließen?
Wenn ja, dann hoffentlich mit einem Windows-Rechner mit der richtigen Version von Microsoft™ Word.

Hier die Mail, die ich (ohne viel Hoffnung auf sinnvolle Reaktionen) gerade an Flinkster geschickt habe:

====8<----- snip ----

Sehr geehrter Damen und Herren,

der zur Vervollständigung des Anmeldeprozesses auszudruckende
Vertrag liegt leider in einem Format vor, welches von meinen
Systemen nicht verarbeitet werden kann.
(Es scheint sich hier um ein Mircrosoft-Word Derivat des
Formates RTF zu handeln)

Bitte lassen sie mir den Vertrag in einer nicht
herstellerspezifischen Form zukommen.

Beispiele für solche übergreifend nutzbaren Formate sind:
* Rich Text Format (rtf) [Standardkonform]
* Portable Document Format (pdf)
* Postscript (ps)
* Hypertext Markup Language (html)
* Tagged Image File Format (TIFF)
* Portable Network Grafics (png)

In der Anlage erhalten sie in Form einer png Datei ein
Beispiel dafür, wie der Vertrag aussieht, der durch das
für die Flinkster Website derzeit eingesetzte System
erstellt wird, wenn er /ohne/ Microsoft Word
ausgedruckt wird.

Mit freundlichen Grüßen
Michael Mahlberg
--
TCG The Consulting Guild AG * Friesenwall 126 * 50672 Köln
Mobil: +49 160 97856224 * Büro: +49 221 677742111 * Fax: +49 221 677742119
HRB (Köln): 63476, Vorstand: Michael Mahlberg (V)
Vorsitzender des Aufsichtsrates: Daniel Speicher


(Nein, die schwärzungen stammen nicht von mir, sondern sind das ergebnis des heruntergeladenen Vertrags)
====8<----- snip ----

Mittlerweile habe ich mich auf ein paar anderen Rechnern ausgetobt: Mit Microsoft Word auf dem Mac sieht es halbwegs vernünftig aus - Zeichensatzprobleme nicht mitgerechnet.

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.