Dieser Artikel wurde ursprünglich auf Englisch verfasst.

Einleitung

Governance ist in aller Munde. Die erste Forderung der neuen CIO eines meiner Kunden war «mehr Governance». Ich höre ScrumMaster nach «besserer Governance» rufen, und eine grosse Organisation, die ich berate, hat festgelegt, dass Projekte erst starten dürfen, wenn eine klare Governance-Struktur definiert ist.

Aber was ist Governance eigentlich, und unterscheidet sie sich in traditionell geführten Projekten von agiler Produktentwicklung? Ich habe mich schon geraume Zeit mit dieser Frage auseinandergesetzt. Inzwischen glaube ich, etwas Klarheit gewonnen zu haben – und die möchte ich hier mit Ihnen teilen.

Dank gebührt Robert Love, Bianca Legorreta, Steffen Foldager, Jesper Boeg, Linda Stougaard Nielsen und meinem Bruder Dirk Bucka-Lassen für das Korrekturlesen und das wertvolle Feedback.

Staus

Haben Sie schon einmal auf der Autobahn im Stau gestanden und sich gefragt, was für ein Unfall weiter vorne passiert sein muss, der das alles verursacht? Ist es nicht merkwürdig, wenn der Verkehr plötzlich wieder fliesst – ohne Erklärung, ohne sichtbaren Grund dafür, dass Sie und viele andere Menschen gerade eine halbe Stunde verloren haben?

Im dichten Verkehr braucht es tatsächlich nicht viel, um einen solchen Stau auszulösen. Ein einziger Fahrer, der bremst – auch nur leicht –, kann den Verkehr dahinter vollständig zum Stehen bringen. Weil die Autos so dicht hintereinanderfahren und weil es eine Reaktionszeit gibt, muss das nächste Auto etwas stärker bremsen, das übernächste noch stärker, und kurz darauf wird notgebremst – bis zum vollständigen Stillstand.

Zusammengefasst gibt es zwei Faktoren, die in Kombination Staus verursachen:

  • eine hohe Auslastung der Strasse (Überlastung)
  • jemand, der bremst (der Fluss wird unterbrochen)

In diesem Artikel möchte ich über das Zweite sprechen: die Unterbrechung des Flusses. Die Auslastung behandle ich ausführlicher in einem separaten Beitrag.

Annahmen und Entscheide

Während eines normalen Arbeitstags trifft ein Entwickler zahlreiche Annahmen. Ich habe dazu keine wissenschaftlichen Studien gefunden, aber aus eigener Erfahrung bin ich überzeugt, dass wir von grossen Zahlen sprechen. Die meisten dieser Annahmen werden unbewusst getroffen, einige bewusst, und einige sind schlichtweg Entscheide.

Jede Annahme birgt das Risiko, nicht optimal zu sein. Was ich damit meine: Wenn wir stets die bestmöglichen Annahmen träfen, würden wir auch das bestmögliche Produkt erhalten (in kürzester Zeit). Wann immer wir nicht bei diesem bestmöglichen Produkt landen, liegt es daran, dass wir unterwegs suboptimale Annahmen getroffen haben.

Lenkrad Egal wie gut wir das zu bauende Produkt spezifizieren – wir wissen, dass während der Entwicklung Fragen beantwortet und Entscheide gefällt werden müssen. Deshalb richten wir Steuerungsprozesse ein, um die bestmöglichen Entscheide zu gewährleisten – zum Beispiel durch die Einrichtung von Lenkungsausschüssen. Der Begriff «Governance» stammt vom griechischen Verb κυβερνάω, was «ich steuere» bedeutet. Das macht also durchaus Sinn, oder?

Agile Governance

Ich stimme zwar zu, dass gute Governance die Erfolgswahrscheinlichkeit erhöht, aber ich glaube, dass viele Menschen Governance falsch verstehen. Für eine Führungskraft geht es nicht darum, selbst das Steuer in die Hand zu nehmen – es geht darum, das Team fahren zu lassen und selbst nur dann korrigierend einzugreifen, wenn es wirklich nötig ist.

Governance bedeutet, zu steuern, wenn es nötig ist – aber auch nur dann. Es ist wie bei einem selbstfahrenden Auto. Es hat noch ein Lenkrad und Bremspedale. Sie lassen es fahren, beaufsichtigen es aber (vorläufig) und prüfen, ob alles in die erwartete Richtung läuft. Wenn etwas schiefgeht, greifen Sie ein.

Der traditionelle Entscheidungsprozess erzeugt Stop-and-Go-Wellen, genau wie im Strassenverkehr. Das führt zu Staus (sofern wir auch Überlastung haben – was ich hier vorerst voraussetze und verspreche, in einem späteren Beitrag zu behandeln), und Staus bedeuten, dass wir uns unglaublich langsam vorwärtsbewegen – was für die meisten Menschen sehr stressig ist. Der Fluss ist zerstört. Es spielt keine grosse Rolle, wie häufig das Change-Review-Board tagt oder wie erreichbar die Projektleitung ist: Wenn ein Entwickler eine Frage stellt und keine sofortige Antwort erhält, muss er die aktuelle Aufgabe beiseitelegen und mit etwas anderem anfangen.

Auch Scrum-Teams sind nicht immun dagegen. Ich sehe viele unerfahrene Teams, die kämpfen. Sie tun alles nach Lehrbuch und sehen trotzdem nicht ansatzweise etwas, das dem verheissenen Land der Hochproduktivität gleicht. Der Grund ist oft ein Mangel an Fluss. Sie halten an der Gewohnheit fest, Vorgesetzte – einen erfahrenen Entwickler, einen Architekten, den Product Owner oder einen Stakeholder – um Entscheide zu bitten, wann immer die geringste Unsicherheit besteht.

Häufige Lieferungen in die Produktion eröffnen neue Möglichkeiten

Was viele nicht begreifen: Wenn wir Produkte auf agile Weise entwickeln und damit oft und früh in die Produktion liefern, können wir uns leisten, weniger sicher in unseren Annahmen zu sein. Wir brauchen nicht alle Fakten auf dem Tisch, um den bestmöglichen Entscheid zu treffen.

Agile Governance bedeutet leiten, nicht entscheiden _«Werden die Benutzer es so oder so wollen? Ich weiss es nicht, und ich könnte fragen gehen – aber ich könnte auch jetzt einen Entscheid fällen und ohne Unterbrechung weiterarbeiten. In ein paar Tagen, wenn die Benutzer das Produkt sehen, werde ich erfahren, ob ich richtig lag oder nicht – und selbst wenn ich falsch lag, lässt es sich schnell korrigieren.»_

Je kürzer die Zeitspanne, bis man herausfindet, ob die Stakeholder mit der Richtung der Produktentwicklung einverstanden sind, desto praktischer ist es für die Entwickler, selbst Entscheide zu treffen – desto mehr Fluss entsteht und desto höher ist die Produktivität.

Was bevorzugen Sie: sechs von sechs neu entwickelten Features am Sprintende akzeptiert, oder acht von zehn?

Wenn ich Teams sehe, bei denen 100 % der implementierten User Stories am Ende des Sprints akzeptiert werden, provoziere ich sie oft, indem ich sie bitte, diese Zahl zu senken. Alles jedes Mal richtig zu machen kann (muss aber nicht) ein Hinweis darauf sein, dass das Team entweder zu viel Vorarbeit leistet und/oder während des Sprints zu viele Fragen stellt, um sich zu vergewissern, dass alles stimmt.

Transparenz ist entscheidend

Transparenz ist einer der Grundpfeiler von Scrum. Sie ermöglicht es den Steuerungsorganen, den Überblick zu behalten. Das Product Backlog, die Reviews und die generelle Einbindung von Stakeholdern, die auslieferbaren Produktinkremente – all das fördert Transparenz und ermöglicht es uns, ein gutes Verständnis davon zu behalten, ob das Produkt sich in die richtige Richtung entwickelt.

Transparenz ist entscheidend Am Anfang wird das Management sehr aufmerksam sein und ein sehr hohes Mass an Transparenz einfordern und häufig nutzen – genau wie Sie es vermutlich bei Ihrer ersten Fahrt in einem selbstfahrenden Auto täten. Sie würden nicht Zeitung lesen, oder? Nach einer Weile werden Sie sich jedoch zunehmend wohler dabei fühlen, kleinere andere Dinge zu erledigen, und kurz darauf befassen Sie sich möglicherweise mit Dingen, die Ihre volle Aufmerksamkeit erfordern – und überprüfen nur noch gelegentlich, was das Auto tut und wohin es fährt.

Das ist agile Governance! Das Team erhält die Befugnis, das Produkt nach bestem Wissen und Gewissen zu entwickeln, und Sie als steuerndes Organ behalten die Dinge im Blick.

Steuern bedeutet nicht, Entscheide zu treffen – es bedeutet, sicherzustellen, dass die richtigen Entscheide getroffen werden.

Wenn Ihnen das gelingt, haben Sie einen weiteren Schritt in Richtung Hochproduktivität gemacht.