Montag, 26. Oktober 2020

Der Product Owner als Key Account Manager

FS
Bild: Pexels / Christina Morillo - CC0 1.0

Eine der zentralen Vorraussetzungen von agiler Produktentwicklung ist die Etablierung von so genannter Product Ownership. Um für den eigenen Fortschritt nicht auf andere angewiesen zu sein wird eine möglichst starke Focussierung angestrebt. Ein einziges crossfunktionales Team exklusiv für ein Produkt, mit allen Berechtigungen es verändern und modifizieren zu dürfen. Nur so ist das schnelle Inspect & Adapt möglich, das den Kern aller agilen Vorgehensweisen bildet.


Der de facto Standard dieser Umsetzungen ist mittlerweile Scrum, das in seinen Teams sogar eine explizite Rolle für Product Ownership hat, sinnigerweise Product Owner genannt. Richtig umgesetzt ist der nicht nur ein einfacher Business Analyst oder Anforderungsmanager sondern er entwickelt sein Produkt langfristig und strategisch weiter, hat den Überblick über vergangene Entscheidungen und hält Kontakt zu dessen Anwendern und Stakeholdern.


Soweit die Theorie. In den meisten Fällen ist sie anwendbar, in einigen allerdings nicht. Im Agentur-Umfeld kommt es beispielsweise vor, dass Teams für einzelne Sprints an Kunden verkauft werden um an dessen Systemen zu arbeiten, in Konzernen kann es sein, dass die Zuordnung eines Teams zu einem Produkt nur so lange anhält wie die dahinterstehende Fachabteilung Projektbudget hat. In diesen und vergleichbaren Fällen springen Teams und Product Owner regelmässig von Produkt zu Produkt.


Um die negativen Effekte dieser ständigen Wechsel zumindest in Grenzen zu halten findet man in manchen Unternehmen eine Ausgestaltung der Product Owner-Rolle die in Teilen einem Key Account Manager entspricht, also dem Hauptbetreuer eines wichtigen Kunden oder Auftraggebers. Für diesen ist der jeweilige Product Owner dann der primäre Ansprechpartner in der Anwendungsentwicklung, selbst dann wenn es um verschiedene (weiter)zu entwickelnde Produkte geht.


Was in einer solchen Konstellation weiterhin möglich ist, ist eine dauerhafte Beziehung zu wichtigen Anwender- und Stakeholdergruppen. Andere Auswirkungen können zumindest abgeschwächt werden: die Kontextwechsel werden tendenziell weniger, da die Wahrscheinlichkeit steigt auch zukünftig wieder mit den Produkten zu tun haben, und vergangene Erfahrungswerte können in diesen Fällen wiederverwertet werden.


Ganz ersetzen kann eine solche Konstellation echte Product Ownership nicht (alleine deshalb nicht weil zwischendurch andere Teams daran arbeiten können), in den oben genannten Konstellationen ist sie aber eine gute Möglichkeit dem zumindest so nah zu kommen wie möglich.

Donnerstag, 22. Oktober 2020

Der Agile Song

FS

Auf die Gefahr hin in diesem Monat eine leichte Schlagseite in Richtung "agile Netzfundstücke" zu bekommen - das hier ist dann doch zu bemerkenswert um es hier nicht einzubetten. Der "Agile Song"  von Adam Janosch wurde gestern auf dem kölner Scrumtisch zwischen den Sessions gespielt und zumindest bei mir ist er direkt im Ohr hängen geblieben.


 


Um es auf eine Meta-Ebene zu hieven: dass es Werke wie dieses Lied gibt würde ich in ein Phänomen einordnen, dass ich einmal The Soft Power of Scrum genannt habe. Viele Umsetzungen dieses und anderer Frameworks sind bewusst verspielt, bunt und geekig gehalten, und das nicht etwa als von oben verordnetes Image-Programm sondern weil die an der Umsetzung Beteiligten sich über das rein Berufliche hinaus mit dem Vorgehen identifizieren und ihre Energie und Kreativität einfliessen lassen. Das ist etwas was nur sehr wenige andere Projekt-, Produkt- oder Prozessmanagement-Ansätze über sich sagen können.

Dienstag, 20. Oktober 2020

Agile Bauprojekte (IV)

FS
Bild: Wikimedia Commons / Michael Wolf - CC BY-SA 3.0

Die Zukunft hat bereits begonnen. Noch vor kurzem galten agile Vorgehensweisen bei Bauvorhaben als etwas hochgradig Theoretisches, mittlerweile können wir eines mitten in Deutschland beobachten. Die Tesla-Gigafactory 4 bei Berlin wird iterativ-incrementell gebaut (nachzulesen bei der SZ): zuerst werden kleinere, schnell fertigzustellende Gebäude errichtet, deren Konstruktionsgeschichte wird ausgewertet und die Erkenntnisse fliessen als Verbesserungen in die nächstgrösseren Bauvorhaben ein, und das in Rekordzeit. Wie ist das möglich?


Ein lesenswerter Artikel der Zeit (leider hinter einer Paywall) liefert einige Antworten. Es beginnt mit den bekannten Faktoren, die z.T. auch den schnellen Bau der chinesischen Corona-Kliniken geprägt haben: Einfachheit, Standardisierung, Modularisierung, Entbürokratisierung und wenn möglich Wiederverwendung der Pläne von bereits erfolgreich abgeschlossenen vergleichbaren Bauvorhaben. Im Mittelpunkt stehen aber zwei weitere, bei Bauprojekten hochgradig unübliche: Risiko-Toleranz und Fehlerkultur.


Um nachvollziehen zu können warum das ein Paradigmenwechsel ist muss man auf das Risikomanagement klassischer Bauprojekte schauen. In ihm wird versucht Risiken dadurch zu begrenzen, dass die Beteiligten in möglichst detaillierten Verträgen regeln was welcher der beteiligten Geschäftspartner zu welchem Zeitpunkt zu erbringen hat. Gelingt einem von ihnen das nicht hat er für die entstehenden Mehrkosten aufzukommen, die anderen aber nicht.


In der Theorie mag das wie eine sinnvolle Umsetzung der Verursacherprinzips aussehen (wer Aufwände und Verzögerungen verursacht zahlt), in der Realität führt es aber zu ausufernden Vertragsverhandlungen, absurd detaillierten Vertragswerken, dem Zweckentfremden von Flexibilitätsreserven, extrem aufwändigen Prozessen bei nachträglichen Anpassungen und oft auch zu erbittert ausgefochtenen Rechtsstreitigkeiten. Die dadurch entstehenden Kosten und Aufwände gehören dann zu den stärksten Treibern von Budget- und Zeitplan-Überschreitungen.


Um derartige Entwicklungen gar nicht erst aufkommen zu lassen werden beim Bau der Gigafactory 4 bewusst Risiken eingegangen: statt der üblichen Festpreis-Verträge für bestimmte Gewerke erhalten die Baufirmen pauschale Aufwandsvergütungen, wenn für den schnellen Baufortschritt mehr Geld benötigt wird als initial geplant ist der Freigabeprozess unbürokratisch und wenn derartige Mehraufwände entstehen liegt das Hauptinteresse nicht auf dem Finden und Bestrafen von Schuldigen sondern auf dem schnellen Reagieren auf die geänderten Rahmenbedingungen.


Letztenendes wird hier ein systemischer Ansatz sichtbar. Natürlich kann es sein, dass bei diesem Vorgehen Teile des Gesamtvorhabens teurer werden als gedacht. Durch den bewussten Verzicht auf Detailregelungen, Prozessverflechtung und (juristische) Konflikte wird die Umsetzungsdauer aber derartig verkürzt, dass die frühe Betriebs- und Wertschöpfungsfähigkeit (und das dadurch mögliche frühere Erwirtschaften von Gewinnen) das bei weitem ausgleichen dürfte.


Für alle die das nicht so ganz glauben können hält der deutsche Standort von Tesla übrigens noch eine schöne Pointe bereit. Nur 30 Minuten Autofahrt entfernt kann man begutachten wohin klassisches Management eines Bauprojektes führen kann. Die Rede ist vom neu gebauten Berliner Flughafen, der jetzt endlich eröffnet wird - neun Jahre nach dem ursprünglich geplanten Termin und deutlich teurer.

Donnerstag, 15. Oktober 2020

Ein Bild sagt mehr als 1000 Worte (XXX)

FS

Wow. einfach wow.

Montag, 12. Oktober 2020

Everything I know about teams, I learned from computers

FS

Das ist ein wundervoll nerdiger und ganz anderer Ansatz auf Teams zu schauen als der den man meistens vorfindet. Andrew Harvey nimmt sein Wissen über verteilte Systeme, überträgt sie auf die Zusammenstellung und das Managen von Teams - und das funktioniert erstaunlich gut.




Was ausserdem hervorzuheben ist sind die im Vortrag enthaltenen Anregungen sich in weitere Themen einzuarbeiten. Von den Neurowissenschaften bis zu den acht Irrtümern über verteilte Systeme ist Einiges dabei was sich zu erforschen lohnt.

Donnerstag, 8. Oktober 2020

Altsysteme (III)

FS
Screenshot: Flickr / Josiah Ritchie - CC BY-SA 2.0
Legacy Software ist immer ein ergiebiges Thema, so auch im folgenden aktuellen Fall. Im Rahmen der Nachverfolgung von Coronavirus-Infektionen ist den britischen Gesundheitsbehörden eine massive Datenpanne unterlaufen: die Daten von fast 16.000 Tests gingen verloren, und das zunächst unbemerkt, mit unabsehbaren Folgen für die Verbreitung der Pandemie. So einzigartig wie dieser Fall erscheinen mag, seine Ursache ist weit verbreitet - das Verwenden einer hoffnungslos veralteten Standardsoftware.


Die ganze Geschichte kann man bei der BBC nachlesen: der die Tests durchführende Dienstleister trug die Ergebnisse zuerst in eine CSV-Datei ein und schickte diese dann an die Behörde Public Health England (PHE). Diese übertrug sie in das dort bevorzugte Tool, Excel von Microsoft. Und bei dieser Übertragung kam dann es zum unbemerkten Datenverlust. Der Grund dafür - die verwendete Excel-Version war zu alt. Warum das ein Problem ist lässt sich einfach erklären.


Bis zum Jahr 2007 speicherte Excel seine Dateien im XLS-Format ab, das bereits im Jahr 1987 eingeführt worden war. Neben anderen Problemen hat dieses alte Format eine Grössenbegrenzung auf genau 65.536 Zeilen, werden mehr eingegeben werden diese einfach nicht gespeichert. Seit 2007 sind daher neuere Excel-Versionen im Einsatz, die Dateien im XLSX-Format abspeichern, mit bis zu 1.048.576 Zeilen (die Erklärung dieser scheinbar krummen Zahlen findet sich hier).


Dem die Testergebnisse zuliefernden Dienstleister dürfte nicht bewusst gewesen sein, dass der PHE seit mindestens 13 Jahren nicht mehr in der Lage gewesen ist sein Excel auf die aktuelle Version upzudaten (warum das so sein dürfte steht hier) und vermutlich wusste der PHE auch nicht, dass seine alte Version die oben erwähnte Beschränkung hatte. Ohne zu ahnen, dass das ein Problem war wurde also eine viel zu hohe Menge an Datensätzen geliefert1, von denen dann alles ab Zeile 65.537 aufwärts beim Übertragen in Excel verloren ging.


Die grundlegenden Phänome die man aus dieser Geschichte ableiten kann: wenn veraltete Versionen einer Standardsoftware im Einsatz bleiben nehmen Anwender oft ohne darüber nachzudenken an, dass Eigenschaften der neuen Versionen (z.B. hohe Speicherkapazität) auch in der alten bereits vorhanden sind. Ausserdem geraten Probleme der alten Version (z.B. ausbleibende Warnungen bei Datenverlust) in Vergessenheit, da sie in der neuen unbekannt sind.


Um nicht den damit verbundenen Risiken ausgesetzt zu sein empfiehlt sich ein permanentes Updaten aller Standardsoftwares auf die jeweils neueste Version. Wenn zu starke Anpassungen vorgenommen wurden kann das zwar aufwändig werden, dass es trotzdem Sinn macht dürfte aber spätestens seit der Datenpanne des PHE offensichtlich sein.



1Da jeder Datensatz mehrere Zeilen enthält konnten pro Datei nur 1.400 gespeichert werden

Montag, 5. Oktober 2020

Geht zur nächsten Windows-Schulung!

FS
Bild: Pixabay / Escola Espai - CC0 1.0

Würde man nach Veranstaltungen suchen die in der IT hochgradig unbeliebt sind, dann gäbe es sicher eine die weit vorne dabei ist: die verpflichtende Microsoft Windows-Schulung, die in vielen Unternehmen für jeden Mitarbeiter vorgesehen ist der neu ist oder der eine neue Windows-Version erhält1. Jeder der in der Softwareentwicklung tätig ist wird alleine bei der Ankündigung genervt fragen was er da noch lernen kann. Die überraschende Antwort - sehr viel, vorausgesetzt eine Sache ist gegeben. Der eigene Arbeitskontext muss einer sein bei dem Anwendungen für den internen Gebrauch entwickelt werden.


Was sich in diesem Fall hier gewinnen lässt ist ein gutes Verständnis der eigenen Zielgruppe, schliesslich sind die Kollegen in dieser Schulung im Zweifel auch die, die später auch die Software benutzen werden an der man selbst arbeitet. Und selbst wenn es um diese in dem Moment nicht geht - man kann trotzdem beobachten wie die Interaktion mit neuen Funktionen und Benutzeroberflächen vor sich geht und Rückschlüsse daraus ziehen.

 

Die offensichtlichste Erkenntnis betrifft die EDV-Affinität. Kennen die Schulungsteilnehmer die Fachbegriffe ("Was ist ein Browser?"), wissen sie wie man durch Dateien navigiert ("Im C-Laufwerk ist nichts") und sind ihnen die wichtigsten Troubleshootings bekannt ("Das Programm hatte sich aufgehängt, ich hab es mit dem Task-Manager geschlossen")? Basierend auf diesen Informationen kann entschieden werden wie kompliziert die eigene Anwendung sein darf und wie gut sie dokumentiert sein muss.


Auch über die Bereitschaft sich in neue Funktionalitäten einzuarbeiten und neue Designs zu akzeptieren kann man hier viel lernen. Gibt es Beschwerden darüber, dass Outlook nicht mehr gelb ist? Wird Freude darüber geäussert von Skype auf Teams-Calls umzusteigen? Abhängig davon kann entschieden werden ob Bedienelemente oder Styleguide sich eher an bisherigen Standards orientieren sollten oder ob man Neues ausprobieren kann.


Ein weiterer Aspekt sind die Hilfsmittel die üblich sind und ggf. erwartet werden. Reicht eine Beschreibung in Textform? Werden Anleitungen mit kommentierten Screenshots erwartet? Gibt es eine Akzeptanz für Wikis, Chatbots und Schulungsvideos oder wird ein Kursleiter erwartet der Fragen beantworten und bei Problemen helfen kann? Für das Rollout der eigenen Features kann später auf dieses Wissen zurückgegriffen werden.


Eine oft vernachlässigte Erkenntnis bezieht sich auf den Grad des Austausches zwischen den Kollegen. Bitten sie sich gegenseitig um Hilfe oder bieten sie sich diese sogar von selbst untereinander an? Oder sitzt jeder still vor seinem Rechner und ruft nur den Kursleiter per Handzeichen zu sich? Je nachdem was der Fall ist kann es für das eigene Produkt ausreichend sein nur jeweils einem "Multiplikator" pro Team Neuheiten vorzustellen oder besser alle einzuladen.


Nicht zu unterschätzen ist auch, dass man lernen kann wie gerne überhaupt in Schulungen gegangen wird. Von "endlich mal was Neues" bis "während wir hier Zeit verschwenden türmt sich bei uns die Arbeit" sind alle möglichen Reaktionen denkbar, und aufbauend darauf kann entschieden werden ob man zukünftig eher häufig oder eher seltener zu Demonstrationen und Hands on-Sessions einlädt.


Zuletzt, und vielleicht ist das sogar das Wichtigste, kann man auf Windows-Schulungen auch etwas über sich selbst lernen. Kommen einem bestimmte Dinge vielleicht selbstverständlicher vor als sie sind (um das Naheliegendste zu nennen - geht man z.B. davon aus, dass eigentlich jeder weiss wie Windows funktioniert)? Und kann es sein, dass man in die eigene Zielgruppe viel von sich selbst hineinprojiziert? Die Antwort auf diese Fragen kann ernüchternd sein, sie verhindert aber, dass man Anwendungen versehentlich für sich selbst entwickelt statt für die Menschen für die sie eigentlich gedacht sind. 


1In vielen Firmen ist die Umstellung auf Windows 10 noch nicht abgeschlossen. Ein eigenes Thema.

Mittwoch, 30. September 2020

Kommentierte Links (LXVI)

FS
  • Kent Beck: Oh The Messes We Will Make

    Ein guter Opener ist bekanntlich alles, und der hier verlinkte Text hat einen besonders schönen. In nur 70 Worten erklärt Kent Beck einen psychologischen Fachbegriff (Ataxophobie), lässt beiläufig fallen, dass er Extreme Programming erfunden hat, macht klar welche Hoffnungen er damit verbunden hatte und verteidigt seinen Status als grimmiger alter Mann der Agilität einmal mehr durch das schöne Bonmont, dass Software nur drei Zustände kennt: desaströs, desaströs und unbenutzt. Es gibt dann noch die Erklärung was die drei klassischen Phasen des Extreme Programming sind, warum in ihnen zwangsläufig Unordnung entehen muss und warum das natürlich und behebbar ist. Und wer danach noch immer nicht genug hat kann bei Ron Jeffries weiterlesen, der das Ganze auf seinem Blog nochmal weiterführt.

  • Fagner Brack: Specialisation Is The Root Of All Evil

    Das hier ist streckenweise etwas technisch, aber der Löwenanteil der agilen Produktentwicklung findet nun mal in der IT statt. Die Botschaft die Fagner Brack hier vermitteln möchte dürfte aber auch in jedem anderen komplexen Umfeld zutreffen: dort wo eine zu starke Spezialisierung von Arbeit stattfindet sind böse Überraschungen im wahrsten Sinn des Wortes vorprogrammiert und tauchen mit unschöner Zuverlässigkeit immer dann auf wenn die Spezialisten-Teilprodukte zusammengefügt werden. Um dem entgegenzuwirken sind Generalisten gefragt, und zwar laut Brack nicht solche die alles können (was unmöglich ist) sondern solche die in der Lage sind herauszufinden welches Wissen sie sich wann zu welchem Zweck aneignen müssen. Ein interessanter (und im Gegensatz zum üblichen Klischee auch umsetzbarer) Blick auf den mythischen "Fullstack-Developer".

  • Alex Ballarín: Time to say goodbye to Dual Track Agile?

    "Dual Track Agile" (zwei parallel laufende und jeweils in sich agil organisierte Stränge für Product Discovery und Product Delivery) gilt für den einen oder anderen als die geheime Zutat für erfolgreiche Produktentwicklung. Das ist auch nicht grundlegend falsch, je nach Kontext kann dieses Vorgehen durchaus Sinn machen. Was Alex Ballarín hier zurecht anmerkt ist aber, dass sich dieses Vorgehen in der Praxis fast immer zu kleinen Wasserfallstrukturen entwickelt, mit allen Nachteilen die damit verbunden sind: langen Lieferzyklen, schlechten Sprintzielen, demotivierten Entwicklern und reduzierten Lerneffekten. Was ihm im Folgenden hoch anzurechnen ist - er stellt nicht einfach ein Idealbild als Gegenentwurf auf sondern er erklärt auch warum das so schwer umzusetzen ist - und wie es vielleicht doch geht.

  • Roman Pichler: Prioritising a Product Backlog When Everything is Important

    Für viele Product Owner eine bekannte Situation: der Auftraggeber will aus einem riesigen Wunschkorb alles haben und für ihn ist auch alles gleich wichtig, so dass es zunächst unmöglich erscheint ein priorisiertes Backlog zu erstellen. Roman Pichlers (verkürzte) Anleitung zur Auflösung dieses Dilemmas: die (Nutzer-)Zielgruppe identifizieren, deren Bedürfnisse feststellen, davon die Dringendsten auswählen und damit anfangen. Das klingt erstmal einfach, dürfte in meiner Erfahrung zuerst zu einer weiteren Erkenntnis führen - hinter einem (zu) grossen Anforderungsumfang steckt sehr häufig eine unklare Vorstellung vom eigenen Kunden. Wenn das der Fall ist macht es Sinn damit anzufangen die zu schärfen und erst danach über die Backlog-Priorisierung nachzudenken.

  • Dilbert: Applying Math To Guesses

    Dass Scott Adams es auch nach über 30 Jahren und tausenden von Comic Strips noch schafft den gelegentlichen Wahnsinn von Konzern-Jobs auf den Punkt darzustellen ist bewundernswert. Diesesmal geht es um die Angewohnheit Prognosen zu unprognostizierbaren Sachverhalten zu verlangen. Und genau so wie hier beschrieben kommt es jeden Tag irgendwo vor.

Montag, 28. September 2020

Regression zum Rand

FS
Grafik: Pixabay / Mediamodifier - CC0 1.0

Ein Hoch auf die Wissenschaft! In diesem Fall ein weiteres mal auf den Oxford-Professor Bent Flyvbjerg, über den ich bereits vor mehreren Jahren etwas geschrieben habe. Flyvbjerg hat sich scheiternde Grossvorhaben als Forschungsgegenstand ausgewählt und publiziert viele lesenswerte Veröffentlichungen zu diesem Thema. Die um die es heute gehen soll definiert eine neue Regel: The Law of Regression to the Tail, zu deutsch Das Gesetz der Regression zum Rand (hier der Link zu einer Zusammenfassung).


Um zu verstehen was damit gemeint ist zunächst ein kurzer Exkurs zu einer anderen Gesetzmässigkeit, dem Gesetz der Regression zur Mitte. Erstmals nachgewiesen 1877 vom britischen Wissenschaftler Francis Galton besagt es, dass nach einem extrem ausgefallenen Messwert die nachfolgende Messung meistens wieder näher am bisherigen Durchschnitt liegt1. Es gibt also eine natürliche (und statistisch belegbare) Tendenz zum Ausgleich und zum Durchschnittswert, die sich als Grundlage für Prognosen und Planungen nutzen lässt.


Zurück zu Flyvbjerg. Seine These ist, dass das Gesetz der Regression zur Mitte in wichtigen Fällen nicht anwendbar ist, und zwar immer dann wenn extrem ausgefallene Messwerte in hoher Frequenz auftreten. Die dahinterliegende Erklärung: da sich mit der Frequenz auch die Varianz erhöht (also die Spanne innerhalb der etwas noch als durchschnittlich gilt) liegen irgendwann auch Extremwerte im Durchschnittsbereich, wodurch die Regression zur Mitte nicht mehr stattfindet.


Darauf aufbauend geht Flyvbjerg noch einen Schritt weiter: wenn eine steigende Frequenz extremer Ereignisse die Varianz so erhöht, dass irgendwann alle Werte im Durschnitt liegen, und wenn ein Durchschnitt per Definition immer das ist was zwischen den Extremwerten liegt, dann ist es zwangsläufig, dass es regelmässig zu immer höheren Extremwerten kommen muss. Diese Umkehrung der Regression zur Mitte nennt er das Gesetz der Regression zum Rand.


Das Auftreten dieser Gesetzmässigkeit verortet er vor allem in seinem eigenen Forschungsgebiet, also bei scheiternden Grossvorhaben. Bei insgesamt 10 Arten von Extremvorfällen erkennt er eine so starke Regression zum Rand, dass sich sämtliche vorbeugenden Gegenmassnahmen regelmässig als unzureichend erweisen: Erdbeben, Cyberkriminalität, Kriege, Pandemien, Kostenexplosionen in IT-Projekten, Überflutungen, Pleitewellen, Feuerkatastrophen, Kostenexplosionen globaler Sport-Events und grossflächige Stromausfälle.


Er belässt es aber nicht bei dieser Analyse sondern nennt auch vier Gegenmassnahmen die sich in seiner Forschung als sinnvoll erwiesen haben: frühzeitige Planung der voraussichtlich nötigen Schadensbegrenzung, vorbeugende Massnahmen zur Begrenzung des Schadensumfangs, Evaluierung theoretisch möglicher "extremer Extremvorfälle" und Aufbau von Strukturen die bei Bedarf zu schnellen und umfassenden Reaktionen in der Lage sein können.


Flyvbjergs Empfehlungen mögen naheliegend erscheinen, üblich sind die aber nicht, zumindest nicht alle. Während die ersten beiden dieser Gegenmassnahmenauch im klassischen Projektmanagement zum Standard gehören sind die beiden anderen seltener vorzufinden. Das heisst aber nicht, dass es sie nicht gibt - für die Evaluierung extremer Extremvorfälle gibt es bereits mehrere Ansätze und für ein Vorgehen schneller Reaktionsfähigkeit sogar einen der sich durchgesetzt hat: Agilität.


1Das gilt natürlich nur wenn die gemessene Entwicklung nicht gesteuert oder beeinflusst wird.

Donnerstag, 24. September 2020

Digitalisierung (IV)

FS
Bild: Pixabay / Joshua Woroniecki - CC0 1.0
Die Faszination an der Tatsache, dass es in vielen Unternehmen auch im zweiten Jahrzehnt des 21. Jahrhunderts noch Digitalisierungsprojekte gibt hat schon zu einigen Artikeln auf dieser Seite geführt. Dass noch weitere dazukommen werden ist absehbar, zu vielschichtig sind die Gründe die zu immer neuen derartigen Vorhaben führen. Der um den es heute gehen soll wurde bereits 2015 beschrieben, mit einem Satz der seitdem in der IT-Branche zu einem geflügelten Wort geworden ist:

"Wenn sie einen Scheißprozess digitalisieren, dann haben sie einen scheiß digitalen Prozess."

Thorsten Dirks, Vorstandsvorsitzender der Telefónica Deutschland, auf dem Wirtschaftsgipfel der Süddeutschen Zeitung


Was Thorsten Dirks mit dieser leicht obszönen Ausdrucksweise hervorheben wollte ist einer der grössten Fehler den man bei Digitalisierungsprojekten machen kann (der aber trotzdem immer wieder gemacht wird) - die Eins zu Eins-Übertragung eines bisher analogen Arbeitsablaufs in eine digitale Form. Warum das ein Fehler ist lässt sich an einem einfachen Beispiel aufzeigen.

Stellen wir uns den Posteingang eines grossen Unternehmens vor. Sämtliche eingehenden Briefe werden von der Zentral-Poststelle nach Ressort sortiert, dann von den Ressort-Poststellen nach Priorität sortiert und dann zur Bearbeitung den Fachreferaten übergeben. Nach einem Digitalisierungsprojekt werden eingehende Emails in der Zentral-Poststelle nach Ressorts sortiert, dann von den Ressort-Poststellen nach Priorität sortiert und dann zur Bearbeitung den Fachreferaten gemailt.1

Zwei Dinge sind an diesem Beispiel zu beachten: zum einen war bereits der ursprüngliche, analoge Prozess offensichtlich schlecht designed. Mit den beiden verschiedenen Poststellen wies er gleich zwei Flaschenhälse auf, dazu kommt, dass die ohne Abstimmung mit den Fachreferaten vorgenommene Priorisierung das Risiko von Fehl-Optimierungen erhöhte. Und zum anderen wurden die Schritte dieses Prozess durch die Digitalisierung nicht verändert sondern nur in ein anderes Medium übertragen.

Eine Digitalisierung derartiger Abläufe kann zwar in überschaubarem Rahmen für Beschleunigung sorgen (Emails sind schneller als Briefe), das mögliche Potential wird dadurch aber nur in Ansätzen ausgeschöpft. Wesentlich weiter kann man kommen wenn auch das grundlegende Prozessdesign neu gedacht wird. Gerade die Bearbeitungsschritte die in der analogen Welt noch nicht möglich waren sind es schliesslich, die die grösste Wirkung entfalten können.

Noch einmal zurück zum Beispiel des Grossunternehmens-Posteingangs. Er könnte so umgestaltet werden, dass die Fachabteilungen von aussen kommende Mails direkt empfangen können2, durch KI könnte bei zentral eingehenden Mails automatisiert erkannt werden wo sie hingehören und die Priorisierung könnte im Rahmen gemeinsamer Arbeit an geteilten Dokumenten erfolgen auf die jeder zugreifen kann.

Vermutlich würde hier eine begriffliche Differenzierung Sinn machen. Neben der Digitalisierung im engeren Sinn (der Umwandlung bestehender Prozesse) könnte die digitale Neugestaltung von Prozessen gestellt werden. Digitalisierungsvorhaben wären beide, der zweite Typ hätte aber einen wesentlich höheren Wirkungsgrad.


1Dieses Beispiel ist von einem real existierenden Fall inspiriert
2Das ist in manchen Konzernen tatsächlich nicht möglich

Montag, 21. September 2020

The Evolution of Enterprise DevOps

FS

Das was Graham Zabel hier bietet ist ein interessanter Einblick in die Art wie in Konzernen DevOps betrieben wird. Angefangen von eher inoffiziellen und anarchischen Anfängen über die "historisch gewachsene" Gegenwart bis zu den regulierten und komerziell getriebenen Ansätzen die sich langsam ausbreiten.




Was man ergänzend erwähnen sollte: so richtig und sinnvoll diese Entwicklung aus betriebswirtschaftlicher und IT-Sicherheits-Sicht sein mag - es besteht das Risiko, dass es als "Kollateralschaden" zu dogmatischen Vorschriften und bürokratischen Genehmigungsverfahren kommt. Die Konzerne die sich auf diesen Weg begeben wären gut beraten, wenn sie darauf ein Auge haben würden.

Donnerstag, 17. September 2020

Agile HR on a Poster

FS

Das ist doch mal eine schöne Übersicht. Meine erste Überlegung war zwar ob das nicht eher Agile allgemein als Agile HR ist, aber das würde in die (zu grosse) Debatte führen was HR eigentlich sein soll und will. Was mir besonders gefällt ist der breite Überblick über viele verschiedene Aspekte, der gute erste Einblicke gibt, auf der anderen Seite aber auch erkennen lässt, dass es noch einen grossen vertiefenden Wissensfundus gibt den man erkunden kann.

Bild: Dandy People - CC BY-SA 4.0 (zum Vergrössern klicken, Download hier)

Und natürlich werden hier auch einige Reflexe getriggert. Oben bei Spotify und SAFe habe ich kurz den Atem angehalten, unten bei Cynefin und Modern Agile war ich dann wieder positiv überrascht. Es dürfte für jeden etwas dabei sein.

Montag, 14. September 2020

Das agile Mindset (eine Dekonstruktion)

FS

 

Grafik: Pixabay / Geralt - CC0 1.0

Dafür, dass das Konzept des "Agilen Mindset" eines ist das häufig genannt und häufig für zentral erklärt wird ist es erstaunlich umstritten. Für die einen ist es die unabdingbare Voraussetzung für jegliche Art des agilen Arbeitens, für andere eher eine esoterische Nebelkerze, die geworfen wird um nicht über die wirklich wichtigen Themen reden zu müssen. Was beide Sichten gemeinsam haben ist aber, dass es hochgradig unklar bleibt was eigentlich gemeint ist wenn dieser Begriff fällt. Höchste Zeit ihn auseinanderzunehmen und einen Blick auf die darin verborgenen Bestandteile zu werfen. Hier sind sie, gesammelt mit einer Kernfrage im Hintergrund - was muss gegeben sein um in kurzen Zyklen reaktions- und lieferfähig (→ agil) zu sein?


Offenheit

Der vermutlich offensichtlichste Bestandteil. Ohne eine grundlegende Offenheit für Neues wird man sich schwer damit tun den initial gefassten Plan ständig zu überprüfen und an die sich ändernde Realität anzupassen. Grundlage dafür ist ein noch fundamentaleres Phänomen, das "Growth Mindset". Es zeichnet die Menschen aus die sich über Überraschungen, neue Herausforderungen und neu zu lernende Themen freuen, statt sie als Belastung zu empfinden ("Fixed Mindset").


Systemisches und analytisches Denken

Ebenfalls fundamental ist die Fähigkeit und Bereitschaft systemisch zu denken. Die Ursache der Komplexität (zu deren Bewältigung die agilen Ansätze entwickelt wurden) sind die unvorhersehbaren Interaktionen der verschiedenen Teil- und Umgebungssysteme. Um auf die Folgen dieser Interaktionen gegebenenfalls schnell reagieren zu können ist es nötig diese Systeme und ihre Beziehungen untereinander identifizieren und analysieren zu können.


Zahlengetriebenheit

Gerade bei Analysen komplexer Zusammenhänge sind es vor allem Zahlen (und deren Veränderungen) die analysiert werden müssen, da Einzelfälle bestenfalls anekdotische Evidenz liefern. Alleine das zu erkennen ist ein wichtiger Schritt, weitere bestehen darin zu erkennen welche Zahlen in welchem Kontext Sinn machen (und in welchem nicht), wie sie erhoben werden können, wozu sie genutzt werden können und wie hoch der damit verbundene Aufwand ist.


Kunden- und Zielgruppenorientierung

Agilität bedeutet auch, die Menschen für die man arbeitet immer besser zu verstehen zu wollen um die Interaktion mit ihnen ständig optimieren zu können. Was sind die Bedürfnisse und Nutzungsgewohnheiten, wie schnell und in welcher Frequenz werden neue und verbesserte Angebote gebraucht, wie werden sie angenommen, wie wird das Feedback eingesammelt und wie fliesst es in das weitere Vorgehen ein? Diese Fragen müssen regelmässig gestellt werden.


MVP-Orientierung

Ein dem Kundenkontakt vorgelagerter Perfektionismus kann alles langsam und teuer machen, da durch ihn die Nutzer- und Auftraggeber-Rückmeldungen erst spät erfolgen und es erst zu spät klar wird wenn irgendwo am Bedarf vorbeiproduziert wurde. Besser ist es auf Minimum Viable Products (MVPs) zu vertrauen, rudimentäre aber bereits benutzbare Früh-Versionen, mit denen bereits Feedback eingeholt und in die Weiterentwicklung integriert werden kann.


Nachholender technischer Perfektionismus

Das unverzichtbare Gegenstück zur MVP-Orientierung. Da diese immer wieder dazu führt, dass Ideen "quick and dirty" umgesetzt werden (was erwünscht ist!) besteht immer wieder die Notwendigkeit diejenigen unter ihnen die von den Nutzern angenommen wurden zu überarbeiten um so die unkomplizierte technische Verständlichkeit, Wartbarkeit und Weiterentwickelbarkeit sicherzustellen. Wird das unterlassen wird alles schwerfällig und langsam, also un-agil.


Verantwortlichkeits- und Delegationsbereitschaft

Zu den grundlegenden Voraussetzungen schneller Kommunikations- und Reaktionsfähigkeit gehört die Abwesenheit grosser oder komplizierter Hierarchien, die den Fluss von Informationen und Entscheidungen verlangsamen und (unabsichtlich) verfälschen würden. Um diese Abwesenheit zu ermöglichen ist es zum einen nötig Informationszugänge und Entscheidungskompetenzen "nach unten" zu verlagern, zum anderen aber auch, dass diese Verantwortungen dort angenommen werden.


Teamfähigkeit

Ein scheinbar einfacher Begriff, hinter dem aber mehr steckt. Teamfähigkeit beschreibt nicht nur die Bereitschaft mit anderen zusammenzuarbeiten sondern im agilen Kontext auch sich als Gruppe so weiterzuentwickeln, dass Crossfunktionalität gegeben ist, dass die Kommunikation effizient ist, dass Flaschenhälse abgebaut werden und dass eine Verantwortlichkeits-, Produktivitäts- und Kreativitäts-fördernde Atmosphäre entsteht.


Transparenz und Ehrlichkeit

Zwei Eigenschaften die beide auf das selbe Ziel einzahlen - die anderen Menschen sollen nicht gezwungen sein nach versteckten und verschwiegenen Informationen suchen zu müssen und sie schlimmstenfalls erst zu spät zu finden. Beides würde entweder zu Verzögerungen führen oder dazu, dass Fehler zu spät erkannt und aufwändig korrigiert werden müssen, schlimmstenfalls mit Auswirkungen auf Qualität und Kundenzufriedenheit.


Humanismus

Ein Wesenszug der meistens (oft unter anderen Namen) zuerst genannt wird steht hier bewusst ganz unten. Um Missverständnisse zu vermeiden - Vertrauen, Empathie, Wertschätzung, Integrität, Augenhöhe und Ähnliches sind grundsätzlich richtige und wichtige Dinge um die sich jeder Mensch bemühen sollte. Zum agilen Mindset gehören sie aber nur, weil sie für einige der zuvor genannten Punkte eine notwendige Voraussetzung sind. Wir können uns glücklich schätzen, dass sie dazugehören, in diesem Kontext sind sie aber nur Mittel zum Zweck. Und Vorsicht ist geboten: dort wo dieses Mittel selbst zum Zweck wird, ist das Agile Mindset zu genau dem esoterischen Konstrukt geworden das es eigentlich nicht sein will. Denn das muss klar sein - in kurzen Zyklen reaktions- und lieferfähig zu sein wird nur durch die Gesamtheit aller zuvor genannten Eigenheiten gewährleistet, aber nicht bloss dadurch dass man sich menschlich verhält.

Freitag, 11. September 2020

Sense of Urgency (II)

FS
Bild: Pixabay / Sasint - CC0 1.0

Einige weitere Gedanken zum Sense of Urgency. Zuerst noch einmal kurz zusammengefasst: es handelt sich bei ihm um eine Wahrnehmung von unmittelbarem Handlungsdruck, beruhend auf sich anbahnenden deutlichen Verschlechterungen bei Nichtstun, und das in einem sehr engen Zeithorizont. Für Veränderungsbemühungen eine ideale Ausgangslage, da nicht mehr diskutiert werden muss ob sich etwas verändern muss sondern nur noch was und wie.


Beruhend darauf geht das klassische Change Management davon aus, das der Sense of Urgency für die Beteiligten und Betroffenen spürbar gemacht werden muss bevor die Veränderungen beginnen. John Kotter (auf dessen Buch der Begriff in seiner heutigen Form zurückgeht) rät z.B. das zu tun indem verfehlte Ziele, unzufriedene Kundenstimmen, frustrierende Mitarbeiter-Erlebnisse, schlechte Zahlen und drohende Konsequenzen öffentlich gemacht werden. Wie das in einem konkreten Fall aussehen kann zeigt anschaulich diese Grafik:



Die Tendenz in diesem Bild ist so offensichtlich, dass der Sense of Urgency den die Besitzer und Mitarbeiter des National Enquirer gerade fühlen dürften sofort nachvollziehbar ist - wenn sich hier nicht sehr schnell und sehr radikal etwas ändert wird von der Auflage dieser Zeitschrift bald nichts mehr übrig sein und sie wird nach fast hundert Jahren aufhören zu existieren. Man kann davon ausgehen, dass beide Seiten zu Anstrengungen und Opfern bereit sein werden.


Auch die umgekehrte Situation ist allerdings immer wieder zu betrachten, dann nämlich wenn das offensichtliche Fehlen einer Notlage dazu führt, dass kein Sense of Urgency entsteht. Ein Beispiel dafür wären etwa die jahrelangen Versuche die Deutsche Bahn zu reformieren. Als staatliche Infrastruktur-Einrichtung waren fehlende Gewinne hier weder ungewöhnlich noch existenzbedrohend, gleichzeitig befand sich die Nachfrage auf einem Höchststand. Viele der Grafiken sahen demnach so aus:

 

Grafik: Wikimedia Commons / MCMC - CC BY-SA 4.0


Auch bei diesem Bild sind die Reaktionen auf Veränderungsprogramme einfach zu erraten, selbst wenn sie diesesmal in eine andere Richtung gehen. Hier soll es einen dringenden Veränderungsbedarf geben, obwohl die Zahlen erkennbar nach oben gehen? Das ist kaum zu vermitteln. Die Change-Programme waren daher eher von Skepsis und Ablehnung begleitet.


Um eine sich daraus ableitende naheliegende Frage zu nennen - heisst das, dass es bei (scheinbar) gut oder zumindest ohne drängende Probleme dastehenden Unternehmen keine Änderungen geben kann? Natürlich nicht, strategische Ziele oder langfristige Herausforderungen können das trotzdem nötig machen. Aber: auf eine Unterstützung durch einen Sense of Urgency (bzw. durch die Menschen die ihn spüren) darf man hier nicht hoffen, es muss auch ohne ihn gehen.


Das Risiko das jetzt auftreten kann ist, dass die mit dem Change befassten Menschen in eine Methodismus-Falle laufen. Statt andere Modelle (etwa Deutschmanns Relate, Repeat, Reframe) zu erwägen wird versucht den Sense of Urgency künstlich zu erzeugen, etwa durch ständige Brandreden, künstliche Deadlines und Ähnliches. Allerdings - was so entsteht ist eher ein "Sense of Harassment", also das Gefühl belästigt zu werden.


Hier wird es dann gleichermassen tragisch wie ironisch. Bei sachgemässer Anwendung von Kotters Methoden würde sich in solchen Situationen nämlich irgendwann doch ein Sense of Urgency feststellen lassen, wenn auch anders als gedacht. Massnahmen wie die oben genannten Sammlungen frustrierender Mitarbeiter-Erlebnisse würden einen dringenden Bedarf nach einem sofortigen Ende der Veränderungsmassnahmen aufzeigen. Im Folgenden kann man sich dann mit einem anderen englischen Fachbegriff auseinandersetzen: Change Fatigue. Eine eigene Geschichte.

Dienstag, 8. September 2020

Warum Regelverstösse nicht agil machen

FS
Bild: Wikimedia Commons / Ibex73 - CC BY-SA 4.0

Einmal mehr bietet die aktuelle Nachrichtenlage eine schöne Analogie für die Dos und Dont's des agilen Arbeitens. Konkret geht es um ein Urteil des Verwaltungsgerichts Berlin zu den in den letzten Monaten entstandenen "Pop up-Radwegen", die kurzfristig mit Baustellenmarkierungen eingerichtet wurden um den unerwartet hohen Radverkehr bewältigen zu können. Sie wurden in ihrer aktuellen Form verboten. Und es lohnt sich zu erzählen wie es dazu gekommen ist.


Am Anfang stand wie so oft eine Krise. Beginnend im Frühling 2020 sorgte der Ausbruch des Covid19-Virus dafür, dass sich fast niemand mehr dem Gedränge im öffentlichen Nahverkehr aussetzen wollte. Stattdessen nahm die Nutzung von Fahrrädern sprunghaft zu und überlastete die bisher dafür vorgesehenen Spuren. Um das dadurch steigende Risiko von Verkehrsunfällen einzudämmen richtete die Stadt so schnell wie möglich die oben erwähnten Pop up-Radwege ein, die einen Teil der bisher auch von Autos genutzten Strassen belegten.


Was das Gericht in seinem Urteil feststellte: diese Eile und die Sondersituation alleine waren keine ausreichende Begründung für einen derartig schweren Eingriff in den Strassenverkehr. Auch in einer solchen Situation hätte begründet werden müssen wie die Massnahmen mit dem relevante Gesetz, § 45 (9) StVO, in Einklang zu bringen war. Und da das nicht geschehen war erfolgte die Anweisung die Spuren wieder abzubauen.


Warum das eine Analogie auf (falsch verstandenes) agiles Arbeiten ist? Weil die hier genannten Fehler oft auch in der agilen Produktentwicklung gemacht werden. Wenn irgendetwas schnell gehen muss verfallen Teams und Unternehmen manchmal in eine "der Zweck heiligt die Mittel"-Haltung, in der die internen und externen Vorschriften (Barrierefreiheit, Datenschutz, etc.) sehr grosszügig ausgelegt oder sogar ignoriert werden.


Auch die folgende Phase der Untätigkeit ist Analogie-fähig. Genau wie die Berliner Verwaltung monatelang darauf verzichtete die neuen Verkehrswege nachträglich rechtssicher zu begründen verfallen auch manche Teams und Unternehmen in den Irrglauben, auf Dringlichkeit beruhende Massnahmen wären nach Abschluss ein Bestandsschutz geniessendes "Minimum Viable Product", selbst dann wenn sie auf nicht wirklich zulässige Art zustande gekommen sind.


Beides zusammen führt letztendlich allerdings zum genauen Gegenteil des ursprünglich anvisierten Ziels. Durch Regelbeugung zustande gekommene Massnahmen sind nur scheinbar ein schneller Erfolg, erfordern aber in der Regel Nacharbeiten die aufwändiger sind als sie es zu Beginn gewesen wären. Und das Einsparen der noch überschaubaren Kosten eines frühen "Refactorings" wird später richtig teuer und zeitfressend, wenn alles zurückgebaut werden muss.


Selbst wenn es für den Einen oder Anderen unintuitiv erscheinen mag: im Kontext von Gesetzen und Vorschriften bedeutet Agilität nicht, dass man beweglich wird indem man sie so weitreichend wie möglich umgeht, sondern dass man versucht sie so früh wie möglich einzuhalten um schnell Rechtssicherheit zu haben. Alles andere führt zu einem Scherbenhaufen wie dem vor dem die Berliner Politik gerade steht.

Donnerstag, 3. September 2020

Agile 1984

FS

Die Anzahl der überzeugten Anhänger agiler Vorgehensweisen die durch die zunehmende Kommerzialisierung enttäuscht sind nimmt in den letzten Jahren gefühlt immer schneller zu, und Allen Holub dürfte zu den bekannteren unter ihnen gehören. Was ihn auszeichnet ist aber die Ausdauer mit der er immer wieder darauf hinweist wie das Ganze ursprünglich gemeint war. So auch hier.



Darüber hinaus ist sein Vortrag auf einer zweiten Ebene sehenswert. Anders als bei vielen anderen Menschen hat die Verlagerung in die Remote-Arbeit bei ihm nicht dazu geführt, dass er sich für seine Vorträge in Powerpoint-Schlachten stürzt. Stattdessen zeigt er, dass auch jetzt noch die Verwendung von Whiteboards und Post-Its möglich ist.

Montag, 31. August 2020

Kommentierte Links (LXV)

FS
  • Adam Tooze: The Sociologist Who Could Save Us From Coronavirus

    Wieder einer dieser Momente in denen mich die Vergangenheit als Geisteswissenschaftler einholt. Das Buch Risikogesellschaft von Ulrich Beck habe ich im Studium gelesen, dann aber irgendwo zu weit im Hiterkopf abgelegt um noch daran zu denken. Vermutlich zu Unrecht. Wie Adam Tooze hier sehr schön herausarbeitet ist Beck heute noch hochaktuell. Bei ihm bezieht sich das auf die Weltlage, aber es lässt sich auch auf die Entwicklung komplexer Produkte übertragen: um Neues zu schaffen und Bestehendes zu erhalten gehen die Menschen permanent Risiken ein, weil anders Modernität und Fortschritt nicht mehr erreichbar sind. Diese treten dann zum Teil ein und werden ausgeglichen, wobei neue Risiken entstehen und in Kauf genommen werden. Ein etwas anderer aber hochinteressanter Zugang zur Untersuchung von Komplexität.

  • Barry O'Reilly: How to Implement Hypothesis-Driven Development

    Zu den Buzzwords die sich in der agilen Bewegung festgesetzt haben gehört auch die Hypothese. (Unbewusst?) aufbauend auf den Kritischen Rationalismus soll dieser Begriff anzeigen, dass alles was wir über Märkte, Kunden und Benutzer zu wissen glauben lediglich Annahmen sind, die validiert werden müssen um eine wirkliche Aussagekraft zu haben. Angelehnt an die legendäre User Story-Schablone hat Barry O'Reilly etwas Vergleichbares für Hypothesen entworfen.
    • We believe <this capability>
    • Will result in <this outcome>
    • We will have confidence to proceed when <we see a measurable signal>
    Wie bei der User Story-Schablone besteht zwar auch die Hypothesen-Schablone das Risiko einer Abdriftung in den Methodismus, für noch ungeübte Anwender kann sie aber eine Erinnerungshilfe sein durch die sich verhindern lässt, dass Annahmen als zu selbstverständlich betrachtet werden oder nicht validiert werden.

  • Steve Denning: Understanding What Good Agile Looks Like (Teil 1, Teil 2)

    Da wir von (scheinbar) einfachen Anleitungen reden - auch diese Artikel von Steve Denning enthalten eine (hier in zwei Versionen direkt verlinkt), in diesem Fall um zu überprüfen ob eine Firma klassisch oder agil strukturiert ist. Das was sie von anderen derartigen Prüflisten unterscheidet ist, dass sie sich nicht auf Implementierungsdetails konzentriert, etwa ob alle Teams nach Scrum arbeiten, sondern stattdessen aufeinander aufbauende Ebenen identifiziert und ihnen Erkennungsmerkmale zuordnet. Das sind zum Beispiel auf der obersten Ebene Unternehmensstruktur und Erfolgs-Definition, auf der mittleren Budgetierungs- und HR-Prozesse und auf der unteren Arbeitseinstellungen und Umgangsformen. Der Anspruch dieser Liste ist es, alles auf richtig verstandene Agilität überprüfbar zu machen, vom eigenen Unternehmen über Beratungs-Dienstleistungen bis zur Management-Literatur. Ob das durchgehend realistisch ist kann man dahingestellt lassen, eine wertvolle Inspiration ist es aber auf jeden Fall.

  • Mark Gray: The Definitive Guide to Burn-down Charts

    Ein schöner Artikel über die möglichen Vor- und Nachteile die sich aus der Verwendung von Burndown-Charts (die ja eines der klassischen Erkennungsmerkmale von Scrum sind) ergeben. Bemerkenswert ist hier vor allem ein Vergleich von sechs derartigen Charts (etwas weiter unten im Text) die sich zwar alle auf den selben Arbeitsstand beziehen, sich aber z.T. deutlich unterscheiden, je nachdem was da "heruntergebrannt" wird. Im dazugehörigen Text erfolgt auch die Erklärung welche dieser Messtechniken man benutzen sollte und welche besser nicht. Kurz zusammengefast: erzeugten Mehrwert und fertig integrierte Arbeitspakete in Burndown-Charts darzustellen ist eine gute Idee, vorher geschätzte Restaufwände und unintegrierte Arbeit erzeugen dagegen in derartigen Darstellungen keine verlässlichen Werte.

  • Kaluhi Anzigale: What Happens When Agile Goes Away?

    Zum Schluss eine Fallstudie. In einer Geschichte die sie selbst miterleben durfte erzählt Kaluhi Anzingale von einer Firma die versucht hat sich durch das Einsparen agiler Rollen und Praktiken profitabler zu machen. Ein Happy End gibt es nicht, die Einsparungen wurden durch die negativen Effekte mehr als ausgeglichen. Dass es nicht viele derartige Studien gibt ist nachvollziehbar, denn wer will schon sein Missmanagement laut verkünden? Um so wertvoller sind Texte wie dieser.

Donnerstag, 27. August 2020

Lean, Agile und der Markt für Zitronen

FS
Bild: Pikist - CC0 1.0

Die 1970 erschienene Studie The Market for Lemons: Quality Uncertainty and the Market Mechanism von George Akerlof gehört zu den grossen Klassikern der Wirtschaftswissenschaften. Am Beispiel scheinbar fehlerfreier, tatsächlich aber mangelhaft konstruierter Autos (in der amerikanischen Umgangssprache "Lemons", d.h. Zitronen genannt) glaubte er, eine Dysfunktion des Marktes nachweisen zu können: da Lemons im Vergleich zu fehlerfreien Autos billiger in der Herstellung aber gleich profitabel im Verkauf waren ging er davon aus, dass die Hersteller diese Fehler ihren Kunden bewusst verschweigen und damit eine Abwärtsspirale aus immer stärker nachlassender Qualität verursachen würden.


Bemerkenswerterweise erwies sich Akerlofs Analyse sowohl als richtig als auch als falsch - während es bei den amerikanischen Herstellern tatsächlich zu den von ihm beschriebenen Effekten kam war nicht etwa eine dauerhafte Abwärtsspirale die Folge sondern der Markt reparierte sich selbst. Genervt von der schlechten Qualität wandten sich die amerikanischen Kunden ausländischen Autos zu, die mit deutscher Wertarbeit oder japanischem Jidōka gebaut wurden. Um keine weiteren Marktanteile zu verlieren mussten die amerikanischen Firmen jetzt auch in Qualität investieren.


Wer in der IT arbeitet wird die Parallelen erkennen - auch hier wurde und wird Software produziert die "von Aussen" gut aussieht aber "unter der Motorhaube" Mängel hat, etwa in Form von Bugs, fehlender Lastfähigkeit, langsamer Erweiterbarkeit, schlechter Wartbarkeit, etc. Und auch hier ist es so. dass die Kunden derartige Anbieter abstrafen indem sie zur Konkurrenz wechseln, etwa vom Internet Explorer zu Chrome oder von StudiVZ zu Facebook. Und auch die Lösungen sind vergleichbar.


Die Methoden mit denen die japanischen und deutschen (und später auch amerikanischen) Firmen daran arbeiteten weniger Fabrikationsfehler entstehen zu lassen bilden heute noch die Grundlage von Lean Management und Agiler Softwareentwicklung: Probleme in der Verarbeitung sollen durch KVP, Kaizen und Inspect & Adapt möglichst früh entdeckt werden, sobald das geschehen ist wird der Verarbeitungsprozess angepasst. Fehlerhafte Auslieferungen gibt es damit immer weniger, und damit auch kaum noch Versuchungen sie aus Profitgier zu ignorieren.


Natürlich gibt es in der Umsetzung Unterschiede zwischen Auto- und IT-Industrie. Während in den immergleichen Abläufen einer Fertigungsstrasse der Automobilfertigung eine möglichst starke Standardisierung von Qualitätssicherungsschritten entlang der gesamten Wertschöpfungskette angestrebt wird steht in der IT mit ihrer Prototypen-Fixierung eine möglichst individuelle Qualitätssicherung möglichst früher Produktumfänge im Vordergrund. Das Ziel bleibt allerdings das Gleiche: Fehler verhindern bevor sie entstehen.


Letzten Endes schliesst sich hier ein Kreis: das grösste selbstorganisierte System der Welt, der freie Markt, bringt hohe Qualität hervor indem er sich der kleinsten selbstorganisierten Einheiten, der agil oder lean organisierten Produktteams bedient. Und beide basieren auf möglichst früher und transparenter Informationserhebung und Kundenkommunikation. Mit anderen Worten - der Markt für Zitronen verschwindet.


Sogar eine finale Pointe hält diese Geschichte bereit: 2001, im selben Jahr in dem Akerlof für The Market for Lemons den Wirtschafts-Nobelpreis erhielt verfassten siebzehn damals noch unbekannte Software-Entwickler in einer Hütte in den Rocky Mountains das Manifest für agile Software-Entwicklung. Eine bessere Metapher für eine Zeitenwende ist kaum denkbar.

Montag, 24. August 2020

Der Vertrag über agile Produktentwicklung

FS

 

Bild: Pixabay / Edar - CC0 1.0

Zu den frustrierenden Erlebnissen die man im Rahmen agiler Projekte haben kann gehört die Vertragskeule. Das wäre ja alles schön und richtig mit Inspect, Adapt, Incremental und Iterativ heisst es häufig, der Vertrag wäre da aber leider sehr restriktiv. Was hierbei zu bedenken ist: derartige Situationen werden in der Regel nicht bewusst herbeigeführt sondern beruhen auf Unkenntnis der für agile Vorgehensweisen nötigen Vereinbarungen. Die in meiner Sicht wichtigsten Punkte für solche Vereinbarungen möchte ich im Folgenden zusammenfassen, basierend auf eigenen Erfahrungen und einigen Impulsen von Philipp Kühn (Verfasser des "agilen Teils" des Handbuchs der IT-Verträge).


Rollen

Vor allem dort wo es noch verbreitet klassische Aufbau- und Ablaufstrukturen gibt von zentraler Bedeutung. Dass der Scrum Master nicht der Projektleiter ist und man für eine gute Software-Architektur keinen Software-Architekten haben muss mag für den überzeugten Agilisten selbstverständlich sein, für den Vertragspartner ist es das ggf nicht. Das klar festzulegen kann verhindern, dass Konflikte und falsche Erwartungen überhaupt entstehen und unnötig Energie binden.


Abnahmen

Auch klare Vereinbarungen zur Art wie Abnahmen in einem agilen Arbeitsmodus ablaufen müssen können Missverständnisse vermeiden. Zum einen dürfen diese nicht mehr ganz am Ende erfolgen sondern kurzfristig, im gleichen Takt wie die Inbetriebnahmen (dazu gleich mehr), zum anderen muss klar werden, dass es sich bei ihnen nicht um den Abgleich mit Detailspezifikationen handelt sondern um Überprüfungen auf welche Weise ein abstrakt beschriebener Anwender-Mehrwert verwirklicht wurde.


Liefer- und Inbetriebnahme-Rhythmus

Ebenfalls ein klarer Bruch zu den klassischen Vorgehensweisen, auf den man sich klar festlegen sollte. Egal ob in Scrum und XP mindestens ein Release pro Iteration stattfindet oder ob ein Kanban-Team möglichst im Single Piece-Flow arbeitet und jedes neue Feature direkt auf Produktion bringt - allen Beteiligten muss von Anfang an klar sein, dass kurze Rhythmen zwingend nötiger Bestandteil von Agilität sind.


Mitwirkung

Passend zum letzten Punkt sollte auch geregelt werden in welchem Umfang und zu welchen Zeitpunkten wer verfügbar sein muss. Das betrifft zum einen die Mitglieder des Umsetzungsteams, die nach Möglichkeit in Vollzeit und dauerhaft verfügbar sein sollten, es betrifft aber auch die Vertreter von Kunden und Auftraggebern, die für die oben genannten Inbetriebnahmen, als Onsite Customer, als Berater oder für Abnahmen verfügbar sein müssen, und zwar regelmässig.


Vergütung

Nicht nur im Umfeld der Agilität ein zentrales Thema, hier aber besonders kompliziert, da sich der Arbeits- und Funktionsumfang nach Erkenntnisgewinnen ändern kann und soll. Im Agentur-Umfeld finden sich oft Festpreise für Sprintziele, in Festpreis-Grossprojekten kann man den Austausch von alten Arbeitspaketen gegen gleichgrosse neue ermöglichen. Möglichkeiten Time & Material-Verträge flexibler zu gestalten wären Preisschwellen für Mindestabnahmemengen oder Mengenrabatte.


Anpassung

Ein weiterer Bruch zu den üblichen Vorgehen. Vertragsänderungen sollten in einem agil arbeitenden Umfeld immer möglich sein. Der dafür passende Anlass wird sich zwar nicht im voraus regeln lassen, wohl aber, dass es grundsätzlich möglich ist, dass es jederzeit zur Diskussion gestellt werden kann und dass diese Diskussion dann auch geführt werden muss. Auch eine kurzfristige Verfügbarkeit der beteiligten Stellen (Recht, Einkauf, etc) kann vereinbart werden.


Mit diesen (und ggf. anderen) Punkten lassen sich Verträge so gestalten, dass sie besser zu den agilen Vorgehensmodellen passen als es bei klassisch gestalteten Unterlagen meistens der Fall ist. Was aber auch klar sein muss - in einem solchen Umfeld wird sich nie alles festlegen lassen, ab einem gewissen Punkt muss zwischen den Vertragsparteien ein Grundvertrauen bestehen. Das ist zwar nicht überall gegeben, andererseits ist dort wo es fehlt die Agilität auch nicht das Thema das als erstes angegangen werden sollte.

Donnerstag, 20. August 2020

Best Practices and Good Practices

FS
Bild: Pikrepo - CC0 1.0

 


Wer schon immer einen lebhaften Kurzmonolog von einem Agile Coach hören wollte hat eine einfache Möglichkeit ihn herbeizuführen. Alles was man dafür tun muss ist ihn zu fragen was denn die üblichen Best Practices sind die er in seinem Beruf kennt und empfiehlt. Die Antwort wird fast immer die Gleiche sein: Best Practices gibt es in einem agilen Umfeld nicht, da sie grundsätzlich nicht zum Gesamtkonzept passen würden. Allenfalls Good Practices würden vorkommen, und die wären etwas völlig anderes.

 

Dass so argumentiert wird hängt mit grundlegenden Glaubenssätzen und Überzeugungen zusammen auf denen sich das Konzept der Agilität begründet. Ihnen zufolge ist jedes komplexe Vorhaben ständig mit dem Problem konfrontiert, dass die ursprüngliche Planung nach einiger Zeit nicht mehr für die zu lösende Aufgabe geeignet ist und per Inspect & Adapt angepasst werden muss. Da aber eine Best Practice schon von der Benennung her eine nicht mehr anzupassende Vorgehensweise ist (sie ist ja bereits die Beste) passt sie nicht in dieses Denkmodell.

 

Bei näherer Betrachtung zeigt sich auch, dass diese Glaubenssätze durchaus eine Fundierung haben. Alleine die jeweils unterschiedlichen Anwendungskontexte lassen es schwer vorstellbar scheinen, den einen richtigen Weg zu finden. Die Ablösung einer 30 Jahre alten ERP-Software und die Neuentwicklung eines Betriebssystems für eine Mondrakete mögen beides komplexe IT-Vorhaben sein, ideale Praktiken die für beides passen wird es aber nicht viele geben.

 

Auch die Unbeständigkeit der Umgebungsfaktoren spricht gegen universell gültige Best Practices. Alleine die Entwicklung immer neuer Endgeräte (Laptops, Handys, Tablets, Brillen, Uhren) verändert auch ständig die Art wie Technologien entwickelt werden, Ähnliches trifft für auch Architekturparadigmen und Nutzungsgewohnheiten zu und wird bei näherer Betrachtung auch für viele andere Aspekte zutreffend sein.


Selbst all das zusammengenommen tritt aber in den Hintergrund wenn man es mit dem grössten Problem vergleicht, dass das Konzept der Best Practice mit sich bringt - es ist zutiefst subjektiv. Alleine der Versuch bestimmte Sachverhalte als objektiv richtig zu bezeichnen kann ganze Generationen von Wissenschaftlern in Streitigkeiten stürzen, von diesen dann auch noch einen als "den Besten" auszuwählen kann eigentlich nur scheitern, und zwar bereits lange vor dem ersten Umsetzungsversuch.


Allerdings: die vollständige Verneinung jeglicher Richtlinien ist auch keine Lösung, zumindest nicht ausserhalb sehr radikaler philosophischer Denkrichtungen. Selbst wenn man sich theoretisch alles selbst erarbeiten könnte wäre der damit verbundene Aufwand unverhältnismässig hoch und die dafür erforderliche Zeit unverhältnismässig lang, ganz zu schweigen von der wirtschaftlichen Unsinnigkeit der redundanten Erarbeitung bereits errungener Erkenntnisse.


Die Lösung besteht aus den oben genannten Good Practices. Sie haben sich in bestimmten Kontexten und zu bestimmten Zeitpunkten als passend erwiesen, erheben aber keinen Absolutheitsanspruch, weshalb man sie problemlos überprüfen, anpassen und ggf. sogar verwerfen kann. Für das agil-typische Inspect & Adapt sind sie damit sehr gut geeignet. 

 

Nur eines kann die Verwendung von Good Practices statt Best Practices dem Anwender nicht ersparen: den Kurzmonolog des Agile Coaches. Sobald der dieser diese differenzierte Herangehensweise irgendwo vorfindet wird er sich zwar nicht mehr kritisch äussern, dafür aber in ähnlichem Umfang seiner Begeisterung freien Lauf zu lassen. Zu Recht.

Montag, 17. August 2020

Digitalisierung (III)

FS

 

Bild: JBSA / Zachary Bumpus - Public Domain

Zu den verwunderten bis spöttischen Reaktionen auf die in nahezu allen grossen Unternehmen und Behörden laufenden Digitalisierungsprogramme gehört die Frage warum es denn heute noch einen Bedarf dafür geben würde. Sollte die Digitalisierung von Büro- und Datenhaltungsprozessen nicht schon seit Jahrzehnten abgeschlossen sein? Die Antwort: leider nein, und aktuelle Ereignisse lassen erkennen auf warum das so ist.

 

Eine in den letzten Tagen durch die Medien gegangene Meldung handelte von fehlender Digitalisierung: an Urlaubsrückkehrern durchgeführte Krankheits-Tests fanden direkt an den Grenzen statt, wobei die Dokumentation von Kontaktdaten und Test-IDs auf Notizblöcken erfolgte. Diese Daten in die Systeme der Gesundheitsämter zu übertragen war aufwändig und manchmal wegen unleserlicher Schrift unmöglich, weshalb hunderte Menschen nicht von ihrer Erkrankung erfuhren


Die Gründe dafür, dass hier keine digitalisierte Datenerfassung stattfand sind schnell zu erkennen - die dafür notwendige Hardware hätte zuerst gekauft und die dazugehörige Software programmiert werden müssen, die Geräte hätten verteilt werden müssten und das Personal müsste geschult, und das alles unter immensem Zeitdruck, da die Ferienrückreiseverkehr sich nicht verzögern liess. Das manuelle Festhalten dürfte trotz der Probleme das Schnellste und Beste gewesen sein was so schnell machbar war.


Und selbst wenn derartige Behelfslösungen durch den Einsatz digitaler Techniken ersetzt werden ist der Digitalisierungsprozess dadurch nicht zwingend abgeschlossen, das zeigt eine andere Meldung: in anderen Testzentren gingen Dokumente zwar auf digitalem Weg ein, allerdings mit einer veralteten, eher für Einzelfallnutzung gedachten Software. Die Folge: mehrere tausend verschiedene Dokumente hatten den identischen Dateinamen "Telefax.pdf" und mussten einzeln gesichtet und umbenannt werden.


Auch hier kann man den Hintergrund verstehen - eine modernere Software wäre zwar erstrebenswert gewesen, deren Entwicklung ist aber noch nicht abgeschlossen. Die Fax-Schnittstelle dagegen existiert bereits und ermöglicht eine zwar umständliche, im Vergleich zur manuellen Erfassung aber deutlich schnellere Datenerfassung, mit der man erstmal anfangen konnte. Das Ergebnis ist eine schrittweise Digitalisierung: erst der Posteingang, dann die Benennung, dann die Sortierung, etc.


Aus "agiler Sicht" sind diese Vorgehensweisen hochgradig sinnvoll. Statt lange auf ein fertig entwickeltes Stück Software zu warten kann man mit einfachen aber schnellen Lösungen erste Erfahrungen sammeln, die Erkenntnisse in die parallel verlaufende Weiterentwicklung einfliessen lassen und dadurch am Ende bessere Ergebnisse haben. Um ein letztes mal die deutsche Seuchenbekämpfung zu nennen: dieser Ansatz wird hier genutzt und vom Ausland als vorbildlich empfunden.


Das Risiko ist allerdings, dass an irgendeinenem Punkt die noch nicht digitalisierten Prozesschritte in Relation zu anderen Aufgaben so unwichtig erscheinen, dass sie "wegpriorisiert" werden. Diese Restbestände sind es, wegen denen viele Digitalisierungsprogramme auch nach Jahrzehnten noch nicht abgeschlossen sind.

Donnerstag, 13. August 2020

Harvesting Value from Change

FS

Ein Grossvater sitzt auf seinem Sofa und gibt einige Weisheiten aus seinem Erfahrungsschatz preis. Das klingt nach nicht viel, ist aber auf ganz erstaunliche Weise fesselnd, tiefgreifend und charmant. Und das Besondere: Es funktioniert auf verschiedenen Ebenen - es lohnt sich nicht nur für Experten aus den Bereichen IT und Change Management sondern auch für Menschen die völlig neu im Thema sind.


 

Tatsächlich ist dieser Vortrag von GeePaw Hill derartig voll mit Informationen und Inspirationen, dass es sich lohnt ihn mehrfach anzusehen. Wie man auf Englisch sagen würde: It keeps on giving.

Montag, 10. August 2020

PMI goes Agile

FS
Screenshot: pmi.org


Zu den bei näherer Überlegung erstaunlichen Phänomenen im Umfeld der agilen Vorgehensweisen gehörte bisher das fehlende Engagement der klassischen Projektmanagement-Organisationen. Obwohl diese Art zu arbeiten immer weiter um sich greift und selbst zum Millionenmarkt geworden ist sind die klassischen Standardisierungs- und Zertifizierungs-Anbieter praktisch nicht wahrnehmbar. Noch weitgehend unbemerkt hat aber vor einigen Monaten ein Versuch begonnen das zu verändern.

Im Sommer 2019 wurde das Disciplined Agile Consortium, Besitzer des relativ unbekannten Skalierungsframeworks DAD (Disciplined Agile Delivery), vom Project Management Institute (PMI) gekauft. Das PMI, neben Axelos eine der beiden grossen internationalen Projektmanagement-Organisationen, hat in den folgenden Monaten vor allem an der internen Integration des Zukaufs gerarbeitet, seit Sommer 2020 ist aber auch von aussen erkennbar wohin die Reise gehen wird.

Aus dem neuen DAD-Bereich der PMI-Website lassen sich einige zentrale Weichenstellungen ablesen. Die vermutlich wichtigste: DAD (bzw. dessen Ableitung, die "Disciplined Agile Toolbox") wird explizit als Hybrid-Framework vermarktet, also als eines das auch Teile von klassischem Projektmanagement enthält. Das ist ein deutlich anderer Weg als der von LeSS, Nexus, Kanban University und SAFe, die alle den Anspruch erheben rein agile Methoden zu vertreten.

Eine weitere zentrale Entscheidung scheint zu sein, dass bewusst darauf verzichtet wird die Teams der Ausführungsebene als Scrum Teams zu bezeichnen. Das ist eine klare Unterscheidung zu LeSS, Nexus und SAFe und dürfte ein vorbeugender Befreiungsschlag gegen den Vorwurf sein, Scrum verkrüppelt oder nicht verstanden zu haben. Das dieser zu erwarten gewesen wäre ist angesichts der Team-Rollen offensichtlich - ganz klassisch gibt es hier den Teamleiter und den Architekten, zwar einen Product Owner aber dafür keinen Scrum Master.

Ebenfalls in ihren Auswirkungen nicht zu unterschätzen ist die PMI-typische Bereitschaft hochgradig umfangreiche Regelwerke zu schaffen. In seinem aktuellen Ausbaustand umfasst das DAD-Framework die vier Ebenen Delivery, DevOps, IT und Enterprise, in denen sechs verschiedene Produkt-Lebenszyklen abgebildet werden können: Agile, Lean, Agile Continuous Delivery, Lean Continuous Delivery, Lean Startup und Program. Dazu kommen Querschnittsorganisationen und Regeln und vieles mehr.

Interessant ist, dass DAD den Anspruch erhebt auf einer übergeordneten Ebene zu schweben, von der aus es alle anderen agilen und nicht-agilen Vorgehensmodelle als Baukästen nutzen kann um einzelne Elemente aus ihnen neu zu kombinieren. Diese versuchte Vereinnahmung dürfte zu ähnlichen Widerständen führen wie das vergleichbare Vorgehen von SAFe, wobei DAD ironischerweise auch SAFe lediglich als einen der besagten Baukästen aufführt.

Was zuletzt nicht fehlen kann sind die Zertifizierungen, die sowohl in der klassischen als auch in der agilen Arbeitswelt weit verbreitet sind. Hier ist am deutlichsten sichtbar, dass die Integration von DAD in das PMI noch nicht abgeschlossen ist. Auf der entsprechenden Übersichtsseite führen noch viele Links zu Einstellungs-Benachrichtigungen, Änderungsankündigungen oder Fahlermeldungen. Die einzige unveränderte Weiterführung scheint ausgerechnet (siehe oben) der Scrum Master zu sein.

Ob die PMI/DAD-Kombination sich am Markt durchsetzen wird ist natürlich noch nicht absehbar, als globale Organisation mit hunderttausenden Mitgliedern und hunderten lokalen Organisationen hat PMI aber eine gute Ausgangslage. Dem ersten Eindruck nach dürfte dabei vor allem SAFe der Konkurrent sein, die Positionierung und die Zielgruppe der beiden überschneiden sich stark. Es wird spannend zu sehen sein ob es hier zu einer Koexistenz oder zu einer Verdrängung eines der beiden kommen wird.

Donnerstag, 6. August 2020

Die Agile Framework-Matrix

FS
Es gibt Ideen von denen man direkt fasziniert ist. Diese hier von Dave Snowden gehört dazu.
Wie er selbst sagt ist sie in dieser Form nicht ganz ernstzunehmen, sie bietet aber einen guten Ansatzpunkt um weiter darüber nachzudenken ob und wie man die gängigen agilen Frameworks in eine zweidimensionale Matrix einordnen könnte und was sich danach mit dieser Einordnung machen lässt. Das Ziel dieser Übung: ein Werkzeug zu entwickeln mit dem sich Verständlichkeit und Anwendbarkeit überprüfen lassen.

Als erste Achse bietet sich definitiv das an was Snowden oben links die "kultgleiche, mystische Sprache" genannt hat. Wer schon einmal in einem agil arbeitenden Umfeld tätig gewesen ist wird wissen was er meint - über die Jahrzehnte hat sich hier eine Fachsprache aus verschiedensten Elementen gebildet (Sport-Metaphern, Management-Englisch, Japanisch, IT-Begriffe, etc.), die Vieles zu Beginn unnötig unverständlich macht. Eine geringe Ausprägung dieses Werts ist demnach gut, eine hohe schlecht.

Die zweite Achse ist schwieriger, da seine Benennung hier "leicht verkopft" ist. Um sich nicht im Versuch einer Definition von "ontologisch-epistemologisch" zu verlieren versuchen wir es mit einem Befreiungsschlag: wenn ein agiles Framework Erkenntnistheorie und Metaphysik notwendig macht ist vorher offensichtlich sein Beschreibungsumfang so ausser Kontrolle geraten, so dass er nicht mehr einfach fassbar ist. Ein geringer Umfang ist demnach gut, ein hoher schlecht.

Und mit diesen Festlegungen lässt sich die Matrix tatsächlich bauen, samt der ersten Framework-Einordnungen.
Um es auf den Punkt zu bringen: unten links in diesem Bild befinden sich die minimalistisch-einfach verständlichen Frameworks, oben rechts die aufgebläht-unverständlichen. Diese Einordnung ist natürlich nicht ohne subjektiven Einschlag, dürfte aber im Grossen und Ganzen so hinkommen.

Interessant ist noch Snowdens Idee, die Frameworks nicht als Punkte sondern als Pfeile darzustellen, also nicht nur ihre Position sondern auch ihre bisherige Entwicklung zu visualisieren. Das würde zwar etwas "historische Forschung" erfordern, würde aber auch die Option eröffnen Trends festzustellen, aus denen man Wahrscheinlichkeiten ableiten kann wie die Entwicklung vermutlich weitergehen wird.

Nachtrag:
Even more Food for Thougt

Montag, 3. August 2020

Ein Bild sagt mehr als 1000 Worte (XXIX)

FS

Freitag, 31. Juli 2020

Kommentierte Links (LXIV)

FS
  • Jeff Gothelf: Working Backwards - A New Version Of Amazon’s “Press Release” Approach To Plan Customer-Centric Projects

  • Über den bei Amazon üblichen Ansatz Produkte und Anforderungen Form von Pressemitteilungen zu verfassen hatte ich letztes Jahr schon etwas geschrieben. Auch Jeff Gothelf sieht darin ein wichtiges Werkzeug, an dem er aber zwei Kritikpunkte sieht - eine zu starke Focussierung auf Output statt auf Outcomes und eine Vernachlässigung der Herausforderungen in der teamübergreifenden Zusammenarbeit. Er schlägt daher das folgende, veränderte, "Pressemitteilungs-Format" vor:
    1. What did you ship?
    2. What customer problems does it solve?
    3. How do you know the problem solved those problems?
    4. What business benefit has been achieved?
    5. Internal quote from someone involved or invested in this project and its success.
    6. Provide a customer quote sharing how this new product made them more successful or helped them achieve something.
    7. How did the team works together to achieve these results? What challenges did the team overcome to make the product successful?
    8. Provide a call to action.
    In dieser Form auf jeden Fall ein interessanter und vielversprechender Ansatz. Ob er ausserhalb von Amazon als Anforderungsbeschreibung ausreichend ist ist zwar diskutabel, aber ein Einsatz in Produktfindungs-Workshops dürfte definitiv eine Option sein.

  • Bob Emiliani: What Comes After Lean?

    Lean Management und Agile sind sich in vielem ähnlich, unter anderem auch in der häufigen Aussenwahrnehmung als vorübergehende Management-Trends (angesichts einer 70-jährigen, bzw. 30-jährigen Geschichte eine gewagte Annahme, aber das wäre ein anderes Thema). Bob Emiliani nimmt das zum Anlass für ein Gedankenspiel - was könnte wohl danach kommen (in seinem Fall nach Lean)? Vier Optionen fallen ihm ein:
    1. Es findet eine Ablösung statt durch einen neuen Ansatz, der die bisherigen Herausforderungen besser lösen kann
    2. Es werden so lange neue Ideen und Prinzipien integriert bis der aktuelle Stand nur noch eine kleine Teilmenge des grossen Ganzen bildet
    3. Die Herausforderungen ändern sich und getrieben dadurch entstehen neue Lösungsansätze (man beachte den Unterschied zu Option 1)
    4. Es folgt einfach nichts. Die ganze Idee methodischer Ansätze verschwindet
    Die spannende Frage aus "agiler Sicht": lässt sich dieses Gedankenspiel von Lean auf Agile übertragen? Ein gutes Thema für die nächste Grundsatz-Diskussion zwischen Agile Coaches (oder sogar für ein ganzes Barcamp).

  • Jason Little: Balancing the Push and Pull of Change

    Der Lean Change-Ansatz von Jason Little hat sich (zumindest im deutschsprachigen Raum) nie so ganz durchsetzen können, weshalb er trotz seiner mittlerweile mehr als zehnjährigen Geschichte noch immer das Potential hat neue Impulse zu liefern. Ganz im Sinn des Agilen Manifests sind auch hier mehrere Gegensatzpaare entwickelt worden an denen man sein Handeln ausrichten kann:
    1. Co-creation over getting buy-in
    2. Meaningful dialogue over broadcasting
    3. Cause & purpose over creating urgency
    4. Experimentation over executing tasks
    5. Response to change over resistance to change
    Genau wie im Fall des Agilen Manifests ist auch hier wichtig, dass sich nicht jeweils eine richtige und eine falsche Option gegenüberstehen, sondern dass beide ihre Berechtigung haben. Die Bevorzugung der linken Seite ist also eher als Richtlinie zu sehen und nicht als Dogma.

  • David Robson: Can you learn to navigate uncertainty?

    Zur Abwechselung mal ein Absatz ohne Aufzählungen. Was die BBC hier gemacht hat ist ein hochinteressantes Experiment. In einer gross angelegten Studie sollten über 7000 Teilnehmer versuchen mehrere Monate im voraus Voraussagen zu Ereignissen in unberechenbaren Umfeldern zu machen - zu Wahlergebnissen, Währungsschwankungen, Pandemie-Verläufen, aber auch zu Produkt-Neuheiten grosser Unternehmen. Das unerwartete Ergebnis: Laien machten bessere Voraussagen als Experten und jüngere Menschen machten bessere Voraussagen als ältere. Dem Anschein nach können Erfahrung und Expertise also schädlich sein wenn man versucht sich in einem volatil oder chaotisch verhaltenden Umfeld zurechtzufinden. Die Erklärungsansätze die sich aus der Studie ergeben sollten nachdenklich machen - Experten und Menschen mit grösserer Lebenserfahrung tendieren demnach dazu die eigene Kompetenz zu überschätzen und neigen dazu die Lösungen vergangener Probleme undifferenziert auf zukünftige zu übertragen. Im Selbstbild vieler Menschen dürfte das spürbare Kratzer hinterlassen.

  • John Cutler: Developer & Designer Collaboration (in the Real World)

    Grau ist alle Theorie, die Praxis ist bunt. Was John Cutler hier teilt ist eine der vielen Arbeitsablauf-Varianten die sich in der Realität nach und nach entwickeln, wenn Teams ihre Prozesse kontinuierlich optimieren. Scheinbar Wasserfall-artige Phasen lösen sich ab mit iterativem Arbeiten, zeitweise wird Arbeit parallelisiert, dann kommt es wieder zu teamübergreifendem Pairing. Die Moral aus dieser Geschichte: diese Abläufe sind in diesem (und nur in diesem) Kontext optimal - und ein erzwungener Einheitsprozess hätte zu suboptimalen Ergebnissen geführt.
Powered by Blogger.