27.10.2017  Verfasst von Simon Schröbel in Agile Blog  

Agiles Prozessmanagement – Vive la Résistance

Was es für die Organisation bedeutet, agiles Prozessmanagement einzuführen und warum sich fast immer Widerstände zeigen wird im Folgenden näher erläutert.

grid 1
Was es für die Organisation bedeutet, agiles Prozessmanagement einzuführen und warum sich fast immer Widerstände zeigen wird im Folgenden näher erläutert.

Agiles Prozessmanagement integriert Konzepte aus der agilen Welt wie z.B. Scrum. Dadurch wird der Kunde (Processowner, Prozessbeteiligter) stärker eingebunden. So kann es gelingen, im Vergleich zum klassischen Prozessmanagement, eine höhere Geschwindigkeit im Prozessdesign und der Prozessimplementierung zu erzielen. Auch das Steuern von Arbeitspaketen, sowie die Erfüllung von KPIs, Zertifizierungs- und Auditzielen kann schneller erreicht werden.

Was es jedoch für die Organisation bedeutet, agiles Prozessmanagement einzuführen und warum sich fast immer Widerstände zeigen wird im Folgenden näher erläutert.

Die Einführung von agilem Prozessmanagement in ein Unternehmen mit keiner bis geringer Erfahrung in agilen Methoden, bringt in der Regel eine ungewohnte Veränderung für die Organisation(seinheit) mit sich. Das agile Vorgehen wirkt auf bestehende Strukturen und interne Vorgänge ein, wie z.B. Kommunikation und Zusammenarbeit, die Meeting Kultur sowie die Berichterstattung. Aber auch im täglichen Doing, denn agile Teams sind cross-functional besetzt und zeichnen sich u.U. auch durch Mitglieder verschiedener Hierarchie-Ebenen aus. Die neue (agile) Arbeitsweise stellt Bestehendes in Frage und macht Entwicklungspotentiale in der Organisation sichtbar. Das löst bei manchem Unmut aus. Denn Veränderungen bedeuten meist, dass man sich mit Neuem befassen und ggf. auch seine Komfortzone verlassen muss.

Viele der daraus resultierenden Widerstände lassen sich in drei Kategorien zusammenfassen.

  • Kommunikation
  • Organisation
  • Unternehmenskultur

 

Kommunikation: Daily Stand-Ups, Sprint Reviews und Retrospektiven, sind kommunikative Mittel im agilen Kontext und kommen auch beim agilen Prozessmanagement zum Einsatz.  Doch können regelmäßige, feste Kommunikationsstrukturen Missverständnisse nicht ausschließen. Dies liegt einerseits daran, dass die Kommunikation innerhalb der agilen Teams, aber auch zwischen den Teams und der Organisation aufgrund bestehender Rapportstrukturen oft ungenügend ist. Denn agile Methoden verlangen auch eine entsprechende Kommunikationsstruktur innerhalb der Organisation. Eine Anpassung wird oft vernachlässigt oder nur schleppend umgesetzt.

Andererseits wird die Organisation oft nicht entsprechend abgeholt. D.h. relevante Stakeholder sind unzureichend über die Einführung eines agilen Prozessmanagements informiert. Allein diese Tatsache, nicht oder mangelhaft informiert zu sein, sorgt oft für Missstimmung und führt somit unweigerlich zu Widerstand gegen das „Neue“. Der Mitarbeiter fühlt sich übergangen.

Organisation: Die Kommunikationsstruktur ist eng mit der Organisationsstruktur einer Unternehmung verknüpft. Zum Beispiel tun sich silogetriebene sowie stark hierarchisch geprägte Organisationen zu Beginn meist schwer bei der Einführung agilen Prozessmanagements. Denn dies kann bedeuten, dass ein Abteilungsleiter mit Mitarbeitern aus der Linie regelmäßig in Sprints zusammenarbeitet. Oder ein Fachexperte an Vorgesetzte Arbeitspakete bis zum nächsten Meeting delegiert. Diese Arbeitsweise ist für Manager, wie auch Mitarbeiter oft ungewohnt und kann für Unbehagen sorgen.

Darüber hinaus verlangt agiles Prozessmanagement klare Verantwortlichkeiten. Processowner, Prozessexperte, Prozessmodellierer müssen ernannt und mit den Befugnissen, Entscheidungen zu treffen und durchzusetzen, ausgestattet werden. Hierzu bedarf es einer klaren Unterstützung durch das Top Management. Exemplarisch hierfür ist das Stellen des Chief Process Officer und die Bildung eines Steering-Komitees zu nennen. Neben der Organisationsstruktur ist auch die Unternehmenskultur ausschlaggebend für den Grad möglichen Widerstandes.

Unternehmenskultur: Unternehmenskultur ist oft immateriell und somit schwer greifbar. Sichtbar wird sie jedoch durch den Umgang der Kollegen und Kolleginnen miteinander. Auch in dem vorherrschende Mindset einer Organisation zeigt sich die Unternehmenskultur. Wird in Teams gearbeitet oder eher isoliert? Gibt es eine etablierte Fehlerkultur? Ist Mikromanagement an der Tagesordnung oder steht die Eigenverantwortlichkeit des Mitarbeiters im Mittelpunkt? Unter anderem, kann durch die Beantwortung dieser Fragen eine Einschätzung der Unternehmenskultur gelingen und damit die Offenheit gegenüber agiler Methoden festgestellt werden.

Wie können die häufigsten Fehler vermieden werden?

Zu Beginn gilt es den Reifegrad des agilen Mindsets einer Organisation zu bestimmen. Starke Hierarchien, silogetriebene Strukturen, keine etablierte Fehlerkultur sowie wenig Eigenverantwortung der Mitarbeiter sind Indikatoren für wenig Offenheit gegenüber agilem Prozessmanagement. Hier gilt es durch methodische Unterstützung die Grundlagen für das agile Vorgehen zu legen. Anhand von Pilot Prozessen sollte das agile Prozessmanagement mit ausgewählten Mitarbeitern und Prozessen erprobt werden. Die resultierenden Learnings eingearbeitet, wird das erprobte und ggf. verbesserte Vorgehen mit der Organisation geteilt. Basierend auf den ersten Erfolgen werden weitere Prozesse hinzugezogen. Dieses inkrementelle Vorgehen, kann entsprechend der Adaptionsgeschwindigkeit der Organisation, Stück für Stück beschleunigt werden. Wichtig ist jedoch, dass zu jedem Zeitpunkt die Widerstände ernst genommen werden und proaktiv entgegengewirkt wird.

Der Autor

11.01.2018 | Verfasst von Oliver Behr und Lorenzo Peroni in Agile Methoden

Agile Methoden in ungewohnter Umgebung. Ausschreibungserstellung neu gedacht.

Agile Arbeitsmethoden haben sich bei der Entwicklung digitaler Produkte und Services durchgesetzt. Kaum noch ein Softwareentwicklungsteam verzichtet auf kurze Iterationen, Task-Boards und Retrospektiven. Doch nutzen neben der Softwareentwicklung auch andere Unternehmensteile agile Methoden und wie wird Agilität hier umgesetzt?

Der Agile Coach Lorenzo Peroni begleitet ein Projekt bei der Deutschen Bahn, bei dem agile Methoden in der Erstellung einer großen Ausschreibung genutzt werden. Oliver Behr hat Ihn zu seinen Erkenntnissen befragt.

Oli: Hallo Lorenzo! Wir sprechen heute über Agilität und zwar in einem Umfeld, das man normalerweise nicht sofort mit agilen Arbeitsmethoden verbindet. Du bist Agile Coach und hast bereits zahlreiche agile Projekte geleitet. Kannst du uns zunächst verraten, welche agilen Projekte du normalerweise begleitetest und wie du Agilität verstehst?

Lorenzo: Agilität beruht auf einem Set von Werten, die im agilen Manifest definiert sind. Menschen und deren Interaktionen stehen dabei im Vordergrund. Agilität erfordert insbesondere, dass man Offenheit und Transparenz lebt: einerseits extern gegenüber Kollegen und Partnern, andererseits gegenüber sich selbst. Es ist eine Geisteshaltung gegenüber Neuem; man erlaubt sich, Fehler zu machen, um aus ihnen zu lernen. Darauf aufbauend, gibt es zahlreiche agile Arbeitsmethoden, deren Fokus auf dynamischer Zusammenarbeit und Kundenzufriedenheit liegt. Agile Projektabläufe zeichnen sich durch aufeinander aufbauende Iterationen aus, was ermöglicht, aktiv auf Umwelteinflüsse zu reagieren und laufende Prozesse stetig zu verbessern. Am Ende einer Iteration steht immer ein Produkt, welches man einem Endkunden ausliefern könnte. Agile Methoden sind seit den frühen Neunziger Jahren bekannt und haben sich in der Entwicklung digitaler Produkte und Dienstleistungen durchgesetzt. Ich habe bisher hauptsächlich bei Entwicklungsprojekten im Softwarebereich unterstützt und dabei erlebt, wie sich Methoden wie Scrum, Kanban, DevOps, Management 3.0 und Design Thinking, etablieren.

Oli: Dein aktuelles Projekt bei der Deutschen Bahn ist jedoch nicht mit der Erstellung eines digitalen Produkts oder Services befasst. Was ist die Zielsetzung eures Projektes?

Lorenzo: Die Deutsche Bahn schreibt die Entwicklung einer Standardsoftware für die Planung und Steuerung des gesamten Fernverkehrs in Deutschland aus. Wir arbeiten seit einem Dreivierteljahr daran, hunderte Seiten Anforderungen für diese Software zu erstellen – das ist erstmal überhaupt nicht agil. Denn das agile Manifest besagt auch, dass eine schrittweise Entwicklung funktionierender Produkte (Software) für den Endkunden wichtiger ist als eine ausführliche Dokumentation. Die Devise lautet eher, auf Basis von Kundenfeedback zu einem Produkt, sich den daraus resultierenden Anforderungen anzupassen. Das sehe ich auch immer noch so. In unseren Fall gilt aber, dass wir die Software erst bekommen, wenn ein Softwareanbieter durch eine Ausschreibung ausgewählt wurde. Wir entwickeln also zunächst keine Software, sondern formulieren deren Anforderungen. Doch auch hier machen die Grundwerte agiler Methoden Sinn.

Oli: Also agile Methoden in einem eher untypischen Umfeld. Wie würdest du den agilen Reifegrad des Teams und des Managements bewerten?

Lorenzo: Sehr gemischt. Die Projektleiter arbeiteten auf ihren vorherigen Projekten in der Softwareentwicklung mit agilen Methoden, die bereits für mehrere Teams skaliert waren. Viele Teammitglieder hatten jedoch noch wenig praktische Kenntnisse agiler Methoden. Auf dieser Basis haben wir entschieden, grundlegend mit dem Framework Scrum zu beginnen und uns an den gängigen Frameworks zur Skalierung zu orientieren. Wir haben immer wieder diskutiert, was für uns sinnvoll ist, und unsere Zusammenarbeit sukzessive angepasst und erweitert.

Oli: Und welche Rolle nimmst du in diesem Projekt ein?

Lorenzo: Ich bin der Agile Coach und wirke auf Managementebene mit, um die Zusammenarbeit methodisch zu verbessern. Weiterhin unterstütze ich insgesamt 25 Personen in drei Teams, die je einen Product Owner haben, jedoch außer mir keinen Scrum Master – was wir noch ändern werden.

Oli: Woher kam denn die Motivation, dieses Projekt agil durchzuführen?

Lorenzo: Da liefen mehrere Bestrebungen zusammen. Zum einen wollten die Fachteams unbedingt agil arbeiten, zum anderen hängt dies mit dem Volumen der Ausschreibung zusammen. Durch die Komplexität der Software mit millionenschweren Entwicklungskosten und einer sehr langen Projektlaufzeit steigt auch das Projektrisiko. Zusätzlich erhöht sich die Komplexität des Projekts durch die Vielzahl an abzulösender Verfahren und tiefgreifenden Changes. Agile Methoden sind dadurch charakterisiert Risiko zu verringern, indem sie komplexe, also nicht unmittelbar steuerbare Themen in komplizierte, aber beherrschbare Einzelschritte herunterbrechen. Durch regelmäßige Feedbackzyklen und aussagekräftige Zwischenergebnisse kann man das Risiko minimieren.

Oli: In eurem Projekt entwickelt ihr die Software also nicht direkt, sondern müsst sie zunächst beschreiben. Wie ließ sich dies nun mit agilen Methoden umsetzen?

Lorenzo: Ganz am Anfang haben wir im gesamten Team eine Wissensbasis aufgebaut und in den ersten Tagen agile Methoden, insbesondere Scrum geschult, um ein gemeinsames Vokabular zu haben. Auch wenn wir Ausschreibungsdokumente erstellen, achten wir darauf, dass diese iterativ aufeinander aufbauen. Dazu definierten wir zunächst die Prozesse, welche die Software unterstützen muss, darauf aufbauend die eigentlichen Nutzeranforderungen und dann wiederum Bewertungsmatrizen und fachliche Erläuterungen. Diese Zwischenergebnisse bauen aufeinander auf und sind für sich allein bereits aussagekräftig. Wir haben für unsere Zwischenergebnisse intensiv Feedback eingefordert, um agil auf Probleme zu reagieren. Durch eine Taktung unserer Projektstruktur in Drei-Wochen-Sprints, konnten wir regelmäßig kritisch hinterfragen, ob unsere Methoden weiterhin sinnvoll sind, und Verbesserungen ausprobieren. So haben wir sukzessive ein individuelles Vorgehen für uns gestaltet, bei welchem wir jederzeit die Möglichkeit haben, agile Methoden so einzusetzen, dass sie uns am besten helfen.

Oli: Das Framework SAFe gilt als Vorreiter, wenn es darum geht, agile Methoden auf größere Strukturen anzuwenden. Gibt es Parallelen zum Vorgehen in eurem Projekt?

Lorenzo: SAFe ist ein sehr interessanter, aber auch umstrittenerer Ansatz. Er beschreibt ein Zielbild, welches sehr kompliziert ist und alle Unternehmensebenen betrifft. Das ist nicht trivial zu implementieren und zu steuern. Man kann nicht von heute auf morgen sagen: „Wir machen jetzt SAFe.“ Wir haben uns vielmehr von SAFe-Grundsätzen und -Methoden inspirieren lassen und einzelne Ansätze implementiert. Grundlegend nutzen wir eine Mischung von Kanban und Scrum, je nach Team und Anwendungszweck. Darauf aufbauend haben wir einen Agile Release Train implementiert: Wir nutzen insbesondere das „Programminkrement“, also die Abfolge mehrerer Sprints, an denen mehrere Teams zusammen an parallelen Themen arbeiten.

Oli: Was waren denn die größten Schwierigkeiten, denen du in dem Projekt begegnet bist?

Lorenzo: Es gab und gibt tatsächlich einige Schwierigkeiten. Dies betrifft vor allem die klassische Struktur eines Großkonzerns. Die Gesamtprojektleitung muss die Freiheit haben, ein agiles Vorgehen vorzuleben. Und das Team muss sich die Aufgaben zutrauen. Transparenz muss gegeben sein, damit klar wird, warum einzelne Methoden sinnvoll sind. Wenn das gegeben ist, kann man beginnen, agile Frameworks einzusetzen. Dies alles immer in dem Bewusstsein, dass es ein wenig dauern wird, bis Neuerungen voll ins Blut übergegangen sind.

Oli: Machen agile Methoden eigentlich Sinn in deinem Projekt?

Lorenzo: Definitiv. Einerseits sind die Mitarbeiter meines Erachtens deutlich intrinsisch motiviert, da sie das Gefühl haben, ihre Aufgaben selbst zu gestalten und dabei viel lernen zu können. Alle Ebenen können an den Zwischenergebnissen besser nachverfolgen, dass der Prozess uns sicher zum Ziel führt, und wir können Probleme sehr früh erkennen und reagieren. Das führte sogar dazu, dass wir ein weiteres, fast gleich großes Thema mit in unser Projekt integrieren konnten. Das Vertrauen wurde uns wiederholt ausgesprochen und wir haben das Gefühl, dass wir das meistern können.

Oli: Wäre das Ergebnis in einem klassischen Wasserfallmodellanders gewesen?

Lorenzo: Das ist schwierig zu sagen, da jedes Projekt ein Experiment ist. In einem parallelen Universum wäre das Ergebnis vielleicht sogar ähnlich gut geworden, jedoch wären die Leute vielleicht total ausgebrannt. Unseren Teammitgliedern hat die Arbeit Spaß gemacht, und der individuelle Lernfortschritt war immens. Durch die agile Projektsteuerung haben wir nun total motivierte Mitarbeiter, die sich darauf freuen, in Vorbereitung der ausgeschriebenen Software bereits erste Prozessoptimierungen in Richtung Effizienz und Qualität durchzuführen.

Oli: Wie siehst du die Zukunft solcher agilen Herangehensweisen für weitere Arten von Abteilungen und Projekten?

Lorenzo: Sehr vielversprechend! Man kann bei unserem Projekt sehr gut sehen, wie eine Zusammenarbeit in Zukunft aussehen kann. Natürlich ist Agile kein Allheilmittel. Man muss von Fall zu Fall bewerten, welche agilen Methoden am meisten Sinn ergeben. Am besten geht dies bei Produkten, die sich aus Schichten aufbauen lassen, welche einzeln bereits funktionsfähig sind. Man konzentriert sich dann auf die Bedürfnisse der Kunden und liefert regelmäßig werthaltige Inkremente. Es bedarf nur etwas Fantasie, die richtigen Anwendungsfälle zu identifizieren und etwas Mut, die Zusammenarbeit weiterzuentwickeln.

Oli: Vielen Dank für das Gespräch!