Eine ähnliche Geschichte wie die folgende kennen wohl einige: Wir betrachten ein mittelgroßes (österreichisches) Unternehmen, 200-300 Mitarbeiter, Softwarehersteller. Die Entwicklung läuft seit Jahren nach traditioneller Methode, alles ist eingespielt, die Teams sind "auf Track", jeder kennt den Prozess, eine kontinuierliche Verbesserung wird zwar durchgeführt, manifestiert sich aber oft nur in einer moderaten Anpassung oder der Umsetzung von Compliancethemen, die oft in einer überdimensionierten Dokumentationsflut enden. Das beeinträchtigt die Effizienz der Entwicklung und die Innovationsfähigkeit der Produkte massgeblich, der Time-to-Market neuer Features ist zu lange und die Kreativität ist auf das Überarbeiten der Benutzeroberfläche beschränkt.
Das Management beschließt deshalb, es einmal mit einem agilen Projekt zu versuchen, um zu sehen, wie ein Pilotteam damit zurechtkommt und welche Auswirkungen sich zeigen. Idealerweise versucht man ein neues Produkt, um nicht gleich zu Beginn schon mit den alten Gepflogenheiten der Transition kämpfen zu müssen. Also wird ein Scrumteam aufgebaut, die Rollen besetzt, alle werden geschult und zertifiziert und los geht's mit "Agile". Das wirkt überzeichnet, läuft aber oft so. Es machen ja alle auf "agil", oder?
Gleichzeitig rührt man die Werbetrommel, intern wie extern, und zeigt sich von seiner modernen Seite, auch wenn das mehr als zwanzig Jahre nach der Vorstellung von Scrum durch Ken Schwaber 1995 schon wieder ein bisschen nach altem Wein in neuen Schläuchen klingt.
Und parallel im "traditionellen" Universum läuft es konventienell nach einem Wasserfall-Äquivalent in den bisherigen Teams wie gewohnt weiter. Diese Kombination nennt man – nach einer Erfindung der Gartner Group – Bimodale IT. Es geht ja im Wesentlichen darum, die Vorteile aus der Diversität zu ziehen und nicht stur das eine oder andere Modell zu favorisieren. Dass das Gegner auf den Plan ruft ist verständlich, aber wenig hilfreich.
Ziel ist eine IT der zwei "Geschwindigkeiten", die Schaffung eines Connex aus traditionellen und agilen Prozessen, eine Art neuer Modus Operandi. Ein Teil, vorzugsweise für unverzichtbare Kernsysteme, fokussiert dabei auf traditionelle Entwicklungszyklen mit Betonung auf Sicherheit und Präzision. Der andere ist explorativ und nichtlinear, unterstützt die Agilität und Innovation mit kürzeren und somit häufigeren Entwicklungszyklen. Der Clou ist nicht, dass "Bimodale IT" gelebt wird, denn das wird vielfach ja schon länger gemacht, der Punkt ist, es richtig zu machen!
Die Gartner Group definierte vor einiger Zeit mit dem Schlagwort der "Bimodalen IT" das parallele Anwenden verschiedener Vorgehensmodelle in einem Unternehmen:
"Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration. Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and optimized for areas of uncertainty. These initiatives often begin with a hypothesis that is tested and adapted during a process involving short iterations, potentially adopting a minimum viable product (MVP) approach. Both modes are essential to create substantial value and drive significant organizational change, and neither is static. Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability. Both play an essential role in the digital transformation."
Begonnen hat diese Entwicklung schon vor einiger Zeit mit Cloudlösungen. Im wesentlichen war das Ziel dabei Opex (für "Operational expenditure") statt Capex ("Capital expenditure"), also der Versuch die Investionsausgaben zu senken, dafür aber die Ausgaben der Operations zu erhöhen. Weitere Ziele waren die Erhöhung von Flexibilität, Performance und Sicherheit, ein Trend der sich bis heute fortsetzt. Unter den guten Bedingungen in diesem Biotop wurden DevOps und agile Methoden rasch weiterentwickelt. Die Bimodale IT profitiert nun auch maßgeblich davon und dreht den Fokus vom Unternehmen in Richtung Kunden.
Wie kann ich Bimodalität fördern?
Bei dieser Entwicklung wird es immer wichtiger, mit einer gut gewählten Toolpalette Bimodalität unterstützen zu können. Das Verwalten von Wasserfall- oder V-Model-Projekten in Kombination mit der agilen Welt ist eine große Herausforderung, die natürlich Vorteile bringt. Die meisten ALM-Werkzeuge unterstützen die bekannten Vorgehensmodelle ausgezeichnet, jedoch gibt es darüber hinaus wenig Unterstützung für eine erfolgreiche Verknüpfung beider Welten. Bevor Sie jedoch an das Tooling gehen ist es unumgänglich darüber Nachzudenken, wie das eigene Unternehmen aufgestellt ist. Eine Notwendigkeit für Bimodalität ist das aktive Fördern einer florierenden Innovationskultur. Es gibt viele Möglichkeiten dies zu fördern, Innovation lässt sich nicht erzwingen, quasi wie sich Kreativität nicht einfordern lässt. Ein guter Schritt auf dem Weg dort hin ist die Unterstützung, oder besser, die aktive Förderung der Kommunikation der Teams untereinander. Transparenz ist der einzige Weg vom Silodenken, dem größten Feind innovativer Ideen, weg zu kommen. Mit Transparenz wächst der Respekt untereinander und wie sagt man so schön in Österreich? – "Beim Reden kommen die Leut' z'samm".
- Vereinfachen Sie komplizierte Workflows und reduzieren Sie diese auf aktuell notwendige Schritte, alles weitere entwickelt sich daraus in natürlicher Weise (das künstliche Aufblasen ist unnötiger Balast).
- Archivieren Sie aufgelassene Bereiche in Unternehmenswikis oder am Sharepoint, das erhöht die Sichtbarkeit der relevanten Informationen.
- Setzen Sie in Ihren Prozessen auf Push und nicht auf Pull, damit ein Ereignis dort getriggert wird, wo die Anforderung entsteht und nicht permanent gepullt werden muss. Polling kostet Resourcen.
- Wachstum erfordert Skalierung, nicht nur technologisch, sondern auch kulturell. Das ist eine unglaubliche Herausforderung in jedem Unternehmen.
- Nutzen Sie in Ihrer digitalen Transformation den agilen Modus für "Minimum Viable Products" (MVPs). Keine Innovation ist am ersten Tag fertig gedacht.
- Etablieren Sie die 20%-Regel – Google hat es vorgemacht, das können Sie auch. 20% der Zeit auf innovative Projekte verwenden. Manche werden MVPs (wer Atlassians Jira kennt weiß, dass das genau so entstanden ist).
Wie hilft Ihnen Software Quality Lab dabei?
Software Quality Lab hat umfangreiche Tool Expertise für alle Tools im Entwickungs-LifeCycle. Wir analysieren Ihre Organisation und erstellen maßgeschneiderte Lösungen. Damit werden die Werkzeuge zielgerichtet und effizient eingesetzt und alle Prozesse in den unterschiedlichen Bereichen auch in einer bimodalen Organisation werden optimal berücksichtigt.
Wir gehen dabei wie folgt vor:
- Durchführen einer Potenzialanalyse, welche Ihre Stärken aber vor allem auch Ihre Verbesserungspotenziale aufzeigt.
- Diese Herausforderungen werden gemeinsam besprochen und in eine für Sie machbare Roadmap gebracht.
- Nach Festlegung der ersten Optimierungsschritte erstellen wir dafür ein durchdachtes Konzept.
- Dies wird dann implementiert und wir helfen bei allen dafür notwendigen Themen von der Prozess-Anpassung über Tool-Beschaffung und Customizing bis zur übergreifenden Integration von Tools.
- Damit die Änderungen auch nachhaltig in der Organisation verankert und gelebt werden, begleiten wir diesen Prozess durch Coaching und Trainings von Tool Experten.
