Kommentierte Links (CII)

Bild: Unsplash / Fabio Bracht - Lizenz

Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

W. Chan Kim, Renée Mauborgne: Innovation Doesn’t Have to Be Disruptive

Disruption, also die Verdrängung eines etablierten Produkts oder Unternehmens durch neu aufkommende innovative Konkurrenz, wird im Agile- oder Start Up-Kontext immer wieder thematisiert, sei es als Treiber für Veränderungen oder als anzustrebendes Ziel der eigenen Produktentwicklung. W. Chan Kim und Renée Mauborgne weisen allerdings völlig zu Recht darauf hin, dass Innovation nicht zwingend disruptiv sein muss. Anhand zahlreicher Beispiele zeigen sie auf, dass es auch gelingen kann, neue Märkte aus dem Nichts heraus entstehen zu lassen. Ein durchaus erstrebenswertes Ziel.

Mikael Vesavuori: From Technical Debt to Technical Health with HealthCheck

Technische Schulden sind ein ähnlich häufig zitiertes Buzzword wie Disruption, was darunter verstanden wird kann aber weit voneinander abweichen. Mikael Vesavuori geht mit einem großen Anspruch in seinen Artikel hinein: er will nicht nur das Konzept verständlich machen, er will es auch ausdifferenzieren, Hintergründe aufzeigen, die Entstehung erklären, das Ganze messbar machen und Wege aufzeigen wie man sich wieder daraus befreit - und das Ganze so, dass auch jemand ohne IT-Hintergrund es verstehen kan. Es dürfte wenig überraschend sein, dass sein Text sehr lang geworden ist, er ist aber gleichzeitig auch sehr gut.

Barry Overeem: How We Made Our Customer The Product Owner

Dieser Blogpost von Barry Overeem ist mit einem bisschen Vorsicht zu lesen, denn wie er am Ende schreibt ist es kein wirklicher Erfahrungsbericht, sondern zusammengesetzt aus verschiedenen Erlebnissen, die er mit verschiedenen Teams gemacht hat. Er enthält aber einige Ideen die auch ich bereits in der Realität beobachten konnte, darunter die beiden wichtigsten: die Beauftragung ganzer Scrum Teams auf Basis einzelner Sprints und die Übernahme der Product Owner-Rolle durch den Kunden. Das kann gut funktionieren, ist aber abhängig vom Kontext. Im hier von Overeem beschriebenen (einer Webdesign-Agentur) kann ich es mir sehr gut vorstellen, in grösseren (z.B. einem Konzern-Projekt) wäre es deutlich schwieriger.

Karl Scotland: The Evidence To Look For In A Successful Agile Transformation

Über die Frage, wann eine agile Transformation abgeschlossen ist, kann man wunderbar philosophieren. Eine klare Antwort gibt es nicht, aber einen guten Ratschlag: man sollte sich im Voraus messbare Ziele überlegen an denen man erkennen kann, dass man voran kommt, und die dann regelmässig überprüfen. Die von Karl Scotland ausgewählten Zielwerte Produktivität, Vorhersagbarkeit, Reaktionsfähigkeit, Qualität, Nachhaltigkeit und Wertschöpfung gehen genau in diese Richtung, da sie tatsächlich quantifizierbar und überprüfbar sind. Ob sie dauerhaft die Richtigen sind wird sich von Fall zu Fall unterscheiden, auf jeden Fall kann man aber gut mit ihnen anfangen.

Alexander Ryazanov: Fixing Agile development

Die Überschrift von Alexander Ryazanovs Artikel hängt die Messlatte sehr hoch und ist auch sicher als Clickbait gedacht, seine Ideen finde ich aber sehr richtig. Was mir darüber hinaus gefällt sind seine zuerst einfach erscheinenden, gerade deshalb aber gut nachvollziehbaren Visualisierungen. Etwas was ich bei Gelegenheit in meinen Workschops ausprobieren werde.

Die Verflechtungsfalle (II)

Bild: Flickr / Oregon State University - CC BY-SA 2.0

Unter den gedanklichen Konstrukten, die ich aus der Politikwissenschaft in meinen Beruf übernommen habe, ist die Verflechtungsfalle einer meiner Favoriten. Sie beschreibt die Situation in der sich überschneidende Verantwortlichkeiten zu einer Koordinations-, Kooperations- und Kontrollbürokratie führen, die alles lähmt, die aber auch einen derartigen Komplexitätsgrad hat, dass sie nur mit erheblichen Aufwänden wieder auflösbar ist. Fast alle grossen Organisationen sitzen in dieser Falle.

In welcher Form sie auftritt kann von Fall zu Fall unterschiedlich sein, es gibt aber einen grossen, immer wieder anzutreffenden Klassiker: eine Matrix-Organisation, die einer auf dem Anforderungsmanagement basierenden Budgetplanung unterliegt. Eine derartige Struktur ist ein fast sicherer Garantiefaktor für das Zuschnappen der Verflechtungsfalle - und bemerkenswerterweise ist sie trotzdem die Grundlage für das Organisationsdesign vieler Grossunternehmen.

Wie sieht das in der Realität aus? Zunächst so, dass die Verantwortung für einzelnen Programme, Projekt- oder Produktteams aufgeteilt wird. Häufig ist eine Trennung in Personal- und Produktverantwortung, auch die lassen sich aber nochmal unterteilen. Die Produktverantwortung lässt sich z.B. trennen in Entwicklung und Betrieb, der Personalverantwortung in Disziplinarisch und Fachlich. Es wirken also zwei, drei, vier (oder noch mehr) Manager gleichzeitig auf die Menschen der Umsetzungs-Ebene ein.

Das verkompliziert sich nochmal dadurch, dass die Gruppen, auf die die jeweiligen Manager einwirken, sich nur zum Teil überschneiden. So sind z.B. die Projektleiter für ihre jeweiligen Projekte zuständig, die Abteilungsleiter für jeweils eine über alle Projekte verteilte Gruppe von Spezialisten (etwa die Frontend-Entwickler) und die Architekten dafür, dass diese Menschen sich in bestimmten Themenfeldern (etwa bei der Weiterentwicklung des Intranets) an bestimmte system- und projektübergreifende Standards halten.

Alleine das wäre schon ausreichend, um für regelmässige Abstimmungsprobleme zu sorgen, aber jetzt kommt die Budgetierung dazu. In solchen Konstellationen verfügen in der Regel die Programm- oder Projektleiter über die Budgets. Diese nutzen sie um auf einem unternehmens-internen Markt von den Abteilungen jeweils die Spezialisten einzukaufen, mit denen die gerade anliegenden Anforderungen umgesetzt werden können. Und nur damit werden diese dann beauftragt.

Die anderen Manager bringt das in ein Problem. Die Ziele der Personalentwicklung (z.B. alle lernen regelmässig neue Programmiersprachen) oder der Architektur (z.B. alle Anwendungen bestehen aus Self Contained Systems) können den Zielen der Produktentwicklung widersprechen, da sie die Umsetzung von Anforderungen temporär oder dauerhaft verlangsamen würden. Da aber an der Produktentwicklung das Budget hängt, droht allen anderen Zielen permanent das Schicksal "wegpriorisiert" zu werden.

Um diesem Schicksal zu entgehen, wird oft versucht, auf einem anderem Weg als über das Budget Einfluss auf die Produktentwicklung zu nehmen. Es gibt beispielsweise Organisationen, in denen Architekten unternehmensweit geltende Entwicklungsvorschriften machen können, deren Einhaltung in einer Qualitätssicherungsphase überprüft wird. Und die Abteilungsleiter können ihre Ziele in die Jahresziele ihrer Untergebenen schreiben, wodurch die versuchen werden, sie irgendwie unterzubringen.

Die häufige Folge eines solchen Organisationsdesigns ist eine auf allen Ebenen ausgetragener ständiger Zielkonflikt, bestehend aus Verhandlungen, Eskalationen, verweigerten Freigaben, zurückgehaltenen Informationen, Kompromissen und Versuchen vollendete Tatsachen zu schaffen, wodurch sich alle Beteiligten gegenseitig behindern. Und wenn dann auch noch jeder Manager Teile seines Gehalts mit der Erreichung seiner Ziele verknüpft hat, wird er für ein solches Verhalten sogar noch belohnt.

Wenn es das Ziel einer Organisation ist, agile Produltentwicklung zu betreiben, ist das alles natürlich nicht zielführend. Wie man davon wegkommt hängt sehr von der Ausgangssituation ab, gute Ideen sind aber, Produkt- und Personalverantwortung zusammenzulegen, die Verfolgung gegenläufiger Ziele nicht zu belohnen (alleine das wäre ein Thema für sich) und die Budgetierung nicht mehr auf Anforderungen beruhen zu lassen sondern auf stabilen, produktorientierten Teams.

In fast allen Fällen sind das tiefgreifende Eingriffe in die bisherigen Strukturen und Abläufe, wodurch das unschöne Kriterium erfüllt wird, das aus einer Verflechtung die Verflechtungsfalle macht - man kommt nur schwer wieder heraus. Aber man kommt heraus, wenn man es darauf anlegt. Ganz nebenbei ist das auch ein guter Test um herauszufinden, wie ernst es mit der Agilität gemeint ist. Dort, wo es keine derartigen Anpassungen gibt, im Zweifel nicht so sehr.

Uncoupling

Ich sage es immer wieder, ein zentraler Schlüssel zu mehr Agilität ist der Abbau von Abhängigkeiten. Das bezieht sich auf Organisationen und Prozesse, es bezieht sich aber auch auf Software. Michael Nygard zeigt sehr schön auf, warum das so ist und was man dagegen tun kann.

Was man an seinem Vortrag besonders hervorheben kann ist, dass er Zusammenhänge der Softwareentwicklung so erklärt, dass man ihm in weiten Teilen auch ohne Informatik-Expertise folgen kann. Er ist daher gut geeignet um Stakeholdern ausserhalb der IT Problemfelder aufzuzeigen.

Dreistunden-Sprints

Bild: Pixabay - Mabel Amber - Lizenz

Zu den Firmen, die in der agilen Community gehypt und als Vorbild gesehen werden, gehört seit einigen Jahren auch Tesla. Dass das so ist, hängt weniger damit zusammen, dass man wirklich weiss wie dort gearbeitet wird, und mehr mit einem bekannten "Methodenbotschafter". Joe Justice hat dort als Agile Coach gearbeitet und erzählt oft von dieser Zeit (zum Beispiel hier). Und die eine Erzählung die zum "agilen Mythos" von Tesla beiträgt ist diese: dort gibt es Teams, deren Sprint nur drei Stunden dauern.

Wie genau das vor sich geht, verrät er mit Verweis auf eine Geheimhaltungsvereinbarung nicht, er betont aber, dass am Ende jedes Sprints ein Increment steht, was durchaus beeindruckend ist. Wenn wir jetzt unterstellen, dass sich dahinter nicht nur eine Fantasie-Geschichte verbirgt, sondern ein echter Erfahrungsbericht, verlockt all das sehr zur Spekulation. Wie kann es Tesla wohl geschafft haben, auf diese unglaublich wirkenden Lieferzyklen zu kommen?

Um mit etwas nicht Unwesentlichem zu beginnen - es ist nicht so, dass alle Teams diese schnelle Taktung haben. Justice berichtet selber, dass es nur einige Teams sind die so organisiert sind, bei anderen dauert es deutlich länger, bis zu drei Monaten.¹ Das relativiert die Geschichte bereits ein bisschen, alleine deshalb weil nicht klar wird, wie die Mengenverhältnisse sind. Würden z.B. nur 10 Prozent der Teams in Dreistunden-Sprints arbeiten wäre das immer noch beachtlich, aber nicht so sehr wie bei 90 Prozent.

Eine zweite wesentliche Rahmenbedingung ist die, dass es sich nicht um Sprints handelt, wie wir sie aus Scrum kennen. Scrum ist für eine bis vier Wochen konzipiert und würde in derartig kurzen Zeiträumen für Meeting-Overhead sorgen, dazu kommt, dass es die zentrale und im Framework zwingend vorgegebene Scrum Master Rolle laut Justice bei Tesla nicht gibt. Dort wird also nicht nach Scrum gearbeitet. Um welche andere Variante von Sprints es sich handelt, bleibt offen, es könnten z.B. auch Endsprints sein.

Eine dritte Information gibt es wieder bei Justice selbst: bei vielen Teams handelt es sich nicht um langfristig stabile Produktteams, sondern um Ad hoc-Teams, die kurzfristig in einem Open Space-artigen Prozess aus den gerade verfügbaren Mitarbeitern zusammengestellt werden. Das bedeutet aber auch, dass diese Teams nicht alle drei Stunden, bzw. jeden Sprint, ein Increment liefern, alleine deshalb nicht, weil sie sich nach jedem Sprint wieder auflösen und ihre Mitglieder ins nächste Ad hoc-Team wechseln.

Mit diesem Wissen im Hinterkopf - möglicherweise ist es am Ende viel banaler als man denkt. Ein Teil der Mitarbeiter arbeitet in tage-, wochen- oder monatelangen Zyklen mehr oder weniger agil, nur der andere Teil findet sich in kurzfristig gebildeten Ad hoc-Teams zusammen, die dann relativ kleine Aufgaben übernehmen (etwa den Austausch eines Maschinen-Bauteils oder das Anpassen eines Formulars auf einer Webseite). Und diese schnellen Klein-Arbeiten nennt man dann "Sprint".

Wie es wirklich ist wird man wohl erst erfahren, wenn Tesla Wissenschaftler oder Journalisten in die Fabriken lässt. Bis dahin werden die Dreistunden-Sprints als Mythos durch die agile Community ziehen und zum Ruf von Tesla beitragen. Und möglicherweise ist das auch genau so gewollt.

¹Je nach Vortrag spricht er manchmal statt Sprints von Projekten. Diese Gleichsetzung wäre nochmal ein Thema für sich.

Dev/Non-Dev Ratio (II)

Bild: Unsplash / Jud Mackrill - Lizenz

Dass es in einer Software entwickelnden Organisation schwierig ist, wenn nur eine Minderheit der Angestellten selbst in der Lage ist zur Software-Entwicklung beizutragen, dürfte nachvollziebar sein. Das Risiko ist in solchen Fällen gross, dass es zu Silo-Bildung, Prozess-Overhead und Arbeits-Rückstaus kommt. In grossen Organisationen ist diese Problemlage aber oft nicht ohne weiteres ersichtlich, so dass ihre Entdeckung oft überraschend wirkt.

Der Grund dafür ist die fehlende Einsicht der meisten Beteiligten in die tatsächlichen Mengenverteilungen. Damit ist weniger gemeint, dass keinem bewusst ist, wie wiele Entwickler im Unternehmen sind und wie gross ihr Anteil an der Gesamtbelegschaft ist, vielmehr geht es darum, dass nur den wenigsten Mitarbeitern ausserhalb der IT klar ist, wer (ausserhalb der eigenen Abteilung) sie regelmässig beauftragt, mit was und in welchem Umfang.

Irgendwo gibt es zwar eine Portfolio- und Aufwandsplanung, aus der man herleiten könnte, für wen alles intern Software entwickelt wird, meistens ist die aber nicht so einfach zugänglich, man sieht nur das was einen selbst betrifft. Und so lange Organisation so aufgebaut sind, dass IT und Fachabteilungen eigene organisatorische Einheiten sind (in der Regel nochmals mit einer auf Funktionen basierenden Aufteilungen in Untergruppen), wäre das Gewinnen eines Gesamtbildes auch relativ aufwändig.

Im Rahmen agiler Transformationen gibt es aber einen Punkt, an dem die Mengenverteilungen schlagartig offensichtlich werden, nämlich dann, wenn versucht wird, die Organisation auf Value Stream- oder Produktorientierung umzustellen. Im Rahmen einer solchen Umstellung werden in der Regel alle Fachspezialisten, Produkt- und Projektmanager, Kundenbetreuer, Marketing- und Vertriebsmitarbeiter und eben Softwareentwickler in einer Einheit oder einer Querschnittsorganisation zusammengefasst.

Dort wo ich derartige Umstellungen in Grossorganisationen erlebt habe, waren am Ende (je nach Produktschnitt) zwischen 10 und 30 Menschen in einer solchen Produkt- oder Value Stream-orientierten Einheit zusammengefasst. wovon (und jetzt kommt es) in fast allen Fällen weniger als 10 Prozent Software entwickeln konnten. Ich kann mich sogar an Fälle in verschiedenen Firmen erinnern, in denen es mehr Value Streams als Entwickler gegeben hat.

Je nach Einzelfall kann man zwar immer argumentieren, dass es immer auch eine Reihe von Nicht-Entwicklungstätigkeiten für das jeweilige Produkt braucht, Fälle wie die gerade genannten (von denen es in grossen Organisationen erstaunlich viele gibt) sind aber offensichtlich dysfunktional und erinnern völlig zu Recht an das Single worker digging hole-Meme. Und dass eine solche Situation nur in einem Nerven- und zeitfressenden Kampf um die knappen Kapazitäten enden kann, dürfte auch klar sein.

Anders als in vielen anderen Fällen ist in einer solchen Situation die Lösung auch realativ klar: man kann entweder die Umsetzungskapazität in der Software-Entwicklung ausbauen (Leute einstellen) oder den umgebenden Overhead abbauen (Leute entlassen oder versetzen). Und wenn man sich dazu nicht durchringen kann sollte man zumindest eines Allen klarmachen - wenn man irgendein Ergebnis nicht so schnell bekommt wie man es gerne hätte liegt das nicht daran, dass die IT so langsam ist, sondern dass die Dev/Non-Dev Ratio völlig unausgewogen ist.

Willkürliche Deadlines (II)

Bild: CCNull / Marco Verch - CC BY 2.0

Dass willkürlich gesetzte Deadlines problematisch sind, dürfte wohl bei kaum jemandem einen Widerspruch auslösen. Dass sie trotzdem immer wieder anzutreffen sind, hat menschliche und politische Gründe, die leider immer wieder vorkommen werden. Wer in einem solchen Umfeld beruflich unterwegs ist, muss sich daher mit diesem Thema beschäftigen und sollte am Besten überzeugende Gründe parat haben, warum sie keine gute Idee sind.

Zu den überzeugendsten dieser Gründe dürfte gehören, dass willkürliche Deadlines negativ auf den zurückfallen, der sie festlegt. Das ist zunächst für viele Menschen kontraintuitiv, schliesslich scheint in solchen Fällen der schwarze Peter doch bei denen zu liegen, die die gesetzten Fristen nicht einhalten können. Ein Praxisbeispiel zeigt aber, dass auch die andere Seite in Mitleidenschaft gezogen werden kann: das Onlinezugangsgesetz (OZG).

Das OZG wurde im Jahr 2017 im Parlament verabschiedet und legte fest, dass bis zum Jahr 2022 alle Behördengänge auch digital zu erledigen sein müssen. Der letzte Tag dieses Jahres, der 31.12.2022, wurde damit automatisch zur Deadline für die Umsetzung. Schon damals gab es Zweifel, dass diese Fristsetzung realistisch war, mittlerweile weiss man, sie war es nicht. Selbst Monate später sind erst 101 von 600 geplanten Leistungen online.

Die offensichtlichste Folge eines solchen Verzuges: weitere Fristsetzungen verlieren durch ihn ihre Glaubwürdigkeit nach aussen. Neben der fristsetzenden und der (verspätet) umsetzenden Seite gibt es nämlich fast immer eine dritte Partei, die externen Stakeholder. Und um beim Beispiel des OZG zu bleiben: verschiedene Kommentare in den Medien lassen keinen Zweifel daran, dass zukünftigen Zielsetzungen nicht mehr vertraut wird.

In Folge dessen werden zukünftige Zeitpläne von Anfang an mit grosser Skepsis begleitet, regelmässig hinterfragt und mit der ständigen Forderung nach Transparenz in Form von Zwischen-Fristen und Zwischen-Berichten konfrontiert. Diese führen bei allen Beteiligten zu z.T. erheblichen Mehraufwänden, die die Umsetzung nochmals verzögern und dadurch selbst solche Teilziele gefährden, die eigentlich erreichbar gewesen wären. Auch hierzu gibt es Beispiele aus dem OZG-Umfeld.

Anders, aber ähnlich schwerwiegend sind die Folgen nach innen. Das offensichtliche und deutliche Verpassen der Frist führt nämlich bei den mit den unrealistischen Umsetzungszielen beauftragten Menschen zu der Erkenntnis, dass ein solcher Verzug eigentlich kein Problem ist, schliesslich gibt es keine negativen Folgen (die meistens einzig vorhandene Sanktionsmöglichkeit, das Entziehen von Mitteln, würde schliesslich nur zu noch mehr Verzögerung führen).

Ist dieser Eindruck erstmal entstanden, kann von einem weiteren Effekt fast sicher ausgegangen werden - ohne ernsthafte Konsequenzen schwindet die Motivation, sich bei der Umsetzung über das übliche Mass hinaus zu engagieren. Selbst mit relativ geringen Mehraufwänden erreichbare Zieldaten lässt man verstrechen, erst recht wenn diese in einer grösseren Menge von Bitten, Forderungen und Eskalationen untergehen, von denen "alles wichtig ist". Es kommt ungewollt zur Erziehung zur Normverletzung.

In Summe entsteht so durch willkürliche Deadlines extern ein grundlegender Zweifel, der durch (gut gemeinte) Kontrollmassnahmen alles noch weiter verzögert und intern ein gewisser Nihilismus, der Eigeninitiative und Engagement verdrängt und ab einem gewissen Grad sogar dazu führt, dass es zu einer Abstimmung mit den Füssen kommt, also zu Kündigungen, durch die es nochmal zu zusätzlichen Verzögerungen kommt.

Ich habe als externer Berater Fälle erlebt, in denen willkürliche Deadlines zu solchen Aufwands-Explosionen geführt haben, dass eigentlich nur leicht verspätete Vorhaben sich um Jahre verlängert haben oder sogar abgebrochen werden mussten - häufig verbunden mit einem empfindlichen Karriereknick der verantwortlichen Manager. Und alleine die Aussicht das am eigenen Fall zu erleben sollte eigentlich ein überzugender Grund sein, sich bei "ambitionierten Zielsetzungen" zurückzuhalten. Schliesslich kann nicht jeder Probleme so einfach aussitzen wie die Digitalisierungs-Politiker.

Compliance as Code Done Right

In vielen Entwicklungsteams ist Compliance (die Ausführung, Überwachung und Dokumentation von regelkonformem Verhalten) etwas das sie zutieft verabscheuen, da es bürokratisch und aufwändig ist. Effy Elden zeigt auf, dass das nicht so sein muss. Integriert in den Code kann Compliance zu einem Teil der Entwicklung werden, der ähnlich zu entwickeln ist wie die restliche Anwendung.

 

 

Was sie hervorhebt, und was aus meiner Sicht auch richtig ist, ist, dass Compliance as Code nicht ohne Vertrauen in die Entwicklungsteams machbar ist. Im Quelltext vorhandene Kontrollen können nur von Entwicklern auf Konsistenz und Wirksamkeit überprüft werden. Allerdings: klassische Compliance-Prozesse der IT bestehen häufig auch nur aus Checklisten, in denen Entwickler durch das Setzen von Haken bestätigen müssen, dass sie sich an alle Regeln gehalten haben. Auch in dem Fall muss man darauf vertrauen, dass sie wissen, was sie tun.

Ein Bild sagt mehr als 1000 Worte (XXXVII)

Heute ist das eine Bild das mehr als 1000 Worte sagt ein Klassiker. Ich habe es vor einiger Zeit bei einem Kunden erstellt, angelehnt ist es an das bekannte Original von Klaus Leopold. Die Aussage ist bei beiden die gleiche: so funktioniert Agilität nicht.

"We are soooo Agile but we don't see any improvement in TTM." Really?! Guess why? pic.twitter.com/zEIvmU9aCV

— Klaus Leopold (@klausleopold) August 13, 2017

BTW: dass ich das Original nicht einfach übernommen habe liegt daran, dass die Abläufe dieses Kunden etwas anders waren.