Agilität braucht Orientierung. Erst eine gemeinsame Ausrichtung ermöglicht effektive Autonomie und dezentrale Entscheidungen, wodurch agile Organisationen so anpassungsfähig werden. Agilität braucht aber auch gemeinsame Standards und Konventionen, damit trotz aller Unabhängigkeit die Zusammenarbeit gut gelingt. Die spannende Frage ist also nicht, ob es solche Standards in agilen Organisationen braucht, sondern wie sie sinnvollerweise entstehen und durchgesetzt werden.
Die Antwort auf diese Frage ist in traditionell funktional aufgeteilten Organisationen naheliegend und leidlich bekannt: Eine Organisationseinheit von Spezialisten wird gebildet mit dem Auftrag, Richtlinien, Standards, Prozessmodelle, Vorgehensmodelle, etc. auszuarbeiten, auszurollen und dann weiterzuentwickeln. Wenige Spezialisten erdenken mehr oder weniger im Elfenbeinturm Standards für den Rest. Denken und Handeln ist damit genauso streng getrennt wie noch zu Zeiten von Henry Ford (wo das Denken in diesem Sinne zwar noch eher beim Manager und nicht bei einer spezialisierten Einheit lag, was aber am Prinzip nichts ändert).
Standards should not be forced down from above but rather set by the production workers themselves.
Taiichi Ōno
Eine wesentliche und entscheidende Neuerung des Toyota-Produktionssystem, das Taiichi Ōno maßgeblich gestaltete, war es, Denken und Handeln wieder am Ort der Wertschöpfung zusammenzuführen. Toyota gelang es dadurch, die Produktivität deutlich zu steigern und nicht nur aus abgeschlagener Position zur amerikanischen Konkurrenz aus Detroit aufzuschließen, sondern sie sogar zu überrunden. Die Konzepte und Methoden verbreiteten sich von der produzierenden Industrie ausgehend als Lean Manufacturing in viele weitere Branchen in der Verallgemeinerung als Lean Management – auch in die IT, wo das Agile Manifest historisch und inhaltlich als Anwendung von Lean Prinzipien auf den Prozess der Softwareentwicklung gelesen werden kann.
Something is wrong if workers do not look around each day, find things that are tedious or boring, and then rewrite the procedures. Even last month’s manual should be out of date.
Taiichi Ōno
Besitzen statt mieten
Für Taiichi Ōno waren Standards die Grundlage jeder kontinuierlichen Verbesserung („Without standards, there can be no improvement.”). Ihm war aber auch klar, dass die einzigen, die diese Standards und Prozesse entwickeln und weiterentwickeln dürfen, diejenigen sind, die sie auch täglich leben. Die Rolle der Führungskraft ist dabei eine unterstützende: Es geht darum, die Mitarbeiter genau dazu zu befähigen anstatt sie zu belehren.
Genau diese Erkenntnisse aus dem Lean Management geben den entscheidenen Hinweis zur Beantwortung der eingangs gestellten Frage, wie Standards, Richtlinien, Prozesse, etc. in agilen Organisationen entstehen und weiterentwickelt werden. All das gehört eindeutig in die Hände und Verantwortung derjenigen, die damit täglich arbeiten müssen. Die Devise lautet: Besitzen statt mieten.
Wie die Aufgabe des Managers im Lean Management ändert sich mit diesem Grundsatz auch die Aufgabe der ehemaligen Zentralstellen für Standards, Prozesse, etc. Anstatt vorzugeben und zu kontrollieren geht es jetzt darum, alle direkt Betroffenen zu dieser Arbeit an den gemeinsamen Standards zu befähigen. Durch Ausbildung und Coaching einerseits und durch ein gutes Community-Management andererseits.
2 Kommentare
Hallo Marcus,
Ja!
Das ist genau auch meine langjährige Erfahrung aus agilen Organisationen, dass es so funktioniert, dass so auch Ownership an den Standards entsteht: Menschen aus verschiedenen Teams oder eben eine Community of Practice setzt sich zusammen und schreibt den ersten Entwurf der Standards, ob das jetzt z.B. eine Coding Guideline ist, oder eine grundlegende Definition of Done für alle Teams und Produkte. Dann wenden alle diese Guideline an, und von Zeit zu Zeit werden neue Erkenntnisse diskutiert, aufgenommen, und wieder in den Teams verbreitet.
Was ich auch schon erlebt habe:
Wenn Entwickler sich weigern, miteinander Standards zu setzen, dann geschieht das, wenn sie keine Spielräume in der Organisation haben, diese auch umzusetzen. Wenn sie beispielsweise bestimmte Arten von Testautomatisierung für wichtig halten, aber keine Zeit bekommen, um sie auch zu implementieren, weil sie das „wie“ nicht wirklich in der Hand haben.
Das Thema deines Artikels geht natürlich noch weit über solche entwicklungsinternen Standards hinaus. Es geht ja um Governance, Risiko und Compliance-Prozesse, die auch in vielen Firmen, wo sich die Entwicklung oder IT für relativ agil/lean hält, noch bei ganz zentralen Einheiten liegen. Da ist es besonders wichtig, dass Themen wie IT-Sicherheit, Datenschutz usw. Teil des agilen Prozesses und Teil der Verantwortung der Produktteams werden, und die zentralen Einheiten sie nur dabei unterstützen, die Anforderungen zu verstehen. Wenn sie dagegen detailliert das „Wie“ der Umsatzung vorschreiben, kostet das oft Monate auf der Timeline, ohne dass dadurch bereits neueste technische Erkenntnisse oder Lösungen zu dem Thema eingeflossen wären.
Vielen Dank für deine ausführlichen Ergänzungen! Je besser dieses „owning“ passiert desto Verantwortlicher werden die Teams und desto besser wird die Qualität. Dennoch tun sich große Organisationen mit diesem scheinbaren Kontrollverlust sehr schwer.