Von "Doing Agile" zu "Being Agile"

Schon wieder kurz vor den Sommerferien - unglaublich wie die Zeit rennt. Und ich habe mein Versprechen nicht halten können, öfter kurze Artikel zu schreiben. Damit ich nicht mit einem schlechten Gewissen in die Ferien gehe, will ich gerne ein paar Gedanken teilen.

Gemeinsam mit Rick Janda durfte ich an der LAS’22 einen gut besuchten und bewerteten Beitrag zu “Scaling Agile” leisten. Und auch in diesem Rahmen wurden Fragen gestellt zu was immer mehr zu interessieren scheint: man hat ein agiles Framework eingeführt und - Überraschung - nichts wurde besser. An dieser Stelle schreiben dann viele Autoren von den Klippen und Hürden auf Mitarbeiterebene. Das ist mit Sicherheit eine Baustelle - aber Leute, ernsthaft jetzt: die grössere Baustelle befindet sich meiner Meinung nach einige Etagen weiter oben.

Ich will an dieser Stelle gar nicht bestreiten, dass es Mitarbeiter gibt, die wissen, welche Antwort man geben muss, um dann dennoch nach anderen Prinzipien zu handeln (Gemba würde hier mehr bringen als ein Interview :)). Das wissen andere aber auch. Und wenn wir ehrlich sind ist der Einfluss auf den Erfolg eines agilen Modells beispielsweise auf Teamebene nur auf die vom Team direkt beeinflussbaren, resp. im Team bekannten Inhalte beschränkt. Zusätzlich funktioniert im Team eine gegenseitige “Begleitung” (man könnte auch Kontrolle sagen) meist relativ gut.

Deswegen - mindestens aus meiner Sicht - kann eine Person im Top Management bewusst oder unbewusst weiterhin gegen ein funktionierendes agiles Modell arbeiten. Und zwar beispielsweise wie folgt:

• Das Management lässt Inhalte von hierarchischen Rollen (z.B. Head of’s) anstelle von den Ablaufrollen (z.B. PO) erarbeiten
  Ein Ziel von Agilität ist, dass Bedarf und Kapazität in ein grobes Gleichgewicht kommen - und ein zweites, dass die Verantwortung für ein Produkt in ein (interdisziplinäres) Team delegiert wird. Solange ein “Head of” keinen Anreiz dafür hat, dieses Gleichgewicht herzustellen (d.h. Leute anders einsetzen, umschulen, “nicht das eigene Gärtchen pflegen”, etc.) oder die Verantwortung für ein Produkt in ein Team abzugeben, kann die Verantwortlichkeitsmatrix nicht vereinfacht werden.

• Das Management hält sich nicht an die vereinbarten Prinzipien
  Erneut: ob bewusst oder unbewusst sei hier gar nicht die Frage. Fakt ist, dass es nicht zu Einfachheit beiträgt, wenn man als “Head of” entscheiden kann, sich frei von Konsequenzen nicht an Prinzipien zu halten. Und das oft, obwohl man von einem Heer von (teuren) Agile Coaches begleitet wird. Solange Prinzipien nicht niedergeschrieben, verabschiedet und verbindlich gemessen werden, habe ich als “Head of” keinen Anreiz, mich anders zu verhalten. Das bringt uns auch gleich zum nächsten Punkt.

• Das Management verlangt keine Veränderung - “act your way to a new way of working”
  So lange Prozesse und Vorgesetzte ein Abweichen von einem agilen Modell tolerieren, wird keine oder nur ungenügende Veränderung eintreten. Was das sein könnte? Nun… Steerings gehören meiner Meinung nach abgeschafft, weil dort nur wieder Aufträge quer zur Ablauforganisation durch die Räume geistern. Boards für “Show & Dance” machen keinen Sinn, wenn dort “nur” Line Management sitzt. Auch hier ist die Versuchung gross, Aufträge vorbei an der Ablauforganisation mitzugeben / mitzunehmen. Es hilft übrigens auch nicht, gleich von Beginn weg sein eigenes agile Framework aufzusetzen - es wäre meiner Meinung nach viel sinnvoller, sich von einem Framework zu emanzipieren, sobald man es einmal zum Funktionieren gebracht hat.

• Das Management hat “Inverse Taylor” nicht konsequent umgesetzt
  Einige Bereiche sind weiterhin tayloristisch aufgestellt, andere bereits in einem interdisziplinären Team. Der Klassiker ist dabei aus meiner Sicht, dass das Team nach Taylor die Konzepte / Produktideen schreibt (nicht die Problemstellung / Benefit Hypothese) und an das interdisziplinäre Ablaufteam zwecks Umsetzung übergibt. Ich kann es nicht genug betonen: ein agiles Team als Delivery einzusetzen macht wirklich wenig Sinn, wenn man agil arbeiten will.

• Das Management hat “Respond to change” als Versprechen von Agilität falsch verstanden
  Natürlich kann man im agilen Zusammenarbeitsmodell rascher auf Veränderung reagieren - weil man beispielsweise in kurzen Iterationen entwickelt und die Ergebnisse dieser Iterationen rasch auf den Markt bringt. Das bringt aber nichts, wenn ich ein riesiges Vorhaben in Iterationen aufteile und doch erst nach “Lieferung” von allen Iterationen an den Markt gehe. Und es bringt erst recht nichts, wenn die Anforderungen für dieses riesige Vorhaben alle drei Wochen ändern, obwohl bereits entwickelt wird. Das ist nicht “respond to change”, sondern “watch money burn”.

• Das Management nominiert vertraute “Dinosaurier” als agile Rollenträger
  Wenn man es nun mal nicht anders kennt, kann man eben auch nicht anders. Und wenn ich dann diese Dinosaurier noch mit Rollen versehe, in welchen die Veränderung federführend getrieben werden sollte, sollte ich mich nicht wundern, dass wenig bis nichts passiert. Oder dass über die Zeit aus einem agilen Konstrukt ein hocheffizienter Projektladen geworden ist, sodass ich mich als Manager wieder wundere, was denn an der agilen Arbeitsweise anders sein soll im Vergleich zu bisher und den Rückschritt gar nicht bemerke.

• Das Management weiss es besser (aka “Micromanager”)
  Zugegeben, ich glaube auch , dass nur mit mir Dinge einfacher / klarer / erfolrgeicher werden. Es ist halt einfach cool, das Gefühl zu haben, fähiger als alle anderen zu sein. Wenn es dann aber so weit geht, der Einfachheit der Lösung mehr Platz einzuräumen als der Nachhaltigkeit der Lösung, entspricht das eher dem Lebensmotto “nach mit die Sintflut”. Dass das dann zu gebauten Lösungen führt, die im Lifecycle dann behoben / verändert / abgelöst werden müssen ist egal - es hat ja keine Konsequenzen. Resp. meistens ist dann einfach die IT schuld, weil es ja nicht so funktioniert, wie ich es im Powerpoint gezeichnet hatte. Ah, guter Übergang zum nächsten Punkt.

• Das Management handelt tendentiell pragmatisch, wenn nicht sogar opportunistisch
  Mein Lieblingsthema. Man entscheidet nicht für das, was richtig ist, sondern das, was gerade dringend scheint. Auch hier: natürlich muss es für solche Dinge Platz haben. Dennoch scheint man nicht bereit zu sein zu investieren, sondern will für sein Geld möglichst viele Themen parallel machen. Geht auch ein bisschen ins Thema “Flusseffizienz vs. Ressourceneffizienz”, aber noch viel mehr in falschen Opportunismus und Pragmatismus. “Es funktioniert ja” ist dann meistens die Antwort - wobei ich jeweils fragen würde, ob es denn richtig ist…

Bitte versteht mich richtig: ich sage nicht, dass es keine Hierarchien mehr braucht. Aber ich glaube sehr, dass die klassischen Hierarchien überholt sind und es für einen funktionierenden Ablauf eigentlich keine klassischen Hierarchien mehr braucht. Ich gehe sogar so weit, dass ich behaupte, dass die klassischen Hierarchien - die im Rahmen der agilen Transformation selten bereinigt oder gar beseitigt werden - einen Grossteil der Schuld daran tragen, dass der Schritt von “doing agile” zu “being agile” nicht funktionieren wird.

Die nicht-agile Organisation schlägt zurück

Was mich und meinen Idealismus ja immer nervt ist, dass es eben eine Wellen- oder Pendelbewegung gibt. Wie bei “Star Wars” - mal haben die Jedi Oberwasser, kurz darauf wieder die Sith. Und ich hätte auch nichts dagegen, wenn diese Wellenbewegungen knappe drei Stunden dauern würden wie so ein Blockbuster. Aber in Tat und Wahrheit sind es für einen Idealisten, der glaubt zu wissen wohin der Weg geht um einen effizienten und effektiven Zielzustand zu erreichen, energiekonsumierende Wochen bis Monate. Noch viel unvorstellbarer als die Zeit und Energie, die es braucht einen Karren in der Spur zu halten ist die Bereitschaft einer Organisation, den einfacheren Weg (d.h. wenig Transformation, mehr “wir machen das so, es war ja bisher immer erfolgreich”) zu wählen. Das Interessanteste daran ist, dass sich alle als “die Guten” wähnen - was aus Sicht des Standpunktes auch Sinn macht. Die einen wollen die Gegenwart möglichst ideal gestalten, die anderen die Zukunft.

Ein guter Kollege und ich tauschen uns regelmässig über die Bereitschaft in unserer jeweiligen Organisation aus um Veränderung herbeizuführen. Während die Unterschiede in den Voraussetzungen gross sind, sind die Reaktionen auf Veränderung genau gleich. Die Utopie, dass alle glücklich sind mit Veränderung, habe ich bereits vor langer Zeit über Bord geworfen. Die Reaktionen lassen sich nicht verhindern - aber man kann die Grundlagen schaffen, dass aus Reaktionen keine oder nur geringe Gegenbewegungen ausgelöst werden. Ich habe aus meiner Sicht notiert, welche Voraussetzungen am effektivsten sind:

• Zunächst braucht es ein - von Vorteil in der Geschäfts- oder Bereichsleitung - gut verankertes Verständnis für die Notwendigkeit einer Veränderung. Ist diese Voraussetzung nicht gegeben, würde ich nicht starten. Die Unternehmensziele wie auch die Strategie müssen die Veränderung begünstigen um auf Arbeitsebene das Zeichen “anders als bisher” zu setzen. Dieses “anders als bisher” kann mehrere Dimensionen betreffen: Verhalten, Belohnungskriterien (Bonus), Fokus auf Outcome statt Output, etc.. Gut wäre dann natürlich, wenn man das “andere” konsequent leben und fördern würde, auch in Stressmomenten.

• Um von Beginn an zu verstehen, wie ein neuer Ablauf aussehen soll, macht ein konkretes Zielbild im Sinne eines Ablaufmodells viel Sinn. Vgl. dazu unten in Abb. 1 meinen Wurf, wie so etwas ab Portfolio Ebene und nur für den “PI Preparation" Teil aussehen könnte, inkl. SAFe Rollen, (Inter-)Kanban Rules, etc.. Das kann als Bild natürlich nicht einfach so stehen gelassen, sondern muss dringend auf der Tonspur begleitet werden. Der Vorteil an solchen Bildern ist auch, dass man einzeichnen kann, wo es eben noch nicht so läuft wie es sollte.

Abb. 1: möglicher Ablauf im Sinne eines Vorwärtsprozesses

• Und wenn das alles mal “safe enough to try” ist, legt man los und nimmt die restliche Organisation mit auf den Weg und in die Pflicht. Es wird bestimmt mehr als eine Gruppe geben, die im Unternehmen etwas zu “Transformation” kommuniziert und vom Unternehmen Veränderung verlangt. Die Unsicherheit, ob die verschiedenen Gruppen wirklich auch dieselben Prinzipien, Strukturen, Schlüsselbotschaften kommunizieren gilt es zu beachten, vernünftig zu alignieren und zu fokussieren. Das gelingt visuell gut mittels einer einfach gehaltenen “High Level” Transformationskarte. Darauf kann dann auch verortet werden, wo man gut oder weniger gut unterwegs ist. Vgl. dazu Abb. 2

Abb. 2: ganz einfach gehaltene “Transformation-Map”

• Dann macht es wenig Sinn, Don Quijote zu sein. Transformation verlangt viel Unterstützung, beispielsweise durch eine “Chief Transformation Officer” Rolle aus der Geschäftsleitung. Bestenfalls ist das sogar der CEO. Aus meiner Sicht sind die meisten Menschen so lange mit Veränderung einverstanden, bis es sie selber betrifft. Insbesondere in der “Lehmschicht” auf bestimmten Management-Stufen immer wieder gut und offensichtlich spürbar. Drum: man muss Verweigerer aus dem Management übersteuern können und nicht für jeden Manager wird es in einer veränderten Organisation noch eine Rolle geben.

• Es braucht auch eine ideale Besetzung der neuen agilen Rollen. Ich hatte jüngst eine sehr gute, kurze Diskussion mit einer Kollegin, die sagte “agile Coaching ist am System”. Sie hat recht. Grosses UND, das eigentlich ein ABER ist: die Veränderungstreiber, die am System arbeiten, sind dann effektiv, wenn die Saat auf fruchtbaren Boden (aka die Menschen im System) fällt. Ist das nicht der Fall, bleibt nichts anderes übrig, als die Change Agents - Menschen mit dem Mut und dem Drang, mit bisherigen Konventionen zu brechen - ins operative System zu bringen. Und genau das ist der wichtige Punkt: man kann nicht den Bock zum Gärtner machen. Es braucht frischen Wind und Menschen mit der Bereitschaft, Dinge zu verändern und nicht die Personen, die in den neuen Rollen dasselbe tun wie bisher und agile Transformation behindern. Die Change Agents kennen und sie in die relevanten Rollen befördern - das ist der Schlüssel für “Veränderungsdrang aus dem System heraus”.

• Und zu guter Letzt folgt dann die Dezentralisierung von Entscheiden, womit man endgültig in der Veränderung der Firmenkultur angekommen ist. Nun entscheidet sich, ob sich Boards und Steerings auflösen oder ob sie bestehen bleiben und weiterhin inhaltliche Entscheide fällen. Vermutlich ist das hier die schwierigste Veränderung, weil Menschen nun merken, dass sie Macht teilen oder sogar ganz abgeben müssen - und damit wohl nicht unbedingt einverstanden sind.

Die oben genannten Kriterien sind aus meiner Optik in einer Sequenz abgebildet. Ist ein Punkt nicht gegeben, müssen die Grundlagen dafür aus dem vorherigen Punkt geschaffen werden. Ist das nicht der Fall, hat die “nicht-agile” Organisation zu viel Kraft und wird - wissentlich oder nicht - mit ihrem Verhalten dafür sorgen, dass die Wogen extremer auf und ab gehen und einen grossen Beitrag leisten, dass ein Unternehmen in einer Art “Transformationsspirale” gefangen wird und für den zu gehenden Weg noch viel mehr Zeit (und Ressourcen) investieren muss. Fairerweise: es ist nicht einfach, loszulassen und mit seinem eigenen Arbeitseinsatz dafür zu sorgen, dass es die eigene Rolle schneller nicht mehr braucht. Auf der anderen Seite sind das die KeyPlayer, die eigentlich immer eine Rolle im Unternehmen finden sollten. Wobei “finden” hier nicht der richtige Ausdruck ist - warum sollten sie denn überhaupt suchen? Das Unternehmen muss bereit sein, genau diesen Leuten einen Entwicklungspfad zu bieten und sie zu behalten.

Böse sein hilft der agilen Transformation

Es ist wieder Freitag und ich habe etwas Zeit gefunden, um euch die agile Welt zu erklären. Heute sind wir mal böse. Also unflexibel. Zwar eher konsequent. Oder regeltreu. Sicher nicht pragmatisch. Es kommt ein bisschen auf die Sichtweise darauf an. Man kann auch sagen: heute verstehen wir, warum “nein, nicht jetzt” zu sagen deutlich agiler ist als “ja, wir finden einen Weg”.

Wir beginnen den heutigen Text mit dem Aufzählen einiger Vorteile von Agilität und schauen uns danach an, warum es eben “gut ist, böse zu sein”. Die angekündigten Vorteile sind aus meiner Sicht: Flusseffizienz, Limitierung “Work in Progress” und freie Kapazität für Freigeister.

Stellt euch also vor, dass eure Kapazitäten belegt sind und euer Chefchefchef (damit es auch wirklich viel Mut braucht) zu euch kommt und sagt “mir ist egal, wie ihr es macht, aber Vorhaben A muss zusätzlich geliefert werden”. Diejenigen unter euch, die meinen Blog schon länger verfolgen, haben bestimmt erkannt, dass der Chefchefchef keine Ahnung von Agilität hat - wer spricht denn schon von “liefern”, wenn es keine Delivery mehr gibt… Auf jeden Fall geht’s für einmal nicht um die agile Maturität von Linienvorgesetzten, sondern um eure Reaktion auf die Anfrage (oder Nötigung?). Es gibt zwei Varianten: entweder ihr seid ein “Servant” (übers. “Knecht”) oder ein “Leader” (übers. “Anführer”) - Achtung, Wortspiel! SAFe spricht ja von “Servant Leader” als festem Begriff, meint aber was ganz anderes (SAFe Beschreibung der Scrum Master Rollen). Hach, ich bin so geistreich heute. Hoffentlich lacht jemand mit mir…

Als “Servant” könnte der Dialog ungefähr so ausfallen:

CCC (Chefchefchef): “Mir ist egal, wie ihr es macht, aber Vorhaben A muss zusätzlich geliefert werden“
Servant: “Ja, wir können das aufnehmen, müssen dafür aber an anderen Orten den Inhalt reduzieren, damit es noch Platz hat. Das bedeutet, dass sich andere Vorhaben verschieben.”
CCC: “Wie viel Mehrbudget braucht ihr, damit wir nichts verschieben müssen?”
Servant: “CHF 1mio”
CCC: “Gekauft”

Wir begegnen einigen Problemen. Einerseits hat der Servant das Rückgrat und sagt wenigstens, dass zusätzlicher Inhalt zu reduziertem Inhalt an anderem Ort führt. Blöd ist, dass er dem CCC gezeigt hat, dass Kapazitätsprobleme in erster Linie wie früher über mehr Budget statt über klarere Prioritäten gelöst werden können. UND der Servant hat auch das Problem, dass er sich mit dem zusätzlichen Budget gerade das Gleichgewicht zwischen “Refinement” und “Implementation” Kapazitäten aus dem Gleichgewicht gebracht hat. Unschön. Das wird der Servant nicht wieder los…

Eine andere Möglichkeit des Dialoges wäre der Folgende, erneut mit einem “Servant” in der Rolle des Gatekeepers.

CCC: “Mir ist egal, wie ihr es macht, aber Vorhaben A muss zusätzlich geliefert werden“
Servant: “Ja, wir können es als “Stretch” aufnehmen und mindestens ein Konzept auf die Beine stellen. Falls es nicht im gleichen “Program Increment” (PI) für eine Implementierung reicht, sind wir dann schneller im nächsten PI.”
CCC: “Gut”

Ach du meine Güte, die Konzepte sind zurück und sie werden sogar als Geschwindigkeitsgewinn verkauft. Und der Brüller ist, dass CCC das auch noch glaubt. So gut. Die haben beide noch etwas zu wenig verstanden. Es bringt nichts, ein Konzept vorzubereiten und im übernächsten Program Increment umzusetzen - man wäre nämlich genau gleich schnell, wenn das Konzept dann vorbereitet würde, wenn es dann auch gleich umgesetzt werden kann. Und der gute Servant vergisst, dass nicht er derjenige ist, der ein “Stretch” definiert, sondern die Teams im PI Planning. Man soll keine solchen Versprechen abgeben, für die man danach viel Energie aufwendet um das Gesicht nicht zu verlieren.

Und jetzt sind wir böse. Wie geht ein “Leader” das Gespräch an?

CCC: “Mir ist egal, wie ihr es macht, aber Vorhaben A muss zusätzlich geliefert werden“
Leader: “Vorhaben A wurde nicht priorisiert.”
CCC: “Das ist mir egal, ich möchte pragmatische Lösungen.”
Leader: “Wir können Vorhaben A mit einem bereits priorisierten Vorhaben tauschen - welches ist weniger wichtig?”
CCC: “Warum ist es nicht möglich, ein einziges, zusätzliches Vorhaben aufzunehmen und zu liefern?”
Leader: “Unsere Kapazitäten sind voll. Wenn wir ein Vorhaben zusätzlich aufnehmen, führt das zu einer Verlangsamung aller anderen priorisierten Vorhaben (aka “Flusseffizienz”), zu Überbuchung der Kapazität, die wir für Experimente vorgesehen haben (aka “freie Kapazität für Freigeister”) und zu mehr “Task Switching”, wodurch wir in der Erarbeitung der einzelnen Vorhaben an Effizienz einbüssen (aka “Limitierung Work in Progress”)”
CCC: “… heisst das jetzt nein…?”
Leader: “nein, es heisst nur “nicht jetzt””

Spannend. Hier hat jemand entweder gerade seinen Job verloren oder seiner Linienorganisation spürbar erklärt, wie Agilität funktioniert. Ich lege meine Hand ins Feuer, dass Unternehmen mit konsequenten Leadern rascher transformieren als solche mit pragmatischen Servants. Mein persönliches Verständnis von “Transformation” ist, dass ihr euer Handeln so anpassen müsst, dass die Zusammenarbeitsprozesse eine Transformation verlangen. Tut ihr das nicht, gehört ihr zu den Menschen, die auf die anderen zeigt und sagt “die Chefetage macht einfach nicht mit” ohne zu verstehen, dass ihr selber die Ursache dafür seid.

Kanban effektiv und effizient nutzen

Wie schnell die Zeit vergeht… Es ist nun bald ein Jahr her, seit ich den letzten Blogartikel geschrieben habe. Das bedeutet jetzt natürlich zweierlei: ich hatte andere Prioritäten mit der Geburt der dritten Töchter (ja, wir können nur Mädchen :)) UND ich habe in diesen Monaten so viel Neues gesehen und gelernt, dass ich wieder viel Futter für neue Blogs habe. Die werden jetzt wieder in regelmässigeren Abständen erscheinen - auch weil es mit an Sicherheit grenzender Wahrscheinlichkeit keine vierte Tochter geben wird.

Wir machen uns wie vor dem Sport zuerst locker mit einer Aufwärmübung. Wir schauen uns zuerst mal ein Kanban (vgl. dazu Wikipedia) und die Vorteile eines Kanbans an. Für alle, die bereits jetzt ins Schwitzen kommen, weil sie den Begriff noch nie gehört haben: ihr braucht mehr Ausdauer! Zurück zum Thema. Wikipedia schreibt, dass ein Kanban eine Methode zur Produktionsprozesssteuerung ist und natürlich von Taiichi Ono und Toyota stammt.

Nun, so ein Kanban ist aus meiner persönlichen Sicht enorm wertvoll aus den folgenden vier Gründen (und wahrscheinlich noch viel mehr als nur diesen vier):

• Möglichkeit, um Ideen, die aktuell keine Priorität haben oder für die es momentan keine freie Kapazität gibt aufzunehmen und zu dokumentieren, damit nichts vergessen geht. Wir nennen diesen Status in diesem Blog einfach mal “Funnel”. Die Profis unter euch merken jetzt, dass ich von SAFe her komme…

• Chance, die bereits in Bearbeitung befindliche Arbeit innerhalb einer Organisation jederzeit transparent zu halten - bestenfalls unterteilt in “Design”, “Umsetzung” und “Validierung” oder ähnlich

• Auswertungen zu Durchlaufzeiten, Messpunkte zu agilen Prinzipien (z.B. nur so viele Vorhaben starten, wie abgeschlossen wurden) oder Daten über die Dauer bis Ideen kompostiert werden - aus einem professionell geführten Kanban liest man so ziemlich alles. Auch Dinge, die man vielleicht lieber nicht hören wollte

• Man kann verschiedene Kanban untereinander in eine Reihenfolge bringen und den gesamten Produktionsinhalt damit steuern

Nun bringt ein Kanban aber nur dann die genannten Vorteile, wenn man ein Kanban auch richtig nutzt. Aus Erfahrung hier schon mal eine kleine Hand voll guter Anwendungsprinzipien, hoffentlich einfach erklärt. Ich fokussiere auf den aus meiner Sicht komplexeren Teil der “Designphase” (oder Refinement):

• Verschiedene Kanban Items
  Für diesen kurzen Blogbeitrag vereinfachen wir und sprechen nur gerade von den Kanban für “Portfolio Epics” (strategische Vorhaben), “Capabilities" (Beitrag eines Solution Trains für ein PI), “Features” (Beitrag eines Agile Release Trains für ein PI) und Stories (Beitrag eines Teams für maximal einen Sprint). Alle diese Items werden in voneinander abhängigen, aber verschiedenen Kanban geführt.

• Verschiedene Kanban für verschiedene Flughöhen / Reifegrade
  Ich gehe so weit, dass ich Folgendes behaupte: wer die oben genannten, verschiedenen Kanban nicht in über einen mit transparenten, einfachen Regeln strukturierten Prozess führt (vgl. dazu Abbildung 1), landet über kurz oder lang im Chaos.
  Ich habe mehrfach erlebt, dass beispielsweise Features gestartet wurden, ehe auf einer übergreifenden Ebene überhaupt ein gemeinsamer Zielzustand definiert wurde. In solchen Momenten werden Kanban zurecht belächelt: wenn sie nicht nach klaren Regeln gemanagt werden, führen sie zu weniger statt zu mehr Klarheit, zu Mehraufwand statt zu Flusseffizienz. Das ist zu vermeiden.

• Klarheit zu “Definition of Ready” für Statuswechsel
  Ein Epic kann nicht erst dann nach “Analysis” gehen, wenn ein Prototyp gebaut ist - das macht keinen Sinn. Jedes Kanban Item und damit auch jedes Kanban hat eine flughöhengerechte Zielstellung.
  Beispielsweise soll ein Portfolio Epic eine Problemstellung abschliessend klären, ehe es in einem gemeinsame Refinement-Termin (“Acknowledged”) mit den betroffenen Ablauforganisationen besprochen wird. Haben die Ablauforganisationen definiert, ob sie zur Lösung der Problemstellung etwas beitragen müssen, wird in einer nachfolgenden Workshop Serie eine erste Lösungsidee inkl. High Level Roadmap gemeinsam definiert (“Analysis”). Danach nehmen die beteiligten Ablauforganisationen die Arbeit an ihrem Beitrag für das nächste PI Planning auf (Wechsel auf Capability- oder Feature-Ebene) und beginnen die detailliertere Ausarbeitung.

• Limitierung von “Work in Progress”
  Mitunter eines der beiden wichtigsten Prinzipien. Man kann zwar extrem viel in einem Kanban abbilden, aber der Sinn dahinter ist, nur die Items in Arbeit zu haben, die auch innert nützlicher Frist und mit der vorhandenen Kapazität abgearbeitet werden können. Es ist kein Erfolg, wenn ein Item 365 Tage lang im Status Analysis versauert - das wird man noch einmal in die Hand nehmen müssen, weil niemand mehr weiss, was vor einem Jahr beschlossen wurde.
  Mit drei Kindern weiss man übrigens teilweise auch nicht mehr, was man gestern wem versprochen hatte…

• Pull- statt Push-Prinzip
  Mein absolutes Lieblingsthema - weil es den Graben zwischen “bisheriger” und “agiler” Arbeitsweise am besten zeigt. Während ein Management weiterhin Vorhaben vorbei am WIP Limit ins System drückt und dann doch erstaunt ist, dass es zu Verzögerungen kommt bei mehreren Vorhaben, das ist teilweise schon Situationskomik. Deswegen hier nochmal das kurze Plädoyer:

  • Die Ablauforganisation zieht die priorisierten Vorhaben gemäss vorhandener Kapazität - ist keine Kapazität vorhanden, wird auch nichts gezogen

  • Es bringt wenig bis nichts, mit mehr Budget die Kapazitäten zu erhöhen - es ist wesentlich sinnvoller, klare Prioritäten zu setzen, damit die Ablauforganisation weiss, welches Vorhaben als nächstes gezogen werden soll und dank der klaren Prioritäten die Zukunft bzgl. Skillbedarf gut zu planen um Engpässe zu vermeiden

  • Wer “pusht” bringt das System aus dem Gleichgewicht und beweist, dass schlecht priorisiert wurde, resp. gesetzte Prioritäten nicht gelten. Was auf den ersten Blick pragmatisch aussieht ist maximal destruktiv. Sowohl im System als auch gegenüber den Menschen in punkto Wertschätzung (für den Einsatz) und Motivation. Natürlich darf man dann mangelnde Belastbarkeit vorwerfen - aber auf Basis der eigenen Unfähigkeit für klare Prioritäten zu sorgen den anderen vorzuwerfen, sie seien nicht belastbar genug (Stichwort “drei Töchter”), ist aus meiner Optik zu dick aufgetragen. “Work-Life-Balance” gilt auch und insbesondere in agilen Systemen

  • Wer Leute beseitigt, die “nein” sagen, beseitigt die Leute, die für ein agiles Arbeiten essentiell sind

  • Wer der Ablauforganisation nicht vertraut, dass Vorhaben gezogen werden, sobald Kapazität vorhanden ist, arbeitet unabsichtlich daran, dass die Firmenkultur nie den agilen Nährboden bieten wird, den die Organisation bräuchte um die Früchte der Agilität zu ernten

Ihr seht und merkt, dass ein Kanban einerseits eine riesige Chance bietet um so viele Bälle gleichzeitig in die Luft zu werfen, wie man auch fangen kann. Ihr seht andererseits, dass es eine kleine Wissenschaft ist, ein Kanban System einer Firma in ein Gleichgewicht zu bringen - und auch da zu behalten.

Abbildung 1: Erst wenn das gemeinsame Refinement zu einem Portfolio Epic stattgefunden hat, darf mit der Ausarbeitung einer zugehörigen Capability begonnen werden. Die Steuerung des Status “Ready4PI Planning” erfolgt “bottom up”. Erst wenn eine erste Story wirklich bereit für das PI Planning ist, können die übergeordneten Elemente auch in diesen Status wechseln. für ein “multiPI Item” wie ein Portfolio Epic haben wir definiert, dass der Status “Ready4PI Planning gesetzt werden darf, wenn das erste direkt mit dem Epic verlinkte Item eben diesen Status erreicht hat.

Effizienz und Effektivität im agilen Umfeld

Es ist mal wieder Zeit etwas über Agile zu schreiben. Und zwar diesmal über den Unterschied von Effizienz und Effektivität - und dass bei Agile oft nur der Effizienzteil betrachtet wird. Und nein, ich habe keines der tausenden von Bücher über Effizienz und Effektivität gelesen. Ich erzähle euch aber gerne das, womit ich die Studenten an der ZHAW geplagt habe.

Wir starten mit einem Zitat von Peter F. Drucker (Wikipedia) - in englisch, weil es einfach cooler klingt:

“There is nothing so useless as doing efficiently something that should not have been done at all”

Peter F. Drucker hat ziemlich viele interessante Dinge gesagt, muss ich zugeben. Wir bleiben aber mal bei diesem Zitat, weil es uns sagt, dass wir die richtigen Dinge tun sollen, ehe wir Dinge richtig tun.

Jetzt die Preisfrage: welche Firmen nutzen Agile um nicht nur effizienter zu arbeiten, sondern auch effektiver? Wartet mal noch mit der Antwort, ich erkläre die Frage noch ein bisschen.

Ausprägungen von “effizienter arbeiten”:

• effizienter entscheiden: Wege verkürzen, Verantwortlichkeiten dezentralisieren, weniger “Task Switching”, etc.

• Ressourcen effizienter einsetzen: die Person, welche den Code schreibt, behebt auch Incidents - die Person macht also nicht nur Dev (Development), sondern auch Ops (Operations)

• Begleitenden Overhead reduzieren: beispielsweise wird Testing und Releasing von denselben Teams verantwortet, die auch den Code schreiben oder bestenfalls sogar ein Produkt “ownen”

• Betriebs- und Personalkosten sparen: mit weniger Personal dasselbe wie bisher tun

• Verträge mit Entwicklungspartnern neu verhandeln, ggf. sogar die Strategie im Partnermanagement verändern

• usw. - alles mit Einfluss auf der Kostenseite

Hat in dieser - bestimmt nicht abschliessenden Aufzählung - jemand erkannt, wie Agile in seiner/ihrer Organisation gelebt wird? Was ich hier beschreibe ist für mich nicht das, was ich als Agilität verstehe, weil es ein reiner Fokus auf Effizienzsteigerung ist. Agile ist mehr, insbesondere bezüglich Effektivität. Ihr versteht was ich meine, oder? Ihr seid nicht agil, wenn ihr nur auf Effizienz fokussiert - finde ich :).

Wie wird man effektiver? Ich erläutere:

• Prioritäten - Effektivität dank Fokus
  Das Unternehmen kennt die aktuellen Problemstellungen, priorisiert diese und fokussiert auf die derzeit relevantesten aus Unternehmens- und Kundensicht. Kapazitätsengpässe werden über Priorisierung und nicht über Mehrbudget gelöst.

• Minimum Viable Product (MVP) - Effektivität dank frühem Markt-Feedback
  Effektiv ist nur, was nachweislich ein Kundenbedürfnis befriedigt. Besser als hypothetische Befragungen ist der direkte Test am Markt.

• Feedbackloop - Effektivität dank systematischem Markt-Feedback
  Nicht nur im Rahmen von MVP soll Feedback von Markt direkten Einfluss auf die Ausgestaltung eines Produktes haben, sondern generell. Dazu braucht es einen systematischen Feedbackloop vom Endkunden / Touchpoint (z.B. Call Center, Social Media Teams) zur Produktownerschaft.

• Phase Out - Effektivität dank dem Mut, Produkte vom Markt zu nehmen
  Die anspruchsvollste Aufgabe ist wohl, im richtigen Moment aufzuhören. Insbesondere dann, wenn in einem Geschäft mit niedrigen variablen Kosten 500 Bestandeskunden laufend Umsatz generieren. Es gilt wieder, sich auf das Richtige zu fokussieren, anstelle diese 500 Kunden effizient zu betreuen und zu begleiten.

• Decentralise Decision Making - Effektivität dank Stärkung der Fachexpertise
  Mein Lieblingsthema… Wohlgemerkt, es soll so sein, dass strategische Entscheide dort gefällt werden, wo die Verantwortung dafür sitzt. Aber es sollen keine Lösungen (aka “how”) beauftragt werden, sondern Problemstellungen (aka “what” und von mir aus auch “why”). Wenn Lösungen beauftragt werden, gilt “HIPPO” (Highest Paid Person’s Opinion) - und das führt kaum zu mehr Effektivität.

Wie immer bei meinen Aufzählungen gilt: sie sind sicher nicht abschliessend, aber klar genug, dass ihr schlussfolgern könnt, was da noch alles stehen könnte. Habt ihr euer Unternehmen bereits einordnen können? Zur Illustration noch ein geklautes Bild zu Alignment vs. Autonomie, immerhin mit Quellenangabe. Wo steht ihr oder euer Unternehmen?

Spotify Model for Engineering Culture - aus Youtube.com

Management und Agile geht irgendwie nicht

Was ich immer öfter auf dem Weg zu “agile doing” erlebe, ist der Rückfall in “klassisches Managementverhalten” in Stressmomenten, die keine sein müssten.

Klingt spannend? Ist spannend!

Klingt vertraut? Weiterlesen!

Zunächst stellen wir - auch um etwas zu provozieren - zwei Definitionen auf:

• Management = mit möglichst vielen Bällen gleichzeitig jonglieren trotz widersprüchlichen, untereinander nicht priorisierten Zielen; Steuerung über zentrale Boards und Steerings; Beauftragung “auf Zuruf”

• Agile = mit den möglichst richtigen Gegenständen jonglieren dank untereinander klar priorisierten Zielen und “Pull” gemäss Kapazität; dezentrale Steuerung über Product Owner und die zuvor festgelegte Strategie, resp. die priorisierten Ziele; Prioritäten ersetzen Beauftragung

Das macht jetzt den Eindruck, als wäre Management der Schatten und Agile das Licht. Aber darum geht’s eigentlich nicht. Es geht vielmehr darum, dass ein gleichzeitiger Einsatz von Management und Agile zu null Mehrwert, aber viel Reibung führt. Das ist die wahre dunkle Seite der Macht… Dieser Text ist ein Plädoyer für einen Entscheid für eine Seite (und zwar Agile :)). Das ist ein Prozess mit wiederkehrenden Momenten der Verführung (wie auch bei Luke Skywalker), aber ein Entscheid, der dringend gefällt und konsequent verfolgt gehört.

Ihr glaubt nicht an die erwähnte Reibung? Ein paar Beispiele, die nicht an den Haaren herbeigezogen sind - dafür sind zu wenige übrig…

• Das Management interessiert sich - aus meiner Sicht zurecht - nicht für Kapazitäten. Interessiert sich das Management gleichzeitig auch nicht für Prioritäten, haben wir den Salat. Um an möglichst vielen Themen gleichzeitig zu arbeiten, folgt man den kommunizierten Erwartungen des Managements und wirft möglichst viele Bälle gleichzeitig in die Luft um auch “Restkapazitäten” zu füllen. Die Probleme: man verstopft das System (= zu kleinteilige und damit länger dauernde Umsetzung), man macht nur das Notwendigste (= Experience Lücken für Kunden) und man alloziert Ops-Kapazität für Dev-Aufgaben (= keine Improves, keine Experimente, nur Bugfix). Fazit: Anti-Agile-Stimmung, viel Reibungspotential, kein Effizienzgewinn

• In einer Organisation hat eine Aufbaurolle (“Head of”) die gleichen Inhalte zu bearbeiten, wie eine Ablaufrolle (z.B. Product Owner). Sind diese beiden Rollen nicht auf der gleichen Person vereint, gibt es Interessenkonflikte. Der “Head of” macht am Management Board XY Versprechungen um beispielsweise nicht das Gesicht zu verlieren, während diese Versprechungen vom PO gehalten werden müssen. Die Probleme: der Product Owner ist Backlog Owner (= keine sehr spannende Rolle), die Transformation weg von der Aufbauorganisation wird nicht geschehen, Fazit: Demotivation der Product Owner oder der Head of’s, viel Reigungspotential, kein Effizienzgewinn

• An einem Steering von DVS A wird gemeinsam mit einigen Management-Vertretern die Strategie von DVS A festgelegt. Am Steering von DVS B mit anderen Management-Vertretern die Strategie von DVS B. Wenn DVS A und DVS B nun Abhängigkeiten untereinander haben, haben sie gerade gegensätzliche Prioritäten erhalten. Das Problem: der selber geschaffene Zielkonflikt gehört gemanagt… Fazit: Zielkonflikt, viel Reibungspotential, kein Effizienzgewinn

• An einem Steering von DVS C werden die gelieferten Inhalte nicht anhand von Zahlen, Daten, Fakten validiert, sondern gemäss Gutdünken aus persönlichem Erleben vom Management. WIE etwas besser umgesetzt werden soll, wird direkt beauftragt - aus dem Steering heraus. Das Problem: das Gegenteil von Vertrauensförderung, nämlich Micromanagement. Fazit: Micromanagement, viel Reibungspotential, viel Waste, kein Effizienzgewinn

• An einem Steering von Programm D wird der Programmleiter beauftragt, die Online-Bestellprozesse noch einmal unter die Lupe zu nehmen und Verbesserungen zu machen um die Conversion Rate zu erhöhen. Das Problem: man hat gerade die falsche Rolle beauftragt - es gibt sicher einen Product Owner für den Bestellprozess. Fazit: Zuständigkeitsgerangel, viel Reibungspotential, kein Effizienzgewinn

• Gelten je nach Jahreszeit andere Ziele (z.B. mal Umsatz, mal Kosten, mal Kundenzufriedenheit), kann eine Organisation weder vorausschauend ein Portfolio planen noch auf die relevanten Vorhaben fokussieren und damit schon gar nicht Kapazitäten ideal allozieren. Fehlt eine mittelfristige BizDevOps-Kapazitätsplanung, will niemand von den aktuell vorhandenen und allozierten Kapazitäten abweichen - sicher auch, weil dahinter oft Partner-Verträge stehen, die nicht auf Zuruf innerhalb von wenigen Tagen oder Wochen “einfach so” doch wieder verlängert werden können. Das Problem: Gartendenken 2.0. Fazit: geringer Anreiz für verbesserte Planung, viel Reibungspotential, kein Effizienzgewinn

Jetzt habe ich mich aus dem Fenster gelehnt - wie macht man es denn dann, wenn man agil sein will?

• Das Management priorisiert die Themen auf Ebene Portfolio gemäss Strategie - und hat das Recht, dann und wann kurzfristig etwas zu verändern. Aber IMMER indem Themen ausgetauscht werden, NIE indem Themen “on top” dazukommen.

• Auf Basis dieser groben, fairen Priorisierung macht ein Portfolio Management (Rolle, nicht Stufe) eine genau so grobe Planung der Anzahl Gegenstände, die man auf Basis der gegebenen Kapazität in die Luft werden kann. Gegebenenfalls wird Budget anders alloziert, dass Kapazität dort hin verschoben wird, wo sie benötigt wird

• Die Ablauforganisation zieht ein Thema nach dem anderen gemäss Priorität, resp. gemäss noch vorhandener Kapazität. Beispielsweise Rang 1, 2, 4, 6 gehen sofort in Arbeit. Rang 3 und 5 nicht, weil die Kapazität eines dafür notwendigen DVS mit den Rängen 1 und 2 schon voll ist. Rang 7ff gehen noch nicht in Arbeit, weil keine Kapazität vorhanden ist

• Diese Sicht von “was ist in Arbeit, was nicht“, wird dem Management regelmässig kommuniziert. Das Management hat natürlich jederzeit auch das Recht nachzufragen, wo man in welchem Thema steht. Zudem beinhaltet eine Sicht auf ein Portfolio nicht nur die Themen, die man begonnen hat, sondern auch einen vernünftigen Ausblick auf die nächsten 12 Monate. Wann ist ein Vorhaben ungefähr fertig, wann beginnen wir voraussichtlich das Vorhaben auf Rang 9, etc.

• Die DVS können einen Teil der Kapazität auf Ops verwenden um zu lernen, ob eine produktive Lösung wirklich das hält, was man sich von ihr verspricht - und wenn nicht, wird es innerhalb dieser Kapazität verbessert. Das ist die Aufgabe der Product Owner als Unternehmer für ihr Produkt

• Will man unbedingt ein Steering einrichten, um die Strategie gegenüber den DVS zu diskutieren, ist das Steering das immer gleiche Board (z.B. eine Bereichsleitung). Wöchentliche Steeringtermine machen hoffentlich keinen Sinn, weil die Strategie nicht so oft ändert… Aber mehr Steerings braucht es eigentlich nicht

• Und zu guter Letzt gibt es noch die Rolle des Epic Owners. Ein Epic Owner begleitet ein Vorhaben durch den Prozess und ist die Person, die man anschaut, wenn man als Manager oder sonstiger Stakeholder Fragen zum Vorhaben hat. Man fragt nicht die Head of’s - die müssen nicht wissen, wo ein Vorhaben steht

Wenn ihr das hinkriegt, seid ihr wirklich gut! Aber unabhängig davon, ob ihr das schon lebt oder nicht: der Weg ist lang und die Stressreflexe werden wohl noch lange in Richtung “Management” zeigen. Ebenso wichtig: wenn ihr euch in dieser Auflistung gar nicht wieder findet, so überlegt euch, ob ihr wirklich agil (= weniger Management, mehr Struktur) sein wollt oder ob Wasserfall nicht effizienter (= einfachere Steuerung, mehr “invest & control”) für euch ist.

Man muss auch nicht zwingend agil sein, sondern nur anpassungsfähig - vgl. unten etwas passendes dazu zum Schmunzeln…

Quelle: Explaining Software Development Methods By Flying to Mars [Comic] - Toggl Blog

Feedback systematisch erfassen statt punktuell danach fragen

Lange nichts mehr geschrieben…. Es ist interessant, wie einem trotz Homeoffice und Zeitgewinn dank null Arbeitsweg für alles ausser Arbeiten und Familie die Zeit fehlt. Aber ich will gar nicht erst lamentieren, für was ich alles zu faul geworden bin. Viel wichtiger ist, dass ihr mal wieder etwas Interessantes zum Thema Agile zu beissen bekommt.

Heute widmen wir uns dem Thema “Feedback”. Ich meine hier nicht Feedback zu persönlichen Leistungen, sondern von Feedback als Systematik. Sehr klar sind schon mal zwei Parteien: es gibt Feedbackgeber und es gibt Feedbacknehmer. Schauen wir uns die beiden Rollen mal an.

Feedbackgeber

Immer der Kunde oder der Anwender, Punkt. Ein Unternehmen muss das Verständnis erarbeiten, dass zwar auch Kolleginnen, Chefs, Boards und verschiedene Management-Ebenen Meinungen haben und diese kundtun sollen und dürfen. Die Feedbacks von Kunden (oder Usern, sofern anonym) und Frontmitarbeitern sind aber höher zu gewichten, als eine interne Meinung. Die Schwierigkeit ist, Kunden und Mitarbeiter systematisch und ohne Ermüdungserscheinungen (man wird als Kunde mittlerweile richtiggehend bombardiert) zu einem Feedback zu motivieren.

Das ist auch genau ein wichtiger Punkt: warum müssen wir Kunden überhaupt zu einem Feedback motivieren, wenn wir schon genügend Momente haben, in welchen sie uns von sich aus Feedback geben? Anruf in ein Callcenter, Besuch eines Shops, Gespräch mit deinem Service Techniker vor Ort, Unterhaltung mit einem Berater, Reklamation wegen einer ungerechtfertigten Mahnung, Online Bestellabbruch auf einer bestimmten Page. Manchmal muss man das Feedback auch suchen gehen (Communities). Aber hey, was wollen wir denn noch mehr? Ist nicht alles da?

Es kommt dazu, dass bei Feedback aus einer Befragung oft der Situationsbezug bereits vorbei ist. Der Kunde muss sich also an Gefühle erinnern oder versuchen, sich in Situationen hineinzuversetzen. Es gibt Menschen, die das können - ich kanns nicht. Aber weil ich höflich bin, werde ich auf solche Fragen immer Feedback geben :).

Die zufriedenen Kunden melden sich nicht, die unzufriedenen melden sich freiwillig und situationsbezogen - und wohl deswegen nicht immer freundlich. Wir lernen aber dennoch mehr von den unzufriedenen Kunden. Das sagt ja beispielsweise auch Bill Gates (“your most unhappy customers are your greatest source of learning”).

Übrigens gilt dasselbe von Mitarbeitern. Die unzufriedenen Mitarbeiter mit Leidenschaft für das Unternehmen melden sich schon - vgl. den etwas älteren Artikel an dieser Stelle zum Thema “Change Agent”. Man sollte diese Mitarbeiter nicht eliminieren (= entlassen) oder totschweigen (= von selber gehen), sondern fördern.

Feedbacknehmer

Jetzt wirds haarig: Kunden sprechen von sich aus ja manchmal über ein Produkt, mal über eine Dienstleistung, eine Rechnung oder ein unerwartetes Ergebnis, zwischendurch auch über Gott und die Welt und die Nachbarn. Derjenige, der das Feedback systematisch erfassen sollte, ist ein Frontmitarbeiter oder ein System (bzgl. Abbruchraten in Online Journeys) - und er, sie oder es ist genial im Filtern von wichtigen vs. unwichtigen Informationen. Der Frontmitarbeiter (oder das System mit den Abbruchraten) ist damit der Feedbackerfasser.

Nun brauchen wir jemanden, der das Feedback qualitativ prüft, verdichtet und an die richtigen Adressaten dispatcht. Seien wir mal ehrlich, Freitext-Analysen habe ich früher noch mit Excel gemacht, heutzutage gibt es Tools, die besser zusammenfassen (bedenke dabei den Grundsatz “shit in, shit out”). Ein Feedbackverdichter ist ein interner Profi - die Person weiss, wo es Feedback abzugreifen gibt, kann damit runde Stories zusammenstiefeln und stellt sie erst noch den Personen zu, die auch etwas damit anfangen können. Adressaten dieses verdichteten Feedbacks sind übrigens meistens die Product Owner in einem BizDevOps Setup.

So weit so gut. Klingt irgendwie machbar. Jetzt ist es aber so, dass uns Agile lehrt, dass wir experimentieren sollen (z.B. Minimum Viable Products am Markt testen). Gleichzeitig wird den höherwertigen Kunden eine bessere Kundenbetreuung versprochen und nebenbei auch noch ein Massenbusiness über vier verschiedene Channels (Telefon, Online, Shop, beim Kunden zu Hause) betreut. Zudem besteht das Produktportfolio in der Masse aus >1 Produkt. Und dank Corona wurden in jüngerer Vergangenheit auch noch zusätzliche Prozesse eingeführt (pick up, Heimlieferung, Bezahlung mit Twint, Bestellprozesse online, etc.). Dann sind da noch die Kunden, die nicht pro Problem genau einmal anrufen, sondern sobald sie genug Probleme beisammen haben anrufen um sie alle gleichzeitig gelöst zu kriegen. Oder sie schreiben sie irgendwo in ein Forum und vergraulen potentielle Kunden. Unser Problem der qualitativ hochstehenden Feedbackerfassung, -verdichtung und -triage wird also doch recht komplex.

Fazit

Die Kunst liegt in der qualitativ hochstehenden Erfassung von Kundenfeedback, in dessen Verdichtung und Verwertung. Fragt nicht nach mehr Feedback, die Antwort ist sowieso subjektiv (Henry Ford und die Story mit dem schnelleren Pferd statt dem Auto). Nutzt das Feedback, das ihr “einfach so” erhaltet und arbeitet es regelmässig systematisch auf. Interessant in diesem Zusammenhang ist die Variante von “Gemba” - das schauen wir uns aber in einem anderen Blogbeitrag an.

Darstellung des Zusammenspiels von Frontmitarbeiter (aka Kundenservice) als Feedbackerfasser zu Gunsten von einem Product Owner in BizDevOps-Strukturen im Rahmen von Massenbusiness, Experimenten oder speziellen Kundengruppen/Einzelkunden.

Die Gemeinsamkeit von Jassen, Karate Kid und Agile

In einer angeregten Diskussion rund um das Thema “Agile” fiel jüngst der interessante Satz, dass man “ein agiles Zusammenarbeitsmodell ja nicht fundamentalistisch umsetzen müsse” (sinngemäss wiedergegeben, nicht wortwörtlich). Meine erste Reaktion war: lachen. Ich wusste aber nicht, warum ich lachen musste. Es war kein Lachen wie bei einem guten Witz, es war auch kein Mitleidslachen oder gar ein deplatziertes Lachen (glaube ich zumindest…). Mit ein, zwei Tagen Distanz verstehe ich nun, warum ich lachen musste. Ganz einfach, weil sich in der Aussage das Dilemma zwischen “Veränderung anstreben” und “Bestehendes bewahren” verbirgt. Der Bereitschaftsgrad zum Lösen dieses Dilemmas - also einen grossen Schritt Veränderung herbeizuführen - versteckt sich ebenso im Satz. Es gibt wohl nur wenige Menschen, die positive Gefühle mit dem Adjektiv “fundamentalistisch” assoziieren.

Natürlich steckt auch Wahrheit im Satz. Es gibt agile Zusammenarbeitsmodelle, die vielleicht eher Geschäftsmodelle sind. Zudem bringt Veränderung immer einige Unruhe mit sich, weswegen man sich immer fragen sollte, wie gross die Notwendigkeit für Veränderung ist oder wie hoch die Belohnung nach der Veränderung sein wird. Aber jegliche Diskussion im Keim zu ersticken, indem man Dinge mit extrem (negativ) wertenden Adjektiven versieht, vernebelt den Blick auf die Realität.

Wir bemühen ein Beispiel in drei Varianten. Ihr wollt eurer Familie Jassen beibringen - den Schweizer Nationalsport. Jassen ist wie Englisch (und Agile): man versteht ziemlich schnell viel und kann es auch rasch anwenden, es ist aber dennoch ein extrem langer Weg bis zum Experten - und natürlich hat jeder das Gefühl, Experte zu sein :).

Variante 1: diejenigen, welchen ihr Jassen beibringen wollen, haben nicht wirklich Lust Jassen zu lernen

Variante 2: diejenigen, welchen ihr Jassen beibringen wollt, sind motiviert die Basics für einen einzelnen Spieler zu lernen und anzuwenden

Variante 3: diejenigen, welchen ihr Jassen beibringen wollt, sind motiviert die Basics und Feinheiten für jede Jassvariante (z.B. Differenzler, Bieter, Schieber, Coiffeur, uvm.)

Blödes Beispiel? Nein, bitte lest weiter! Was ich mit dieser Analogie sagen will ist, dass es zunächst darauf ankommt, welches Ziel man erreichen will. Ist das Ziel definiert, kommt es darauf an, die Mitstreiter für das Ziel zu motivieren. Zu guter Letzt bestimmt das konsequente Handeln den Erfolg ehe die Mitspieler zu Experten werden und der Spielspass endgültig maximiert wird.

Übersetzt auf Agile bedeutet das:

1. Wähle, ob du Agile arbeiten willst - wenn nein, brich hier besser gleich ab…

2. Wähle, mit welchem Modell du die Motivation deiner Mitarbeitenden maximierst

3. Richte dein Handeln (und das der anderen) konsequent nach den Regeln des Modells aus

4. Lass Veränderung zu NACHDEM die Regeln gelebt werden

Insbesondere das “konsequente Handeln nach den Regeln” schränkt Freiheiten ein und verlangt viel Veränderungsbereitschaft. Man kann Punkt drei jetzt einen negativen Beigeschmack verleihen, indem man es als “religiös” oder “fundamentalistisch” bezeichnet. Es ändert sich deswegen aber keine Tatsache. Und die wichtigste Tatsache ist, dass “agil sein” viel konsequentes Handeln gemäss Spielregeln und viel Geduld erfordert. Vgl. dazu “Shu-Ha-Ri” (vgl. Wikipedia) oder schaut euch mit diesen Gedanken im Hinterkopf einfach wieder mal den Film “Karate Kid” an (bitte das Original…).

Führung in der agilen Welt

erschienen am 15.09.2020 auf www.denkwiese.ch

Schon immer hatte ich Mühe mit dem Ausdruck "geführt werden", insbesondere wenn es mich selber betraf. Unführbar war ich für Vorgesetzte mit einem Führungsstil aus den 1990-er Jahren (direktiv top-down), führbar war ich für all jene Menschen, zu denen ich fachlich aufgesehen habe, die mich aber dennoch auf Augenhöhe behandelt haben.

Wie können wir in der heutigen Zeit Menschen optimal führen?

Vertrauen schenken
Mitarbeitende hatten noch nie einen so hohen Basis-Bildungsgrad wie heute. Und sie stehen bestimmt auch nicht jeden Morgen auf, um sich als Erstes zu überlegen, wie sie dem Unternehmen schaden könnten.

Entscheide dezentralisieren
Führung wird heute oft so interpretiert, dass der Chef auch entscheidet. Dank Agilität werden Entscheide und dazugehörige Verantwortlichkeiten dezentralisiert. Es gilt, die organisatorische Klarheit zu schaffen und zu verstehen, wo welche Rolle den Entscheid treffen soll.

Fokus auf Stärken legen
Zu oft orientieren wir uns an Schwächen und versuchen, den Fokus auf das "aber" statt auf das "und" zu legen. Dies hat zur Folge, dass wir in vielen Lebenslagen den Weg zur Nulltoleranz suchen. Der Weg zu einer Feedbackkultur (Feedback als Entwicklungschance sehen) oder sogar Fehlerkultur (Scheitern als Entwicklungschance sehen) bleibt entsprechend weit.

Mit direkt beeinflussbaren Zielen arbeiten
Führen bedeutet immer auch Ziele zu haben und Menschen dafür zu gewinnen. Engstirnige Key Performance Indicators (z.B. Anzahl Verkäufe) oder gar konkurrenzierende Ziele (die in einem schlechten Kompromiss enden) dürfen nicht der Führungskompass sein. Gesucht sind gemeinsame, geteilte Ziele, aus denen sich auf jeder Ebene ableiten lässt, was der persönliche Beitrag ist – hergleitet aus der Vision des Unternehmens.
Apropos "Vision"…

Vision konsequent verfolgen

Neben den sichtbaren Zielen am Horizont sollte man auch eine Idee haben, wie es dahinter weiter geht. Die Erde ist nicht flach, es gibt keinen Grund, am Horizont mit dem Denken aufzuhören. Es braucht eine griffige, motivierende Vision oder – wer es weniger esoterisch mag – ein Zielbild, von Vorteil aus Kundensicht. Persönlich glaube ich daran, dass ein prosperierendes Unternehmen das Ergebnis einer weitsichtigen Führung auf Basis eines Zielbildes ist. Ich glaube auch, dass sich darin der Unternehmer und der Manager unterscheiden (der eine hat Herzblut für die Vision, der andere für die Zielerreichung).

Kontrolle oder Coaching

Das klingt jetzt, als wäre viel Kontrolle nötig, um Schritt für Schritt in die agile Führung zu gelangen. Das Gegenteil ist jedoch der Fall. Ja, es ist viel Aufwand, aber es geht eher um Coaching als um Kontrolle. Als Ergebnis erreichen wir eine effiziente Selbstorganisation der Mitarbeitenden. Als Mitarbeiter kenne ich die Vision, das nächste Etappenziel und meinen Spielraum. Ich weiss, dass ich scheitern darf und dass man mir Vertrauen schenkt. Was will ich als Mitarbeiter mehr? Die Leitplanken sind gesetzt, jetzt will ich mich bewegen! Mein Vorgesetzter soll mich als Coach partnerschaftlich ermutigen, mehr zu tun und mir nicht sagen, was ich tun soll. Der beste Coach ist derjenige, der in seinen Mitstreitern die Sehnsucht nach dem Gewinnen weckt.

Nun noch der Disclaimer: Es gibt Menschen, die sich nicht selber organisieren wollen – oder sie können nicht, weil die Leitplanken sehr eng gesteckt sind. Es gibt auch Menschen, die nur direktiv führen können und wollen. Als vorgesetzte Person hat man immer die Pflicht, die Mitarbeitenden arbeitsmarktfähig zu halten – und das ist heute zwingend die Befähigung für die agile Arbeitsweise durch Selbstorganisation!

Über "Change Agents" und Kunst

Meine Schwester meinte, ich solle nicht so viele Abkürzungen oder Fachjargon verwenden. Der Feedback Loop funktioniert! Und die Umsetzung des Feedbacks ebenfalls - ausser für den Titel des neuen Artikels. Ein bisschen “Buzz Word Bingo” wird ja noch erlaubt sein.

“Change Agent” - was ist das denn?

Der Montag dieser Woche war mal wieder mühsam. So viele Mitarbeiter, die Mühe damit haben, dass du vor zwei Jahren zum Chef befördert worden bist. Mindestens ist das deine Hypothese. Du hast keine andere Erklärung dafür, warum sie dir ständig sagen, welche Baustellen dringend behoben gehören, damit sie effizient und effektiv arbeiten können. Du stellst teure Berater (nicht mich, ich bin nicht teuer - nur gut) ein, die dir nach nur wenigen Wochen einen 80 Seiten starken Foliensatz in Schriftgrösse sechs zur Vorbereitung für die Präsentation am nächsten Tag zustellen. Deine letzten Gedanken kurz nach drei Uhr nachts: die Kernaussagen kommen dir höchst bekannt vor.

Wir analysieren an dieser Stelle nicht das Geschäftsmodell von Beratungsunternehmen. Wir widmen uns “nur” der relevanten Frage: warum hörst du eher auf Berater als auf eigene Fachexperten, die für das Unternehmen brennen und etwas verändern wollen?

Was charakterisiert einen “Change Agent”:

• meldet sich ungefragt zu Themen, die ihn/sie aus deiner Sicht nichts angehen

• spricht auch heikle oder politische Missstände an

• bringt (praktikable) Lösungsvorschläge statt nur Probleme

• ist ein ungeduldiger, mühsamer Wadenbeisser (bei dir!) und lässt sich nicht abwimmeln

Es gibt genügend Artikel rund um den Begriff “Change Agent”, beispielsweise auf Wikipedia. Ich möchte auch keine neue Definition formulieren - dafür fehlt mir die strengwissenschaftliche Disziplin und die Schriftgrösse sechs. Aber ich möchte herausstreichen, dass man viel Geld woanders investieren kann, wenn man seine “Change Agents” identifiziert und so positioniert, sodass sie ihre Wirkung entfalten können. “Positionieren” steht hier nicht für Hierarchie, sondern dafür, dass die Mitarbeiter die Plattformen oder zentrale, beratende Rollen erhalten um Veränderung für das Unternehmen vorleben zu können und zu treiben. Auch gegenüber Chefs oder dem Management. Das motiviert endlos - sowohl diejenigen, welche die Chance haben etwas zu verändern als auch diejenigen, die bemerken, dass unangenehm sein honoriert wird.

This is it?

Nein, noch nicht. Es kommt noch ein Abschnitt. Worüber will ich denn noch schreiben? Darüber, dass die “Change Agents” zu oft mit negativen Adjektiven beschrieben werden. Man bezeichnet sie als “dogmatisch”, “nicht kompromissfähig” oder “schwer führbar”. Und diese Menschen gibt es natürlich auch! Die Kunst liegt darin, die Spreu vom Weizen zu trennen und Optimist zu bleiben. Aus Dogmatismus wird Entschlossenheit, fehlende Kompromissfähigkeit führt zur klaren Zielvorstellung, Unführbarkeit löst sich in Selbstorganisation auf. Unbezahlbare Eigenschaften für ein Unternehmen um vorwärts zu kommen.

“Change Agents” sind mühsam - sie wollen verbessern und werden auch scheitern. Die besten Vorgesetzten sind Künstler - sie wollen fördern und werden sich auch täuschen. Das erfolgreiche Unternehmen ist der Spielplatz für Erfolg und Misserfolg.

"Agile" - ein grosser Schritt für DevOps, ein noch grösserer Schritt für Business

Nachdem mein erster Blogbeitrag viel Zuspruch erhalten hat, nehme ich zwei Dinge mit:

1. Der Beitrag war tatsächlich stilistisch gut geschrieben und inhaltlich verständlich

2. Ich war nicht provokativ genug, weil es nur Konsens gab

Das versuche ich mit meinem nächsten Beitrag zu ändern. Auch diesmal gilt: viel Spass beim Lesen, nachdenken und kommentieren des Textes!

Warum “Agile” ein grösserer Schritt für Business als für DevOps ist

Jaja, ich provoziere bereits. Ich will weder die wertvollen Tätigkeiten von Dev noch von Ops oder den Aufwand von Dev + Ops hin zu DevOps klein reden - au contraire. Nichts desto trotz bedeutet “Agile” für Business eine enorme Anpassung der bisherigen “Lebensgewohnheiten” und darum soll es im Folgenden gehen, weil diese Punkte aus meiner Sicht viel zu wenig beleuchtet und insbesondere verstanden werden:

1. “invest + control” wird abgelöst durch “trust + invest”

2. Product Ownership verlangt echte wirtschaftliche Verantwortung für ein Produkt auf Teamebene

3. Kurze Entscheidungswege verhindern eine Board-Kultur

4. Der Bereich “IT” ist als bisherige Blackbox plötzlich erschreckend nah

5. Ineffizienzen auf Seiten Business werden transparent

6. Es geht nicht um die Lösung, es geht zunächst um das gemeinsame Problemverständnis

7. Die Karte “die KL will…” sticht in einer Welt von objektiv bewerteten Prioritäten nicht mehr

8. Von der Aufbau-Org getriebene Teams (“der Chef entscheidet”) rutschen plötzlich in eine Matrix zwischen Aufbau-/Ablauf-Org mit neuen (an sich klaren) AKV-Strukturen

…und ich bin sicher, dass das nur ein kleiner Teil der Anpassungen ist. Schauen wir sie uns doch nacheinander etwas detaillierter an.

“invest + control” wird abgelöst durch “trust + invest”

Wer kennt die Prozesse mit “Milestones”, “Decision Points” oder sogar “Toll Gates” nicht? Zu fix definierten (Fortschritts-) Zeitpunkten eines Vorhabens muss auf Basis von Aufwand (Kostenschätzung) und Ertrag (Business Case) eine nächste Tranche der Projektgelder freigegeben werden. Manchmal wird auch die persönliche Wichtigkeit darüber definiert, an wie vielen solcher Boards man regelmässig sitzen darf (ja, ich provoziere schon wieder - ertappt). Auf jeden Fall ist diese Art des “invest + control” im Rahmen von “Agile” weder sinnvoll noch möglich.

Die gute Nachricht: es ist in “Agile” deutlich einfacher. Ein zu realisierendes Vorhaben wird möglichst objektiv gegenüber anderen Vorhaben priorisiert (mit so wenig Aufwand wie sinnvoll!), wobei die Priorisierung mittels “forced Ranking” zu diesem Zeitpunkt problemlos übersteuert werden kann - es hat ja noch niemand viel Zeit investiert, der “Waste” (= für nichts investierter Aufwand) ist damit vernachlässigbar.

Die schlechte Nachricht: es braucht viel Vertrauen, resp. die richtigen Menschen in den richtigen Rollen. Es folgen nämlich viele weitere Priorisierungsrunden entlang der Ablauforganisation, wobei die involvierten Rollen (und damit oft auch die Personen) wechseln. Aber hey, Unternehmen, die ihre Mitarbeiter seit Jahren dazu anhalten, unternehmerisch zu handeln, hatten die Zeichen der Zeit ja bereits erkannt. Nun braucht es nur noch konsequentes Handeln nach den unternehmenseigenen Grundsätzen.

Product Ownership verlangt echte wirtschaftliche Verantwortung für ein Produkt auf Teamebene

A propos “unternehmerisch handeln” (wow, was für ein Übergang!). Product Ownership hat nichts mehr mit Delivery zu tun. Product Ownership kann nur wahrnehmen, wer auch wirklich die vollen Kompetenzen erhält wie auch die vollen Konsequenzen verantwortet - dazu gehört auch der wirtschaftliche Erfolg eines Produktes. Geht diese Verantwortung nicht an die Product Ownership über, wird es immer ein Beauftragungsmodus desjenigen mit der wirtschaftlichen Verantwortung an denjenigen mit den Skills für die Umsetzung bleiben. Und das kennen wir: das ist das klassische Business <-> IT Muster, das “Agile” überwinden will.

Es geht nicht um die Lösung, es geht zunächst um das gemeinsame Problemverständnis

Solange die Business-Einheiten denken, dass sie nicht Teil von BizDevOps sind, werden sie die agilen Teams als Delivery anschauen. Entsprechend werden Lösungen im Silo “Business” designt, an Boards freigegeben und den agilen Teams zur Umsetzung beauftragt. Ein Abweichen von diesem Auftrag - wenn auch gut begründet und vielleicht sogar abgetestet und mit Zahlen, Daten, Fakten unterlegt - wird nicht goutiert.

Im Idealfall versteht Business, dass sie Teil der agilen Organisation sind und sorgt nach der notwendigen businessseitigen Priorisierung für ein gemeinsames Verständnis der Problemstellung in der Ablauforganisation. Ist das Problem verstanden, wird der Fokus auf die gemeinsame Erarbeitung einer Lösung gelegt, bestimmt durch Hypothesen und Validieren dieser Hypothesen.

Kurze Entscheidungswege verhindern eine Board-Kultur

Wir hatten weiter oben “Milestones”, “Decision Points” und “Toll Gates” erwähnt. Noch unerwähnt ist, dass diese (Fortschritts-) Zeitpunkte zumeist zentralisiert an “Boards” abgenommen werden. An diesen Boards sitzen oft hochintelligente Menschen - gleich intelligent wie die Menschen, die an diese Boards eingeladen werden - die manchmal so weit von der Materie entfernt sind, dass sie entweder Standardfragen (“geht das nicht einfacher?”), Fragen aus vergangener eigener Erfahrung (“wir haben das damals so gemacht - geht das hier nicht?”) oder nur Fragen zu Inhalten stellen können, die sich aus dem Kontext der Präsentation oder aus Briefings zuvor ergeben. Bitte diese Passage nicht falsch verstehen - dass man Unternehmen erfolgreich führen kann, hat die Vergangenheit ja bewiesen. Aber die Zeichen der Zeit deuten klar weg von dieser Board-Kultur. Einerseits wegen der immer besseren Ausbildung der Mitarbeiter (früher war ja ein Chef tatsächlich oft auch die gescheiteste Person, wenn auch nicht zwingend die intelligenteste), andererseits wegen der steigenden Komplexität der Inhalte und der Menge der Themen. Oder kurz: der eigene Denkprozessor kommt schlicht an die Grenzen.

Entsprechend macht es viel Sinn, die kurzen Entscheidungswege mit viel Vertrauen zu dezentralisieren. Wobei: dezentralisieren bedeutet fairerweise, dass sie auf einer anderen Ebene wieder zentralisiert werden. Aber sagen wir es so: für jeden Entscheid gibt es eine optimale Flughöhe. Entsprechend wird auch eine Konzernleitung weiterhin Entscheide fällen müssen - ggf. aber ausschliesslich strategische Entscheide mit (potentiell) grossem Einfluss auf die Wirtschaftlichkeit des Unternehmens. Alle anderen Entscheidungen werden entlang der Ablauforganisation gefällt - dort wo die wirtschaftliche Verantwortung für die Produkte liegt.

Der Bereich “IT” ist als bisherige Blackbox plötzlich erschreckend nah

So nah, dass man versteht, wie viel Aufwand von 100 Personentagen für verschiedene Tätigkeiten investiert werden muss. Nochmal zur Erinnerung: die Menschen, die vorher nur Dev gemacht haben, machen nun auch Ops (und umgekehrt). Es ist eigentlich nur logisch, dass weniger Kapazität für reine Dev-Arbeit zur Verfügung steht. Es ist schon erstaunlich, dass von 100 Personentagen brutto vielleicht ein Drittel eingesetzt werden kann für die Entwicklung von neuen Features. Der ganze Rest muss investiert werden für Abwesenheiten, agile Zeremonien, Refinement & Kanban Management, Operations (Überwachung, Alarming, etc.), Lifecycle (Improve), agile Reserve für beispielsweise Gemba, Security (im Falle von BizDevSecOps), usw. Man könnte fast sagen, dass “IT” als “Feindbild” (oder Ehemann [= immer schuld] - das ist witzig gemeint, imfall!) sehr viel mehr taugte, als sie noch eine Blackbox war. Die agilen Teams schultern so viel Last, dass man ihnen mehr Verständnis entgegenbringt. Business muss sich also ein neues Feindbild suchen…

Ineffizienzen auf Seiten Business werden transparent

Auf die andere Seite wird plötzlich transparent, was man denn rein auf Businessseite für Aufwände in Themen investiert, die nicht priorisiert werden können und auf Umsetzung warten. Früher war es noch so, dass die Projekte eben die Teile umgesetzt haben, die sie über Argumentation oder die KL-Karte (“…die KL will…”) zur Umsetzung bringen konnten. D.h. ein Projektteam war nie zu 0% ausgelastet (= Stillstand). Neu ist das aber so. Niemand arbeitet an einem nicht priorisierten Vorhaben, weil es sich schlicht nicht lohnt. Plötzlich haben Menschen Zeit, weil ihre Themen nicht weitergehen - und vielleicht auch (berechtigten) Respekt vor der Situation, dass das Unternehmen sie nicht auslasten kann. . Es ist aber mindestens gut so, dass ein Kanban und die dazugehörige Priorisierung dazu führt, dass generell nur an den Themen gearbeitet wird, die aus Unternehmenssicht priorisiert sind und auch eine Umsetzungschance haben.

Die Karte “die KL will…” sticht in einer Welt von objektiv bewerteten Prioritäten nicht mehr

Und auch hier folgt ein toller Übergang zum nächsten Thema: was will denn die Konzernleitung? Die Konzernleitung will vor allem ein prosperierendes, rentierendes (von Rendite, nicht von Rentier) Unternehmen im Sinne von Umsatzsteigerung und Kostensenkung. Die KL hat also ureigenes Interesse daran, dass die Prioritäten richtig gesetzt werden und sollte auch das Vertrauen in die Menschen haben, dass die nicht am Morgen aufstehen um Prioritäten zu setzen, die dem Unternehmen in erster Linie schaden. Natürlich muss und soll die KL strategische Entscheide fällen, aber die Entscheide sollen in Priorisierungsrunden nicht der “Trumpf-Puur” sein. Es wäre das Gegenteil von Objektivität, wenn in Unkenntnis von allen anderen Themen entschieden wird, dass ein Thema die höchste Priorität haben muss.

Von der Aufbau-Org getriebene Teams (“der Chef entscheidet”) rutschen plötzlich in eine Matrix zwischen Aufbau-/Ablauf-Org mit neuen (an sich klaren) AKV-Strukturen

Der Titel sagt eigentlich bereits viel. Spannend (wenn nicht eher destruktiv) wird es dann, wenn es kein Alignment gibt, welche Leadership Rolle jetzt welche Themen übernimmt. Sagen wir es mal im Stile eines guter Fribourger Kollegen (also schwarz/weiss):

• Eine vorgesetzte Person in der Aufbauorganisation ist verantwortlich für die Skillentwicklung - also beispielsweise Zertifizierungen, Weiterbildungen, Sprachen, etc.

• Eine vorgesetzte Person in der Ablauforganisation existiert in dem Sinne nicht. Dennoch gibt es die mit den Rollen verbundenen “AKV” - beispielsweise ist ein Scrum Master dafür verantwortlich, dass sich ein Product Owner auch wie ein Product Owner verhält

Im Wissen, dass es auch Graubereiche gibt, ist der simple und relevante Punkt, dass die verschiedenen Rollen, die einen Anspruch auf die Entwicklung der Mitarbeiter haben transparent miteinander sprechen.

Damit schliessen wir diesen Artikel. Ich bin wieder gespannt auf eure Kommentare und Anregungen. Vielen Dank fürs Lesen!

Den Begriff “Agile” begreifen

Du liest meinen ersten Blogbeitrag. Es geht um Agilität. Ja, auch ich schwimme mit - ich bin allerdings kein intellektueller Überflieger sondern ein bodenständiger Praktiker. Wenn du lieber Beiträge zum Thema “Agile” liest, die dich bezüglich Satzbau und Wortwahl herausfordern, lies bitte nicht weiter.

Dank “Agile” verschwimmt die Grenze zwischen Business und IT. Nicht von den Skills her. Ich selber kann gerade mal HTML programmieren und Jira-Filter mit JQL basteln. Aber vom Gefühl her zwei verschiedenen Bereichen anzugehören, wobei der jeweils andere der Inbegriff des Bösen ist (ich übertreibe ein bisschen…).

Eigentlich ist es ja logisch: endlich wird zusammengeführt, was zusammen zu Wert für Kunden und Anwender führt. Klingt einfach – ist es aber nur auf den ersten Blick. Die Reise beginnt beim Begriff "Agile", den damit verbundenen Erwartungen basierend auf verschiedenen Maturitätsebenen und dem steten Ringen um Mittelwege und Kompromisse. Im Folgenden ein paar als Aussagen verpackte Beispiele.

• "Dank Agile können wir kurzfristig Vorhaben grundlegend verändern"

  Die Annahme, dass man dank agiler Arbeitsweise kurzfristig Themen verändern kann, ist korrekt. Die Ablauforganisation muss so organisiert sein, dass sie ein bestimmtes Mass an Veränderung verdauen kann. Die Erwartung, dass man Themen kurzfristig grundlegend verändern kann ohne die Sprintplanung oder ein ganzes PI Planning über den Haufen zu werfen, ist falsch. Die Teams stecken viel Aufwand in das Erreichen einer "Definition of Ready", beispielsweise für die Abklärung von Abhängigkeiten zu anderen Teams oder Systemen, für die Abstimmung von einem Solution Design oder für Prototyping und Exploration. Das alles zu wiederholen ist "waste".

• "Dank Agile wird die Time to Market reduziert"

  Das ist korrekt – für einen Scope mit "Minimum Viable Product"-Charakter. Die Zeit für "Time to Market" des "Full Scope" dürfte sich wegen der Lernyzklen ("Time to Learn") sogar verlängern. Das bringt zwei grosse Vorteile: einerseits erhält man so früh wie möglich Marktfeedback, andererseits wird unter Umständen ein Produkt gebaut, das gar nie so geplant war. Kommt bekannt vor? Genau: beispielsweise Post-It waren nie so geplant.

• "Dank Agile können wir kurzfristig grosse Themen starten"

  Diese Aussage ist hinsichtlich zwei Dingen falsch. Einerseits können jederzeit Themen gestartet werden – egal ob gross oder klein. Das Ziel von Agile ist, dass mit jedem Sprint oder jeder Iteration etwas Werthaltiges für Anwender oder Kunden auf den Markt gebracht wird. Damit werden auch grosse Themen zunächst als "Minimum Viable Product" (MVP) gestartet. Andererseits soll dieses MVP kein Wegwerfprodukt, sondern bereits ein erster sinnvoller Schritt hin zum grossen Ganzen sein. Es ist entsprechend auch für ein MVP ein genügend grosser Zeitinvest für das Erreichen der "Definition of Ready" einzuplanen. Andernfalls riskiert man auch hier "waste".

• "Dank Agile können wir mehr Bälle als früher gleichzeitig in der Luft halten"

  Ehrlicherweise muss ich hier sagen: das genaue Gegenteil ist der Fall. Limit Work in Progress, klare Prioritäten setzen und Fokussieren der Ressourcen auf die priorisierten Vorhaben, die sich an einem (mittelfristig erreichbaren) Zielbild orientieren. Ich denke nicht, dass es darauf hinausläuft, mehr Bälle gleichzeitig in der Luft zu halten…

• "Wir arbeiten agil"

  Ich denke, viele Firmen haben "doing agile" erreicht. Es gibt grosse Differenzen zwischen "doing agile" und "being agile", was die eigentliche (und ziemlich anstrengende) Transformation darstellt. Du findest sie in den obenstehenden Punkten und auch in weiteren Feinheiten wie beispielsweise: tragen die Vorhaben aus deinem Unternehmen coole Namen, die sich intern vermarkten lassen oder tragen sie das Ziel aus Kundensicht im Titel?

Wir fassen zusammen, wie ich Agile verstehe und vorlebe:

• Verändere kurzfristig so viel wie nötig, aber so wenig wie möglich

• Time to Learn vor Time to Market

• Plane MVPs und lass dich vom Feedback zum fertigen Produkt leiten

• Weniger ist mehr

• Die Transformation hat erst begonnen und braucht dein Leadership - finde deine Change Agents

Schön, dass du den ganzen Blogbeitrag gelesen hast. Dieser Text ist mein MVP um zu schauen, ob die “ich wäre gerne agil”-Welt auf mich gewartet hat oder eher nicht. Vielen Dank für dein Feedback und/oder deinen Kommentar!