Unpopuläre Thesen 2013-09-25: Scrum und Kanban sorgen nicht für gute Softwareentwicklung

Scrum an sich macht niemanden zu einem besseren Software-Entwickler!
Und (Software-)Kanban macht als solches ebenfalls niemanden zu einem besseren Software-Entwickler (und ist – nebenbei bemerkt – auch kein Ersatz für Scrum! )

Und – nur um es noch mal deutlich zu machen – Scrum ist kein Synonym für "Agil" oder "Agile". Unter den Agilen Methoden sorgt zum Beispiel eXtreme Programming (XP) meiner Ansicht nach sehr wohl für gute Softwareentwicklung, solange man es ausreichend ernst nimmt.
Aber zurück zu Scrum. Das Schöne an Scrum ist ja gerade, dass es so universell einsetzbar ist! Um die deutsche Übersetzung des Scrum-Guide zu zitieren: „Scrum ist ein Framework, das die Entwicklung komplexer Produkte unterstützt.“ In diesem Satz steht nichts von Software – und wenn man den Scrum-Guide nach „Programm“ oder „Software“ durchsucht, wird man ebenfalls nicht fündig – egal, ob in der englischen Ausgabe vom Juli 2013 oder in der deutschen Übersetzung zum Stand 2011.

Eines der bekannteren Beispiele für die Anwendung von Scrum ausserhalb der Software-Entwicklung ist die Wartung von Formel-1 Wagen mit Scrum^[1] – ich bin sicher, dass gerade hier von allen Team-Mitgliedern erwartet wird, dass sie ihr Handwerkszeug perfekt beherrschen.

Die Dinge, die dabei helfen, bessere Software-Entwickler zu werden, sind andere: Wissen über Entwurfsmuster (siehe auch: Wikipedia), Kenntnis von Architektur und Entwurfsprinzipien (z. B. SOLID (siehe auch: Wikipedia) und Co.), Einsatz von testgetriebenem Design, Programmieren in Paaren, kontinuierliche Integration und letztendlich – auch wenn aus einem gewissen Blickwinkel die konkrete Programmiersprache nicht so entscheidend sein mag – die Beherrschung der für die Umsetzung notwendigen Sprachen, Bibliotheken und Frameworks.
Wenn diese Elemente erfüllt sind, dann helfen Prozesse wie Scrum und Prozessverbesserungsmethoden wie die Kanban Methode (oder als englische Kurzübersicht) dabei, wirklich das zu entwickeln, was einen Wert für den Kunden darstellt, und sich nicht in Technikalitäten zu verlaufen, in der Analyse stecken zu bleiben oder in eine der vielen anderen Fallen des Projektmanagements zu laufen.
Analog zum alten Rezept für einen guten Grog („Rum muss, Zucker kann, Wasser braucht nicht“) an dieser Stelle daher mein Plädoyer:

• Technische Expertise: Notwendig, aber nicht hinreichend
• Kanban Methode: Sollte, aber nicht als einziges
• Scrum: Kann, aber nicht als einziges

Bis demnächst
  Michael Mahlberg

---

[1] Die „Scrum in der Formel-1“ Geschichte hält sich seit Jahren, ich habe aber leider keine Primärquellen finden können

Es gibt keine Server für kontinuierliche Integration (oder auch "CI-Server" ist ein Oxymoron)

Sätze wie

• „Der gesamte Vorgang wird automatisch ausgelöst durch Einchecken in die Versionsverwaltung.“[1]
• „<x> is an open-source continuous integration server with...“ [2]
• „[…] Kontinuierliche Integration steigert die Effizienz durch Automatisierung […]“[3]

zeigen mir immer wieder die immense Macht der semantischen Diffusion.

Es gibt keine CI-Server – selbst Szenarien, in denen der Server am Ende eines fehlerhaften Buildlaufes das gelieferte Changeset zurückweist, stellen nicht sicher, dass die Teilergebnisse wirklich integriert werden.

Was oft als CI-Server beschrieben wird, sind Build-Server, integriert wird hier nichts. Buildserver gibt es durchaus auch in meinem Vokabular, kontinuierliche Integration aber, so wie ich sie das erste Mal 2001 bei Kent Beck beschrieben gesehen habe, ist eine Arbeitsweise, bei der alle Beteiligten sicherstellen, dass ihre letzten fertiggestellten Arbeitsergebnisse in das Gesamtprodukt integriert sind. Dorthin zu kommen, gibt es viele Wege, aber keiner davon ist durch einen Server zu automatisieren.

Auf abstraktem Niveau ist das Vorgehen immer wieder das Gleiche:

• An den eigenen Arbeitsergebnissen arbeiten
  • Sicherstellen, dass die aktuelle Version des Produktes funktioniert
  • Meine eigenen Arbeitsergebnisse integrieren
  • Sicherstellen, dass die jetzt aktuelle Version des Produktes funktioniert
  • wenn sie nicht funktioniert, wieder einen funktionierenden Stand herstellen
    • Wenn dies ebenfalls nicht funktioniert, dann das ganze Team zusammenrufen, um wieder einen funktionierenden Stand herzustellen
  • Die eigenen Arbeitsergebnisse modifizieren, bis berechtigter Grund zu der Annahme besteht, dass eine Integration jetzt erfolgreich sein kann
• Das Ganze so lange wiederholen, bis die eigenen Arbeitsergebnisse komplett in das Gesamtprodukt integriert sind, bevor neue Halbfertigteile produziert werden

In der Praxis gibt es sehr viele valide Ausprägungen dieses Vorgehens, die unter anderem auch die Nutzung von Buildservern umfassen können. Sie alle aber scheinen zunächst einen erheblichen Nachteil zu haben, der meiner Meinung nach Ursache dafür ist, dass so oft keine permanente Integration stattfindet, sondern statt dessen das fehlen der Integrationsarbeit hinter dem Feigenblatt des „Integrations-Servers“ versteckt wird.
Dieser Nachteil ist, dass in dieser Welt nicht mehrere „Änderungen“ zur gleichen Zeit integriert werden können. Und da die Integration nach diesem Modell ja erst abgeschlossen ist, wenn das System nachweislich funktioniert, steht und fällt die Umsetzbarkeit dieses Vorgehens mit der Zeit, die benötigt wird, um das Funktionieren des Gesamtsystems nachzuweisen.

An dieser Stelle sind zwei grundsätzlich unterschiedliche Herangehensweisen üblich. Eine Lösung für die Herausforderung kann sein, die Zeit zu minimieren, die benötigt wird, um das Funktionieren des Gesamtsystems nachzuweisen. Das ist der „harte” Weg, der zunächst deutlich schwieriger scheint und es erforderlich macht, sich mit allen Problemen auseinanderzusetzen, sobald sie auftauchen. Eine andere – scheinbare – Lösung, dieser Herausforderung zu begegnen, ist die Entkopplung der Integration von der Weiterführung der Arbeiten. Hier haben dann automatisierte Integrationstests und die sogenannten „CI-Server” ihren großen Auftritt.

Das Vorgehen hier ist also:

• An den eigenen Arbeitsergebnissen arbeiten
• Die eigenen Arbeitsergebnisse zur Verifikation an den Integrationsserver abgeben (möglicherweise von mehreren Teams zur Zeit)
• An neuen eigenen Arbeitsergebnissen arbeiten
  hier haben wir je nach Anzahl der Entwickler mehr oder weniger nicht-integrierten Code
• Falls (später) ein Fehler vom Server gemeldet wird, versuchen diesen zu beseitigen

Das ist natürlich viel einfacher, es gibt keine Schleifen, die man drehen muss, keine Synchronisation mit anderen Integrationswilligen, keine Wartezeiten während der Integration.

Das große Problem bei diesem Vorgehen ist nur, dass nicht verifizierte Teilfertigprodukte entstehen – um so mehr, je häufiger die Entwickler ihre Teilergebnisse an den Server überantworten.

Es gibt zwar schon geraume Zeit Ansätze dieses Thema auch technisch zu adressieren – z. B. mit gerrit und darauf aufsetzenden Workflows – aber hier dienen die Werkzeuge erfreulicherweise der Unterstützung der Menschen, und es wird nicht unterstellt, dass sie die Integration durchführen.

Eigentlich lässt sich ganz leicht feststellen, ob es in einer Umgebung eine permanente Integration gibt oder nicht – immer dann, wenn es fehlerhafte Builds gibt, scheint die Integration weder permanent noch kontinuierlich zu sein.
Schließlich ist in der „roten“ Zeit mindestens der für den Fehler verantwortliche Teil eben gerade nicht integriert. Und wenn die Build-Zeit lang genug ist, dann ist in der Zeit Neues entstanden, was ebenfalls nicht integriert ist. Und während die Fehler behoben werden steigt die Menge nicht integrierter Teilprodukte, wenn die anderen Projektmitglieder weiter arbeiten.
All dies passiert nicht, wenn tatsächlich nach dem oben beschriebenen Muster permanent integriert wird!

Wer also permanente Integration (continuous integration) will, muss sich meiner Ansicht nach auf Prozessebene damit auseinandersetzen und wir alle sollte Build-Server auch Build-Server nennen und den Begriff CI-Server meiden, solange diese keine wirkliche Integration betreiben können.

Bis zum nächsten Mal
  Michael Mahlberg

Quellen aus der Einleitung:

• [1] aus dem deutschen Wikipedia Eintrag
• [2] von der Jenkins Startseite
• [3] aus einem Industrieartikel

Und gerade noch im Netz gefunden: Bereits vor 2006 hat Jim Shore seine Einstellung zu Continuous Integration veröffentlich, und hatte insbesondere seine eigene Meinung zu CruiseControl (einem speziellen Build-Server)

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.)

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.