Mittwoch, 31. August 2022

Kommentierte Links (XCI)

Bild: Pixabay / Buffik - 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.

Ebenezer Ikonne: In Praise of Mandates

"Ein Lob der Vorschriften", in etwa so könnte man den Titel dieses Artikels von Ebenezer Ikonne übersetzen. Angesichts der Neigung vieler Agilisten, alle von aussen kommenden Vorgaben kategorisch abzulehnen, eine hochgradig kontroverse Aussage - aber auch eine die hier nachvollziehbar begründet wird. Vorschriften können dabei helfen Unklarheiten und Mehrdeutigkeiten zu vermeiden, sie können Handlungsspielräume definieren und Qualitätssicherungsmassnahmen verpflichtend machen. Auch die Eigenschaften guter Vorschriften arbeitet Ikonne heraus: sie müssen einfach verständlich und umsetzbar sein, für den der sich an sie halten muss müssen sie Sinn ergeben, sie dürfen nicht in Widerspruch zu anderen Vorschriften stehen und ein Nichtbefolgen muss mit (wie auch immer gearteten) Folgen verbunden sein. Derartige Vorschriften sollten dann auch wieder mit agilem Arbeiten kompatibel sein.
[Btw: eine kritischere Sicht gibt es bei Jason Yip: Cross-pollination over imposed standards]

Kent Beck: Better/Sooner/Cheaper/More

Im (IT-)Projektmanagement gibt es das alte Sprichwort, dass es die drei Ziel-Dimensionen Gut, Schnell und Billig gibt, von denen man aber maximal zwei gleichzeitig erreichen kann. Kent Beck, der Erfinder der Extreme Programming-Frameworks (XP), fügt noch eine vierte hinzu, die Menge des gelieferten Mehrwerts. In seinen Worten ergeben sich so die Dimensionen Better, Sooner, Cheaper und More. Seine Überzeugung: wenn Extreme Programming richtig umgesetzt wird ist es sogar möglich, immer drei dieser vier zu erreichen, wobei die erste, Better, in jedem Fall dabei ist (über sie hat er noch einen zweiten, weiterführenden Artikel geschrieben). Das klingt zwar gewagt, kommt aber eben auch von jemandem der in grossen Firmen wie Chrysler und Facebook bewiesen hat, dass er weiss wie man agile Produktentwicklung erfolgreich umsetzt.

Itamar Gilad: How To Learn From FAANG

Apropos grosse Firmen. Eigentlich sollte man immer sehr vorsichtig sein wenn versucht wird aus den Arbeitsweisen bekannter Unternehmen Handlungsempfehlungen abzuleiten, an die man sich halten muss um auch erfolgreich zu sein. Das was Itamar Gilad hier aus den FAANG-Konzernen (Facebook, Apple, Amazon, Netflix, Google) zusammengetragen hat geht aber über das blosse Kopieren von Praktiken wie Tribes oder OKRs hinaus. Er konzentriert sich eher auf grundlegende Prinzipien, wie z.B. die, dass technikferne Personen keine Entscheidungen zu technischen Produkten treffen sollten, oder dass Produkte immer von (teil-)autonomen, crossfunktionalen Teams entwickelt werden sollten (und nicht von auslastungs-optimierten Komponententeams). Das ist tatsächlich zur Nachahmung empfohlen.

Tobias Haar: Selbstständige Scrum-Entwickler wohl ohne Sozialversicherungspflicht

Dieses Urteil hat das Potential die deutsche Software-Industrie deutlich in Richtung Agilität zu verschieben. Zum Hintergrund: um mögliche Fälle von Scheinselbstständigkeit von vornherein auszuschliessen werden in vielen Unternehmen externe Entwickler von einem Grossteil der Meetings, Informationen und Tools ausgeschlossen. Gemischte interne/externe Scrum Teams sind dadurch dort de facto unmöglich, was sowohl für Firmen als auch für Freelancer ein echtes Problem ist. Das Landessozialgericht Baden-Württemberg hat nun geurteilt, dass externe Entwickler in Scrum Teams aufgrund der dort gegebenen Selbstorganisation nicht weisungsgebunden und damit nicht scheinselbstständig sein können. Sollten weitere Gerichte dem folgen wären gemischte Teams wieder in allen Unternehmen möglich. Und für alle Fans der Juristerei: hier ist der Originaltext des Urteils.

John Coleman: Talking about Sizing and Forecasting in Scrum

Auch diesesmal führt der letzte kommentierte Link zu einem Longread. Mit dem Themenkomplex des Schätzens, Kleinschneidens und Prognostizierens hat sich John Coleman ein Thema ausgesucht zu dem es viele verschiedene Meinungen, Werkzeuge und Erfahrungswerte gibt, die er zusammenfasst und einordnet. Den Königsweg kann natürlich auch er nicht aufzeigen, nach dem Lesen seines Artikels ist man aber sehr gut über den aktuellen Stand informiert und wird vieles gelernt oder aufgefrischt haben was auch im eigenen Team nützlich sein kann.

Montag, 29. August 2022

Agile Demenz

Bild: Pixabay / Saiyed Hirfan - Lizenz

Es gibt eine Erfahrung, die so ziemlich jeder Scrum Master oder Agile Coach schon einmal gemacht haben dürfte: Die initialen Schulungen sind schon lange vorbei, im Arbeitsrhythmus des Teams oder Projekts ist eine gewisse Routine eingekehrt, es gibt auch keine grundlegenden Akzeptanzprobleme des methodischen Vorgehens - aber plötzlich hat ein Grossteil der Kollegen in den Entwicklungsteams das agile Methodenwissen weitgend vergessen und fährt deswegen wichtige Prozesse vor die Wand.


Dieses Phänomen, in Fachdiskussionen oft flapsig als "agile Demenz" bezeichnet, wirkt zwar nach aussen wie ein wiedererkennbares und sich wiederholendes Muster, tatsächlich können dahinter aber sehr unterschiedliche Ursachen stehen (von denen ggf. auch mehrere gleichzeitig vorhanden sein können). Je nachdem welche das sind können dementsprechend unterschiedliche Gegenmassnahmen die jeweils vielversprechendsten sein.


Ein häufiger Grund dafür, dass methodische Aspekte in Vergessenheit geraten ist eine zu hohe Kompliziertheit. Das kann man immer wieder bei SAFe mit seinen zahlreichen Rollen und Prozessen beobachten, aber auch Kanban-Systeme mit zu vielen Policies und Scrum-Umsetzungen mit einer zu kleinteiligen Definition of Done gehören z.B. dazu. In solchen Fällen kann eine Verschlankung des Regelwerks ein guter Weg sein, um eine bessere Erinnerbarkeit herbeizuführen.


Eine verwandte Ursache ist gegeben wenn die Methodik zwar für sich genommen einen überschaubaren Umfang hat, in Relation zur zu lösenden Herausforderung aber unproportional aufwändig ist. Das kommt z.B. dann immer wieder vor, wenn in stabilen, nicht-komplexen Umgebungen nach Scrum (o.Ä.) gearbeitet wird. Für die Beteiligten fühlt sich das schnell wie Bürokratie an, mit der man sich lieber nicht gedanklich befassen will. Auch hier ist Reduktion ratsam.


Ein anderer Grund kann der hohe Anteil an Fach-Vokabular sein, das vor allem für Menschen mit geringen Englischkenntnissen verwirrend sein kann. Die naheliegende Gegenmassnahme wäre die Verwendung von deutschen Worten und einfacher Sprache, die allerdings mit Vorsicht eingesetzt werden sollte. Zwar mag sie intern einiges verständlicher machen, die Kommunikation mit Geschäftspartnern oder das Verständnis von Fachliteratur können aber darunter leiden.


Immer wieder anzutreffen ist die Situation, in der das Methodenverständnis durch eine dauerhaft zu hohe kognitive Belastung verschwindet. Dort wo herausfordernde Fachlichkeit, hochvernetzte Technik und Zeitdruck zusammenkommen ist es nur menschlich, dass (ggf. unbewusst) versucht wird durch das Ausblenden von Themengebieten diese Überlastung zurückzufahren. Die Lösung kann hier nur sein, die Belastung der Menschen zurückzufahren, sonst kann mehr verlorengehen als nur Methodenwissen.


Abgeleitet davon kann schliesslich noch eine weitere Konstellation vorkommen: wenn versucht wird die kognitive Gesamt-Belastung dadurch gering zu halten, dass die Beschäftigung mit Prozess- und Methodenthemen komplett zum Scrum Master oder Agile Coach geschoben wird, dann können diese dadurch im Arbeitsalltag der anderen so wenig präsent sein, dass es hochwahrscheinlich ist, dass sie in Vergessenheit geraten. Dieses "Wegschieben" ist daher eine eher schlechte Idee.


Alleine das Nebeneinanderhalten der letzten beiden Fälle zeigt, dass die Identifizierung von Gründen für die "agile Demenz" zwar möglich ist, einfache Gegenmassnahmen aber der Vielschichtigkeit der Situation aber kaum gerecht werden. Wie so oft im Umfeld des agilen Arbeitens wird daher auch hier kein Weg an ständigem Inspect & Adapt vorbeiführen, um durch ständige Optimierungen dafür zu sorgen, dass die Arbeitsmethodik von allen Beteiligten erinnert und verstanden wird.

Freitag, 26. August 2022

Agilität aus soziologischer Perspektive

Als ursprünglicher Geisteswissenschaftler, den es irgendwann in IT und Projektmanagement verschlagen hat, bin ich grosser Fan von Stefan Kühl. Als Soziologie-Professor der zum Thema Agilität forscht dürfte er einer der wenigen Kenner der Thematik sein, der selbst ausserhalb der Gruppe der Anwender und Erfinder der agilen Frameworks steht, weshalb er eher als viele andere zu einer neutralen Betrachtungsweise in der Lage ist.



Was ihn gleichzeitig von den meisten in seinem Bereich forschenden Wissenschaftlern unterscheidet ist die Fähigkeit pointiert und unterhaltsam zu sprechen. Dieser Talk zum Thema der Formalitäts-Affinität oder Formalitäts-Aversion agiler Organisationen ist ein schönes Beispiel dafür.

Dienstag, 23. August 2022

Ein Bild sagt mehr als 1000 Worte (XXXIII)

Grafik: Monkey User - Lizenz

Freitag, 19. August 2022

Fullstack, T-Shape, π-Shape und weitere Skillprofile

Bild: Wikimedia Commons / Plamen - Public Domain

Ein wiederkehrender Einwand gegen Scrum und andere Ansätze die auf crossfunktionalen, nach dem Pull-Prinzip arbeitenden Teams beruhen, ist der, dass sie von unrealistischen Stellen- oder Skill-Profilen ausgehen würden. In ihnen müsste jeder Einzelne in der Lage sein, alle in Frage kommenden Arbeiten durchzuführen, was in einer komplexen und vielschichtigen Arbeitswelt gar nicht möglich wäre. Das ist natürlich ein Mythos, niemand verlangt das. Aber er hat einen wahren Kern.


Tatsächlich ist das beste was einem agilen Team passieren kann, dass möglichst viele seiner Mitglieder Full Stack-Developer sind, also an allen Aufgaben arbeiten können. So lässt sich sobald eine Aufgabe abgeschlossen ist immer die am höchsten priorisierte nächste Aufgabe ziehen und erledigen. Allerdings geht das nur bis zu einer gewissen Vielfältigkeit des Produkts, sobald die überschritten ist (z.B. in den meisten kombinierten Hardware/Software-Produkten) gibt es Full Stack Developer kaum noch.


Der häufigste Weg das zu kompensieren sind die so genannten T-Shape Profile. In ihnen gibt es vertieftes Wissen in einem Bereich (symbolisiert durch den vertikalen Balken) und nur grundlegendes Wissen in den anderen Bereichen (symbolisiert durch den horizontalen Balken). In dieser Konstellation kann zumindest ein Teil der Aufgaben ausserhalb des eigenen Spezialgebietes übernommen werden, die verzögernden Flaschenhalseffekte (im Zweifel muss auf den Spezialisten gewartet werden) werden so abgeschwächt.


Wann genau dieser Begriff eines T-förmigen Skillprofils entstanden ist lässt sich nicht mehr genau nachvollziehen, die früheste bekannte Erwähnung ist aber der Artikel "The hunt is on for the Renaissance Man of computing" von David Guest, der 1991 in der britischen Zeitung "The Independent" erschienen ist. Guest bezog sich in ihm noch weitgehend auf Manager, in den folgenden Jahren wurde der Begriff aber mehr und mehr auf die unteren Ebenen übertragen.


Sobald sich T-Shape Profile im Team etabliert haben wird häufig versucht einen nächsten Schritt in Richtung Full Stack zu gehen, indem jeder sich einen zweiten Schwerpunkt aussucht in dem er sich vertieftes Wissen erarbeitet. Da das grafisch dargestellt dem griechischen Buchstaben π entspricht (zwei vertikale Balken, ein horizontaler Balken) ist in diesem Zusammenhang häufig von π-Shape Profilen die Rede (btw: π wird wie Pi ausgesprochen).


Auch das lässt sich natürlich noch weiter steigern, immer wieder wird versucht Modelle zu entwickeln in denen die Skillprofile noch mehr Spezialisierungs-Gebiete haben sollen: Key Shape, Paint Drip Shape, Icicle Shape, Chtulu Shape und Comb Shape sind einige davon (auf den verlinkten Webseiten werden die Benennungen erklärt), die aber alle nur noch detailliertere Zwischenstufen in Richtung eines Full Stack Profils darstellen.


Wie viele dieser Entwicklungsschritte ein Mensch gehen kann (und will) hängt ganz von den jeweiligen Umständen ab, anzustreben sind aber zumindest T-Shape oder π-Shape. Dort wo sie nicht gegeben sind wird ein Team auf Mitglieder mit I-shaped Skills zurückgeworfen, die sich auf eine Sache spezialisiert haben und sonst nichts können oder wollen. Dass man solchen Menschen nahegelegt hat besser nicht in agilen Teams zu arbeiten dürfte übrigens der Grund für den zu Beginn genannten Mythos sein.

Montag, 15. August 2022

Beherzte Rebellion im Konzern

Bild: Pexels / Mikael Blomkvist - Lizenz
Ein grosser Teil meines Berufslebens dreht sich darum, grosse, eher schwerfällige Organisationen beweglicher und flexibler zu machen. Und obwohl ich das seit mittlerweile über 10 Jahren mache gibt es immer wieder neue Blickwinkel darauf die ich entdecke. Dieser hier ist von Peter Biddle, der eine schöne Analogie gefunden hat: er vergleicht innovative und agile Einheiten in Grossorganisationen mit den Bakterien im Körper eines Menschen. Sie sind nicht direkt sichtbar und es ist ohne Vorwissen nicht klar was sie tun, sie leben aber in einer derartig symbiotischen Beziehung mit ihrem Wirt, dass jede der beiden Seiten auf die andere angewiesen ist.


Und apropos über 10 Jahre - auch dieses Video ist schon fast so alt. Und es ist bis heute relevant geblieben. Ein weiteres Zeichen dafür, dass mir so bald die Arbeit nicht ausgehen wird.

Donnerstag, 11. August 2022

Change Management

Grafik: Wikimedia Commons / Meyers Konversationslexikon - Public Domain

Ein bemerkenswertes Phänomen im Change Management ist die weitgehende Unklarheit darüber was dieser Begriff eigentlich bedeutet. Beide Bestandteile - Change und Management - sind bereits für sich genommen mehrdeutig und weit interpretierbar, zusammengenommen sind sie es erst recht. Als Folge dessen hat sich eine ganze Reihe möglicher Bedeutungen entwickelt, die zum Teil parallel und ohne klare Abgrenzung zueinander verwendet werden. Sie sich vor Augen zu führen und explizit zu machen ist von elementarer Bedeutung wenn man für sich selbst definieren will was eigentlich zu tun ist wenn man von Change Management redet. Hier sind sie:


Veränderungen durchführen

Die technokratische Variante. Die sozialen und psychologischen Dimensionen von Veränderungsvorhaben werden nicht gesehen oder bewusst ignoriert. Für Fragen und Proteste ist keine Anlaufstelle vorgesehen, Kommunikation beschränkt sich auf die Verkündung von Stichtagen an denen Veränderungen in Kraft treten. Kritisch zu sehen, da sich Probleme und Emotionen immer weiter aufstauen und selbst offensichtliche Fehlentwicklungen aufgrund fehlender Feedbackkanäle nicht bemerkt werden können.


Veränderungen durchsetzen

Die rabiateste Variante, gleichzeitig aber auch eine die in klassischen Organisationen noch immer sehr häufig ist. Meistens getrieben von einem Menschenbild in dem Mitarbeiter "zu ihrem Glück gezwungen werden müssen" oder in dem ihnen Destruktivität unterstellt wird, werden Veränderungen mit Befehlen, Drohungen und Bestrafungen in die Organisation hineingezwungen. In der Wissensarbeit ein hochgradig kontraproduktiver Ansatz, da er in der Regel zu dysfunktionalem "Dienst nach Vorschrift" führt.


Veränderungen erträglich machen

Die abgeschwächte Form des Durchsetzens. Statt mit Befehlen oder Strafen wird mit anderen Mitteln gearbeitet, vor allem mit ausgleichenden Belohnungen (Boni, kostenloser Kaffee, modernere Büros, etc.), oder mit dem in Aussicht Stellen von bald folgender Ruhe und Sicherheit ("Wenn Ihr das mitmacht sind für erste alle Personalabbaupläne vom Tisch"). Dieses Vorgehen kann zwar Widerstände dämpfen, kann aber nicht verhindern, dass Unzufriedenheiten unterschwellig erhalten bleiben.


Veränderungen verkaufen

Verkaufen ist hier gemeint im Sinn von Vermarkten. Das kann passieren durch die Suggestion von Notwendigkeit oder Modernität ("Nur so bleiben wir wettbewerbsfähig", "Google macht das auch so") oder durch emotionale Vereinnahmung ("Und jetzt alle: Tschakka, wir schaffen das!"). Dosiert eingesetzt kann es durchaus wirkungsvoll sein, bei häufigem oder regelmässigen Einsatz kommt es aber schnell zu Gewöhnungs-, Abstumpfungs- oder Abstossungs-Effekten.


Veränderungen aushandeln

Ab hier beginnt eine Begegnung auf Augenhöhe, wenn auch noch eher in Form eines Kuhhandels. "Was müssten wir für Euch tun, damit Ihr Euch umgekehrt an den Veränderungen beteiligt?" Solche und ähnliche Verhandlungen treiben die Veränderungen voran, sorgen aber auch dafür, dass nicht mehr die Sinnhaftigkeit des Neuen im Vordergrund steht sondern die zu erwartende Gegenleistung. Kann zu einer "für Geld machen wir alles, auch wenn es sinnlos ist"-Einstellung führen.


Veränderungen gemeinsam gestalten

Schon ein sehr moderner Ansatz. Dass Veränderungen stattfinden müssen wird zwar noch als gegeben hingenommen, in welcher Form, in welchem Zeitraum und von wem sie umgesetzt werden wird aber bereits weitgehend delegiert und dezentral umgesetzt. Zu beachten ist, dass Mitarbeiter ohne entsprechende Vorkenntnisse bei der Umsetzung in die Autonomie-Falle tappen können und daher zu Beginn ggf. Unterstützung brauchen.


Veränderungsbedarfe gemeinsam suchen, bewerten und darauf reagieren

State of the Art in agil arbeitenden Organisationen. Im Rahmen der üblichen Inspect & Adapt-Prozesse wird kontinuierlich und dezentral ermittelt ob und wo Veränderungen notwendig sind, dort wo das der Fall ist wird möglichst dezentral und selbstorganisiert darauf reagiert (hilfreich sind dabei transparente Regelungen wann Zentralisierungen doch Sinn machen können, z.B. diese hier). Häufige agile Praktiken sind Retrospektiven und Kaizen-Prozesse.


Veränderungen kontrolliert verursachen und institutionalisieren

Die post-moderne Endausbaustofe. Es wird nicht mehr darauf gewartet, dass Veränderungsbedarfe irgendwo entdeckt werden, stattdessen werden die eigenen Prozesse und Strukturen immer wieder durch kontrollierte Experimente und Belastungstests verändert, überprüft und angepasst. Zwar lässt sich nicht alles voraussehen, viele Veränderungsnotwendigkeiten und Verbesserungspotentiale können so aber im voraus erkannt und ohne Zeitdruck umgesetzt werden.


Wie bei anderen Begriffsdifferenzierungen gilt auch hier, dass noch zahllose weitere Abstufungen möglich sind, und natürlich kann in jedem dieser Fälle die Ausgestaltung nochmal sehr unterschiedliche Formen annehmen. Dennoch bietet diese Übersicht gute Anhaltspunkte wenn man Change Management-Massnahmen plant - und auch wenn man die analysieren will von denen man gerade betroffen ist.

Montag, 8. August 2022

PMI goes Agile (II)

Bild: Pexels / Gustavo Fring - Lizenz

Drei Jahre ist es mittlerweile her, dass das Project Management Institute (PMI) das agile Framework Disciplined Agile (DA) gekauft hat. Sicher hat auch hier die Corona-Pandemie einiges von den ursprünglichen Plänen durcheinandergeworfen, trotzdem lohnt sich mittlerweile wieder ein Blick: wie hat sich das DA-Regelwerk entwickelt, wie ist mittlerweile der an den Zertifizierungen ablesbare Verbreitungsgrad, was gibt es sonst noch?


Zuerst zum Regelwerk. Der Baukasten-Ansatz ist weiter vorangetrieben worden, die Möglichkeit den eigenen Arbeitsprozess selbst zu gestalten steht im Vordergrund. Grundlegend ist das auch gut so, die Anleitung für den Auswahlprozess ist aber eine kuriose Mischung aus esoterisch und mechanistisch. Z.B. soll dort wo agiles Arbeiten in Frage kommt das Mindset der Teams geprüft werden. Ist es ein agiles Mindset soll agil gearbeitet werden, wenn nicht dann Lean. Alleine diese Vorgabe wirft viele Fragen auf.


Auch das agile Mindset selber hat jetzt eine Ausformulierung bekommen, in seiner DA-Form besteht es aus den drei Bereichen der Prinzipen, Versprechen und Richtlinien. Auch hier ist wieder grundlegend alles sinnvoll, im Detail aber hinterfragbar. Dass zum Beispiel gleich das erste Versprechen die Herstellung von Psychologischer Sicherheit ist, ist gewagt. Ein derartig fragiles und privates Gefühl ist nur schwer zu beeinflussen. Daran arbeiten kann (und sollte) man, aber es versprechen?


Während diese Aspekte noch ambivalent betrachtbar sind dürfte ein anderer den meisten Agilisten zu Schnappatmung verhelfen: die Rollen. Alleine auf Teamebene gibt es 10 Team- und Unterstützungsrollen, für die umgebende Organisation kommen nochmal 40 weitere dazu. Selbst wenn herausgestrichen wird, dass man nicht alle einführen muss und dass ggf. eine Person mehrere übernehmen kann - das ist im Vergleich zur ursprünglichen Rollen- und Posten-aversen Agilität ein heftiger Paradigmen-Bruch.



Auch einen zweiten Paradigmen-Bruch kann man im aktuellen Stand von DA beobachten: DevOps hat in seiner DA-Variante zwar theoretisch noch seine ursprüngliche Bedeutung von Entwicklung und Betrieb in einer Hand, in den Detailbeschreibungen ist aber vieles doch wieder verkompliziert und in eigene Organisationseinheiten ausgelagert, in denen dann einige der gerade genannten Rollen vorgesehen sind. De facto entsteht so doch wieder eine Parallelexistenz von Entwicklung und Betrieb.


Bei weiterer Betrachtung ist diese Konstellation Teil eines grösseren Musters: je länger man liest desto mehr Themen findet man die sich nicht in der Verantwortung der umsetzenden Einheiten befinden. Einige davon nachvollziehbarerweise (z.B. Recht), bei einigen anderen handelt es sich aber um solche deren Verantwortung man normalerweise innerhalb und nicht ausserhalb eines agilen Teams verorten würde, zum Beispiel Produktmanagement und Architektur. Dies ist der dritte, und bei weitem grösste, Paradigmenbruch.


Die Begründungen dafür lesen sich zunächst eingängig: DA ist explizit nicht für einzelne Teams gedacht sondern für ganze Unternehmen, da gibt es eben Koordinationsbedarf. Und Frameworks wie Scrum bescheiben nicht wie Koordination stattfinden soll. Bei genauerer Betrachtung liegt hier der Knackpunkt - das Grundmuster des kleinen, crossfunktionalen, (teil)autonomen Teams wird in DA gar nicht gewollt (oder für möglich gehalten). Der un-agil wirkende Überbau ist nur die Folge davon.


Nun ja. Bei realistischer Betrachtung ist das PMI mit dieser Einstellung nicht alleine, die meisten grossen Firmen denken so. Kann man daraus schliessen, dass DA zumindest in Konzernen bereitwillige Abnehmer vorfindet und nach und nach dieses Marktsegment aufrollt? Eher nicht. Eine aktuelle Auswertung kommt auf lediglich 5000 verkaufte Zertifizierungen. Zum Vergleich: Scrum Alliance und SAFe haben über eine Million, Scrum.org 700.000, sogar vom veralteten agilen ACP-Zertifikat von PMI gibt es noch 50.000.1


Und apropos Zertifizierungen - die bilden weiterhin ein Kuriosum. Zwar sind sie mittlerweile neu strukturiert und umfassen an Stelle des ehemaligen "Disciplined Agile Lean Scrum Master" (DALSM) jetzt den "Disciplined Agile Scrum Master" (DASM), den "Disciplined Agile Senior Scrum Master" (DASSM), den "Disciplined Agile Coach (DAC) und den "Disciplined Agile Value Stream Consultant" (DAVSC) - im gesamten Regelwerk tauchen sie aber kein einziges mal auf.


Der Gesamteindruck: Disciplined Agile wurde erkennbar strukturiert und konsolidiert, macht aber noch immer über weite Teile einen eher konfusen Eindruck. Und bei vielen Inhalten stellt sich die Frage wie agil es überhaupt noch ist. Nimmt man den Verkauf der Zertifikate als Massstab ist das Ganze zudem ein wirtschaftlicher Fehlschlag. Auch darüber hinaus scheint einiges im Argen zu liegen, im oben erwähnten Artikel steht auch, dass die DA-Gründer Mark Lines und Scott Ambler das PMI verlassen haben.


Das muss natürlich noch nicht das Ende sein, mit seinen Finanzreserven und seiner globalen Verbreitung hat das PMI noch immer gewaltige Ressourcen die es in seinen agilen Bereich stecken kann. Es ist aber zumindest zweifelhaft ob es in absehbarer Zeit dazu kommen wird, dass Disciplined Agile mehr als nur ein Nischendasein fristen wird.



1Zahlen von den Websites der drei Organisationen: Scrum Alliance, SAFe, Scrum.org

Donnerstag, 4. August 2022

Scrum Shots

Bild: Pixabay / MasterTux -

Heute gibt es mal wieder einen kleinen Erfahrungsbericht aus dem Arbeitsalltag eines Agile Coaches. Konkret geht es um ein alternatives Format zur Vermittlung von Methodenwissen. In diesem Fall von Scrum, das Vorgehen liesse sich aber auch für jedes andere Vorgehensmodell anwenden. Und um es gleich zu Beginn klarzustellen: die Idee ist zum Ausprobieren empfohlen, eine Blaupause die man einfach in grossem Ausmass auf alle Teams ausrollen sollte ist es aber nicht.


Um mit dem Hintergrund zu beginnen: vor einiger Zeit hat ein Kollege aus meiner Firma einen Kunden-Einsatz an mich übergeben zu dem auch die Begleitung eines relativ neuen Teams gehört. Das Team möchte nach Scrum arbeiten, hat aber relativ wenig Erfahrung mit diesem Framework. Normalerweise würde sich in so einem Fall eine initiale Methodenschulung anbieten, zu der es aber aus irgendeinem Fall nicht gekommen ist.1 Stattdessen findet ein Training on the Job statt.


Um in diesem Rahmen Methodenwissen vermitteln zu können wurde im Team ein neues Format entwickelt, die so genannten "Scrum Shots". Dabei handelt es sich um kurze, fünfzehnminütige Sessions direkt nach dem Daily Scrum, in denen auf jeweils einen Askpekt des Frameworks eingegangen wird. Wegen der kurzen Zeit- und Themenmenge wurden sie nach den Shot-Gläsern benannt, deren Inhalt zwar ein geringes Volumen aber dafür eine hohe Wirksamkeit hat.


Zum Ablauf: auf einer (digitalen) Themenwand befinden sich Karten, die den 25 Abschnitten des aktuellen Scrum Guide entsprechen (Version von 2020). Am Ende jedes Scrum Shots wird vom Team per Dot-Voting darüber abgestimmt welches dieser Themen beim nächsten mal behandelt werden wird. Das wird dann von mir (bzw. vorher von meinem Vorgänger) vorbereitet und beim nächsten mal vorgestellt und gemeinsam diskutiert.


Die Art der Themenvorstellung kann sich je nach Einzelfall unterscheiden. Da wo es bisher nur oberflächliche Berührungspunkte gab macht z.B. eine grundlegende Einführung Sinn, bei Punkten die nach Schnelleinführung bereits etabliert wurden und bei denen sich bereits erste Routinen etabliert haben geht es vertieft hinein (im Fall des Daily Scrum beispielsweise in den Aspekt, dass es auch dafür gedacht ist den Fortschritt zur Erreichung des Sprint Ziels zu diskutieren).


Gegebenenfalls können darüber hinaus auch Aspekte eingefügt werden die nicht direkt aus dem Scrum-Regelwerk kommen, es aber verständlicher machen oder dessen Implikationen aufzeigen. Im Fall des Product Backlog bedeutet das etwa, dass seine wörtliche Bedeutung (der Rückstau) herausgestrichen wird, im Fall des Transparenzprinzips lässt sich diskutieren wie weit das gehen muss, zum Beispiel ob es auch auf Geschäftszahlen (inclusive der Gehälter) angewandt werden sollte.


Der Nachteil im Vergleich zu einer grösseren Schulung zu Beginn ist, dass am Anfang der Einsatz von noch nicht (oder nur verkürzt) erklärten Scrum-Elementen zu Missverständnissen führen kann, die sich schlimmstenfalls in nicht zielführenden Routinen niederschlagen können. In diesem Fall ist das zum Glück nicht passiert, bei zukünftigen Anwendungen in anderen Teams sollte man sich aber bewusst machen, dass es dazu kommen kann.


Der Vorteil ist auf der anderen Seite, dass die kontinuierliche Beschäftigung über längere Zeit dazu führt, dass die Inhalte besser ins kollektive Gedächtnis des Teams übergehen und sich dort festsetzen. Gerade vor dem Hintergrund, dass es ein häufig zu beobachtendes Phänomen ist, dass operative Alltagsthemen die Reflektion und Anwendung von methodischen Aspekten in den Hintergrund drängen, ein nicht zu verachtender Punkt.


Wie am Anfang gesagt, die Idee ist zum Ausprobieren empfohlen, eine Blaupause die man einfach in grossem Ausmass auf alle Teams ausrollen sollte ist sie aber nicht - die erwähnten Risiken zeigen auch auf warum. Sie kann auch variiert werden, z.B. durch Umwandlung in eine öffentliche, teamübergreifende Veranstaltung. Auf jeden Fall ist sie aber eine sinnvolle Option für alle Fälle in denen es aus irgendeinem Grund nicht zu einer initialen Schulung kommen kann.



1Natürlich wurden Termine für Dailies, Plannings, etc. eingestellt, die aber nur sehr kurz erklärt wurden

Montag, 1. August 2022

Kommentierte Links (XC)

Bild: Pixabay / Buffik - 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.

Jeff Gothelf: How long should we keep the team together?

Dass Teams so lange wie möglich in unveränderter Konstellation bestehen sollen ist ein Dogma von dem sich die agile Community gerade löst, nicht zuletzt dank des Dynamic Reteaming-Konzepts. Da andererseits das in vielen Grossunternehmen übliche permanente Durcheinanderwürfeln der Mitarbeiter massive Nachteile mit sich bringt stellt sich die Frage, wie lange wohl der optimale Zeitraum sein sollte in dem ein Team stabil zu halten ist. Jeff Gothelf gibt die einzig wahre Antwort darauf (es kommt darauf an), ergänzt diese aber um ein Modell der langsamen aber kontinuierlichen Veränderungen, in dem ein- oder zweimal pro Jahr einzelne Mitglieder stabiler Teams in andere Bereiche wechseln und ihre Erfahrung dort einbringen, während ihre bisherige stabile Umgebung genutzt wird um neuen Kollegen einen einfachen Einstieg zu ermöglichen.

Charles Lambdin: Agile and Science (and Politics?)

Mal wieder etwas eher Geisteswissenschaftliches. Charles Lambdin überträgt einige Erkenntnisse aus Jonathan Rauchs Buch Kindly Inquisitors auf die agile Produktentwicklung. Während Rauch mit Verweisen auf Adam Smith, Charles Darwin, John Locke, Bertrand Russell und Karl Popper belegt, dass es in der (scheinbar empirischen) modernen Wissenschaft keine absoluten Wahrheiten gibt, sondern nur Zwischenstände auf dem Weg zum nächsten Erkenntnisschritt, sieht Lambdin das Gleiche als eine der zentralen Rahmenbedingungen der Agilität an. In beiden Bereichen folgt aus dieser Grundthese, dass eine Zuschreibung von Richtig und Falsch (wenn überhaupt) nur für die eingesetzten Vorgehensweisen möglich ist, nicht aber für die erzielten Ergebnisse. Food for Thought.

Bianca Kastl: Was von Digitalisierungsversuchen übrig blieb

"Der Witz am oftmals desolaten Zustand der Digitalisierung in Verwaltung und Gesundheitswesen ist eigentlich: Vieles davon ist – in Theorie – „digitalisiert“." Mit diesem Satz beschreibt Bianca Kastl ein Phänomen, das auch aus anderen Branchen bekannt ist. Die ursprünglich revolutionären und modernen ersten Digitalisierungsvorhaben sind mittlerweile in die Jahre gekommen, und was ursprünglich dazu beigetragen hat die Arbeit einfacher, schneller und nachvollziehbarer zu machen ist nach einer langen Phase des Wildwuchses, mangelhafter Wartung und unterlassener Modernisierung in einem beklagenswerten Stadium angekommen. Dieser Beitrag soll den Auftakt zu einer Reihe bilden in der beschrieben wird wie es besser geht. Man kann gespannt sein.

Derek Thompson: The Biggest Problem With Remote Work

Wer hier schon länger mitliest wird wissen, dass ich zur Remote-Arbeit ein ambivalentes Verhältnis habe. Auf persönlicher Ebene kann sie unbestreitbare Vorteile haben und auf Teamebene kann man ihre Nachteile kompensieren, auf der Gesamtorganisations-Ebene schwächt sie aber die Zusammenarbeit und das Zusammengehörigkeitsgefühl zwischen Teams und Abteilungen. Was Derek Thompson hier beschreibt ist eine Folge die ich bereits selbst in verschiedenen Firmen beobachtet habe: mehr mittleres Management. Das ist nicht per se schlecht, gerade in einem agilen Arbeitskontext aber gegenläufig zu den dort eigentlich angestrebten Zielen von Dezentralisierung, Subsidiarität, Ownership und Empowerment.

Leigh Griffin, Arjay Hinek: What Kind of Coach Does Your Team Need?

Als letztes ein wirklich langer Text. Augenzwinkernd könnte man sagen, dass Leigh Griffin und Arjay Hinek mehr als 3500 Wörter brauchen um auch wieder nur "Kommt drauf an" zu sagen, tatsächlich sind aber sowohl diese Aussage als auch die Länge für das Thema angemessen. Es sind nunmal sehr viele Faktoren und Dynamiken die hier zusammenspielen und die zu berücksichtigen sind.