Bei der XYZ GmbH kann kein Projekt starten bevor ein Budget festgelegt worden ist. Bevor die Entwicklung des Projektes starten kann kommen die Business Stakeholder zusammen und legen die Top Prioritäten fest. Es gibt wochenlang wenn nicht monatelang Meetings, Powerpoint Slides mit geschätzten Kosten und ROI Zahlen, um das Projekt zu rechtfertigen und zu belegen warum das Projekt wichtig ist und warum gerade die gewählte Vorgehensweise die bestmögliche für XYZ GmbH ist. Die hohen Kosten und lange Lieferzeiten resultieren meist aus der Menge an Features welches das Projekt alles liefern soll.
Wenn die Entscheidung einmal gefallen ist legen dann Business Analysten, Designer und Requirement Engineers los, um eine lange Liste an Anforderungen zusammen zu schreiben. Dies dauert Monate bevor die Anforderungen an die Entwicklung zur Umsetzung gehen. In dieser Phase finden Umpriorisierungen statt, Qualitätstests werden definiert und das Ganze für die Produktion optimiert vorbereitet. Am Ende ist das Projekt weder in-time noch in-budget.
Wie man sehen kann sind viele Schritte involviert in diesem Value Stream welche die Zeit negativ beeinflussen bevor der Kunde eine Änderung oder Feature präsentiert bekommt. Technologie ist dabei Teil der Gleichung, aber es spielt keine Rolle welches Framework Sie einsetzen, es wird den Prozess nicht agiler machen oder verkürzen. Das System als Ganzes ist nicht entsprechend designed um „schnell“ zu sein. Die DevOps und Lean Thinking communities zielen darauf ab diese Probleme der System Optimierung zu lösen, die zu mehr Agilität führen und „Mehrwert“ schneller zum Kunden transportieren.
Das Problem mit dem dargestellten System ist, dass jede Menge Zeit und Geld eingeflossen ist bevor wir einen Mehrwert sehen. Ausserdem ist dieser Mehrwert theoretischer Natur, denn es ist nur eine Annahme. D.h. selbst der Mehrwert ist anzuzweifeln. Es ist nur eine Hypothese. Selbst wenn alles glatt läuft im Projekt und das IT Team der XYZ GmbH in-time und in-budget liefert garantiert keiner, dass überhaupt ein Mehrwert geschaffen worden ist. Eines der Eckpfeiler der agilen Entwicklung, DevOps und Lean thinking ist, dass wir uns in einer Welt voller Unsicherheiten befinden und unsere Anstrengungen im Vorfeld vorauszusagen was Mehrwert liefert komplett Glaskugel Leserei ist. Wir sollten eine wissenschaftliche Vorgehensweise anwenden um unsere angenommenen „guten Ideen“ as Hypothese zu formulieren welche es zu beweisen gilt. Z.B. mit der Hilfe von „Experimenten“, um Unsicherheit was wirklich Mehrwert bietet auszuräumen.
Um auf die IT zurückzukommen: Wir brauchen ein System welches Teams die Möglichkeit gibt schnell und günstig solche Experimente durchzuführen und Resultate bewerten zu können. Das Problem ist – und das ist ganz wichtig – das selbst Kunden nicht genau wissen was sie eigentlich wollen. Wenn wir Kunden gefragt hätten was sie denn wollen hätten wir jetzt schnellere Pferde und Telefone mit einer physischen Tastatur. Was wir mit unseren Experimenten erreichen wollen ist Dinge den Kunden zu präsentieren und zu beobachten was sie damit anstellen und wie sie damit umgehen. Aus diesen Erkenntnissen verbessern wir unser Produkt, unsere Webseite, unseren E-Commerce Shop usw. Wir wollen genauer verstehen welche Probleme die Kunden versuchen zu lösen und ihnen die Mittel dazu zu geben. Aus den Erkenntnissen formulieren wir neue Hypothesen die wir wiederum evaluieren und bewerten. Bevor wir in einem Folgeartikel weiter beschreiben wie wir ein solches System in der IT aufbauen und was die Herausforderungen und deren Lösungen sind möchte ich nochmal auf den Titel des Artikels eingehen.
Bei der digitalen Transformation eines Unternehmens geht es im wesentlichen um genau diesen oben beschriebenen Punkt. Natürlich ist die Umsetzung eine andere Sache, aber leider ist das Bild in der deutschen Unternehmer Landschaft ein völlig anderes. Vorstände meinen wenn Sie „Scrum“ einführen haben sie die digitale Transformation angestossen und können sich beruhigt zurücklehnen. Sie heuern große Agenturen und Beratungshäuser an, die mit einer Horde Agile Coaches einfallen und Scrum in großem Stil durchpeitschen. Scrum ist ein kleiner Baustein in der Transformation welches dem Gesamt Zweck dienen sollte was wir oben beschrieben haben. Zu meinem Erschrecken jedoch ist es zu zum Selbstzweck mutiert. Scrum ist zum Selbstzweck mutiert mit unendlichen Meetings und Groomings und Plannings I-III und Reviews und Retros. Da werden „Charters“ gebildet und im Team Marshmallow Türme gebaut, Maskottchen und Teamlogos entworfen und besprochen, bis hin zu stundenlangem Diskutieren über Rollcontainer und Kleiderständer, weil man ja den Teams die komplette Selbstorganisation überträgt. Bitte liebe CEOs, überlasst die digitale Transformation in euren Unternehmen nicht einfach einer Agility Company, die Scrum als Allheilmittel versprechen und propagieren. Lasst eure Alarmglocken angehen wenn sie mit einem Workshop nach dem anderen um die Ecke kommen und erzählen wie wichtig dies bei der Transformation wäre und dass das „dazu“ gehören würde. Was sie alles in ihrem Unternehmen tun, damit sich die Angestellten und Entwickler wohl fühlen ist etwas völlig anderes und hat mit Scrum nichts zu tun. Scrum ist ein Vehikel in dem Redesign des oben dargestellten Prozesses. Aber man darf dieses Redesign nicht aus den Augen verlieren und Scrum nicht damit gleichsetzen.
In dem nächsten Artikel führen wir fort, wie ein ein System designed sein müsste um Experimente schnell durchführen zu können.
