Braucht jedes Unternehmen einen Transformation Officer?
Im Rahmen unserer Weihnachtsaktion erhalten Sie 10% Nachlass für einen RaaS-3-Vertrag für 3 Stellenbesetzungen. Aus unserem Erlös spenden wir 10% an das Kinderprojekt von "Die Arche" in München.
Agile Arbeitsweisen sind heute in aller Munde. Warum? Agiles Arbeiten nach Scrum verspricht einen Produktivitätszuwachs von bis zu 300% ohne Burnout in der Organisation, d.h. das die gleiche Arbeit mit einem Drittel der Mannschaft durchgeführt werden kann bzw. mit der gleichen Mannschaft bis zu 300% mehr erwirtschaftet werden kann - jedenfalls in der Theorie. Praktisch ist das auch möglich - hierbei spreche ich aus eigener Erfahrung.
Die agile Transformation ist das Change Projekt, um in der Organisation agiles Arbeiten einzuführen und den gesagten Produktivitätszuwachs zu realisieren.
Das agile Manifest beschreibt in einen agile Framework, was agiles Arbeiten bedeutet. Es beschreibt die verschiedenen Artefakte und Rituale, die notwendig sind, um nach Scrum und nach Kanban eine agile Arbeitsweise zu realisieren.
In der Praxis - gerade in etablierten Unternehmen zu sehen, die klassisches Projektmanagement anwenden - ist Effizienzsteigerung ein wichtiges Thema, da Projekte in der Regel immer die Herausforderung haben, das Budgets und Zeitpläne zu knapp eingestellt werden und das Projektteam sehr stark arbeiten muss, um den Projektplan in Time und Budget zu realisieren - was in den meisten Fällen nicht eintritt.
Gerade bei dieser Herausforderung wird das Wort Agilität gerne verwendet, um klassische Projekte noch effizienter durchzuführen, was letztendlich ein Trugschluss ist. Das richtige Wort wäre sicherlich Flexibilität, da Agilität im Agile Manifest entsprechend definiert und verankert ist.
Meine Empfehlung an dieser Stelle: Versuchen Sie klassische Projektorganisation nicht mit agilen Methoden zu mischen. Es macht das Ergebnis nicht besser. Es erhöht den Druck auf die Organisation mit der Konsequenz, dass die Organisation in Burn-out abdriften kann, was zu nachhaltig schlechter Qualität führt.
Scrum und Kanban sind im Agile Manifesto beschrieben, diese definieren im Grunde die Arbeitsweise in einer Produktrealisierung - wir sprechen hier bewusst nicht von Projekten. Scrum arbeitet auf Basis von Sprints (1 bis 4 Wochen) und hat ein Paket von User-Stories, welche vom Scrum-Team in der jeweiligen Sprintlänge zu realisieren sind. Hierbei werden alle User-Stories zu Beginn des Sprint im Rahmen des Sprint-Goals vom Scrum Team von der Komplexität bewertet und in den Sprint übernommen. Scrum erfordert ein gutes Zusammenspiel zwischen dem Product-Owner, dem Scrum-Master und dem Development Team, um ein gutes Arbeit zu erreichen.
Kanban ist im Gegensatz zu Scrum in der Arbeitsweise anders strukturiert. Es werden User-Stories erstellt und das Development Team kann sich die User-Stories individuell ziehen und abarbeiten. Es gibt keinen festgelegten Sprint, in welchem das Development Team ein Userstories-Paket zu liefern hat. Kanban findet oft seine Anwendung in agilen Teams, welche neu bzw. In der Findungsphase sind oder eine Aufgabenerfüllung nachgehen, in der es nicht praktikabel ist, in Sprints zu arbeiten.
Im Lebenszyklus von Organisationen kommen viele etablierte Unternehmen aus einer klassischen Organisation, die wie eine Pyramide Top-Down organisiert ist. Im besten Fall gibt es eine Matrix-Struktur, in der Personal-Isa und Fachverantwortung getrennt sind, um Siloübergreifend arbeiten zu können.
Die agile Delivery findet hierbei in vielen Unternehmen eine praktische Anwendung. Meist ist diese in modernen Projektmanagement Organisationen zu finden.
Eine agile Organisation ist jedoch noch ein Schritt weiter gedacht. Es stellt erstmal alles auf den Kopf. Geschäftsführer, Bereichsleiter etc. gibt es in der agilen Organisation nicht mehr. Es gibt nur noch agile Teams, welche selbstorganisiert sind, ihr Thema verfolgen und sich ständig selbst optimieren und weiterentwickeln.
Um diese Organisationsform zu realisieren, ist ein radikaler Wandel notwendig. Wie das stattfinden kann, lässt sich praktisch in der Agile Safari bei der metafinanz erleben, die ihre eigene Organisation von 300 Mitarbeitern auf 35 selbstorganisierende Squads umgestellt haben.
Eine agile Transformation der Organisation hat keinen Selbstzweck. Im Rahmen von agilen Arbeitsweisen wird wieder der Produktivitätszuwachs von bis 300% genannt.
Ja, das ist richtig. Allerdings braucht es im Rahmen einer agilen Transformation die Verbindung zu einer Geschäftsmodell-Veränderung, um von dem Produktivitätszuwachs zu profitieren. Wird die eine agile Transformation nur aus organisatorischen Gesichtspunkten vollzogen, um mit dem möglichen Produktivitätszuwachs die Organisation mit neuen Aufgaben betreuen zu können, so wird die Transformation nicht funktionieren.
Hier braucht es die strenge Vorgehensweise nach „Culture follows Strategy“ oder besser gesagt „Culture follows Business Model“.
Unternehmen, welche ihre Geschäftsmodelle weiter digitalisieren möchten bzw. diese weiter komponentisieren möchten, brauchen in der Organisation mehr Geschwindigkeit, und damit eine höhere Produktivität sowie mehr Intelligenz. Diese Fähigkeiten sind in agilen Organisationen erhalten.
Eine agile Transformation ist ein Change Projekt in der Organisation. Jeder, der sich mit Change Projekten intensiv auseinander gesetzt hat, weiß, dass Menschen nicht veränderbar sind. Es lässt sich nur ein Raum schaffen, in dem sich Menschen verändern und dabei die Veränderung selbst durchführen. Das macht es so schwierig, Change-Projekte zu planen, vorzubereiten und erfolgreich durchzuführen.
Eine agile Transformation durchzuführen benötigt Vorlauf. Am besten ist es mit einer agilen Delivery in der Organisation zu starten und dann einzelne agile Teams in der Organisation zu etablieren, um agile Arbeitsweise in der Unternehmenskultur zu verankern und Interessenten, die Möglichkeit zu geben, darüber mehr zu erfahren und die Freiheit zu besitzen, auch in agilen Teams arbeiten zu können. Hierfür gibt es zahlreiche Modelle, die eine agile Transformation auf Teams-Ebene beschreiben.
Wenn die agile Transformation beschlossen ist, sollte dem Management Team klar sein, dass die Transformation nur erfolgreich sein kann, wenn das Management Team die Transformation selbst durchführt und sich damit selbst überflüssig macht. Andernfalls wird der Change nicht glücken.
Meine Empfehlung: Um so radikaler der Change im Management geplant und durchgeführt wird, desto besser folgen auch die Mitarbeiter.
Das Spotify Modell ist ein sehr verbreitetes Modell, um eine agile Organisation zu strukturieren. Es ist kein theoretisches Modell, sondern wir von Spotify selbst genutzt und in der Praxis umgesetzt. Im Grunde ist das Modell sehr einfach. Es gibt ein Team, es gibt Tribes und Gilden, das sind jeweils thematische Zusammenschlüsse von Individuen, um außerhalb der Teams ebenfalls themenspezifisch weiter zu arbeiten sowie Innovation im Unternehmen zu fördern. Damit wird erreicht, dass die Teams offen in Kommunikation mit Individuen außerhalb der Teams bleiben und keine neuen Silos in der Organisation entstehen.
Angelehnt an das Spotify Modell haben wir die agile Organisation im Feel Good Universe etwas abgewandelt strukturiert. Bei uns gibt es Squads, welche einem selbstorganisierenden Team entsprechen und max. 8 bis 10 Personen groß sind. In diesem Team gibt es einen Squad Leader, der wie eine Art Klassensprecher funktioniert und das gegenüber einem Kunden und in der Organisation vertritt. Der Squad Leader hat ebenfalls Einblick über die Finanzen des jeweiligen Teams und ist aufgefordert, unternehmerische Entscheidungen zu treffen. Im Team selbst gibt es einen Product Owner, einen Scrum Master sowie ein Umsetzungsteam, welches interdisziplinär aufgestellt ist. Die Arbeitsweise ist an Scrum angelehnt, kann jedoch auch variieren, wenn die Aufgabe des Squads einen anderen Reifegrad der agilen Arbeitsweise erfordert.
Jedes Team besetzt ein Thema in der Organisation und kann sich mit einem Namen innerhalb der Organisation sowie über ein eigenes Außenbild oder Marke positionieren.
In unserer Organisation ist es gewünscht, dass sich ein Team stetig weiter entwickelt. Wenn es in der Lage ist, sich auszugründen, so soll es geschehen und wird von unserer Organisation unterstützt.
Zudem fördern wir der Organisation den Wechsel von Team-Mitgliedern zwischen den Squads, auch wenn die Squads unterschiedlichen Unternehmen angehören.
Durch all diese Maßnahmen ist es unser Anspruch, das Individuum in der Selbstorganisation zu fordern und zu fördern, um damit die optimale persönliche Herausforderung für den Mitarbeiter sowie das beste mögliche Ergebnis für den Squad, das Unternehmen und der Organisation zu erreichen.
In agilen Transformation unserer Organisation wurden wir fortwährend mit der Situation konfrontiert, dass sich die agilen Teams selbst organisieren und die wirtschaftlich funktionieren. Hierfür war unser klassisch Finance-Controlling nicht aufgestellt. Zudem gab es hierzu auch keine Best-Practice Modelle, wie ein agiles für Finance-Controlling aussehen könnte.
Daraufhin haben wir unser eigenes Modell entwickelt, welches wir unseren Klienten gerne als Best Practice Modell weiter empfehlen, weil wir es auch selbst bei uns einsetzen.
Jedes Team hat bei uns die Maßgabe einen Gewinn in Höhe von 30% des eigenen Umsatzes zu erzielen. Mitarbeiterkosten sind Fixkosten und werden mit maximal 40% des Umsatzes zugelassen. Es gibt ein Budget für Innovation, für Marketing und für Sonstiges in Höhe von jeweils 10% des eigenen Umsatzes.
Praktisch erfolgt die Realisierung als Finanzschablone, in welcher die Mitarbeiterfixkosten festgelegt werden und damit ein Umsatz-Forecast in Höhe des 2,5 fachen der Mitarbeiterkosten zu erreichen ist. Die Budgets für Innovation, Marketing und Sonstiges sollen dabei unterstützen, die Umsatzgrösse zu planen und zu realisieren.
Unterstützt wird das jeweilige Team durch Experte aus den Zentralen Diensten, das ist ein Experten Team in der Geschäftsführung mit dem Anspruch, das jeweilige Team zum Erfolg zu verhelfen.
Geschäftsführer, Berater Strategie und Transformation, AI Engineer, Developer, SCRUM-Master und Product Owner
