Kolumne

DevOps Stories: Lasst die Spiele… nie enden

Konstantin Diener

Projekte sind endlich, Produkte für die Ewigkeit. Viele Entwickler sind mittlerweile der Meinung, dass IT-Projekte eigentlich Produkte sein müssten, denn abgeschlossen ist das Projekt mit der Fertigstellung eben nicht. Wo genau es sinnvoller ist, Projekte durchzuführen und wann man von der Definition „Produkt“ Gebrauch machen sollte, erklärt Konstantin Diener in diesem Teil der DevOps Stories.

Erik ist der Product Owner für das Produkt MusicStore, an dem Lukas und sein Team arbeiten. Er hat zu einem Backlog-Refinement-Workshop eingeladen, um die kommenden Monate mit dem Team zu planen.

Erik: „Hallo ihr Lieben. Ich habe euch zusammengerufen, weil ein neues Projekt ansteht.“
Christian: „Puh, schon wieder? Wir sind doch gerade erst mit dem letzten fertig!“
Erik: „Es ist doch gut, dass das MusicStore so eine Traktion hat!“

Erik hat eine Reihe von User Stories auf Karten notiert und breitet sie auf dem Besprechungstisch aus.

Christian: „Die hier wird mindestens einen Monat dauern … die hier auch … und die kann ich überhaupt nicht schätzen! Und zur Music Timeline ist gar nichts dabei …“
Ruben (Scrum Master): „Warum bist du so negativ, Christian?“
Christian: „Ich bin nicht negativ, sondern realistisch. Das ist ein riesen Haufen Holz, den Erik da wieder mitgebracht hat. Was sagt ihr denn dazu?“
Lukas: „Ich glaube auch, dass diese Stories sehr knifflig werden. Wir haben besonders an diesen Stellen mittlerweile zu viele technische Schulden …“
Ruben: „Technische Schulden?“
Christian: „Wir rennen immer nur von einer Deadline im Projekt zur nächsten … und wenn wir Erik sagen, dass wir da im Code mal aufräumen müssen, heißt es immer ‚nach der Deadline ist auch noch Zeit’ …“
Julia: „… aber dann kommt ja schon wieder das nächste Projekt inklusive einer harten Deadline. Aber wenigstens werden wir nicht mehr nach jedem Projekt zu neuen Teams zusammengewürfelt.“
Martin: „Ja, das war wirklich noch viel schlimmer!“
Ruben: „Christian, du hast vorhin was von der Music Timeline gemurmelt. Was meintest du damit?“
Christian: „Naja, wir haben im letzten Projekt die Timeline umgekrempelt und müssten jetzt eigentlich weiter dran arbeiten …“
Erik: „Ja, aber das neue Projekt soll sich mit den Store-Funktionen beschäftigen! Die müssen wir verbessern.“
Christian: „Das heißt, wir machen erstmal nichts an der Music Timeline?“
Erik: „Genau!“
Christian: „Das ist doch Murks. Die Timeline ist das Herzstück des Produkts …“
Ruben: „Erik, warum bist du der Meinung, dass wir am Store arbeiten müssen?“
Erik: „Weil ich gerne den Umsatz pro Kunde mit MusicStore steigern möchte.“
Christian: „Aber doch nicht mit dem Store!“

Abb. 1: Arbeitsteilung zwischen Manager und Team

Abb. 1: Arbeitsteilung zwischen Manager und Team

Die meisten IT-Projekte müssten eigentlich Produkte sein

Lukas und seine Kollegen tun sich schwer damit, dass ihre Arbeit in Projekten organisiert ist. Um ihr Problem zu verstehen, sehen wir uns zunächst erst einmal an, wie ein Projekt definiert ist. Laut DIN 69901 ist ein Projekt ein „Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z. B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Organisation.“

Projekte sind also einmalige Vorhaben. Sie sollen in einem klar umrissenen Zeitrahmen ein vorher definiertes Ziel erreichen. Genau wie das Projekt selbst unterliegen die Organisationsstrukturen und die Teamzusammensetzung einem Verfallsdatum.

Jens Coldewey bezeichnet Projekte in Anlehnung an James P. Carse deshalb als endliche Spiele, wohingegen Produkte unendliche Spiele sind[1]. Innerhalb eines solchen Spiels wird alles auf das Ziel ausgerichtet und ähnelt beispielsweise einem Fußballspiel. Das Spiel endet spätestens mit dem Abpfiff, die Spieler konzentrieren ihre ganze Energie darauf, dass sie am Ende als Gewinner vom Platz gehen – auch wenn sie sich dabei so verausgaben, dass sie am Ende vor lauter Krämpfen kaum noch laufen können. Sie wissen, dass sie nach dem Spiel regenerieren können.

Wenn wir bei diesem Beispiel bleiben, dann ist die kontinuierliche Weiterentwicklung der Mannschaft das unendliche Spiel. Die Ziele entwickeln sich weiter und sind meist vielschichtig. Wenn beispielsweise der Kader zu schwach besetzt ist, werden sich bald die Verletzungen häufen. Zusätzlich müssen Sponsoren angeworben, der Transfermarkt beobachtet werden und vieles mehr. In einem unendlichen Spiel geht es darum, im Spiel zu bleiben und zu diesem Zweck die Regeln und die Mitspieler flexibel anzupassen. Die Unterschiede sind in Tabelle 1 zusammengefasst.

endliches Spiel unendliches Spiel
zeitlich begrenzt zeitlich unbegrenzt
Mitspieler bleiben gleich Mitspieler wechseln
Ziel: gewinnen Ziel: im Spiel bleiben
Regeln bleiben gleich Regeln ändern sich

In vielen Organisationen wird Produktentwicklung als Folge von Projekten betrieben. Dies führt zu einigen Problemen, wie sie auch Lukas und seine Kollegen beobachten.

Die Teams werden nach jedem Projekt neu zusammengestellt

Das größte Problem von Projektorganisationen scheint Christians Firma bereits beseitigt zu haben. Da Projektteams auf Zeit angelegt sind, wurden sie früher nach jedem Projekt wieder aufgelöst und die Mitarbeiter zu neuen Teams zusammengestellt. Allerdings können Teams nicht unbedingt auf Knopfdruck zusammenarbeiten. Sie durchlaufen verschiedene Phasen, die Mitglieder stellen sich erst mit der Zeit aufeinander ein und regeln ihre Zusammenarbeit beispielsweise in Form von Teamverträgen[2]. Laut Larman und Vodde erreicht ein Team einen ersten Höhepunkt hinsichtlich der Produktivität erst nach etwa vier Jahren! Die beiden argumentieren, dass deshalb die Teams möglichst langlebig sein sollten[3].

Technische Schulden durch Rennen von einer Deadline zur nächsten

Das augenscheinlichste der noch bestehenden Probleme ist, dass dem Projektziel alles untergeordnet wird (wie bei den Fußballspielern, die sich völlig verausgaben). Die technischen Schulden wachsen, weil ein Abbau nicht dem aktuellen Projektziel dient. Anders als die Fußballspieler haben Lukas und seine Kollegen aber keine Chance zur Regeneration. Das Refactoring wird immer auf einen Zeitpunkt nach dem nächsten Projekt verschoben. Technische Schulden im Code sind in diesem Zusammenhang nur eines von mehreren Beispielen. Um die Deadline zu erreichen, werden in Softwareprojekten nicht selten auch funktional Trampelpfade verwendet. Das agile-Good-Enough-Mantra wird hier einzig eingesetzt, um die Deadline zu halten.

In DevOps-Teams gibt es keine Linienorganisation mehr

Das liegt daran, dass Projekte von ihrer Definition her ein klares Ende haben müssen, an dem das Ziel erreicht ist. Produkte sind aber nie fertig, sondern müssen sich kontinuierlich verändernde Kundenbedürfnisse befriedigen. Christian thematisiert in der Diskussion die Timeline des Produkts MusicStore. Er ist der Meinung, dass sich in ihr das Alleinstellungsmerkmal widerspiegelt und sie unbedingt kontinuierlich weiterentwickelt werden muss. Im Projektmanagement unterscheidet man zwischen Projekten und der Linienorganisation. Die Projekte führen den Change durch und die Linienorganisation kümmert sich um das Tagesgeschäft. Am Ende des Projekts wird die geänderte Software „in die Linie übergeben“. In einer DevOps-Organisation gibt es keine Linienorganisation mehr. Die Produktteams sind für die Weiterentwicklung genauso verantwortlich wie für das Tagesgeschäft („You build it, you run it.“).

#noprojects fordert, Projekte abzuschaffen

In der Definition eines Projekts am Anfang dieses Artikels heißt es, Projekte seien einmalig. Wenn Produkte durch Projekte geändert werden, erklärt man die Veränderung zur Ausnahme. Durch eine sich stetig verändernde Umwelt etabliert sich Veränderung für alle Organisationen aber immer mehr zur Regel und stellt keine Ausnahme mehr dar. Um auf diese ständige Veränderung adäquat zu reagieren, erweisen sich Projekte als die denkbar schlechteste Option.

Das Ziel eines Projekts ist nämlich in der Regel kein echtes Ziel, sondern eine Hypothese. Erik geht davon aus, dass die Store-Funktionen verändert werden müssen. Das Team soll in den nächsten Wochen User Stories umsetzen, die auf dieser Hypothese basieren. Das eigentliche Ziel liegt darin, mehr Umsatz mit dem Produkt zu erzielen. Erik weiß aber gar nicht, ob eine Anpassung des Stores zu mehr Umsatz führt. Vielleicht wäre es sinnvoller, weiter an der Timeline zu feilen, wie Christian es vorschlägt.

Wenn das eigentliche Ziel eine Erhöhung des Umsatzes ist, gibt es also mindestens zwei Hypothesen, wie sich eine solche Umsatzsteigerung erreichen lässt. Diese Optionen lassen sich sinnvoller durch kleine überschaubare Experimente überprüfen, als durch ein Projekt von mehreren Wochen oder Monaten Dauer. Bei diesen Experimenten steht der Outcome im Vordergrund. Da die Ziele von Projekten meist eigentlich Hypothesen sind, steht hier in der Regel der Output im Vordergrund. Aus diesem Grund fordert die #noprojects-Bewegung, Projekte abzuschaffen.

Sollten wir Projekte also komplett aus unserem Vokabular streichen? Wir sollten uns im Klaren darüber sein, dass wir es in der IT in der Regel mit Produkten zu tun haben. Wenn aber bis zu einem bestimmten Stichtag eine gesetzliche Änderung in verschiedenen Produkten reflektiert sein muss, handelt es sich durchaus um ein Projekt mit festem Zeitrahmen und einem klaren Ziel, das keine Hypothese ist.

Erik hat sich im Workshop mit dem Team geeinigt, dass sie in Zukunft Hypothesen mit kleinen Experimenten statt mit Projekten überprüfen.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: