Kommentierte Links (XVIII)

Grafik: Pixabay / Geralt - Lizenz

• Jason Little: Is Your Organization Ready for Agile Change? (Edit: Link ist mittlerweile tot)

Ich bin mittlerweile ein Fan von Jason Littles Blog, so ziemlich alles was er schreibt könnte ich unterschreiben. Wenn er darüber hinaus noch sinnvolle Werkzeuge vorstellt - umso besser. Die in diesem Beitrag vorgestellten Umfragen habe ich in ähnlicher Form bereits an anderer Stelle gesehen, was ich noch nicht eingesetzt habe sind die Perspective Maps, für die es dort zwei schöne Beispiele gibt. Die Idee dahinter ist, die Sichtweisen verschiedener Gruppen (Teams, Management, Stakeholder, etc) zu erheben und festzuhalten wo sie voneinander abweichen oder sogar gegenläufig sind. Das visualisierte Ergebnis kann dann an einer zentralen Stelle aufgehängt werden, an der es nicht mehr übersehen werden kann. Das ist Transparenz!

• Melissa Perri: Stop Blaming the User

  Was Melissa Perry da schreibt ist leider eine viel zu häufige Realität. Software (und Hardware) ist oft so benutzerunfreundlich, dass es ohne Vorwissen oder Hilfe nicht mehr möglich ist sie korrekt zu bedienen. Das hat fast nie mit Bosheit oder Unfähigkeit zu tun, sondern fast immer mit "Sachzwängen". Um Geld und Zeit zu sparen werden neue Funktionen nicht richtig entwickelt sondern notdürftig irgendwo an bestehende Prozesse und Oberflächen drangeklemmt, mit den entsprechenden negativen Folgen für Usability und User Experience. Richtig bedenklich wird das aber erst, wenn Unternehmen oder Entwicklungsteams die Schuld für die daraus entstehenden Akzeptanzprobleme auf den Benutzer schieben wollen. Mit Perris Worten: "If the user doesn’t understand something, they are just stupid. If the user won’t tell us what they want, they are difficult. If they are calling to complain, they are ungrateful." Bei der Entwicklung von Anwendungen für die eigenen Mitarbeiter kann dieses User Blaming dazu führen, dass die Betroffenen in die innere Kündigung abtauchen, bei externen Anwendungen können schlechte Presse und Verluste von Marktanteilen die Folge sein. Das Abstellen dieser (vermeintlichen) Sachzwänge sollte daher immer höchste Priorität haben. Apropos:

• Tom Bartel: Refactoring For Non-Coders

  Einfache Erklärungen wie diese hier von Tom Bartels sind extrem wichtig, und zwar aus einem banalen Grund: zu den technikfernen "Non-Coders" gehört in vielen Unternehmen auch das Management, das die Refactoring-Aufwände verstehen, genehmigen und einplanen muss. Für jemanden der von einer Anwendung nur die Benutzeroberfläche kennt können Refactorings leicht den Eindruck erwecken, hier würde nur "der Code hübscher gemacht". Wenn nur begrenzte Ressourcen verfügbar sind gehört das dann zum Ersten was gestrichen wird (das sind die "Sachzwänge" aus dem letzten Abschnitt). Die Folge: schlecht wartbare, bedienbare und erweiterbare Anwendungen. Mit plastischen Methaphern wie dieser hier können die Auswirkungen von fehlendem Refactoring vermittelt werden.
  

• Mike Perrow: 5 tough questions about scaled agile you'll need answers for

  SAFe ist vermutlich das umstrittenste unter den großen agilen Frameworks, für viele ist es sogar ein Antipattern, das durch die Hintertür Wasserfall-Elemente wiedereinführt. Sein Erfinder Dean Leffingwell hat allerdings einen Punkt wenn er festhält, dass Scrum oder Agile in großen Firmen Fragen aufwerfen, die man beantworten können sollte:
  

  1. Wie kann sichergestellt werden, dass alle Teams das gleiche Ziel im Blick haben und darauf hinarbeiten?
  2. Wie kann verhindert werden, dass die Teams unterschiedliche (schlimmstenfalls inkompatible) Wege in Architektur, Benutzerführung und Design gehen?
  3. Wie funktioniert langfristige (Budget)Planung in einem skalierten agilen Umfeld?
  4. Wie lässt sich berechnen, welchen Geschäftswert die getätigten Ausgaben einbringen werden?
  5. Warum ist eine permanente Anpassung von Anwendung und Anforderungen billiger als das schnelle Fertigstellen und Abliefern klarer Aufträge?

  Ob SAFe die richtigen Antworten auf diese Fragen liefert ist umstritten, zumindest sind sie aber für klassische Management verständlich. Und in einem Punkt hat Leffingwell definitiv recht: wer diese Fragen nicht beantworten kann wird schnell als unseriös gelten und nicht mehr ernstgenommen werden.

• Harald Schlüter: Eine Fallstudie zur Einführung von Kanban

Diese Fallstudie von Harald Schlüter ist gleich in zweifacher Weise interessant: zum einen aufgrund ihres Inhalts, zum anderen aber aufgrund der visuellen Aufbereitung. Auch wenn man bei der Veranstaltung nicht dabei war geben die Flipchart-Blätter einen sehr guten Einblick darüber wie die Einführung strukturiert und durchgeführt wurde..

Digitalisierung

Grafik: Pixabay / Geralt - Lizenz

Wenn meine Kunden mich nach den Voraussetzungen für eine gelungene Einführung von Scrum/Agile fragen nenne ich (neben anderen) immer die Digitalisierung von Daten und Prozessen. Das überrascht dann den einen oder anderen (was wiederum mich überrascht¹). Bei genauerer Betrachtung stellt sich oft heraus, dass noch weite Teile des Unternehmens in der Welt der physischen Datenhaltung verblieben sind. Aber warum ist das ein Problem? Aus mehreren Gründen.

Zunächst sind nicht digitalisierte Informationen nur schwer verfügbar. Wenn man sich nicht gerade am Standort des physischen Archivs befindet muss man den Archivar oder die Sekretärin anrufen, sie auf die Suche schicken und hoffen, dass sie das Richtige finden. Und selbst wenn das gelungen ist gehen die Probleme weiter. Entweder man muss auf die Zustellung warten oder man lässt alles einscannen und hat dann ein riesiges, nicht durchsuchbares PDF (oder noch schlimmer: einen Ordner voll JPGs). Handelt es sich bei derartig schwer zugänglichen Dokumenten um wichtige Informationen (Lizenzverträge, Zuständigkeitsabgrenzungen, Stakeholderverzeichnisse, etc.) kann es sein, dass ihre späte Verfügbarkeit den Beginn der Arbeiten stark verzögert, bzw. bereits getane Arbeit obsolet werden lässt.

Dazu kommt, dass physische Daten oft nur mit Mühe zu aktualisieren sind. In einem Unternehmen habe ich erlebt, dass die Mitarbeiter ihr Feedback zu einer neuen Software auf Papier schreiben und in BVW-Briefkästen einwerfen mussten. Alleine das Entziffern und Abtippen dauerte ewig. In einem anderen Fall druckte der Kundendienst die Feedback-Emails der Kunden aus und heftete sie in Aktenordnern ab (!). Infolgedessen traten wieder die im letzten Abschnitt beschriebenen Probleme auf. Mit einem solchen Vorgehen ist es nahezu unmöglich die Rückmeldungen der Benutzer zeitnah in die Weiterentwicklung einfließen zu lassen.

Einen Sonderfall bilden halbherzige oder Teil-Digitalisierungen. Auch hier Beispiele aus der Praxis: In einer Behörde lag der von einer Agentur erstellte Corporate Identity-Leitfaden zwar digital vor, allerdings nur gebrannt auf CDs, die (natürlich) in Aktenordnern im Archiv lagen. In einem anderen Unternehmen waren Produktdaten zwar in einer Access-Datenbank erfasst, die allerdings keine Schnittstelle zu den Webanwendungen hatte, die diese Daten benötigten. Eine Gruppe von Werkstudenten machte nichts anderes als die beiden Systeme manuell zu synchronisieren, was jedesmal mehrere Wochen dauerte.

Wenn solche Daten von Anfang an in miteinander vernetzten CMS oder CRM-Systemen aufgenommen werden können Vorgänge auf eine im Vergleich atemberaubende Geschwindigkeit beschleunigt werden. Auf wichtige Dokumente oder aktuelle Nutzerstatistiken lässt sich innerhalb von Minuten zugreifen, und die entnommenen Informationen und Erkenntnisse können sofort in die Weiterführung der Arbeit übernommen werden. Schöne neue Welt. Erst so lässt sich wirklich agil arbeiten.

Das Problem an dieser Stelle ist natürlich, dass eine Digitalisierung und Vernetzung größerer Aktenbestände Zeit und Geld erfordert. Der mittel- und langfristige Effizienzgewinn ist allerdings so groß, dass diese Investition sich absolut lohnt.


¹Okay, mittlerweile nicht mehr.

D-A-CH Chapter der Scrum Alliance ist im Aufbau

Bild: Pixabay/Lusign - Lizenz

Angekündigt war es schon länger, letzte Woche war es so weit: die Scrum Alliance hat im Anschluss an das Global Scrum Gathering Munich ein deutschsprachiges Chapter gegründet. Anders als zunächst angekündigt handelt es sich dabei nicht um eine nationale Organisation nur für Deutschland sondern um eine für den gesamten deutschsprachigen Raum. Die URL lautet zwar noch http://membership.scrumalliance.org/group/GermanChapter [Edit: Link ist mittlerweile tot], der Name ist aber bereits in D-A-CH Chapter geändert. Gut so.

Beim ersten Arbeitstreffen ging es um u.a. Themen wie gegenseitiges Coaching oder die Erarbeitung von Standards für Unternehmen, die Gruppe an der ich teilgenommen habe war aber die, die sich mit der Vernetzung, bzw. dem Aufbau der lokalen Events und User Groups beschäftigt hat. Ein Engagement in diesem Bereich halte ich grundsätzlich für wichtig, schließlich gehören Agilität und Subsidiarität für mich zusammen. Darüber hinaus scheint es in manchen Orten noch Nachholbedarf zu geben - selbst in großen Städten wie Frankfurt oder Wien finden dem Vernehmen nach nur unregelmässig Veranstaltungen statt.

Der bescheidene Beitrag den ich an dieser Stelle leisten kann ist das Weitergeben von Erfahrungen und best practices, schließlich bin ich recht intensiv in der Community in Köln/Bonn unterwegs und trage mit dem Scrumtisch Bonn auch zu ihr bei. Und vielleicht profitiere ich irgendwann auch selbst davon - wenn ich mal wieder ausserhalb des Rheinlandes unterwegs sein sollte wäre eine lokale Veranstaltung eine willkommene Alternative zur Hotelbar.

Backlogs ausmisten! (II)

Bild: Piqsels - Lizenz

Warum zu große Backlogs regelmässig ausgemistet werden sollten habe ich bereits beschrieben, jedem Product Owner lege ich den regelmässigen Griff zur Heckenschere ans Herz. Nicht festlegen würde ich mich auf die maximale Zahl vertretbarer Backlog Items, das kann je nach Einzelfall unterschiedlich sein. Meine Faustregel ist aber, dass man sich spätestens ab dem hundertsten Eintrag Gedanken machen sollte. Konkrete Ratschläge kann ich dagegen zu etwas anderem geben, nämlich dazu nach welchen Kriterien aussortiert werden sollte. Da gibt es mehrere Möglichkeiten:

Nach Priorität

Zugegeben, ein No Brainer. Je weiter nach unten eine Anforderung priorisiert ist desto verzichtbarer ist sie, weshalb man es sich ganz einfach machen kann - weg mit den unwichtigsten 10 Prozent und das Problem ist gelöst. Aber apropos Problem: an dieser Stelle gibt es eines. Die wichtigsten Anforderungen bekommt man noch irgendwie identifiziert, aber in den meisten Backlogs folgt danach eine amorphe Masse in der alles irgendwie gleich (un)wichtig ist. Wie soll man da mit dem Sortieren weitermachen? Die häufigste Antwort darauf lautet:

Nach Business Value

Okay, noch ein No Brainer. Je geringer der erzeugte Mehrwert desto eher kann eine Anforderung weg. Benutzen wir also das als Vergleichswert und wir haben ... schon wieder Schwierigkeiten. Ein paar zentrale Faktoren für ein funktionsfähigeses MVP oder eine bessere Vermarktbarkeit lassen sich natürlich finden, aber dann - wieder Unklarheit. Ist die intuitive Hauptnavigation jetzt wertvoller als der einfache Bezahlvorgang oder der schnelle Login? Viel Spass beim Entscheiden. Aber es gibt ja weitere Priorisierungskriterien. Zum Beispiel:

Nach Alter

Hier werden die Ersten widersprechen. Denn ich würde sagen: je älter eine Anforderung ist desto eher kann sie weg. Das widerspricht für viele den Denkgewohnheiten, schließlich könnte man meinen, dass eine Umsetzung um so dringlicher wird je länger sie sich hinzieht. Ich sehe das umgekehrt - wenn eine Anwendung so lange Zeit ohne ein Feature funktioniert, dann kann das nicht wirklich wichtig gewesen sein. Aber das nächste Dilemma kommt bereits um die Ecke - gerade zu Beginn kippen üblichweise alle Stakeholder gleichzeitig ihre Wünsche ein, wodurch ihre Anforderungen alle ähnlich alt sind. Doch auch hier gibt es einen Ansatz für eine weitere Auswahl:

Nach Stakeholder

Ja, genau, nach Stakeholder. Es soll weitergehen, es soll mehr Zeit geben, mehr Budget, mehr Ressourcen? Dann hilft es, wenn man nett zu dem ist der das Geld in der Tasche hat. Du kriegst Dein Feature, ich meine Ressourcen, beide sind glücklich. Ein Kuhhandel? Ja, ist es. Opportunistisch? Vermutlich auch. Aber hey, so ist es nun mal in der Welt. Ein grosses Geben und Nehmen. Allerdings, selbst wenn wir das machen bleiben oft noch Anforderungen übrig bei denen man nicht sicher sein kann für wen sie mal wichtig sein könnten. Im Zweifel behalten? Ach was, auch da lässt sich noch reduzieren, und zwar so:

(Festhalten:) Nach Zufall

Wait, what? Nach Zufall. Jetzt kann man losen, Glücksrad drehen, blind mit dem Finger auf etwas zeigen oder einfach jede vierte verbliebene Anforderung löschen. Alles ist erlaubt. Aberwitzig? Mitnichten! Schauen wir nochmal auf die letzten Auswahlrunden. In denen haben wir nicht nur entschieden was nach unten priorisiert wird, wir haben damit gleichzeitig auch nach oben priorisiert, das eine gehört untrennbar zum anderen. Und was in keinem dieser Durchgänge für wichtig genug befunden wurde, das kann eigentlich nur verzichtbar sein. Und deshalb kann die Zufalls-Auswahl so lange weitergehen bis das Backlog auf eine vernünftige Größe eingedampft ist. Nur zu.

AberAber: Was, wenn irgendwas davon doch wichtig war?

Ja, was dann? Was wenn wir versehentlich etwas rausgeworfen haben was wir doch ganz dringend brauchen? Ganz einfach - sobald das auffällt kommt es als neue Anforderung wieder rein. Und wenn auf diesem Weg so lange Anforderungen wieder zurückkommen bis das Backlog erneut ausufert? Na dann geht das Ausmisten eben von vorne los.

Backlogs ausmisten!

Bild: Wikimedia Commons / Jorge Royan - CC BY-SA 3.0

Ein mitgenommenes Thema vom ersten Lean Coffee für Product Owner und Produktmanager, der letzten Freitag stattgefunden hat: wie kann man es schaffen, dass ein Backlog einen überschaubaren Umfang behält und nicht ausufert? Die einfache Antwort - regelmässig ausmisten. Von Zeit zu Zeit ist es sinnvoll sich in grossem Ausmass von bisher gesammelten Anforderungen zu trennen, selbst, bzw. gerade von solchen die noch nicht umgesetzt wurden. Und dafür gibt es auch Gründe:

Zu große Backlogs sind zu unübersichtlich

Zugegeben, eine Binsenweisheit, aber eine mit Folgen. Bei einer drei- oder vierstelligen Anzahl von Einträgen ist es nicht mehr möglich alle Inhalte im Kopf zu behalten, Duplikate, Redundanzen oder Überschneidungen fallen dann nicht mehr auf. Man kann zwar versuchen durch Kategorien, Schlagworte oder Verlinkungen die Übersicht zu behalten, allerdings ist das mit zusätzlicher Arbeit verbunden, die auch erstmal erledigt werden muss. Das bringt uns zum nächsten Punkt:

Zu große Backlogs erfordern einen unverhältnismässigen Pflegeaufwand

Ich habe Menschen gesehen, die in Vollzeit nichts anderes gemacht haben als alte User Stories und Bugs zu aktualisieren. Immer wieder überprüften sie ob das was sich in ihnen befand nicht bereits durch andere Anforderungen umgesetzt wurde, noch gewollt war oder seine Priorität geändert hatte. Nur in den seltensten Fällen führte das dazu, dass irgendetwas aus dem Backlog herausgenommen werden konnte, stattdessen kam es immer und immer wieder zurück (es war nicht ohne Grund so niedrig priorisiert). Eine unglaubliche Verschwendung von Zeit und Geld.

Zu große Backlogs veralten (auch wenn sie gepflegt werden)

Egal wieviel Mühe man sich gibt: zu große Backlogs werden immer Anforderungen enthalten die obsolet oder bereits umgesetzt sind. Alleine die Länge der Aktualisierungszyklen sorgt dafür, denn die können sehr schnell Wochen oder sogar Monate in Anspruch nehmen. Selbst wenn sie gerade erst durchlaufen wurden ist das aber keine Garantie dafür, dass alles aktuell ist. Grund dafür sind die oben erwähnte Unübersichtlichkeit und eine "im Zweifel behalten"-Einstellung die immer wieder anzutreffen ist.

Zu große Backlogs führen zu unrealistischen Erwartungshaltungen und Enttäuschungen

Für viele Stakeholder ist die Angelegenheit klar: ist meine Anforderung noch im Backlog? Klasse, dann ist es ja nur eine Frage der Zeit bis sie umgesetzt wird. Dass unwichtige Dinge immer wieder nach unten priorisiert und von neuen Anforderungen "überholt" werden wird dabei nicht bedacht. Am Ende führt das zu falschen Erwarungen, enttäuschten Hoffnungen und Frustrationen. Die entladen sich dann irgendwann. Apropos:

Zu große Backlogs führen zu Konflikten

"Meine User Story ist jetzt zum fünften mal nach hinten geschoben worden. Jetzt bin ich auch mal dran, wenn nicht eskaliere ich das!" Aussagen wie diese sind die fast schon zwangsläufige Folge zu großer Backlogs. Nicht nur weil ein Stakeholder das Gefühl hat, dass ihm falsche Hoffnungen gemacht wurden, sondern auch aus handfesten Gründen: es ist in vielen Unternehmen "best" practice, dass Boni und Jahresziele an die Umsetzung von Anforderungen geknüpft werden, und wenn die nicht erreicht werden stehen unangenehme Jahresgespräche bevor. In solchen Situationen ist es klar, dass die Betroffenen schnell in Krawallstimmung sind.

Also her mit der Heckenschere

Genug der guten Gründe und ans Werk. Her mit dem Backlog und raus mit allem was nicht wirklich nötig ist. Nur - wie? Wie wird entschieden was bleibt und was nicht? Nun, das wird ein Thema für einen eigenen Artikel.

Hierarchiefreie Kommunikation

Auch eine interessante Change Management-Geschichte: Der Stahlhändler Klöckner versucht Informationen schneller und effizienter im eigenen Unternehmen zu verteilen indem er "Hierarchiefreie Kommunikation" einführt, basierend auf einem firmeninternen sozialen Netzwerk. Hierarchiefrei bedeutet in diesem Fall horizontal, also durch direkte Ansprache des entsprechenden Kollegen und ohne Umweg über die jeweiligen Vorgesetzten.



Für viele Beschäftigte der Startup-Branchen, des Mittelstandes oder der IT-Industrie mag es zwar selbstverständlich sein direkt mit demjenigen zu reden für den man ein Anliegen hat, in Großunternehmen ist das allerdings häufig unüblich. Hier herrscht an vielen Stellen noch immer der Dienstweg, der erfordert, dass alle teamübergreifende Kommunikation über die jeweiligen Teamleiter und ggf. Unterabteilungs- und Abteilungsleiter zu erfolgen hat. Ein Vorgehen wie das von Klöckner kann in solchen Fällen dazu führen, dass sich Informationsverteilungen deutlich beschleunigen (in einem anderen Unternehmen habe ich miterlebt, dass bei einzelnen Vorgängen Monate (!) an Zeit eingespart werden konnten). Insofern eine bemerkenswerte Entwicklung.

Certified Scrum Professional

Seit letzter Woche bin ich dem (organisierten) agilen Olymp eine Stufe näher. Ich habe die Ruhephase zwischen zwei Aufträgen genutzt um mich bei der Scrum Alliance als Certified Scrum Professional (CSP) zertifizieren zu lassen, wodurch ich jetzt in der Verbandshierarchie eine Stufe oberhalb der Certified Scrum Master (CSM) oder Certified Scrum Product Owner (CSPO) stehe.

Überraschend finde ich, dass der CSP verhältnismässig einfach und billig zu bekommen ist. Man zahlt 250 $ und benötigt nur drei Jahre nachweisbare Berufserfahrung im Scrum-Umfeld sowie 70 so genannte "Education Units", die aber recht banal zu bekommen sind: ein paar Fachartikel, ab und zu bei einer User Group wie z.B. dem Bonner Scrumtisch vorbeischauen und das war es. Keine Prüfung, kein Lehrgang, keine Präsenzveranstaltung - im Grunde reicht es einfach seinen normalen Job zu machen und sich ab und zu in der Community sehen zu lassen. Angesichts dessen finde ich es erstaunlich wie wenige CSPs bisher vergeben wurden.

Im Zertifizierungs-Verzeichnis der Scrum Alliance findet man im Moment 384.800 CSMs, immerhin 84.200 CSPOs aber gerade einmal 4.600 CSPs. Lediglich ein Prozent (!) der zertifizierten Scrum Master und Product Owner nimmt die nächste Stufe, die anderen bleiben da wo sie sind. Das ist dürftig, vor allem wenn man bedenkt, dass viele große Unternehmen permanent nach irgendwelchen Zertifizierungen suchen mit denen sie ihre Weiterqualifizierungsquoten für ihre Belegschaft erfüllen können. Was könnte also der Grund für diese niedrige Zahl sein?

Eine gute Begründung hat mir ein in einem Konzern arbeitender Freund gegeben. "Klar, für Dich ist das einfach" meinte er, "aber Du machst ja auch was in dem Bereich. Für die Leute bei uns ist das viel schwerer, die sind ja nur zertifiziert." Hinter diesem "nur zertifiziert" dürfte tatsächlich ein wesentlicher Teil der Begründung liegen: bei einem sehr großen Teil der CSMs und CSPOs handelt es sich um ganz normale Team-, Abteilungs- und Bereichsleiter, die irgendwann mal aus irgendeinem Grund (siehe letzter Abschnitt) auf eine zweitägige Schulung geschickt wurden, danach aber einfach so weitergearbeitet haben wie bisher (das entspricht auch meinem Eindruck aus vielen Unternehmen). Denen dürfte bereits der Nachweis von drei Jahren Scrum-Erfahrung schwerfallen, und ohne die sind auch Fachartikel und Community-Engagement nur schwer vorstellbar.

Weiter gedacht würde das bedeuten, dass es sich bei der organisierten Scrum-Community um einen Scheinriesen handelt. Einer großen Gruppe Zertifikatsinhaber stehen nur wenige gegenüber die auch wirklich nach dieser Methode arbeiten. Schlecht für den State of Scrum, gut für mich als käuflicher Scrum Master und Scrum Coach. Vor allem da jetzt der CSP-Badge auf meinem CV meine Kompetenz noch strahlender zur Geltung bringt als ohnehin schon.

Wie technikfern darf ein Scrum Master sein?

Bild: Public Domain Files/US Department of Energy - Public Domain

Anscheinend hat das Thema gerade Konjunktur, seit ca. zwei Wochen bekomme ich gefühlt jeden zweiten Tag von irgendjemandem erzählt, dass er ohne IT-Kenntnisse Scrum Master oder sogar Scrum Coach sein kann, bzw. werden möchte. Nun sehe ich an mir selbst (Geisteswissenschaftler), dass das geht und auch durchaus annehmbar funktioniert. Sowohl ich als auch meine Teams sind in den letzten Jahren damit erfolgreich gewesen. Aber:

Selbst wenn ein Quereinstieg möglich ist würde ich sagen, dass ein komplett technikferner Scrum Master auf Dauer in Probleme hineinlaufen wird. Das beginnt schon bei einer der Kernaufgaben, dem Beseitigen von Impediments: wenn die Entwicklerrechner zu wenig RAM haben, wenn es zu wenige Testumgebungen gibt oder wenn die Teams mit Feature Branches in eine Merge-Hölle geraten, dann muss man das nicht selbst beheben können, man sollte aber verstehen können worum es geht, damit klar ist wie eine Lösung angestoßen werden kann. Auch bei Microservices, festen und dynamischen IDs, Code Covarage, TDD und vielem mehr ist ein gewisses Verständnis mehr als hilfreich. Allerdings:

Die Bereitschaft sich in diese Bereiche einzudenken und einzulernen ist leider nicht bei jedem gleichermassen vorhanden. "Ich glaube, ich brauche das nicht. Ich coache ja nur deren soziale und methodische Skills" durfte ich mir in einem Fall gerade erst anhören. Und das ist gefährlich. Der schönste Prozess und das beste Arbeitsklima bringen nichts, wenn die Anwendung so verschachtelt gebaut und so schlecht durch Tests abgesichert ist, dass jede User Story durch eine mehrwöchige Analyse- und Bugfixing-Phase muss bevor sie auf Produktion kann. Deshalb:

Kein Scrum Master muss Entwickler sein (und ganz nebenbei - selbst wenn man als einer angefangen hat kann man erstaunlich schnell aus der Übung kommen). Wenn man aber nicht in unkalkulierbare Risiken hineinlaufen will sollte man Technikferne als relativen und nicht als absoluten Begriff begreifen.

Die Verflechtungsfalle

Bild: Wikimedia Commons / Fallaner - CC BY-SA 4.0

Wieder einmal ist eine großartige Agile Cologne vorbei und für mich hatte sie diesesmal den gefühlten Schwerpunkt "Scrum und Management". Während meiner Session, aber auch in vielen anderen stellte sich dabei immer wieder die Frage, warum es auf allen höheren Hierarchie-Ebenen Menschen gibt, die sich vehement gegen die agile Transition stemmen. Neben einigen (zu) einfachen Erklärungsansätzen (z.B. der Angst vor Macht- oder Statusverlust) kamen auch komplexere zur Sprache, von denen ich einen hier vorstellen möchte: die Verflechtung, bzw. die Verflechtungsfalle. Ursprünglich für die Analyse politischer Systeme gedacht lassen sich diese von Prof. Fritz Scharpf entwickelten Begriffe auch auf sonstige Organisationen anwenden und bieten eine nachvollziehbare Deutung für scheinbar irrationales Managementverhalten.

Verflechtung

Verflechtung kann entstehen, wenn verschiedene organisatorische Ebenen oder Einheiten eine gemeinsame Verantwortung für eine Organisationseinheit oder ein Ergebnis haben, für die sie sich eng abstimmen müssen. Eine typische Folge davon ist eine umfangreiche Koordinations-, Kooperations- und Kontrollbürokratie, die zum einen hemmend und dysfunktional ist, aber auf der anderen Seite immer weiter ausgebaut wird (basierend auf dem Irrglauben, damit die Dysfunktionalität auflösen zu können). Ab einem gewissen Punkt wirken die Prozesse und Vorschriften so stark verlangsamend und verkomplizierend, dass die Beteiligten nach Wegen suchen sie zu umgehen: es entstehen informelle Parallelstrukturen, in die sich immer weitere Entscheidungswege verlagern - die so genannte brauchbare Illegalität, über die ich letztes Jahr geschrieben habe. Die Überlagerung und Zunahme der formellen und informellen Strukturen ergibt in Summe das Phänomen der Verflechtung.

Die Verflechtungsfalle

Anders als man denken könnte liegt es häufig nicht im Interesse der Beteiligten die Verflechtung aufzulösen. Wer informell bestimmte Entscheidungskompetenzen gewonnen hat will sie nicht verlieren, umgekehrt wollen viele der formell zuständigen Personen sie nicht zurückhaben, da sie Überarbeitung oder Überforderung fürchten. Das obere Management will die Koordinations- und Kontrollprozesse nicht aufgeben, da sie ein Gefühl (bzw. die Illusion) von Kontrolle vermitteln, die mittleren Hierarchieebenen wiederum verdanken diesen Prozessen häufig ihre gesamte berufliche Existenzberechtigung und verteidigen sie entsprechend verbittert. Ein spezieller Fall liegt vor, wenn Teile des Managements kontraproduktive oder fehlerhafte "Verbesserungsmassnahmen" durchgeführt haben, z.B. die Einführung von Scrum nur in einigen IT-Teams bei gleichzeitiger Beibehaltung von Wasserfall im restlichen Unternehmen. Da der eigene Name und häufig die eigene Karriere mit diesen Massnahmen verbunden sind werden ihre negativen Auswirkungen oft auch dann noch abgestritten wenn sie für alle Beteiligten offensichtlich sind.

Der gordische Knoten

Ist ein Unternehmen in eine Verflechtungsfalle getappt kann es sich aus den genannten Gründen nur sehr schwer aus ihr befreien. Ähnlich wie im Fall des gordischen Knotens ist die Situation in vielen Fällen so verworren, dass eine Entwirrung einen Komplexitätsgrad am Rand der Unlösbarkeit erreicht. Als einzige Lösung bleibt dann die Zerschlagung des Knotens, was in diesem Fall ein komplettes Zurücksetzen aller Prozesse auf Null und einen sauberen Neustart bedeutet. Das ist eine radikale und nicht immer machbare Methode, allerdings eine die die verschiedenen Widerstände abschwächen kann. Da das Gesamtsystem zurückgesetzt wird kommt es nicht zu individuellen Schuldzuweisungen oder Karriereknicks von Einzelpersonen, zudem bietet der Neustart allen Beteiligten die gleichen Möglichkeiten die umstrittenen Zuständigkeiten und Verantwortlichkeiten zu bekommen, zu behalten oder abzuwehren. Natürlich ist auch das mit Risiken verbunden, weshalb es auch hier zu Abwehrreaktionen kommen kann. Durch die Loslösung von Einzelfällen, bzw. Einzelpersonen gibt es allerdings weniger Anreize diese bis zur letzten Konsequenz durchzuziehen.