Visualisierung in Projekten: Braucht Skalierung Tools?

"Big Visible Charts" war einmal das Motto - Scrum-Teams wollten schnell ihre Informationen an jene mitteilen, die daran vorbeigehen. Ein wundervolles Beispiel für diese Variante der Informationsverbreitung findet sich hier. Die Idee war es, physisch und haptisch, schnell und ohne viel Aufwand Teams zu ermöglichen, effektiver zu arbeiten.Dann kamen die Leute, die unbedingt die große, allumfassende Visualisierung über alle Projekte haben wollten. Sie setzen immer noch Entwickeln mit Produktion gleich und wollten per Mouse Click haben, was bis dato kein MS Projekt Ghantt-Chart konnte: Tagesaktuelle, verlässliche und korrekte Zahlen über den Entwicklungsfortschritt liefern. Sprich: Reporting bis zum Exzess.Findige und geniale Entwickler wie zum Beispiel die Jungs von Atlassian bauten coole Tools wie Jira, Greenhopper, und einige andere entwarfen die wirklich abgefahrenen Lösungen wie Trello, VerisonOne, Mingle und wie sie alle heißen, damit sie die geforderten Informationen möglichst schnell und einfach liefern konnten.Und was passiert jetzt: Es gibt Software-Entwickler, die ihr Geld damit verdienen, z.B. JIRA für Kunden zu konfigurieren, die Workflows anzupassen, und aus der simplen Idee von drei Spalten - TODO, INPRG, DONE - wochenlange Entwicklungsprojekte zu machen. Das ist zwar eine tolle Einnahmequelle und wir als Scrum Consulting Firma werden vielleicht sogar schwach und machen das bald auch - aber das war nicht der Sinn und die Idee hinter alldem. Was wir wollten, war ganz einfach: Wissensarbeit sichtbar machen, damit man darüber sprechen kann. Mehr nicht. Damit ein Teammitglied dem anderen helfen kann. Damit klar wird, wo es noch Lücken gibt und wo man sofort eingreifen kann.Die Entwicklung geht aber leider in die - meines Erachtens - falsche Richtung. Scrum Entwicklungsteams werden automatisiert dazu gezwungen, über jede Story und jede Zeile Code Rechenschaft abzulegen. Ihre Chefs, leider oft auch die Product Owner, müssen das nicht. Warum eigentlich? Wieso wird von den Entwicklern diese Transparenz erwartet, nicht aber von denjenigen, die die Ansagen machen?Meine klare Vermutung: Es würde zu deutlich zeigen, dass dort gar nichts produziert wird. Dort wird keine Leistung, keine Wertschöpfung erbracht. Erklären Sie doch einmal der nächsthöheren Ebene, was Sie den ganzen Tag in den 6 Meetings zu je 90 Minuten und in den 10 Telefonaten dazwischen produziert haben.Wir haben in unserem Unternehmen die Beweiskette, den Nachweis, dass etwas passiert, umgekehrt. Ich muss klar darlegen, was ich tue. Ich führe ein Backlog, das sich alle in einem Confluence Wiki ansehen können. Dort stehen alle Aktivitäten (fast alle - ich vergesse auch mal was), die ich an einem Tag ausführe, und ich lege die Ziele ebenfalls öffentlich ab. Nicht weil ich sie vorgeben will, sondern weil wir sie nur dann diskutieren können, wenn wir sie immer wieder sehen. Man kann nur über etwas reden, das man offenlegt.Und wisst ihr, was passiert ist? Es hat Schule gemacht. Jeder legt nun das, was er tut, ganz von selbst offen. Wir haben noch kein Taskboard - noch nutzen wir ein Wiki. Vielleicht nutzen wir auch bald mal JIRA intern ;-) - als verteiltes, skaliertes und multikultures Team. Aber nicht, damit mir meine Kollegen reporten, sondern damit sichtbar wird, wer gerade woran arbeitet und sich die Kollegen gegenseitig helfen können - egal, wo sie gerade sitzen. Internationalisierung, das remote Arbeiten und das ständige mobil Onlinesein lässt sich nicht mehr zurückdrehen. Wer diese Geschwindigkeitsvorteile nutzen will, darf Tools für die Zusammenarbeit über die Grenzen eines Büros hinaus nicht mit Reportingtools für das Management verwechseln oder sie dafür missbrauchen.