Tun ist seliger denn nicht tun

In dem Unternehmen, in dem mein Freund arbeitet, wurde vor einiger Zeit ein internes Projekt gestartet. Es sollte ein Analysetool entwickelt werden, das die Firma bei Kunden einsetzen wollte. Und mein Freund - noch ganz frisch an seinem neuen Arbeitsplatz - sollte daran mitwirken! Völlig begeistert von dem Gedanken, versuchte er die wichtigsten Anforderungen in Use Cases bzw. User Stories zu formulieren und er hatte bereits angefangen, einen Prototypen zu bauen.Doch kaum hatte er den Begriff "Scrum" in den Mund genommen, blockierte sein Chef. Man müsste das ganzheitlich denken, man könne doch nicht einfach anfangen, etwas zu entwickeln. Es sei eine Meta-Perspektive nötig. Man müsste erst einmal alles durchdenken und miteinander verknüpfen, bevor man die Entwicklung starten könne. Jetzt, wo man das alte Tool ablösen wollte, musste man es ja „richtig“ machen - nicht wieder einfach Stück für Stück etwas dazufrickeln.Etwas zerknirscht ließ sich mein Freund also auf die Suche nach dieser geheimnisvollen Formel ein. Eine wirkliche Wahl hatte er nicht, denn einen Prototypen durfte er nicht entwickeln. Es ging nur schleppend voran. Alles lief in den Anforderungen, Ideen, aber auch Beschränkungen des Chefs zusammen. Diese änderten sich nicht nur permanent, sondern man entdeckte immer noch eine weitere Abzweigung oder Möglichkeit, die im Gesamtkonzept berücksichtigt werden wollte und damit das bisherige Konzept wieder in Frage stellte. Die Angst, etwas nicht komplett Ausgereiftes und zu 100% Fertiges zu liefern, gebar ein Meta-Konzept nach dem anderen. Den anderen Chefs der Firma wurde natürlich weiterhin kommuniziert, dass man an der Lösung arbeite. Sehen durften sie von alledem jedoch nichts.Die marginal verfügbare Info nutzte einer der Chefs, um das neue Tool bereits fleißig zu verkaufen. Er tat es so hervorragend, dass er mit der alten Lösung nicht mehr alle Anfragen bearbeiten konnte. Vielleicht hätte er nicht fragen sollen, wann denn das neue Tool nun fertig sein würde bzw. ob er es denn nun endlich nutzen könne. Nichts war fertig. Bis auf die Konzepte.Kurzerhand kaperte dieser Chef das Projekt - natürlich sollte der andere Chef nichts davon wissen. Die Anforderungen sprudelten nur so aus ihm heraus und unbedingt, unbedingt, unbedingt solle man jetzt diese „Scrum-Programmierung“ ausprobieren. Und obwohl mein Freund streng war, und in den nächsten zwei Tagen erst mal die Kernfunktionalitäten prototypisch umsetzte, verkürzte sich die Bearbeitungszeit für eine Analyse von ca. 5 Stunden auf 30 Minuten. Außerdem wurde bei der ersten Strukturierung der Daten deutlich, welche Neustrukturierung sinnvoll wäre bzw. welche Möglichkeiten der Meta-Analyse es gab. ;-)Als der Vertriebs-Chef nach 1,5 Jahren der Konzipierung und 2 Tagen Prototyping die ersten Ergebnisse sah, sagte er nur: „Das mit dieser Scrum-Programmierung ist toll! Da kommt man so schnell voran und sieht Ergebnisse.“ Das ganze Wochenende über spielte er mit dem Prototypen.Noch so ein Nebeneffekt dieser Scrum-Programmierung: Nachdem mein Freund mir am Freitag Abend stolz sein Ergebnis präsentiert hatte, und ich ihm Feedback zu einer möglichen Visualisierung gegeben hatte, bekam ich ihn kaum vom Computer weg. Sein Meta-Konzept-Frust der letzten 1,5 Jahre schien vollkommen verflogen.Natürlich musste ich beim Begriff „Scrum-Programmierung“ schmunzeln. Warum? Weil es mir mal wieder gezeigt hat, dass man nicht wissen muss, was Scrum ist, um zu verstehen, wofür Scrum gut ist.Es geht nicht um Meetings, Rollen, Artefakte - es geht ums Tun, Ausprobieren und Liefern. 
Macht die Dinge angreifbar, baut etwas. Seid stolz auf das, was ihr gemacht, nicht was ihr gedacht habt. Seht das Gemachte als Gedankenanstoß - nicht als Endprodukt! Bindet andere ein und nehmt jegliche Art von Feedback als Kompliment. Ihr habt etwas gebaut und ermöglicht so, dass sich andere damit auseinandersetzen. Die Zeit, die sie dafür investieren, ist das beste Kompliment, das man bekommen kann.