Dienstag, 30. April 2019

Kommentierte Links (XXXXVIII)

FS
  • Christiaan Verwijs: Here’s what's wrong with maturity models

  • Die Frage ist erstmal naheliegend: Wie gut bin ich eigentlich in dem was ich mache? Auf diesen Kontext hier übertragen: Wie gut beherrsche ich Agile, Scrum, Lean, Kanban, etc.? Die scheinbar naheliegendste Lösung der Überprüfung und Auszeichnung durch Zertifizierungen läuft sich gerade tot, so dass eine andere gesucht wird. Maturity Modelle scheinen auf den ersten Blick eine naheliegende Alternative, allerdings eine die mit Vorsicht zu betrachten ist. Christiaan Verwijs zeigt die grundlegenden Probleme dieses Konzepts auf - zu generalistisch, zu wenig auf den jeweiligen Fall eingehend, zu linear. Mit anderen Worten: nicht agil.

  • Joshua Kerievsky: Preconditions for Agility

    Mit der Bewegung von agilen Vorgehensweisen in Richtung Mainstream erhöht sich nicht nur die Zahl der Erfolgsgeschichten sondern auch die der Fehlschläge. Ein häufiger Grund dafür ist der Versuch "agile" Vorhaben in einem Kontext durchzuführen in dem sie nur eingeschränkt oder gar nicht funktionieren können. Joshua Kerievsky führt einige Vorbedingungen auf die gegeben sein müssen damit das Ganze Erfolgsaussichten hat: Crossfunktionalität, gemeinsames Verständnis der Ziele, Teamwork, Bereitschaft zu Work in Progress-Limits und Kenntnis der üblichen Praktiken bei allen Beteiligten. Dass das für Agilität elementar ist dürfte offensichtlich sein, umgekehrt stellt sich aber die Frage wie ohne zumindest einige dieser Vorbedingungen überhaupt produktiv gearbeitet werden kann.

  • Jeff Sutherland: Why Less Communication is Better!

    Ein weiterer Beitrag zu den Ursprüngen von Scrum und Agilität im Militär. Nach den römischen, mongolischen und preussischen Armeen diesesmal mit einem Verweis auf die modernen amerikanischen und vor allem deutschen Streitkräfte. Vom Deutschland des 21. Jahrhunderts aus betrachtet nicht ganz unproblematisch. Einen der beiden Scrum-Gründer von Wehrmachts-Begriffen wie "Auftragstaktik" und "Führen mit Auftrag" schwärmen zu sehen ist (gelinde gesagt) befremdlich und führt spätestens dann zu Unwohlsein wenn der Frankreich-Feldzug von 1940 als positives Beispiel herangezogen wird. Selbst wenn man versuchen könnte das militärische Vorgehen von der dahinterliegenden Ideologie zu trennen ist es unwahrscheinlich, dass dieses Thema hier populär wird.

  • Roman Pichler: 10 Scaling Tips for Product People

    Im Grunde auch benutzbar für jede andere Form von Skalierung im agilen Umfeld (und darüber hinaus). Pichlers 10 Skalierungstips sind:
    1. Beziehe die richtigen Leute ein
    2. Skaliere nicht zu früh
    3. Starte mit einem MVP (um noch nicht skalieren zu müssen)
    4. Mache die Entwicklungsteams verantwortlich und selbstständig
    5. Teile Teams und fülle sie auf um zu wachsen
    6. Mache Teams produktorientiert statt komponentenorientiert
    7. Starte mit allen Beteiligten an einem Ort und expandiere schrittweise (und nur wenn nötig)
    8. Erwäge die Abspaltung neuer Teilprodukte oder Varianten
    9. Nutze die Vorteile gemeinsamer Plattformen (z.B. von Frontend-Komponenten oder Security)
    10. Skaliere nie zu einem späten Zeitpunkt
    Interessant an dieser Liste: während das meiste die vorbehaltlose Zustimmung der meisten agilen Practitioner finden dürfte sind mit den Tips 5 und 9 zwei durchaus kontrovers zu betrachtende dabei. Nicht dass sie nicht funktionieren könnten, sie bergen aber Risiken in sich derer man sich bewusst sein sollte.

  • Shaaron A. Alvares: Tuckman Was Wrong! Doc Norton on Reteaming Models

    Zum Abschluss noch ein Link der zusammen mit dem ersten eine thematische Klammer bildet. Auch das legendäre Tuckman-Modell der Teambildungsphasen (Forming, Storming, Norming, Performing, Adjourning) krankt daran, dass es zu generalistisch, zu wenig auf den jeweiligen Fall eingehend und zu linear ist. Interessant ist insbesondere der Link zu einer Studie mit über 300 Teams, derzufolge nur zwei Prozent von ihnen (!) sequentiell durch die fünf Phasen gingen. Ob die beschriebenen Alternativen der "fluiden Teams" oder des "dynamic Reteamings" besser sind könnte man aber auch diskutieren. Wie so oft: es kommt darauf an.

Donnerstag, 25. April 2019

The New Managerial Contract

FS
Nach diesem Video ist man glatt versucht sich bei Hamza Khan um einen Job zu bewerben, so überzeugend ist er in seinem Vortrag. Dazu die Acherbahnfahrt durch die Management-Geschichte, von der Industrialisierung über Peter Drucker bis Jay-Z und einige minimalistische Slides mit prägnanten Aussagen. So sollten Talks sein.


Montag, 22. April 2019

Willkürliche Deadlines

FS
Bild: Wikimedia Commons / Waterced - CC BY-SA - 4.0
Fast jeder der länger in Projekten oder Programmen jeglicher Grösse gearbeitet hat wird sie kennen: willkürliche, unrealistische Deadlines. Nicht zu verwechseln mit den gerechtfertigten Deadlines (z.B. wegen sich ändernder Gesetze), mit denen man irgendwie umgehen muss, handelt es sich bei ihnen um scheinbar ohne Notwendigkeit getroffene Entscheidungen, bei denen allen Beteiligten von Beginn an klar ist, dass man sie mit grosser Wahrscheinlichkeit deutlich verfehlen wird. Warum es trotzdem immer wieder zu ihnen kommt erkennt man an einem aktuellen Beispiel.

Nur wenige Tage nach dem Brand der weltberühmten Kirche Notre Dame de Paris wurde bereits verkündet wann der Wiederaufbau abgeschlossen sein soll: in fünf Jahren, also 2024. Dass diese Zahl realistisch ist kann zu Recht bezweifelt werden. Bereits vor dem Brand war der Bau schwer beschädigt, die zusätzlichen Beschädigungen durch den Brand sind in ihrer Tragweite noch nicht absehbar und um das Ganze noch komplexer zu machen soll in den Wiederaufbau das Ergebnis eines noch durchzuführenden Architekturwettbewerbes einfliessen. Auf dieser Grundlage in so kurzer Zeit fertig zu werden ist illusorisch.

Dass diese Zahl trotzdem im Raum steht hat Gründe. Der naheliegendste: Wunschdenken. Die pariser Bürgermeisterin Anne Hidalgo äusserte ganz offen einen Grund für den engen Zeitplan - zu den in Paris stattfindenden olympischen Spielen 2024 sollten die Schäden beseitigt sein. Ein nachvollziehbares Anliegen, schliesslich werden dann zigtausende Athleten, Touristen und Journalisten nach Frankreich kommen. Dass dieses Wunschdenken aber nicht von Beginn an als das erkannt wird was es ist liegt unter anderem an der Entkoppelung von Auftrag und Umsetzung. Je weniger man über ein Thema weiss, desto stärker kann Realismus von Hoffnung überlagert werden.

Ein zweiter Grund ist der, dass eine derart gewagte Aussage den der sie trifft als tatkräftigen Macher erscheinen lässt. Gerade im Fall des Urhebers dieses "Fünfjahresplans", des französischen Präsidenten Macron, der sich gerade erst von verheerenden Umfragewerten erholt, eine grosse Verlockung - nicht zuletzt weil mit der Europawahl eine wichtige Abstimmung nur wenige Wochen bevorsteht. Mit dem noch frischen Eindruck eines energischen Krisenbewältigers könnte er hier punkten, unabhängig von den langfristigen Erfolgsaussichten. Und sollte er damit erfolgreich sein können sich seine Wähler später an die eigene Nase fassen.

Ein dritter Grund ist, dass das angekündigte Zieldatum in einer Zeit liegt in der Macron keine negativen Folgen für sich selbst mehr befürchten muss. Laut französischer Verfassung kann er nur einmal wiedergewählt werden, und zwar 2022, also Jahre vor dem von ihm selbst gesetzten Zieldatum. Selbst wenn die Wähler es ihm übelnehmen sollten wenn der Wiederaufbau 2024 nicht abgeschlossen ist - die Folgen darf dann ein anderer ausbaden (und selbst der kann sich dann darauf berufen, dass die Ankündigung nicht seine war. Siehe hier). Parallelen zu zeitlich begrenzten Management-Amtszeiten sind offensichtlich.

Faktoren wie diese lassen sich in vielen komplexen Vorhaben finden, ob in Staat oder Wirtschaft, in Bau- oder IT-Projekten. Betrachtet man sie lassen sie die Setzung scheinbar willkürlicher Deadlines in neuem Licht erscheinen. In den meisten Fällen sind sie bedingt durch die Funktionsweise des umgebenden Systems und ergeben im Kontext von dessen Rahmenbedingungen absolut Sinn. Umgekehrt regen diese Erkenntnisse zur Hoffnung an. Wenn ein Systemdesign derartige Phänomene begünstigt, dann kann ein anderes sie unwahrscheinlicher machen. Man kann also daran arbeiten.

Donnerstag, 18. April 2019

Warum Scrum-Zertifikate früher Sinn gemacht haben (und heute nicht mehr)

FS
Bild: Pxhere - CC0 1.0
Zertifizierungen werden im Rahmen des agilen Arbeitens (und hier besonders im Zusammenhang mit Scrum) kontrovers diskutiert. Während viele Recruiter und Personaler noch immer ein Gütesiegel in ihnen sehen herrscht unter Practitionern eher der gegenteilige Eindruck vor. Ein Zertifikat gilt hier lediglich als Beweis dafür, dass man etwas Geld übrig hatte und eine begrenzte Menge Wissen auswendig lernen konnte (und selbst das mit begrenztem Praxisbezug). Was in dieser Debatte untergeht: Scrum-Zertifikate waren mal anders gemeint und haben einen ganz anderen Sinn ergeben als heute.

Ein Blick zurück auf die Anfänge: 2002 wurde mit der Scrum Alliance die erste Zertifizierungs-Organisation gegründet, zuerst nur mit Scrum Master-Zertifizierungen, erst später mit immer weiteren. Zwei bedeutende Dinge waren in dieser Zeit anders als heute - zum einen war Scrum noch relativ unbekannt und wenig verbreitet, zum anderen befand sich das Internet noch in seiner Frühphase, in der viele der heute populären Dienste noch nicht oder nur in einer frühen Form existierten. Beides führte dazu, dass die frühen Anwender des neuen Frameworks noch stark voneinander isoliert waren.

Während heute jeder Interessierte eine immer grösser werdende Auswahl an Meetups und Unkonferenzen in seiner näheren Umgebung finden kann befand sich die Scrum-Community damals noch im Zustand einer Diaspora. Vereinzelt gab es schon erste User Groups (vor allem an der amerikanischen Ost- und Westküste), im grössten Teil der Welt waren die ersten Vorreiter aber noch auf sich gestellt. Der heute fast überall vor Ort mögliche Austausch mit Gleichgesinnten war nur in Verbindung mit Reisen und Konferenzteilnahmen möglich, was nicht für jeden organisierbar und finanzierbar war.

Auch Informationen aus dem Internet gab es spärlicher als heute. Selbst die heutigen sprichwörtlichen ersten Schritte waren noch nicht möglich. Die Wikipedia existierte erst ein Jahr und war noch hochgradig lückenhaft, bis zum ersten Artikel über Scrum (siehe hier) sollten noch Jahre vergehen. Hier war also keine Hilfe zu finden. Und auch das Betrachten eines Einführungsvideos auf Youtube war keine Option, diese Seite ging erst im 2005 online, also ebenfalls Jahre in der Zukunft. Einzelne Websites zu dem Thema gab es zwar, aufgrund der im Vergleich zu heute schlechteren Suchmaschinen waren sie aber nur mit Mühe zu finden.

Die Zertifizierungen (und vor allem die Zertifizierungskurse) haben daher in den ersten Jahren eine wichtige Lücke geschlossen. Durch sie war es erstmals möglich die eigene Scrum-Umsetzung mit der offiziellen Version abzugleichen, Good Practices kennenzulernen und sich mit anderen Anwendern auszutauschen. Dass es dazu noch ein buntes Stück Papier gab war eine schöne Zugabe, von grösserer Bedeutung waren aber die beiden Tage davor, die Einblicke bieten konnten die sonst nur schwer zu haben gewesen wären. So war es damals.

Zurück in die Gegenwart: Heute gibt es all das was es früher nicht gab. Es gibt Meetups und User Groups in der eigenen Umgebung, auf denen man sich mit Menschen jeder Erfahrungsstufe austauschen kann. Es gibt online mehr kostenlose Artikel als man im gesamten Leben lesen könnte und mehr Videos als man in Jahren sehen könnte. Es gibt Inhouse Communities in grossen Firmen, es gibt Podcasts, kollegiale Fallberatungen und vieles mehr. Und wer auch nur einen kleinen Teil seiner Zeit hier investiert kan viel, viel mehr lernen als in jeder Zertifizierung.

Darum zum Fazit: es gab mal eine Zeit in der die Scrum-Zertifikate viel Sinn gemacht haben, aber die ist weitgehend vorbei.

Montag, 15. April 2019

Deine Muda: Overprocessing

FS
Bild: Pixabay / Geisteskerker - CC0 1.0
Siebter Teil der Deine Muda-Serie. Die sechste Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Überregulierung, auf englisch Overprocessing. Diese Muda ist etwas Besonderes: während die ersten fünf (Transportation, Inventory, Motion, Waiting und Overproduction) die zeitweise Untätigkeit, bzw. Nicht-Nutzung von Personen und Gütern zum Inhalt haben verhält es sich hier anders. Es herrscht eine hohe Auslastung, nur eben keine sinnvolle.

Die meisten Angestellten kennen es - ein Grossteil ihres Arbeitstages besteht aus Tätigkeiten die nicht zur Wertschöpfung beitragen sondern die Befolgung von Dokumentations-, Beantragungs- oder Arbeitsvorschriften sind. Sind die Empfänger einer Mail nach Hierarchie geordnet? Wurde für den Antrag das vorgeschriebene gelbe Formular verwendet und nicht das blaue? Waren alle Mitarbeiter in der Anwendungsunterweisung für die neuen Bürostühle?

Die offensichtlichte Folge einer derartigen Überregulierung sind steigende Kosten. Die für die Befolgung und Umsetzung der Vorschriften nötige Zeit ist Arbeitszeit die dann an anderer Stelle fehlt. Die ursprüngliche Intention kann sich so in ihr Gegenteil verkehren. Statt alles effizienter und billiger zu machen (das ist nämlich die Absicht der meisten Prozesse) wird alles langsamer und damit teurer. Und auch das lässt sich noch steigern: wenn ganze Stellen geschaffen werden die nichts anderes machen als Prozesseinhaltung zu überwachen. Auch die kosten Geld.

Ein weiterer Effekt von Überregulierung kann sein, dass nicht nur Zusatzaufwand entsteht sondern bestehende Prozesse sich verschlechtern, etwa wenn durch den Versuch Menschen besser auszulasten Staus entstehen. Hinter diesem Phänomen steckt meistens das Gesetz der Penetranz der negativen Reste: um die letzten Effizienzreserven zu heben werden Regulierungen eingeführt die für diesen Zweck unverhältnismässig kompliziert sind - und statt zu Verbesserungen kommt es zu Verschlechterungen.

Weitgehend unberücksichtigt kommt noch ein dritter Faktor dazu: eine starke Regulierung des Arbeitsalltags kann schnell dazu führen, dass nicht mehr offensichtlich ist an welche Vorschriften man sich jetzt halten muss. Ist bei der Beantwortung einer Beschwerde nur der Leitfaden für Kundenkontakt zu beachten oder auch der für lösungszentrierte Kommunikation und der für revisionssichere Fach-Dokumentation? Derartige Unklarkeiten führen schnell in Regel-Aversion und informelle Strukturen, beides mit Effektivitätsverlusten als Folge.

Aus diesen Gründen ist es empfehlenswert die vorgegebenen Prozesse und Regulierungen möglichst gering zu halten und regelmässig zu überprüfen ob die bestehenden sich nicht abschaffen lassen. Im letzten Fall wichtig: abschaffen, nicht durch andere ersetzen. Sonst ist nicht viel gewonnen.

Donnerstag, 11. April 2019

Kontinuierliches Experimentieren (Popcorn Flow)

FS
Dass ich grosser Fan von kontrollierten Experimenten bin hatte ich schon geschrieben. Wie man diese nachhalten und verstetigen kann ist von Team zu Team anders, aber eine mögliche Variante ist der PopcornFlow von Claudio Perrone. Hier von ihm selbst erklärt:



Und: hier befindet sich die dazugehörige Präsentation.

Montag, 8. April 2019

Replenishment (Just in Time-Delivery)

FS
Bild: Flickr / Lyza Danger - CC BY-SA 2.0
Für viele Kanban-Anwender in der IT oder anderen Bereichen der Wissensarbeit ist es in Vergessenheit geraten, aber dieses Framework hat ursprünglich einen sehr handfesten Hintergrund. In den ersten Jahrzehnten seiner Existenz wurden nicht Kreativarbeit oder Dienstleistungen damit gesteuert sondern Fabrikarbeit. Ein besonderer Aspekt war dabei die Organisation von Materialnachschub über so genannte Replenishments. Da es die in der Wissensarbeit auch gibt lohnt ein näherer Blick.

Die Grundidee der Kanban-Replenishments ist die Lieferung möglichst genau zum benötigten Zeitpunkt, also weder zu früh noch zu spät. Da das durch zentrale Steuerung kaum machbar wäre (alleine das dafür nötige Detail-Reporting wäre immens) erfolgt die Koordination dezentral. Wann immer der Vorat eines Werkstoffs eine Mindestmenge unterschreitet wird eine gemeinsam mit diesem Werkstoff aufbewahrte Kanban-Karte entnommen und an denjenigen weitergegeben der für die Bestellung zuständig ist. Da die Mindestmenge auf Verbrauch und Lieferzeit abgestimmt ist erfolgt die Lieferung kurz bevor der Vorrat erschöpft ist.

Der Vorteil dieser so genannten Just in Time Delivery: die Lagerhaltung wird deutlich verringert. Statt vorsichthalber grössere Mengen vorhalten zu müssen ist möglich, dass nur relativ kleine Vorräte angelegt werden. Die mit Lagerhaltungen verbundenen Nachteile (Totes Kapital, benötigte und instandzuhaltende Räumlichkeiten, Veraltung und Beschädigung der Waren, etc.) werden so minimiert. Die im Vergleich zu Europa und Amerika zeitweise erheblich billigere Produktion in Japan ist so zu erklären. Soviel zur Hardware. Aber ist das auch in der Wissensarbeit umsetzbar?

Es ist umsetzbar, wenn auch mit anderen Objekten. Werkstoffe werden in den IT- und Dienstleistungsbrachen praktisch nie zugeliefert, dafür kommt aber etwas anderes in ununterbrochener Regelmässigkeit nach: Anforderungen. Auch bei denen treten negative Effekte auf wenn sie in zu grosser Zahl gleichzeitig eintreffen - sie brauchen länger bis zur Umsetzung, veralten, ihr Kontext ändert sich, Schnittstellen ändern sich, und so weiter. Auch hier kann eine Just in Time Delivery daher Mehrwert stiften.

Natürlich ändert das die Art wie Anforderungen geschrieben werden müssen. Statt möglichst alles zu Beginn auszuspezifizieren muss jetzt mit den Detail-Beschreibungen so lange wie möglich gewartet werden, damit diese Arbeit nicht zu früh fertig wird. Das hat Auswirkungen auf die Organisation: statt einer vorgelagerten Phase ist das Erheben der Anforderungen jetzt ein parallel zur Umsetzung verlaufender Prozess. Und damit trotz allem zielgerichtet gearbeitet wird braucht es Dinge die leider nur wenige Unternehmen haben: eine Produktvision und fachliche Zwischen- bzw. Sprintziele.

Viele Organisationen scheuen diese Umstellung und gehen den scheinbar leichten Weg - vor dem Kanban-System befindet sich ein Backlog mit möglichst vielen, möglichst früh geschriebenen, möglichst detaillierten Anforderungen. Den dafür Verantwortlichen sei ein Besuch in der nächsten nach Kanban arbeitenden Fabrik empfohlen, um dort zu erfahren wie diese Arbeitsweise eigentlich gedacht ist.

Donnerstag, 4. April 2019

Broken Window (II)

FS
Bild: Pixabay / Jeimo - CC0 1.0
Der Broken Window-Effekt, bzw. die Broken-Window-Theorie gehört zu den Klassikern der Kriminologie und Sozialforschung. Sie gehen davon aus, dass die sichtbare Beschädigung eines Objekts (zum Beispiel in Form einer eingeschlagenen Autoscheibe) die Hemmschwelle für weitere Beschädigungen senkt. Findet keine Reparatur statt wird es mit grosser Wahrscheinlichkeit zu weiteren Schäden in der näheren Umgebung kommen, bis hin zum Niedergang ganzer Stadtteile.

Die Übertragbarkeit dieses Effekts, bzw. dieser Theorie auf Transitionsvorhaben ist naheliegend, auch in diesem Fall können erste Verfallserscheinungen mittelfristig zum Scheitern ganzer Change-Vorhaben führen. Darüber hinaus lassen sie sich im Fall agiler Methodeneinführungen aber auch im unmittelbaren Sinn anwenden - dann nämlich wenn es zur Beschädigung oder Verwahrlosung physischer Objekte kommt.

Den agilen Ansätzen kann in diesem Zusammenhang zum Verhängnis werden, dass mit ihnen in der Regel eine intensive Nutzung von an die Wand gehängten "Information Radiators" einhergeht. Kanban-Boards, Product Backlogs, Impediment Backlogs, Personas, Burndown Charts, Roadmaps und viele weitere Fortschrittsindikatoren gehören zum alltäglichen Erscheinungsbild der Arbeitsräume agiler Teams. An ihnen werden Unstimmigkeiten schnell offensichtlich.

Meistens beginnt der Verfall verhältnismässig unspektakulär. In einer Stressphase werden Sprint Backlog und Burndown-Chart nicht aktualisiert, in einem Offsite gesammelte Anforderungen werden nicht sofort nach der Rückkehr an die Wand übertragen, die nicht mehr zur neuen Firmenstrategie passenden Personas bleiben wegen ihrer dekorativen Wirkung hängen, etc. Nach und nach baut sich eine Bugwelle an notwendigen Aktualisierungen auf.

In Summe wird die aufzuholende Arbeit immer mehr, Prokrastination beginnt und setzt sich fest, auf weitere Verschlechterungen "kommt es jetzt auch nicht mehr an", so dass sie bewusst toleriert werden. Vor allem wenn der letzte Punkt erreicht ist, ist der Broken Window-Effekt in vollem Gang. Im harmloseren Fall wird die Arbeit jetzt durch ein schlecht koordiniertes Miteinander digitaler und physischer Tools koordiniert, im schlechtesten Fall findet sie nur noch auf Zuruf statt.

Im Gesamtbild ergeben die vielen vernachlässigten und veralteten Objekte zusammen mit den immer schlechter laufenden Prozessen irgendwann ein immer negativer werdendes Bild. Den Betrachtern kommen problematische Assoziationen in den Sinn: Ungepflegtheit, Vernachlässigung, Verwahrlosung. Früher oder später reift dann im Management die Überzeugung, dass die Mitarbeiter mit selbstorganisiertem Arbeiten überfordert sind und wieder "Führung" brauchen. Die Transition scheitert.

Will man es nicht bis zu diesem Punkt kommen lassen ist es sinnvoll und notwendig schon auf erste Zeichen des Broken Window-Effekts zu reagieren. Wann immer Information Radiators veralten muss allen Beteiligten ins Gedächtnis gerufen werden, dass es sich bei ihnen um ein Spiegelbild des Teamszustandes handelt. Alle (nicht nur der Scrum Master!) müssen daran arbeiten sie durchgehend aktuell und aussagekräftig zu halten, und zwar nicht nur für das Management sondern auch im eigenen Interesse.

Zuletzt noch ein Punkt der häufig in diesem Zusammenhang thematisiert wird: ein Umstieg von physischen auf digitale Tools würde hier Nichts besser machen - die Probleme würden nur weniger offensichtlich werden und sich länger hinziehen.

Montag, 1. April 2019

Kommentierte Links (XXXXVII)

FS
  • Dave Nicolette: Maximizing the Amount of Work Not Done

    Es ist eine der Passagen des Manifests für agile Softwareentwicklung die mehr Beachtung verdienen: Einfachheit - die Kunst die Menge nicht getaner Arbeit zu maximieren - ist von besonderer Wichtigkeit. Was das bedeutet ist nicht näher definiert, so dass es verschiedene Möglichkeiten der Umsetzung gibt.  Die hier vorgestellte ist aus dem Lean Management abgeleitet, wenn auch mit einem Twist: statt in einer negativen Definition die zu vermeidenden Mudas aufzuzählen wird eine positive Herleitung versucht - Einfachheit ist die Focussierung auf lediglich die Tätigkeiten die unmittelbaren Kundennutzen erzeugen, und deren Abarbeitung in einem Pull-orientierten Arbeitsfluss. Ein Ansatz der gut geeignet für Prozessoptimierungen jeglicher Art ist.

  • Klaus Leopold: Es war einmal ein Flight Level

  • An sich ist Kanban alleine darum wunderbar als Framework für agiles Arbeiten geeignet weil es "Open Source" ist. Jeder kann und darf es anpassen wie es passend und notwendig erscheint. Dass ausgerechnet unter den Kanban-Praktikern (vor allem denen die von der Lean Kanban University zertifiziert sind) in den letzten Jahren ein zunehmender Dogmatismus zu erkennen ist ("Das ist nicht Kanban, das ist nur die Visualisierung von Arbeit") ist demnach schade bis ironisch zu betrachten. Im Fall der von Klaus Leopold eingeführten Flight Level hat das zu einer Entkoppelung geführt - dadurch dass nicht mehr von Kanban Flight Leveln gesprochen wird lassen sich Methodendiskussionen vermeiden. Für diesen Fall eine gute Lösung, die im grossen Zusammenhang aber ein Risiko birgt - sollte an weiteren Stellen Vergleichbares passieren könnte sich Kanban irgendwann von der Praxis entkoppeln und in einen Elfenbeinturm zurückziehen.

  • Ron Jeffries: Three-C's Revisited

    Dass nahezu alle Vordenker der verschiedenen agilen Vorgehensmodelle noch am Leben (und sehr meinungsfreudig) sind hat einen grossen Vorteil: wann immer jemand versucht die ursprünglichen Ideen umzudeuten oder zu verfälschen riskiert er korrigiert und blossgestellt zu werden. In diesem Fall handelt es sich bei den Blossgestellten um die Beratungsfirma SolutionsIQ, deren Ansatz zur Standardisierung von User Stories von deren Erfinder seziert wird (siehe auch hier). Er stellt klar, dass eine derartige Vereinheitlichung weder gewollt noch sinnvoll ist. Dass Ron Jeffries sich derartig klar äussert kann man nur dankend annehmen, und man kann nur hoffen, dass er dass noch lange tun kann. Immerhin ist der Mann mittlerweile 80 Jahre alt.

  • Andrew Higgins: How Powerful Is Vladimir Putin Really?

    Ein scheinbar abseitiges Thema. Dass dieser Artikel über die russische Innenpolitik hier verlinkt wird hat aber einen Grund: es geht um die Demystifizierung der Idee des "starken Führers" anhand eines ihrer scheinbar prominentesten Beispiele. Anders als oft angenommen scheint es sich bei Russland nicht um eine "gut geführte Diktatur" zu handeln sondern um ein System in dem zunehmender Kontrollverlust herrscht. Statt den Befehlen von oben zu gehorchen entwickeln die unteren Hierarchiestufen ein Eigenleben, und da das an zu vielen Stellen gleichzeitig geschieht kann die Regierungszentrale das nur noch in Einzelfällen unter Kontrolle bekommen. Ein gutes Anschauungsbeispiel für alle die glauben, grosse Organisationen liessen sich von oben führen.

  • Michael Küsters: Your Sprint Reviews suck, and that's why!

    Zu diesem Thema hatte ich auch schon etwas geschrieben, aber natürlich noch nicht abschliessend. Michael Küsters fügt weitere wichtige Punkte hinzu. Man könnte sicher noch weitere auflisten, man kann es aber auch kurz machen: Sprint Reviews sollten unbürokratisch und handlungsorientiert auf den Punkt bringen welcher Mehrwert, bzw. Kundennutzen erzeugt wurde. Dann sind sie gut.
Powered by Blogger.