Raus aus dem Geschwindigkeitsrausch

Wäre dieses agile Velocity Diagramm eines Scrum-Teams würdig?

Velocity

Mein Gefühl ist, dass nicht viele Teams (oder Manager von Teams) damit zufrieden wären. Die Velocity sinkt von Iteration zu Iteration. Das schaut nicht gut aus, oder? Was ist da nur los? Die Fortschrittsgeschwindigkeit sollte von Iteration zu Iteration doch am besten steigen oder zumindest um einen konstanten Wert in engen Grenzen pendeln. Oder?

Die Kurve des Burn-up Diagramms wird immer flacher, der Zuwachs an Story Points pro Iteration immer geringer. Oh, oh. Nicht gut.

Ok, jetzt vorläufige Entwarnung: Diese Diagramme stellen gar keinen Softwareentwicklungsfortschritt dar. Sie zeigen vielmehr meinen Fortschritt auf dem Weg zu einer Stelle an der Küste von Fuerteventura, von der aus ich ein Foto machen wollte.

Sehen Sie die Gischt in der Mitte dieses Bildes?

Diesem Punkt wollte ich möglichst nahe kommen, um mit meinem iPhone ohne Teleobjektiv ein hübsches Bild von dem Spektakel zu machen. Dafür musste ich ungefähr 100m über Lava-Untergrund zurücklegen.

Wie lange würde das dauern? Ich hatte keine Ahnung. Am Ende brauchte ich ca. 10 Minuten. Kommt Ihnen das bekannt vor? Der Scope lag vor mir – mehr oder weniger klar erkennbar. Doch ich konnte selbst hier Phase 1keine Aussage machen, wie viel Aufwand er zur Erledigung wohl brauchen würde. Natürlich habe ich Erfahrung mit der Tätigkeit, natürlich war mir auch klar, dass ich länger als auf einem Bürgersteig brauchen würde. Aber wie lange genau? Die 10 Minuten wären mir eher nicht in den Sinn gekommen.

Da ich keinen Zeitdruck hatte, bin ich einfach mal losgegangen. Anfangs war der Untergrund gut zu gehen, ich habe ca. 15m pro Minute zurückgelegt.

Phase 2Doch dann veränderte sich etwas. Ich musste öfter Umwege gehen, um nicht in Wasseransammlungen zu treten. Außerdem wurde der Untergrund holpriger. Mein Fuß fand nicht mehr so gut Halt. Ich konnte meine anfängliche Geschwindigkeit nicht mehr halten.

Als ich schon dachte, es könnte nicht mehr schlimmer kommen, wurde es dann allerdings auch noch glitschig. Phase 3Eigentlich nicht so verwunderlich, oder? Aber das hatte ich nicht vorhergesehen. Die Wasseransammlungen nahmen zu und ich musste noch vorsichtiger von Fuß zu Fuß wechseln, um nicht auszurutschen. Meine Geschwindigkeit in Bezug auf das Ziel nahm weiter ab.

Zwar gewann ich unterwegs einige Erkenntnisse zu Flora, Fauna und Erosion, doch ich brauchte ganz schön lange, bis ich nahe genug an den Felsen war, um eine Aufnahme nach meinem Geschmack machen zu können.

Nach ca. 10 Minuten war ich am Ziel. Das hätte ich nicht vorhergesehen können. Ebenfalls hätte ich nicht geahnt, dass auf dem Weg meine Geschwindigkeit so unterschiedlich und quasi konsequent abnehmend sein würde.

Und was bedeutet das für die Softwareentwicklung? Nicht weniger, als dass Geschwindigkeit sich nach dem Terrain richten sollte. Geschwindigkeit kann nicht befohlen, verordnet, dekretiert werden. Oder wenn man das tut, dann steigert man offenen Auges das Risiko.

Ich hätte mir ja auch eine Vorgabe machen können: “Du brauchst jetzt nur max. 4 Minuten bis zum Felsen. Los geht’s…” Dann hätte ich im Zweifelsfall auf dem zunehmend unebenen, pfützendurchzogenen und schlüpfrigen Terrain einen Sturz hingelegt oder mir den Fuß verletzt.

Oder nach der ersten Minute hätte ich sagen können: “Das war jetzt super: 15m. Das ist mein Ziel für die nächste Minute.” Und so weiter. Dann wäre ich bald enttäuscht gewesen. Ich ahne, dass ich dann angefangen hätte, mehr auf die Einhaltung einer Geschwindigkeit geachtet hätte, als auf den Untergrund. Ein risikosteigerndes Verhalten.

Der Fortschritt der Softwareentwicklung ist heute zu oft eine Funktion der Lautstärke des Kunden. Stattdessen sollten wir ihn zu einer Funktion des Schwierigkeitsgrades von Anforderungen machen.

Dass der Schwierigkeitsgrad immer gleich ist, dass er womöglich monoton abnimmt, ist nicht zu erwarten. Überraschungen, Fallen, unbekannte Unbekannte lauern überall. Selbst mit einem big design up-front (BDUF) ließe sich das nicht ändern.

Also mutig den Unwägbarkeiten ins Auge sehen. Velocity ist kein zielführendes Mittel, wenn es um die saubere Erfüllung aller Anforderungen geht, also nicht nur der in Hinsicht auf Funktionalität und Effizienz, sondern auch von Korrektheit und Wandelbarkeit.

Kurzfristig mag man sich schneller bewegen können, als das Terrain eigentlich erfordert. Wenn es dann aber zum Sturz kommt, entstehen plötzlich Mehrkosten. Nachbesserungen jeder Art, weil man versucht hat, Abkürzungen zu nehmen, schränken die Produktivität am Ende stark ein.

Geschwindigkeit für die nächste Iteration vorherzusagen, ist kontraproduktiv. Bewegen Sie sich so schnell wie möglich, aber gleichzeitig so langsam wie nötig. Mehr geht einfach nicht verantwortungsvoll.

Das Velocity-Diagramm vom Anfang ist also absolut eines agilen Teams würdig.

Posted in Deutsche Beiträge and tagged .

2 Comments

  1. Hallo Ralph,

    ich finde deine Vorgehensweise im Analogon des Weges an die Kante wunderbar und habe noch eine Anregung: Wie wäre es, auch auf dem Rückweg vom Fotostandort zum “sicheren Untergrund” den Fortschritt zu messen? Sind Hin- und Rückweg vergleichbar?

    Das animiert mich, eine frühere Kollegin zitieren: “Software-Entwicklung ist ein hochgradig nichtlinearer Prozess!” Alle diese Geschichten um Story-Points, Projekt-Pläne, Vorgehensmodelle versuchen doch diese Nichtlinearität plattzuhauen und doch wieder linear zu machen. Ich habe mich davon innerlich lösen können und bleibe bei dem, was ich z.B. bei Robert C. Martin gelernt habe: “Manager kämpfen um Budges und Zeitpläne. Das ist ihr Job. Wir Software-Entwickler haben um die Qualität von Software zu kämpfen, machen wir verdammt nochmal unseren Job!”

    Zu deinem Velocity-Diagramm: ‘würdig’ und ‘unwürdig’ sind in dem Zusammenhang Wertungen, die mich im Sinne von Gewaltfreier Kommunikation ohnehin kaum berühren. Was man aber über das Diagramm sagen kann, sind drei mögliche Effekte:
    – die Story-Points könnten nicht vergleichbar sein (dann wäre die fast lineare Abnahme ab der 4. Iteration schon komisch)
    – Druck in den ersten Iterationen führte dazu, nicht abgeschlossene Paket abzuhaken. In den Folgeiterationen waren dann Nacharbeiten erforderlich. Diese Nacharbeiten könnten – da es jemandem (wem auch immer) zu peinlich war – nicht mit neuen Arbeitspaketen und entsprechenden Story-Punkten unterlegt sein.
    – die Qualität der Systems (im Sinne von Dekomponierbarkeit) könnte so unangenehm sein, dass sich der Aufwand jedweder weiterer Pakete ganz anders verhält als zu Beginn der Implementierung

    –> Agilität braucht eine Menge von Eigenschaften, die ich immer wieder vermisse:
    (1) Qualitätsbewußtsein des Teams
    (2) Fähigkeit des Teams die Lösung sinnvoll zu strukturieren
    (3) Fähigkeit des Teams in Diskussionen nicht nur zu argumentieren, sondern auch zuzuhören
    (4) Fokussierung auf das Projektziel von wenigstens einem Drittel des Teams (ein weiteres Drittel kann sich mitziehen lassen, das letzte Drittel muss sich entscheiden, mit auf die agile Reise zu gehen oder das Team zu verlassen)
    (5) das unmittelbare Management muss loslassen können: es darf nicht hineinregieren und muss das Team effektiv abschirmen oder den Schirm respektieren

    In dem Moment, in dem jemand von Außen deine Eingangsfrage in Form eines Vorwurfs stellt, wird die Transparenz, die agiles Arbeiten mit sich bringt, ganz eindeutig missbraucht. Agilität bedeutet gerade nicht von Außen ständig eng führend einzugreifen.

    Wenn eine ähnlich Frage im Team (z.B. im Retrospektiv-Meeting) auftaucht, fänd’ ich das sehr in Ordnung. Vielleicht braucht das Team etwas an der Art der Schätzung ändern? Dem Team müsste auffallen, dass die 4 Story-Punkte der 10 Iteration den 15 Story-Punkten der ersten Iteration entsprechen. Dann müssen die Pakete neu geschätzt werden. Lassen sich 4 Story-Punkte in einer Iteration überhaupt in genügend Pakete zerlegen, die man effektiv Scrum-mäßig planen und über die Iteration nachvollziehen? Oder hat sich das Team in eine Architektur verrannt, die die Arbeit über die Zeit extrem schwierig macht? Was kann das Team besser machen? Oder haben sich im Team Wissensinseln gebildet – bzw. vorhandene Wissensinseln lassen sich (aus Angst vor dem unbekanntem Chaos, das die Kollegen im Code hinterlassen haben) nicht bekämpfen? Werden Software-Metriken (z.B. findbugs, sonar, pmd), automatisierte Tests (junit, nunit, cunit und wie sie alle heißen) und automatisierte Formatierung als nervend (die Freiheit einschränkend) oder als Hilfsmittel angesehen?

    Ich war vor einiger Zeit in einem Team, da ging es in einem der Retrospekiv-Meetings genau um diese letztgenannten Punkte. Gefühlte zwei Drittel des Teams hatten Angst vor der Clean-Code-Fraktion. Sie argumentierten, sie würden Freiheiten verlieren. Das klang dann so: “Müssen etwa alle auf dieselbe Art ihren Code schreiben? Muss denn bei allen derselbe Code herauskommen?” Endlich war es heraus! Es ging um Angst vor Gleichmacherei, es ging um die Angst, die eigene Kreativität einschränken zu müssen. Die Clean-Code-Fraktion ist vor Lachen fast vom Stuhl gefallen: “Nein, es geht darum, das jede(r) jeden anderen Code versteht – ohne stundenlanges Rätseln und/ oder an die Hand nehmen!”

    Die Erleichterung war unglaublich. Ein paar Tage später konnten alle darüber lachen – und es ging ein Ruck durchs Team.

    Fazit: wird diese Frage von oben einem Team aufgedrückt, könnte es sich um agile-but handeln, aber das ist nicht die ganze Wahrheit. Möglicherweise sind auch nicht genügend fokussierte und/ oder erfahrene Leute im Team (einschließlich Moderator). Vielleicht ist auch das Projekt-Ziel zu diffus – in dem Fall kann Agile auch zur strukturlosen Beliebigkeit werden.

    Ich bin überaus dankbar, kennen gelernt zu haben, wie Scrum funktioniert, wie Scrum-but nicht funktioniert und das Fehlen von Zielen alle Leute ‘rumeiern läßt.

    Gruß Henrik

  2. Ein schöner Hinweis, Henrik, auf die Nichtlinearität. Die verdient eigentlich mal einen eigenen Blogbeitrag 🙂 Genau so siehst nämlich aus: mit jeder Veränderung in den Anforderungen ist unklar, welchen Effekt das auf die Softwareentwicklung hat. Ein kleiner Schritt für den Kunden kann ein großer für die Programmierung sein. Zur Lektüre kann ich da “A New Kind of Science” empfehlen: http://www.amazon.de/gp/product/1579550088.

    Dass die Angst vor Gleichmacherei Entwickler reserviert sein lässt gegenüber Clean Code, mag sein, halte ich aber nicht für einen großen Faktor. Mir scheint sich eher darin eine Angst zu verkleiden: die Angst vor Leistungsabfall. Der Gedankengang ist “Wenn ich so sein muss wie andere, kann ich nicht mehr so sein, wie ich bin und will. Wenn ich nicht mehr so sein kann, wie ich bin und will, kann ich nicht mehr so arbeiten, wie ich es am besten kann. Wenn ich nicht mehr meine beste Arbeit abliefern kann, kann ich nicht mehr den Ansprüchen von Vorgesetzten entsprechen. Wenn ich den Ansprüchen nicht mehr entspreche, bekomme ich Druck. Ich will keinen Druck. Also will ich auch nicht, was mittelbar zu Druck führt.”

    Das Freiheitsmotiv bei Softwareentwicklern halte ich für überbewertet. Ja, es mag “Freigeister” geben. Doch für viel weiter verbreitet halte ich das Kontroll- bzw Feedbackmotiv. In der Programmierung geht es um Kontrolle und um unmittelbares Feedback für die eigene Leistung.

    Eine neue Technologie ist deshalb tendenziell immer attraktiv, weil sie wieder mehr Möglichkeit zur Ausübung von Kontrolle bietet, über die ich zu positivem Feedback komme, weil ich sie beherrsche. Nach dem nächsten Compilerlauf, nach dem nächsten Testrun, nach dem nächsten Programmstart weiß ich, ob ich erfolgreich war.

    Aber ein neues Vorgehensmodell oder Clean Code bietet mir nichts in der Hinsicht. Oder schlimmer: Ich bekomme negatives Feedback und fühle mich viel weniger in Kontrolle, um das zu ändern. Das ist hochgradig unattraktiv für Entwickler, hat aber nichts mit Einschränkung der Kreativität zu tun.

    Letztlich sehe ich den wahren Widerstand gegen konsequentes Clean Coding jedoch nicht bei Entwicklern. Auch in der von dir beschriebenen Situation ist es nur vorrübergehend. Der wahre Widerstand sitzt in den Policies und Glaubenssätzen und Gewohnheiten der Organisation drumherum und im Markt, der mit Software bedient werden soll.

    Außerhalb der Softwareentwicklung will man lineare Herstellung, aber die Softwareentwicklung ist eben nicht linear. Das kann nur zu Reibung führen.

Comments are closed.