Wie wichtig ist eigentlich die richtige Technik?

Wie wichtig sind eigentlich bestimmte technische und methodische Dinge für eine agile Arbeitsweise? Kann man auch ohne Pair Programming oder Automatisierung auskommen oder ist man damit zum Scheitern verdammt? Warum sich ein Blick auf die Methoden lohnt, eine Einführung mit der Brechstange jedoch eher nicht.

Wie wichtig sind eigentlich bestimmte technische und methodische Dinge für eine Arbeit nach Scrum, Kanban oder in manchen Unternehmen vielleicht Scrumban?

Müssen wir unbedingt User Stories schreiben, eine Definition of Done haben oder vielleicht sogar eine Definition of Ready, in Punkten schätzen und unsere Velocity kennen? Müssen wir Pair Programming betreiben, Code-Reviews durchführen, Tests automatisieren und allem eine Continuous Delivery Pipeline geben, was nicht bei drei auf den Bäumen ist?

Die Antwort auf diese Fragen ist nein. Vielleicht auch ja, aber eigentlich ist die Frage einfach völliger Blödsinn.

Im Grunde kann man sie gar nicht beantworten, weil sie ähnlich sinnnvoll wie die Frage ist, ob man zum Essen einen Löffel braucht. Wenn es Pudding gibt vielleicht ja, bei Hähnchen mit Pommes vermutlich eher nicht und wenn ich Pizza esse … wohl auch eher nicht. Die Frage lässt einfach den Kontext vermissen, um den es geht.

Im Gegensatz zum Daily oder beispielsweise der Retrospektive wird übrigens keine der genannten Praktiken im Scrum-Guide erwähnt, und trotzdem tun manche Agilisten und Scrum Master als ginge es nicht ohne sie. Tatsächlich dürfte es einige Teams geben, bei denen genau solche Praktiken auch zum Erfolg beitragen, aber es dürfte doch fraglich sein, ob das mit der bloßen Existenz der Methode zusammenhängt oder doch viel mehr damit, dass sie eben zum jeweiligen Kontext passt also im jeweiligen Fall zur eigentlichen Zielerfüllung beiträgt.

Methoden und Techniken können „enabler“ sein

Denn der Trick mit diesen Methoden und Techniken ist, dass sie „enabler“ sein können, also helfen können, die eigentlichen Ziele besser oder einfacher zu erreichen oder das Erreichen der Ziele sogar erst möglich machen.

Wenn unsere Zielsetzung etwa darin besteht, regelmäßig ein Softwareprodukt zu liefern, dann werden uns aufwändige, manuelle Tests wohl eher im Weg stehen und wir täten gut daran, für automatische Tests und dafür zu sorgen, dass diese auch ausgeführt werden.

Oder wenn wir in unserem Team Wissensinseln vermeiden, abbauen und einen regelmäßigen Wissensaustausch sicherstellen wollen, dann könnte die Einführung von Pair Programming oder gar Mob Programming (das stellenweise etwas ungünstig auch als Mobbing bezeichnet wird) hilfreich sein. Genau wie das gute alte Peer Review, das ja aber in vielen IT-Unternehmen ohnehin schon ein alter Hut ist. Das Spannende daran: die Qualität unserer Ergebnisse kann sich dadurch auch verbessern und trotz erhöhtem Zeitaufwand damit mittel- bis langfristig sogar zu unserer Entlastung beitragen.

Auch der regelmäßige Abbau von technischen Schulden wäre übrigens so ein „enabler“, wenn wir nicht früher oder später in der Ineffektivität unseres Effizienzwahns ertrinken wollen.

Doch es muss eben auch passen: zur Aufgabe, zum Umfeld und zu den Leuten.

Wie Eckart von Hirschhausen sagen würde „Wenn du als Pinguin geboren wurdest, machen auch sieben Jahre Psychotherapie aus dir keine Giraffe“ .

So mag zum Beispiel die Planung mithilfe von Story Points, Velocity und einem Sprint-Ziel ganz nützlich sein für ein Team, das sich ausschließlich mit relativ planbarer Arbeit beschäftigt (wie beispielsweise in der Produktentwicklung). Aber für ein Team, das gleichzeitig mit einem hohen Maß unplanbarer Arbeit wie Support-Tätigkeiten gesegnet ist, mag es wie die Forderung nach der Verwandlung vom Frosch zum Prinzen vorkommen, wenn der Scrum Master ihnen erklärt, dass sie unbedingt ein Sprint-Ziel brauchen und dass sie etwas falsch machen, wenn sie es nicht erreichen.

Überhaupt sollten diese Methoden und Techniken nie als etwas betrachtet werden, mit dem man den gewünschten Agilitätsgrad schon in das Team einpeitschen kann. Das könnte nämlich ziemlich kontraproduktiv sein.

Man kann den Leuten im Team aber die Möglichkeit aufzeigen, die Vorteile erläutern und sie dann entscheiden lassen; auch ihnen vorschlagen, einer Methode versuchsweise eine Chance zu geben.

Und vielleicht passt es ja, vielleicht aber auch nicht.