Wenn man lange genug im agilen Kosmos unterwegs ist, – gerade während Lock-Down-Maßnahmen während einer Pandemie – dann taucht irgendwann die Frage auf, welches Tool man denn für diesen ganzen agilen Kram am besten einsetzen sollte. Heute ist es Zeit, dass ich mich einmal dem widme, was ich Tool-Driven Development nenne. Denn: A fool with a tool is still a fool.

Das Problem mit so gut wie allen Tools

Das Problem mit so gut wie jedem Tool: Der jeweilige Tool-Hersteller hat das Tool so umgesetzt, wie er agil verstanden hat und lässt agile Vorgehensweisen nur in dem Maße zu, wie sein Verständnis reicht.

Fertig. Bis kommende Woche.

Ok, vielleicht nicht ganz. Ich schmücke das mal noch ein wenig weiter aus.

Ich ziehe immer mal wieder gerne über Jira her in Schulungen. Die Probleme mit Jira beginnen bei so technischen Kleinigkeiten wie wann der Sprint startet. In Jira ist es so, dass man in Scrum im Sprint Planning einen neuen Sprint anlegt, die noch offenen Dinge aus dem letzten Sprint ggf. in den neuen Sprint zieht, neue Dinge hinzufügt und um technische Tasks anreichert. Irgendwann ist das Scrum-Team so weit, dass sie mit dem Planning abgeschlossen haben. Dann drückt man in Jira auf den Knopf „Sprint starten“. Technisch gesehen ist das falsch. Der Sprint startet mit der ersten Sekunde des Sprint Plannings.

Ok, auf den ersten Blick ist das ein wenig an der Nase herbeigezogen, zeigt aber die Natur meines eingehenden Satzes.

Als Coach und Berater bin ich häufig in der Situation, dass ich Einführung von agiler Entwicklung begleite. Aus Erfahrung weiß ich, dass der erste Prozess, mit dem wir mit einem neuen Team starten, nach einigen Iteration nicht mehr der gleiche sein wird, weil wir unterwegs Dinge verbessern werden, die vielfach Prozessanpassungen sind. Wenn wir jetzt von Beginn an mit einem Tool starten, dessen Tool-Hersteller gewisse Prozessanpassungen, die in unserem Kontext besser funktionieren würden, nicht zulässt, dann ist die Situation mehr als ein wenig kaputt. Das Team wird zum Sklaven des Tools, nur weil ein Toolhersteller der Meinung war, dass seine Interpretation von agil die einzige gültige sei. Wir dienen damit dem Tool selbst, statt dass das Tool uns dienen soll.

In dem gleichen Atemzug sage ich dann immer, dass mir die größtmögliche Flexibilität am Anfang immer durch Post-Its an der Wand gegeben ist. Papier lässt sich auf jede beliebige Form schnell und leichtgewichtig anpassen. Ich weiß schon gar nicht mehr, in wie vielen Sprint Plannings ich saß, wo ein Product Backlog Eintrag für den Sprint zu groß war, aber niemand sich so wirklich daran erinnern konnte, wie genau man jetzt diesen Eintrag in zwei kleinere splitten kann. Mit Post-Its und mehreren Stiften auf dem Tisch fangen zwei Personen parallel an zu schreiben und niemand muss lange darauf warten, bis die Person an der Tastatur oder Maus sich durch alles, was ihr zugerufen wird, durchgeklickt hat.

Meistens kommt dann aber eigentlich immer das Argument, dass man ja ein verteiltes Team an mehreren Standorten sei, oder Leute immer mal wieder im Home Office seien, etc. und deswegen Papier an der Wand einfach niemals nichts funktionieren können wird. Aus meiner Perspektive ist das ein ähnlich an den Haaren herbeigezogenes Argument wie mein Sprint-Starten-Beispiel vorher.

Die Product Ownerin in Scrum arbeitet zum Großteil mit dem Product Backlog, um den kommenden Sprint vorzubereiten. Wenn für die Product Ownerin Zettel an der Wand am besten funktionieren, dann sollten die Zettel bei der Product Ownerin an der Wand hängen. Wenn der Rest des Scrum-Teams Einblick in die kommende Arbeit haben soll, dann schicke ich ein Bild von den relevanten Zetteln an meiner Wand herum oder bringe die entsprechenden Zettel zum Refinement mit. Wenn für mich als Product Ownerin ein Tool die beste Unterstützung darstellt, dann mache ich das entsprechend in einem Tool.

Das Sprint Backlog ist tägliches Arbeitsmittel für den Rest des Scrum-Teams im Sprint. Wenn ein Großteil des Scrum-Teams an einem Ort sitzt, dann hängt man das dort auf. Bei zwei gleichstark verteilten Arbeitsorten hänge ich das Sprint Backlog an eine Standort auf und sorge für einen regelmäßigen Austauschen zwischen den Standorten, oder dopple das Sprint Backlog an beiden Standorten und habe zwei Kopien mit einem Synchronisationsverantwortlichen je Standort. Jemand, die im Home-Office arbeitet, informiert dann den Synchronisationsverantwortlichen vor Ort, wenn Arbeiten abgeschlossen wurden oder sich auf dem Sprint Backlog etwas bewegen soll oder wenn ich im Home-Office eine neue Tätigkeit beginnen will und nicht weiß, was jetzt noch offen ist. Ggf. kann man auch einfach ein Bild vom Sprint Backlog auf täglicher Basis herumschicken und so alle synchron halten.

Und ja, wenn für ein Team ein Tool dafür am besten funktioniert, dann nehme ich auch das. Es sollte aber nicht Gott-gegeben sein, dass man bei verteiltem Arbeiten ausschließlich erfolgreich sein kann, wenn man ein Tool einsetzt – gerade, wenn das Tool Verbesserungspotential unterbindet, das ansonsten mehr als sinnvoll für das Team wäre. Das Team ist verantwortlich für den Prozess, nicht das Tool und schon gar nicht der Toolhersteller.