Niemand will ein Code-Monkey sein, aber viele Entwicklungsteams in der Softwareentwicklung machen sich zu genau dem. Sie nutzen dabei den Mechanismus der Definition of Done, um in den bequemen Zustand zu kommen, nur noch nach Spezifikation programmieren zu müssen. Und da sie es selbst bestimmen können, haben sie dann auch noch das Gefühl, alles richtig zu machen!
Foto: https://www.flickr.com/photos/scragz/132750728
In der Softwareentwicklung existiert ein Horrorszenario für Entwickler: Der Code-Monkey!
Das englische Wikipedia spendiert dazu einen ganzen Satz:
A derogative term for a computer programmer who isn't actually involved in any aspect of conceptual or design work, but simply writes code to specifications given.
Code-Monkey ist also eine abfällige Bezeichnung für Programmierer, die nicht in konzeptionelle oder Design-Aspekte der Arbeit integriert sind, sondern nur nach Spezifikationen Programmcode schreiben.
Obwohl sich die meisten Entwickler absolut davon ausnehmen würden, ein Code-Monkey zu sein, begegnen sie mir doch immer wieder: Die DoR-Code-Monkeys.
DoR – die Definition of Ready
Die Definition of Ready (DoR) bezeichnet in Scrum einen Vertrag zwischen Product Owner und Entwicklungsteam über den Zustand der "Product Backlog Items", wenn diese angefangen werden sollen. Die Definition of Ready ist auch im Kanban-Kontext immer wieder anzutreffen. Hier bezeichnet sie die Kriterien, die an einen Auftrag gestellt werden, wenn er den Commitmentpunkt überschreitet. Same same, but a little bit different.
Viele Menschen stoßen sich schon am Begriff des Vertrags. Aber was anderes, als eine beidseitig verbindliche Abmachung über einen zu erbringenden Sachverhalt, ist es denn? Und spannenderweise wird die DoR durch die Entwicklungsteams auch nicht selten behandelt wie die steinernen Gesetzestafeln vom Berg Sinai.
Die Definition of Ready ist also eine Vereinbarung, die sagt, was alles zu leisten ist, bevor sich ein Entwicklungsteam ernsthaft mit der Bearbeitung eines Dienstleistungsauftrags beschäftigt. Das ist durchaus hilfreich, um die Variabilität bei der Bearbeitung der Aufträge zu senken: Wir standardisieren den Prozess etwas und bekommen dadurch weniger Rückfragen und notwendige Klärungen und können dadurch schneller und vorhersagbarer unsere Dienstleistung erbringen.
Die Retrospektive droht
Auch bei der Verwendung von Scrum besteht immer wieder das Bedürfnis nach langfristiger Vorhersagbarkeit. Scrum kann diese zum Teil dadurch erzeugen, dass die Länge der Iterationen beschränkt ist und in einem Push-Pull-System mit kurzen Horizonten geplant wird.
Leider wird viel geschätzt und die Aufträge klein geschnitten, um sie in die Integration hineinzupressen. Vieles von dem, was ich hier erwähne, entspricht übrigens der Realität in vielen Teams und NICHT der Idee und Guidance des Scrum-Guides.
Trotz allen Mechanismen, die bemüht werden, um planbar zu werden: Die Variabilität der komplexen Produktentwicklung siegt, weil sie sich häufig schlecht in einen festen Plan integrieren will. Und so schafft das Scrum-Team sein vorhergesagtes Volumen nicht und "reisst den Sprint."
Über Push- und Pull-Systeme gibt's in meinem Podcast übrigens noch mehr zu hören!
Woran hat's gelegen??
Wie nach jedem Sprint folgt die Retrospektive und der Wunsch zur Verbesserung. Die Ursachen sind schnell gefunden: Die Anforderungen waren nicht ausreichend gut vorbereitet!
- Zu wenig war bekannt über sie
- Die Designs fehlten
- Die Akzeptanzkriterien waren nicht vollständig
- Oder zum Beispiel: Das Ablaufdiagram über die Interaktion mit dem User war nicht hinreichend genau.
Ich weiß wirklich nicht, wie häufig ich das schon hören musste!
Und so versucht, das Entwicklungsteam mehr und mehr Arbeit auf den Product Owner zu drücken, um noch besser vorbereitete Aufträge zu bekommen. Die Definition of Ready wird eine immer längere Liste und die Pedanterie bei der Kontrolle der Aufträge nimmt immer weiter zu. Dabei beraubt sich das gesamte Scrum-Team der Kreativität des Teams, denn sie könnten ja eigentlich miteinander, mit dem Kunden oder User, kontrovers und kooperativ arbeiten, um tatsächlich ein besseres Ergebnis herauszubekommen. Stattdessen wird versucht, alles auf Papier zu bannen.
Und so wird aus einem Entwicklungsteam eine Gruppe von DoR-Code-Monkeys.
Die, die sie nie sein wollten, wollen sie jetzt gerne sein. Und das alles passiert im Sinne der Vorhersagbarkeit, die aber bei der situativ richtigen Anwendung von Scrum nicht im Sinne der Firma ist.
Dabei fehlen im Grunde nur zwei Fragen: Was ist der Zweck der Dienstleistung und wie erreichen wir ihn am besten?
Kommentar schreiben