Einleitung
Agile Methoden sind vor allem durch ihre Anwendung in der Softwareentwicklung bekannt, genauer gesagt in „software-only“ Umgebungen. Seltener, aber auch immer öfter, kommen sie auch in hybriden Produktentwicklungsumgebungen zum Einsatz, also da, wo Hardware und Software in Kombination das Produkt ergeben. Ein sehr prominentes Beispiel hierfür ist der deutsche Autobauer BMW.
Ohne echtes agiles „Produktdenken“ zu implementieren, werden agile Vorgehensweisen auch gerne für die reine Umsetzung, eines ansonsten ganz klassisch geplanten Projektes, eingesetzt. Dann wird es als sog. „agiles Projektmanagement“ bezeichnet und konzentriert sich ausschließlich auf die Arbeitsaufteilung und Abarbeitung in festen periodischen Zeiträumen, „Sprint“ genannt (vom agilen Framework SCRUM entliehen). Diese Zweckentfremdung ist sehr populär und entspringt oft schlicht einem Missverständnis und unzureichender Ausbildung auf diesem Gebiet. Sie könnte trotzdem in manchen Fällen sinnvoll sein, führt aber leider durch ihre Anwendung auch zu einer Weitergabe von gefährlichem Halbwissen, das auch immer mal wieder zu einer Rufschädigung von z.B. SCRUM geführt hat.
Wo, und in welcher Art und Weise, diese Zweckentfremdung sinnvoll sein kann und wie diese dann im Detail aussieht, das möchte ich hier im Kontext Digitalisierung bzw. digitale Transformation im Umfeld Industrie 4.0 näher beleuchten.
Was fehlt?
Die Reduktion agilen Produktdenkens auf die reine Umsetzungsarbeiten eines klassisch geplanten Projektes, bedeutet wesentliche Teile des agilen Mindsets komplett wegzulassen. Man muss schon vielmehr von einem Herauspicken von wenigen Elementen sprechen, statt von einer Reduktion. Ich möchte hier lediglich auf die fehlenden Teile eingehen, die eine mehr als sinnvolle Ergänzung wären, um zusammen genommen zu einem flexiblerem Projektmanagement zu kommen, das große Vorteile gegenüber klassischen Methoden hat, und das in vielen Einsatzbereichen, weit über Softwareentwicklungsprojektes hinaus, effektiv genutzt werden könnte:
Sowohl die Einarbeitung in die Inhalte des Projektes als auch die Umsetzung, macht ein für diesen Zweck auf Dauer zusammengestelltes Team, fortan „Umsetzungsteam“ genannt.
Die Einarbeitung in das Projekt und die daraus resultierende Aufteilung des Projektes in kleine Arbeitspakete macht das Umsetzungsteam gemeinsam mit dem Auftraggeber.
Ein Arbeitspaket ist so klein, dass es in wenigen Tagen fertiggestellt werden kann.
Ein Arbeitspaket ist ein „Teilprodukt“, das für sich genommen bereits einen Mehrwert hat, also bereits sinnvoll vom Auftraggeber benutzt werden kann.
Bei der Umsetzung wird stets die komplette Fertigstellung eines einzigen Arbeitspaketes angestrebt, bevor mit dem nächsten begonnen wird.
Die wichtigsten Arbeitspakete werden zuerst umgesetzt.
Diese Ergänzungen adressieren die Hauptgründe, die für das Scheitern von Projekten verantwortlich sind:
Es wird nicht gebaut, was der Auftraggeber wollte oder das Gebaute löst nicht die Probleme, die es lösen sollte.
Erst am Ende der Umsetzung des Gesamtprojektes kann beurteilt werden, ob das was gebaut wurde auch den Erwartungen des Auftraggebers entspricht.
Diese Gründe werden durch obige Ergänzungen gemildert oder ganz ausradiert, da die Personen, die mit der Umsetzung betraut werden, ohne Indirektion die Anforderungen erfahren müssen. Sie müssen den Gesamtzusammenhang verstehen und durch direkte Rückfragen offene Punkte klären können. So haben sie auch die Möglichkeit, eigene Umsetzungsvorschläge einzubringen, die eine zielführendere und gewinnbringendere Lösung hervorbringen könnte. Werden dann noch die wichtigsten Komponenten zuerst entwickelt und in einen benutzbaren Zustand gebracht, kann diese der Auftraggeber bereits in einer frühen Phase ausprobieren und sein wichtigstes Problem ist zuerst gelöst.
Woran scheitert es?
Bei der Planung eines Projektes ist oft nicht sicher, ob es auch wirklich durchgeführt wird. Die Planung dient lediglich einer Angebotsabgabe also einer Schätzung des Aufwandes und damit des Preises für die Umsetzung. In dieser Phase wird aufgrund der Unsicherheit, ob es zur Umsetzung kommt oder nicht, noch gar kein Umsetzungsteam ausgesucht oder neu gebildet und kann daher nicht einbezogen werden.
In einem Umsetzungsteam befinden sich oft Personen, die den direkten Umgang mit einem Auftraggeber nicht gewohnt sind. Sie werden dafür nicht ausgebildet und sie haben nicht das Verständnis dafür, es als Teil ihrer Arbeit anzusehen. Erst recht, wenn es sich um einen externen Auftraggeber, aka Kunde, handelt. Der Projektverantwortliche schreckt daher davor zurück, die eigenen Mitarbeiter direkt mit dem Kunden in Kontakt treten zu lassen.
Last, but not least, fehlt obendrein oft die Erkenntnis, dass das Zusammenbringen des Auftraggebers mit dem Umsetzungsteam, das größte Projektrisiko massiv minimiert: Wer aus erster Hand im Dialog erfährt, was gebraucht wird, muss nicht raten und kann Verständnisfragen direkt klären.
In welchen Einsatzgebieten kann diese Methode benutzt werden? Nur in der Softwareentwicklung?
Die erläuterte Vorgehensweise kann bei der Umsetzung vieler verschiedener Projekte eingesetzt werden. Sie eignet sich insbesondere für Projekte rund um digitale Transformation, also die Überarbeitung, das Neudenken und digitale Aufsetzen von Prozessen in Unternehmen. Dieser Anwendungsfall ist so spannend, weil meiner Erfahrung nach dabei
die firmeneigene IT-Abteilung für die Umsetzung zuständig ist, diese aber entweder keine Erfahrung mit Agilität hat oder nicht daran denkt, diese auch für die Umsetzung von Nicht-Softwareentwicklungsaufgaben zu nutzen,
der Auftraggeber in der Regel das Management des eigenen Unternehmens ist, also eigentlich sehr leicht „zugänglich“ ist und verfügbar für Absprachen, Rückfragen und ggf. Workshops und
der Nutzer der ersonnenen Lösung ebenso im eigenen Haus sitzt und daher sehr schnell und einfach die ersten Umsetzungsergebnis direkt nutzen und bewerten kann
also, zusammengefasst, eine optimale Umgebung für den Einsatz gegeben ist. Weiterhin ist gerade auch bei der digitalen Transformation das Risiko des Scheiterns sehr groß, da seltsamerweise der Nutzer, nämlich die eigenen Mitarbeiter, oft gar nicht mit einbezogen werden, obwohl dies der Schlüssel zum Erfolg ist/wäre. Siehe dazu auch meinen anderen Post „Die Mitarbeiter an die Hand nehmen“.
Hier nur ein paar Beispiele für Projekte im Kontext der digitalen Transformation, die von der beschriebenen Vorgehensweise profitieren würden:
Umstellung der Bürokommunikation von Telefon und Fax hin zu E-Mail oder Kollaborationstools wie Microsoft Teams oder Slack.
On-Premise Betrieb von Exchange- und Fileservern umstellen auf Nutzung von Cloud-Diensten.
Ersetzen der Papierdokumentation von Prozessschritten durch Nutzung eines MES- oder ERP-Systems.
Zusammenfassung von Daten verschiedener, unabhängig existierender IT-Systeme in eine einzige kollaborative Datenplattform wie z.B. Grafana unter Verwendung eines MQTT-Brokers.
Automatisierung von bisher manuellen Interaktionen mit IT-Systemen.
usw. usw. usw.