Patterns für Business Agility

Können wir alle Agile?

Ursprünglich für die Softwareentwicklung vorgesehen, hat das Manifest in den letzten Jahren eine große Verbreitung auch außerhalb dieser Domäne erlangt. Mittlerweile stellt sich jedes Unternehmen und jede Abteilung die Frage, wie es agiler werden kann. 

Dabei gibt es einige Voraussetzungen zu beachten: 

- Das agile Manifest ist für die Produktentwicklung vorgesehen. In Bereichen, wie der HR-Abteilung oder dem Vertrieb sind die Prinzipien des agilen Manifests gar nicht vollständig umsetzbar. Das heißt nicht, dass diese Bereiche nicht effektiver werden können, nur nicht mit den Standard-Methoden. 

- Alle Prinzipien gehen von Cross-Funktionalen Teams aus und von einem direkten Kontakt zu den Endkunden des Unternehmens. In klassisch aufgebauten Unternehmen mit ihren Hierarchien und Abteilungen ist diese Voraussetzung nicht gegeben. 

- Es benötigt einen Kulturwandel im Unternehmen. Teamorientierung, Übernahme von Verantwortung und Lernen aus Fehlern war in der Vergangenheit nicht sehr förderlich für die Karriere, nun ist es Voraussetzung. 

- Das Ziel von Agilität ist nicht die Effizienzsteigerung, sondern die Steigerung der Effektivität. Agilität ist ein Gegenentwurf zum Taylorismus. Dieses Ziel muss von allen verfolgt werden, vom Top-Management bis zur Reinigungskraft. 

- Die Werte des Manifests brauchen daher die Unterstützung des Managements. Dieses ist aber meist auf Effizienz ausgerichtet, nicht auf Effektivität. Ändert sich das Management nicht, ändert sich das Unternehmen nicht. 

- Die agilen Methoden sind nicht geeignet, um agil zu werden, sondern nur um agil zu sein! 

Werden die Voraussetzungen nicht beherzigt, landen wir im „Cargo-Agile“. Wir setzen die Agilität zum Beispiel für eine Effizienzsteigerung ein, bauen aber ein Produkt, das keiner haben will. Ich habe auch oft gesehen, dass nur einzelne Methoden eingesetzt werden und das im falschen Kontext. Die Folge ist Widerstand bei den Mitarbeitern oder eine Verschlechterung statt einer Verbesserung gegenüber dem Anfangszustand.
DieMethoden werden dann angepasst, bis sie nichts mehr mit Agilität zu tun haben. Sie werden so weit gebogen, bis sie brechen – und damit den eigentlichen Sinn verfehlen.

Generell gilt: Werden Methoden eingesetzt, ohne die Voraussetzungen zu beachten und ohne Klarheit darüber, wie genau was mit der Methode erreicht werden kann, können die Ansätze ihr Potenzial nicht entfalten oder sind sogar schädlich: Das Pattern wird gebrochen. 

Pattern nicht brechen 

Um diesem Dilemma zu entgehen, gibt es zwei Möglichkeiten: 

1. Bei einem vollständigen Einsatz eines Frameworks, wie Design Thinking, Scrum oder Kanban müssen folgende Dinge erfüllt sein: 

- Das Umfeld muss stimmen, also den oben genannten Voraussetzungen entsprechen 

- Die Strukturen sind ausgerichtet auf Wertschaffung (Kundennutzen), nicht auf Hierarchien 

- Die Zusammenarbeit in den Strukturen ist möglichst selbst-organisiert, iterativ und inkrementiell 

- Die Weltsicht, also die Haltung und Einstellung aller beteiligten Personen, entspricht den 4K 

- Alle verfolgen das gleiche Ziel 

Kleine Unternehmen gelingt es besser, diese Voraussetzungen zu erfüllen, als großen, schon lange existierenden Unternehmen. Deshalb wird dort oft nur in Teilbereichen agil gearbeitet, zum Beispiel in der Softwareentwicklung. Möchte ich unternehmensübergreifend agiler werden, ist daher Möglichkeit zwei besser geeignet:
 

2. Übernahme von Methoden und Tools aus den verschiedenen Frameworks („Cherry Picking“) bei Beachtung der Voraussetzungen, des ‚wie‘ und des Zwecks der einzelnen Methoden, kurz: Patternorientierung. 

Beispiel: Eine beliebte Methode aus dem agilen Werkzeugkoffer ist das Daily-Meeting, auch Standup-Meeting genannt. Es soll jeden Tag stattfinden und 15 Minuten nicht überschreiten. Gedacht ist es für ein Team von bis zu neun Personen, die gemeinsam an einem Produkt arbeiten und sich gegenseitig bei ihren Tätigkeiten unterstützen sollen. Bei einem meiner Kunden beobachtete ich zu Beginn meiner Tätigkeit, dass das Meeting nur einmal pro Woche stattfand, mi der Begründung, es gäbe ja gar nicht so viel zu bereden. Das stimmte auch. Bei dem Meeting nahm die ganze Abteilung teil, jeder Einzelne in mehreren Projekten eingebunden, nie in den gleichen Projekten, wie die anderen Meeting-Teilnehmer. Das ganze Meeting mutierte daher zu einem wöchentlichen Reporting an den Abteilungsleiter.
Kernelement des Daily-Meetings ist die gemeinsame Arbeit an genau einem Projekt. Das Team, nicht der Einzelne, ist für den Projekterfolg zuständig und man hilft sich gegenseitig, um die gemeinsamen Ziele zu erreichen. Scheitert einer, scheitern alle. In diesem Fall ist es relevant, dass jeder Projektbeteiligte weiß, was die anderen Projektbeteiligten gerade machen, wo sie Hilfe brauchen, wie man gemeinsam die Ziele erreicht. Gibt es gar keine gemeinsamen Ziele, da jeder in anderen Projekten arbeitet, kann das Meeting das Ziel einer effektiven Zusammenarbeit nicht erreichen und ist somit überflüssig, sogar Zeitverschwendung.