Teamübergreifende Konfiguration digitaler Kanban-Boards

Wer sein Board nicht nur in physischer sondern auch in digitaler Form haben will kann mittlerweile zwischen einer ganzen Reihe von Programmen wählen: Jira, Agile Manager, Redmine, Rally, ScrumDo, Trello und viele weitere können benutzt werden und sie alle funktionieren mehr oder weniger gut. Problematisch wird es aber, wenn mehr als ein Team ein gemeinsames Tool benutzt und die verschiedenen Teams unterschiedliche Konfigurationen vornehmen. Findet das ohne gegenseitige Absprachen statt kann man fest davon ausgehen, dass eines der folgenden Probleme auftreten wird:

1. Edit Wars

Der Name sagt eigentlich bereits alles. Ein Team ändert die Konfiguration und verändert damit auch alle anderen Boards. Jemand aus den anderen Teams merkt das und macht es rückgängig, jemand aus dem ersten Team wiederholt die Änderungen, etc., etc., etc. Ein solcher Edit War muss auch nicht notwendigerweise auf irrationaler Sturheit der Beteiligten beruhen - gerade in größeren Firmen, in denen 20, 50 oder noch mehr Teams ein gemeinsames Tool benutzen, kann es sein, dass gar nicht festzustellen ist wer die letzten Änderungen vorgenommen hat. Dem Verursacher sind die Folgen seines Tuns vielleicht gar nicht bewusst, und dass die veränderten Einstellungen ständig zurückgesetzt werden wird eher einem Bug zugeschrieben als einem Kollegen. Ich durfte einmal miterleben, dass die Standardkonfiguration in einer Firma über Wochen immer wieder von Story Points zu Personentagen und von Personentagen zu Story Points geändert wurden. Erst als die gesamte Belegschaft zusammengerufen wurde und alle sich melden mussten die in letzter Zeit Änderungen vorgenommen hatten hörte das Hin und Her auf.

2. Kaputtkonfigurierte Tools

Auch das habe ich bereits mitmachen müssen. Jedes von mehreren Teams hatte spezielle Workflows, die es auf seinem Board sehen wollte. Für die einen waren es Spalten für Rewiew und Release, für die anderen Akzeptanztest und Resolved, wieder andere wollten anzeigen können auf welchen Umgebungen sich die entwickelten Features befanden. Die salomonische Lösung der Admins war, dass alle Wünsche gleichzeitig umgesetzt wurden, so dass die Boards am Ende 17 (!) verschiedene Spalten hatten. Den Entwicklern wurde mitgegeben, dass sie doch einfach nur die benutzen sollten, auf die sich ihre Teams geeinigt hatten, die anderen sollten sie ignorieren. Als wäre das nicht bereits kompliziert genug enthielt die Konfiguration auch noch mehrere Workflows, die beim Verschieben der Tickets einzuhalten waren - zum Beispiel To Do-In Progress-Review-Done, To Do-Design-In Progress-Test-Resolved oder To Do-In Progress-Done-Release. Wenn jetzt ein Ticket versehentlich von In Progress auf Test geschoben wurde statt auf Review konnte der Finale Status nicht mehr Done sein sondern nur noch Resolved. Da die Reports aber nur nach einem dieser Status filtern konnten wurden sie dadurch immer wieder verfälscht.

3. Jenga-Konfigurationen

Im Grunde ein Sonderfall von kaputtkonfigurierten Tools. Vom ersten Eindruck her ist alles in Ordnung, jedes Team hat ein nach seinen Bedürfnissen konfiguriertes Board, alle Workflows funktionieren. Das verborgene Problem tritt auf sobald an irgendeiner Stelle eine zusätzliche Anpassung gemacht wird: wie bei einem Jenga-Turm führt nämlich jede einzelne Veränderung sofort zum Zusammenbruch des Gesamtkonstrukts. Verschiedene Boards benutzen in wilder Kombination verschiedene Workflows, Status, Verknüpfungen und Beschränkungen, und da das alles "historisch gewachsen" ist kann keiner mehr genau sagen welche Einstellung mit welcher anderen zusammenhängt. Irgendeinen Zusammenhang gibt es aber fast immer, im schlimmsten Fall sogar mit ganzen Kaskaden von Abhängigkeiten, so dass eine kleine Änderung ausreichen kann um das Gesamtsystem unbrauchbar zu machen.

Legacy-Systeme

Wenn diese Proble auftreten - wie geht man mit ihnen um? Im Fall von Edit Wars ist es relativ einfach: in den meisten Fällen hilft es wenn die Kommunikation verbessert wird (siehe oben), im schlimmsten Fall muss durch einen Mehrheitsendscheid oder ein Geschäftsführer-Machtwort eine Entscheidung herbeigeführt werden. Anders ist es im Fall von kaputtkonfigurierten Tools oder Jenga-Konfigurationen. In diesen Fällen führt langfristig kein Weg daran vorbei das System wieder zu vereinfachen und zu vereinheitlichen, was häufig in kleinteilige und langwierige Arbeit ausarten kann. Die dafür nötigen Aufwände fehlen dann natürlich bei der Produktentwicklung. Um dem Management begreiflich zu machen, dass sich dieses Investment lohnt empfiehlt sich der Vergleich mit Legacy-Code. Auch der muss schließlich zeitaufwändig refactored werden um wartbar und bearbeitbar zu bleiben. So verargumentiert kann nebenbei sogar noch etwas Vorteilhaftes herausspringen: selbst technikfremde Manager können an diesem Beispiel sehr schön erkennen, welche Auswirkungen technische Schulden haben können.