Transformation und Delivery – die Unzertrennlichen
Die digitalen oder informationstechnischen Elemente der oft gehypten digitalen Transformation sind nicht die bedeutendsten, interessantesten oder wertstiftenden Aspekte der Veränderungen, die heute in Organisationen vonstattengehen müssen. Hinter den Fortschritten in der Technologie stehen bereits viele konsumentengetriebene Impulse, Blockierer gibt es kaum.
Konsumenten fordern es, wir sparen Geld bei der Implementierung, es hilft uns bei der kostengünstigen Integration verschiedener Kanäle und es gibt einen guten Markt an Möglichkeiten bezüglich erfahrener Technologiepartner, spezifische Fähigkeiten und Services zu angemessenen Preisen zu liefern. Und als netter Nebeneffekt liefern neueste technologische Fortschritte eine riesige Menge an Daten, die uns dabei helfen, unseren Kunden durch ein Ausmaß an Insights zu verstehen, das es so vorher noch nicht gab. Auf diese Weise wird das Potential (realisiert durch jüngste Fortschritte und ein steigendes Angebot an Fähigkeiten in der Datenforschung und –analyse), deren Bedürfnisse in der Zukunft präziser und effizienter zu abzudecken, freigelegt. Diese coolen neuen technischen Ideen werden vom Fachpersonal wie Software-Entwicklern begeistert angenommen, wodurch ich sie als schnellen Gewinn oder „low hanging fruits“ einstufe.
Ein entscheidender Aspekt dieser neuen, sich aktuell vollziehenden Veränderungen ist die Adaptierung von agilen Methoden unter Software-Entwicklungsteams. Besonders über die letzten fünf Jahre ist der Einsatz von Scrum innerhalb von Software-Entwicklern fast zum Mainstream geworden. Dennoch wurde in vielen Fällen – vor allem in größeren Organisationen – echte, durchgehende Agilität nicht erreicht, weil der IT-Fokus von Agile und Scrum die anderen Teile des Wertstroms gefühlt außen vor gelassen hat. Dieser Fokus auf IT ist im Wesentlichen das, was Kahn als bloße Digitalisierung, eine Art Vorstufe der echten Digitalen Transformation, bezeichnet.
Ideen, die darauf abzielen, die Skalierung von Agile in größeren Organisationen zu unterstützen, so wie SAFe, LeSS und Nexus, tendieren immer noch dazu – auch wenn sie erfolgreich angewendet wurden –, sich auf eine Transformation der IT zu fokussieren und die Organisation selbst unverbessert und oftmals mit veralteten Management-Ansätzen zurückzulassen, die mit der neuen Kultur, die aus der IT-Abteilung kommt, kollidiert.
Sehr neue Konzepte wie etwa Design Thinking haben dabei geholfen, die vorgelagerten Aktivitäten im Produktentwicklungsprozess ein wenig zu „evolutionieren“. Diese waren aber nur selten gut in den Software-Entwicklungsteil des Wertstroms integriert und haben die Agilität in manchen Fällen sogar verringert, da die typische Implementierung in einer wasserfallartigen Design-Thinking-Phase resultierte, die in einer Dokumentation endete, um später in User Stories als Input für die agile Software-Entwicklungsphase umgewandelt zu werden.
Vor nicht allzu langer Zeit hatte eine große Beratungsfirma kurze Zeit des Ansehens als leitendes Unternehmen, das für die digitale Transformation eines Innovationsansatzes eines großen Kunden verantwortlich war. Der größte Fehler, der dabei begangen wurde, war Transformation von Delivery zu trennen. Sie haben dem Kunden ein teures Beratungspaket verkauft, mit der Intention, die neue Struktur der Organisation aufzusetzen, während andere Anbieter diese Struktur später auffüllen und die eigentlichen Produkte liefern sollten. Aber man kann eine neue Organisation nicht wirklich formen, bevor die Leute da sind, um die Organisation zu füllen und bevor es überhaupt etwas zu tun gibt. Was sie tatsächlich ausgeliefert haben, war schlicht Dokumentation: Power-Point-Folien. Ein Leitfaden, wenn man so will, der erklärt, wie jeder seine Aufgaben zukünftig erledigen soll. Das hat natürlich nicht funktioniert. Die Delivery-Organisationen hatten ihre eigenen Ideen, wie die Arbeit strukturiert sein sollte. Und natürlich hat der Kunde den ein wenig abstrakten und theoretischen, vorgegebenen Ansatz missverstanden. Existierende Teams haben ausgewählt, was und wie implementiert wurde. Sie haben etwa Design Thinking umgesetzt – aber auf der Business-Seite in einem phasenbasierten Wasserfallansatz. Sie haben nie auch nur in Erwägung gezogen, in den gleichen Teams wie die Software-Entwickler zu arbeiten. Vermutlich hätten sie das auch nicht gekonnt, selbst wenn sie gewollt hätten. Zu dem Zeitpunkt, als die Scrum Master involviert waren (als die Entwicklungsphase startete), war es zu spät. Die meisten Produkte waren bereits gestaltet und in der Dokumentation, in Wireframes und sogar Prototypen beschrieben. Es war keinerlei Kreativität mehr erforderlich, lediglich die Umwandlung eines nahezu fertigen Produktes in Quellcode. An diesem Punkt sind Scrum und die dazugehörigen Rollen vollkommen überflüssig.
Wenn Transformation und Delivery nur richtig wahrgenommen werden würden und zwar als unzertrennliche Aspekte ein und derselben Sache – wie immer vorgestellt – hätten sich alle Teile des Prozesses zusammen verbessert, alle Fragen hätten sich auf eine ganzheitliche Art und Weise gelöst, jegliche Missverständnisse hätten sofort korrigiert werden können und die Organisation hätte die vollen Vorzüge einer wahrhaftigen, durchgängigen Agilität genießen können.
Es funktioniert auch in die andere Richtung. Ich kann mir nicht vorstellen, wie eine Organisation Scrum ordnungsgemäß als Framework zur Produktentwicklung einsetzt, ohne eine tiefgreifende Transformation zu erleben. Der Charakter von Scrum als Framework (mehr als ein Prozess) verlangt danach. Den Teams muss die Freiheit gegeben werden, mit der Zeit ihren eigenen Prozess in diesem von Scrum zur Verfügung gestellten Framework zu entwickeln. Und diese Evolution muss kontinuierlich sein. Der Markt ändert sich, Technologien ändern sich. Die wahre Kraft von Agile und Scrum steckt in der Befähigung von Teams, diese dezentralisierte Transformation, die die Organisation benötigt, voranzutreiben. Tatsächlich kann es in den meisten Fällen nur auf Team-Ebene passieren, dass diese Transformation schnell genug erfolgt. Sogar oder vielleicht besonders in Bereichen, die nicht direkt mit der Produktentwicklung selbst in Zusammenhang stehen. Die Rolle des Managements im Speziellen kann sich von einem „Command-and-Control“-Stil zu einem Scrum-Master-Stil dienenden Leitungsansatz ändern, der sich weniger auf die Maximierung von Mitarbeiterauslastung fokussiert, sondern mehr auf das Coaching ihrer Teams, das aus dem Weg räumen von Hindernissen und die Vernetzung von Menschen. Die Art, wie wir auf die Arbeit an sich schauen, wird sich ändern – es wird sich weniger um das Planen und Abhängigkeitsmanagement drehen und mehr um die schnelle Bereitstellung und Verbreitung von Informationen durch die gesamte Organisation hinweg, ohne das Aufbauen von verzögerungsverursachenden Warteschlangen. Auch Marktfeedback kann an diejenigen, die es brauchen und nutzen, genauso schnell geliefert werden. Tatsächlich wird sich vielleicht die Struktur der Organisation entwickeln – weniger top-down, hierarchisch und mit mehr adaptierten Elementen eines dezentralisierten, outside-in, marktorientierten Netzwerks von funktionsübergreifenden Gruppen, unterstützt von Kernfunktionen, die im Zentrum angesiedelt sind.
Behalten Sie das im Hinterkopf, wenn Sie Scrum und im Speziellen Scrum Master in ihrer Organisation einführen wollen. Delivery zu unterstützen ist nur ein Teil ihrer Rolle. Scrum – zusammen mit anderen mächtigen Tools im Scrum-Master-Werkzeugkoffer wie etwa Kanban – können eine vorteilhafte Transformation in Ihrer Organisation unterstützen, die nicht im Sotware-Entwicklungsteam angesiedelt ist.
Der neue Lean-/ Agile-Ansatz lautet daher, Delivery und Transformation nicht als getrennte Bereiche anzusehen. Lean-/ Agile-Berater werden dazu ermächtigt werden, Sie nicht nur in der Auslieferung von neuen Produktinnovationen zu unterstützen, sondern auch Anleitung zu geben hinsichtlich Anpassungen, die in der Organisationsstruktur, Kultur, Rollen, Prozessen und Systemen über den durchgängigen Wertstrom gemacht werden könnten. Und dabei kommen sie nicht herein (und wären gar nicht in der Lage) und schreiben Ihnen einfach vor, etwas zu ändern, ohne gemeinsam im echten Kontext von Delivery zu erkunden, welche Optimierungen exakt die Endergebnisse liefern, die Sie erwarten.
