Donnerstag, 16. August 2018

Krisenkommunikation

FS
Bild: Flickr / Katjung - CC BY-SA 2.0
Zu den interessanteren Medienbeiträgen der letzten Zeit gehört ein Interview mit dem Psychologen Reiner Kemmler zum Thema Krisenkommunikation auf Flughäfen. Auf den ersten Blick erscheint das Thema sehr spezifisch, auf den zweiten Blick finden sich aber viele Parallelen zur Agilität: eine bereits komplexe Ausgangssituation, unerwartete Geschehnisse mit zum Teil grossen Auswirkungen, autonom und unkoordiniert vorgehende Akteure, etc. Vieles lässt sich auf andere grosse Unternehmenen und Behörden übertragen.

Der Ausgangspunkt: die Krise

Wo Komplexität zu finden ist, da gibt es auch Krisen, das ist fast schon ein Naturgesetz. Ausfallende Flüge und gestandete Passagiere sind da nur ein Beispiel, andere wären insolvent gehende Geschäftspartner, disruptive Umwälzungem am Markt oder in der Technik, offensichtlich werdende Fehlplanungen, sich ändernde gesetzliche Rahmenbedingungen, Wirtschaftskrisen und vieles mehr. Sie alle stellen die betroffenen Organisationen vor grosse Herausforderungen, von denen es hier um eine gehen soll: wie kann die Krise so kommuniziert werden, dass Märkte, Mitarbeiter und Kunden beruhigt werden statt durch Panikreaktionen alles zu verschlimmern?

Verstärkung der Krise durch fehlendes Reaktionsvermögen

Es ist ein unschöner Klassiker: über Jahre werden Abäufe so auf Effizienz getrimmt, dass jeder Mitarbeiter zu fast hundert Prozent ausgelastet ist und fast jeder Prozess auf dem kritischen Pfad verläuft. Dass eine hundertprozentige Auslastung schlecht ist zeigt sich im Krisenfall - die für eine schnelle Reaktion notwendigen Kapazitäten und Freiräume wurden wegrationalisiert, jeder Zusatzaufwand führt zu Überlastung, Rückstauungen und Stillstand. Und wenn sich die Arbeit erst aufgestaut hat kann sie nur durch Überstunden wieder abgebaut werden, mit den bekannten Folgen: Übermüdung, Frustration, dadurch überhastete und fehlerhafte Kommunikation, die dann noch mehr Aufwände verursacht.

Herrschaftswissen und Flurfunk

Irgendwann ist es offensichtlich - sensible Informationen können während und nach ihrer Bekanntgabe nicht mehr ausreichend genug kommunikativ begleitet werden um Unruhe und Fehldeutungen zu vermeiden. Häufig führt das zu der Entscheidung, dass so lange mit der Bekanntgabe gewartet wird bis man glaubt die Lösung gefunden und umgesetzt zu haben. Allerdings ist das in der Regel nicht möglich, irgendwo sickern immer Teilinformationen durch, verbreiten sich, werden schlimmstenfalls aufgebauscht und sorgen für Misstrauen gegenüber offiziellen Verlautbarungen. Selbst wenn jetzt offen kommuniziert werden würde, gäbe es den Verdacht, dass Informationen zurückgehalten werden.

Endstadium: aus der Krise wird Chaos

Letztendlich treten genau die Gruppendynamiken und Absetzbewegungen auf die man vermeiden wollte. Verunsichert von der schwerfälligen und intransparenten Kommunikationspolitik versuchen Kunden, Partner und Mitarbeiter sich vorsorglich in Sicherheit zu bringen. Aufträge werden storniert, Projekte nicht verlängert, statt für das gemeinsame Ziel wird nur noch für die eigene Absicherung gearbeitet, ganze Abteilungen beschliessen "zu überwintern" bis sich die Situation beruhigt hat. Beruhigende Verlautbarungen werden grundsätzlich nicht mehr geglaubt sondern als Vertuschungsversuche interpretiert. Schlimmstenfalls setzt sich die Situation im kollektiven Gedächtnis der Organisation fest und belastet die Zukunft.

Aber wenn nicht so - wie dann?

Im Grunde durch die Umkehrung der oben genannten Antipattern. Statt die gesamt Organisation bis ins letzte Eck durchzuoptimieren müssen freie Kapazitäten vorhanden sein die auch kurzfristig Kommunikationsaufgaben übernehmen können sobald es nötig ist. Ein passender Vergleich wäre ein Feuerwehrmann, bei dem die Brandbekämpfung auch nur einen kleinen Teil der Arbeit einnimmt. Des weiteren empfiehlt sich grösstmögliche Offenheit von Anfang an. Klar und offen zu zu kommunizieren, dass es eine Krise gibt mag zwar zu Beginn schmerzhaft sein, das dauerhafte Misstrauen das sich aus dem Zurückhalten von Informationen ergibt ist aber langfristig um ein Vielfaches verheerender. Und wenn klar ist, dass Reaktionen möglich sind und bereits stattfinden verliert die Ungewissheit viel von ihrem Schrecken. Es ist ein Allgemeinplatz aller agilen Vorgehensmodelle - wenn man in der Lage ist kurzfristig auf Veränderungen zu reagieren ist es unkritisch wenn sich die Realität anders entwickelt als geplant.

Natürlich muss dafür auch die Gesamtorganisation zu Reaktionen in der Lage sein und nicht nur die Kommunikationsabteilung. Das ist aber dann ein Thema für sich.

Montag, 13. August 2018

Planning Poker

FS
Bild: Wikimedia Commons / Rachmaninoff - CC BY-SA 4.0
Wer bereits Zeit in einem Scrum-Projekt verbracht hat wird das Bild kennen. Irgendwo stellt ein Product Owner eine Idee vor und bittet sein Entwicklungsteam um eine Aufwandsschätzung. Kurz darauf halten die Teammitglieder Karten oder Mobile Apps mit Zahlen darauf hoch und nehmen so die Schätzung vor. Da immer wieder nach dieser zunächst merkwürdig aussehenden Methode gefragt wird kommt hier eine Erläuterung dazu, zum so genannten Planning Poker.

Zunächst einige Kontextinformationen: mit Planning Poker werden normalerweise Story Points geschätzt. Story Points sind personenunabhängige Aufwandseinheiten und nicht mit Stunden und Tagen gleichzusetzen, mehr zu ihnen steht hier und hier. Und Planning Poker ist kein offizieller Teil von Scrum, man könnte es also auch weglassen. Es wird allerdings trotzdem von fast jedem Scrum Team genutzt, da es sich sich als good Practice durchgesetzt hat (mehr dazu hier).

Zur Anwendung: normalerweise werden alle Teammitglieder aufgefordert ihre Schätzung (Karte) in Ruhe auszuwählen, sie noch nicht zu nennen und zu warten bis auch die anderen damit fertig sind. Dann werden die Karten gemeinsam aufgedeckt. Dadurch wird vermieden, dass ein Meinungsführer die anderen bewusst oder unbewusst beeinflusst, die Schätzung ist dadurch repräsentativer.

Da die von den Teammitgliedern geschätzten Werte normalerweise nicht identisch sind kann im nächsten Schritt versucht werden ein einheitliches Verständnis zu erzielen. Immer wieder anzutreffen sind an dieser Stelle Mehrheitsentscheidungen oder Durchschnittswerte, wodurch aber Potential verschenkt wird. Besser ist es, wenn die oberen und unteren Grenzwerte erläutert werden, die Teammitglieder kommen dadurch oft zu Einsichten die sie selbst nicht gehabt hätten.

Neben diesen beiden sehr häufigen Vorgehensweisen gibt es auch weitere, die immer wieder anzutreffen sind. Manche Teams führen für die selbe Anforderung mehrere Schätzrunden nacheinander durch, bis alle die selbe Zahl hochhalten, andere nehmen alle Schätzungen ab einer bestimmten Punktezahl zum Anlass die jeweiligen Anforderungen kleinzuschneiden, wieder andere haben Joker-Karten, mit denen sie einen Experten konsultieren können, etc., etc.

Was all diesen Techniken geimeinsam ist: neben dem Ermitteln des (abstrahierten) Aufwandes steht beim Planning Poker auch ein zweites Ziel im Mittelpunkt - das bessere Verstehen der Anforderung. Die verschiedenen Anwendungsfälle der Karten können dafür sorgen, dass die Ideen des Product Owners gründlicher diskutiert und hinterfragt werden als es normalerweise der Fall wäre. Alleine das ist schon ein Mehrwert.

Donnerstag, 9. August 2018

Agile Roadmaps

FS

Zu den klassischen Planungsinstrumenten gehören die so genannten Roadmaps. bei ihnen handelt es sich (vereinfacht gesagt) um einen Zeitstrahl auf dem verschiedene Fertigungsschritte und -phasen nacheinander und parallel zueinander angeordnet sind. Dieses Instrument hat unverkennbare Stärken: man kann planen was wann gemacht werden soll (ggf. auf dem kritischen Pfad), kann sequentielle Abhängigkeiten darstellen und den Fortschritt überprüfen. Wie viele anderen Planungswerkzeuge ist es aber auch denkbar unflexibel.

Roadmaps gehen immer von einer einzigen Ablauf-Reihenfolge aus, der die man für die ideale hält. Dass es mehrere Varianten geben kann von denen jede ihre Vor- und Nachteile hat geht dabei unter. Auch ist es in der Regel schwierig nachträgliche Änderungen vorzunehmen, und zwar nicht nur da diese den vorgegebenen Zeitplan durcheinanderbringen würden - alleine die Rechtfertigungen und Schuldzuweisungen dafür, dass der ursprüngliche Plan eben doch nicht ideal war, rauben Zeit und Energie.

Eine flexiblere Variante könnte sich an den Streckenempfehlungen der gängigen Karten- und Navigationsdienste orientieren. Gibt man in ihnen Start- und Zielpunkt ein erhält man verschiedene Optionen zwischen denen man wählen kann. Im Fall des oben gezeigten Screenshots bietet etwa die südliche Route in der Mitte noch eine Alternativstrecke, die nördliche aber nicht. Und während die nördliche und die mittlere Route mehrere grosse stausgefährdete Stellen haben hat die südliche nur wenige, führt dafür aber an mehreren Baustellen vorbei. Die Parallelen zu einer Projekt- oder Produktplanung sind offensichtlich.

Durch die frühen oder späten Abzweigungen lassen sich frühe oder späte Architekturentscheidungen symbolisieren, Systeme oder Teams mit begrenzter Bearbeitungskapazität stellen staugefährdete Stellen dar und Systeme an denen auch andere Teams und Projekte arbeiten sind Baustellen. Und sind derartige Faktoren transparent lassen sich auch andere Informationen zu ihnen in Bezug setzen. Nocheinmal zum Screenshot oben: die Südstrecke hat zwar eine etwas kürzere voraussichtliche Fahrtzeit (Projektdauer), durch die Baustellen aber auch ein ungleich höheres Risiko, dass etwas Ungeplantes passiert. Ist der Zeitgewinn dieses Risiko wert? Eine interessante Frage.

Man sieht: die flexiblere Roadmap bietet nicht nur alternative Wege, die ggf. auch eine spätere Umplanung ermöglichen, sie bietet zu den Varianten auch Kontextinformationen, die eine wesentlich differenziertere Abwägung ermöglichen als die klassische, lineare Roadmap. Und die Visualisierung in einer Form die fast jedem Menschen aus seinem Alltag bekannt ist bietet dazu noch einen wesentlich höheren Erkennungs- und Erinnerungswert. Auch das sollte nicht unterschätzt werden.

Dass diese Form der Planung nicht häufiger verwandt wird hat übrigens einen zentralen Grund: sie lässt sich kaum in Powerpoints und Planungstools darstellen sondern praktisch nur auf einer physischen Wand. Und Planung die nicht auf Powerpoints passt ist in vielen Organisationen keine richtige Planung. Das wäre aber ein Thema für sich.

Montag, 6. August 2018

Killing the Monster Merge

FS
Eine enthusiastisch vorgetragene Einführung in das Thema Continuous Integration, und dazu noch eine die mit relativ wenig technischem Verständnis nachvollziehbar ist. Zwar mit einem kleinen Werbeblock ganz am Ende, aber den muss man sich ja nicht ansehen.

Donnerstag, 2. August 2018

Lernen, wie man nein sagt

FS
Grafik: Pixabay / Geralt - CC0 1.0
Zu den wichtigsten Dingen die man lernen muss wenn man beginnt agil zu arbeiten gehört das "Nein"-sagen. Nur wenn man nicht mehr Arbeit beginnt als man beenden kann wird sie in vertretbarer Zeit fertig, nur wenn man nicht jeden Feature-Wunsch umsetzt vermeidet man kaum noch erweiterbare Bloatware, etc., etc. Das große Problem: viele Menschen haben das nie gelernt, zumindest im beruflichen Kontext nicht.

"Ein Nein akzeptiere ich nicht als Antwort" ist eine beliebte Management-Floskel, die man vom Kleinunternehmen bis zum Grosskonzern immer wieder findet. Die Mitarbeiter solcher Firmen lernen irgendwann, dass das Nein-sagen nur zu Eskalation, Druck und Stress führt und lassen es einfach. Stattdessen wird unkritisch fast alles abgenickt und zugesagt, selbst wenn diese Zusagen völlig unrealistisch sind. Erst kurz vor Schluss gibt es dann die Rückmeldung "Ging doch nicht".

Selbst wenn in diesen Kontexten ein Kulturwandel stattfindet in dem die Ablehnung unrealistischer und nicht zielführender Anforderungen möglich und erwünscht ist, tun viele Mitarbeiter sich schwer die jahrelange berufliche Sozialisation zu überwinden und sagen doch immer wieder Dinge zu, die bei realistischer Betrachtung eigentlich abgelehnt werden müssten. Wenn man es nicht gewohnt ist kann das Nein-sagen etwas sein was man wieder lernen muss.

Eine Methode die ich vor kurzem bei einem der von mir gecoachten Teams kennengelernt habe hat mir aufgrund ihrer Einfachheit gefallen: gegen Ende einer Retrospektive verteilte der Scrum Master fünf "Nein-Karten" an jedes Teammitglied. Die damit verbundene Übung - während des Sprints in fünf relevanten Situationen Nein sagen, die Situation auf der Karte notieren und in der nächsten Retrospektive vorstellen.

Als Effekt kommt es nicht nur dazu, dass mehr nicht zielführende Anfragen abgelehnt werden, die Teammitglieder bekommen auch Übung darin es zu tun. Und dadurch, dass die jeweiligen Situationen in der Retrospektive besprochen werden können, kommt auch eine Kommunikation darüber in Gang, wie man Ablehnungen ausspricht, welche Reaktionen darauf entstehen können und wie man mit denen konstruktiv umgeht. Auch das gehört nämlich zum Nein-sagen dazu.

Montag, 30. Juli 2018

Kommentierte Links (XXXIX)

FS
  • SZ: Einschaltquoten waren gestern

    Einer der ursprünglichen Gründe für die Entwicklung agiler Frameworks sind die sich ständig ändernden Wünsche und Bedürfnisse der Kunden, bzw. der Nutzer. Nur um diesen zeitnah gerecht werden zu können wurden Sprints, Daily Standups, User Stories, etc. überhaupt erfunden. Das weitergedacht ist der folgerichtige nächste Schritt ein Service der sich ohne Entwicklungsaufwand selbst an die Kundenbedürfnisse anpassen kann, und das nicht einmal sondern immer wieder. Die in diesem Artikel beschriebenen personalisierten Streaming-Angebote sind ein solches Angebot und dürften damit das sein, was man als "agiles Produkt" bezeichnen könnte.

  • Steve Denning: How Agile Helped Elect Donald Trump

  • In der (in weiten Teilen humanistisch-esoterisch angehauchten) Agile-Community ist die Vorstellung weit verbreitet, dass agile Vorgehensweisen immer einen Bezug zur Menschenfreundlichkeit haben, da sie sowohl Nutzern als auch Mitarbeitern das Leben angenehmer machen. Steve Denning weist zurecht darauf hin, dass es sich bei ihnen lediglich um ein Werkzeug handelt, mit dem ungeachtet seiner Geisteshaltung jeder arbeiten kann. Die von ihm angeführte "agile Kampagne" von Donald Trump ist ein sehr greifbares Beispiel, aber bei weitem nicht das Einzige. Vermutlich ist diese Entwicklung der Preis dafür, dass Agilität in den Mainstream wandert.

  • The Washington Post: Open office plans are as bad as you thought

    "The shift in office space could have profound effects on productivity and the quality of work." Das ist das vorweggenommene Fazit einer aktuellen Studie der britischen Royal Society, aus der die Washington Post zitiert. Zusammengefasst: Grossraumbüros sorgen für eine Fragmentierung, Verlangsamung und Verringerung von Kommunikation in und zwischen Teams, mit den erwartbaren Auswirkungen auf Produktivität und Qualität. Bemerkenswert ist die Studie vor allem wegen ihrer Methodik: in ihr wurden nicht nur die Schwankungen der schriftlichen Kommunikation (Mail, Chat, etc.) überprüft sondern mit Hilfe von Sensoren auch die Gesprächsfrequenz. Sie dürfte dadurch valider sein als viele andere.

  • Informatik Aktuell: Was Microservices wirklich kosten

    Ein eher technisches Thema. Microservices gelten seit einigen Jahren als ein guter Softwarearchitektur-Ansatz für agile Teams oder Unternehmen. Trotz unbestreitbarer Vorteile sind sie aber auch mit Nachteilen verbunden, die Jürgen Lampe hier aufzählt, vom Ressourcenverbrauch über den Testaufwand bis hin zu einer Rückkehr (oder Entstehung) von organisatorischen Silos und Wissensinseln. Wie in vielen anderen Fällen sollte man sich auch bei Microservices fragen, ob die erwarteten Vorteile in einer vertretbaren Relation zu den damit verbundenen Kosten stehen.

  • Ron Jeffries: How to Impose Agile

    Ein Versuch die agilen Transitionen wieder vom Kopf auf die Füsse zu stellen. Statt Rollen, Events und Lieferzeiträume einzuführen "weil das so im Lehrbuch steht" geht Ron Jeffries von der anderen Seite an die Thematik heran. Welche Strukturen sind nötig um in kurzen Abständen neue Funktionen auf Produktion zu bringen, wo sie von den Anwendern genutzt (oder durch Nichtbeachtung abgelehnt) werden können? Im Ergebnis ist es natürlich wieder agil, allerdings mit einem Focus darauf warum das Sinn macht und wo die Schwerpunkte liegen sollten.

Donnerstag, 26. Juli 2018

Deine Muda: Inventory

FS
Bild: Flickr/GOVBA - CC-BY-2.0
Dritter Teil der Deine Muda-Serie. Die zweite Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Lagerhaltung, auf Englisch Inventory. Auf den ersten Blick ein Problem das vor allem in Hardware-produzierenden Branchen auftritt, auf den zweiten Blick aber auch eines der Software-Industrie.

Zunächst zum Grundsätzlichen: warum ist Lagerhaltung ein Problem? Weil Güter die gerade gelagert werden gebundenes und nicht nutzbares Geld darstellen. In ihren Einkauf oder ihre Herstellung musste bereits investiert werden, so lange sie irgendwo gestapelt liegen kann mit ihnen aber kein Gewinn erwirtschaftet werden. Man spricht in diesem Zusammenhang auch von totem Kapital. Lagerhaltung zu vermeiden erhöht demnach die Liquidität und spart nebenbei noch die Kosten für die Anlagen in denen die Lagerung stattfindet.

Auch in der Softwareentwicklung gibt es das Phänomen, dass "auf Halde" produziert und dadurch totes Kapital angehäuft wird. Es tritt da auf wo Deployment- und Rollout-Prozesse so schwerfällig, bürokratisch und arbeitsaufwändig sind, dass ein Go Live neuer Features nur alle paar Monate möglich ist, im schlimmsten Fall nur ein- oder zweimal pro Jahr. Auch hier liegt zwischen dem Ausgeben von Geld für Lizenzen und Gehälter und dem Erwirtschaften der ersten Gewinne des neuen Produkts ein langer Zeitraum. Wirtschaftlich vernünftig ist das nicht.

Was spezifisch in der Software-Industrie dazukommt ist das Risiko, dass mit veraltenden Anwendungsteilen einhergeht - und veraltet ist Software mitunter schon nach mehreren Monaten "Lagerzeit". Wenn über längere Zeit hinweg Features zwar produziert aber nicht integriert werden (oder nicht mit echten Produktionsdaten laufen, oder keine echte Schnittstellenanbindung haben, etc.), dann steigt die Wahrscheinlichkeit, dass der Go Live Ausfälle, Hotfixes und übereilte Anpassungen nach sich zieht. Das kostet dann wieder Zeit und Geld.

Um eine derartige Folgen von Lagerhaltung fertiger Features zu vermeiden ist es nötig, dass die für einen Go Live nötigen Prozesse und Arbeitsschritte verschlankt, beschleunigt, digitalisiert und automatisiert werden. Erst wenn es möglich ist mindestens monatlich auf Produktion zu deployen können totes Kapital und ausufernde Integrations- und Bugfixing-Phasen vermieden werden. Das ist zwar nicht einfach, es ist aber machbar. Und es ist ein Business-Case.

Montag, 23. Juli 2018

Dev/Non-Dev Ratio

FS
Bild: Pixabay / Louise Hoffmann - CC0 1.0
Grundsätzlich ist es zwar so, dass die Situation jeder Organisation irgendwie einzigartig ist, trotzdem gibt es bestimmte Rahmenbedingungen, die durchgehend Einfluss auf das jeweilige "Agilitätspotential" haben. Eine davon (zumindest in Software entwickelnden Firmen) ist das Verhältnis von Software-Entwicklern zu Nicht-Entwicklern. Je höher der Anteil an Nicht-Entwicklern an der Belegschaft ist, desto schwerer wird sich die Firma mit Agilität tun.

Um Missverständnissen vorzubeugen: in kaum einem Unternehmen nennenswerter Grösse werden die Software-Entwickler hundert Prozent des Personals ausmachen. Es wird so gut wie immer den Bedarf nach Buchhaltung, Einkauf, etc. geben. Zu einem Problem kann das aber werden, sobald die Anzahl dieser Leute an die der Software-Entwickler heranreicht oder sie übersteigt. Dann sind nämlich meistens einige (oder alle) der folgenden Konstellationen gegeben:

Es existieren organisatorische Silos

Wenn Teams und Abteilungen nicht crossfunktional aufgestellt sind enstehen permanent Koordinations- und Eskalationsaufwände. Im besten Fall müssen die verschiedenen Silos (Fachabteilung, Anwendungsentwicklung, Betrieb, etc.) ihr Vorgehen ständig miteinander abstimmen, gegebenenfalls gibt es sogar abweichende und gegenläufige Planungen, die regelmässig in Konflikten münden. Im schlimmsten Fall stellen sich die Silos ihre Leistungen gegenseitig in Rechnung, mit allem was das an Verhandlungen und Spar-Lösungen zur Folge hat.

Es existieren Wasserfall-artige Prozessketten

Ein ähnliches Phänomen, allerdings innerhalb der Anwendungsentwicklung. Wenn verschiedene Teams für Anforderung, Konzeption, Entwicklung, Test und Rollout tätig sind, dann führt das zu den gleichen Problemen wie im Fall der organisatorischen Silos. Zusätzlich dazu kommt das Phänomen, dass frühere Prozesschritte (Anforderung und Konzeption) in der Regel einen höheren Output haben als spätere (Entwicklung, Test und Rollout), wodurch es zu Stau, Multitasking und Priorisierungskonflikten kommt.

Es existieren vielstufige Hierarchien

Zum Teil eine Folge des letzten Punktes. Bei Konflikten greift noch zu häufig der Reflex, diese durch eine übergeordnete Eintscheidungsinstanz (das Management) lösen zu lassen statt durch die Beteiligten selbst. Das Weiterleiten vieler Entscheidungen nach oben kann aber nur zu zwei Ergebnissen führen: entweder entsteht dort ein weiterer Flaschenhals durch den alles verlangsamt wird, oder es werden immer mehr Entscheider/Manager eingestellt, die zwangsläufig einen immer grösseren Anteil ihrer Zeit dafür verwenden müssen, sich untereinander zu koordinieren.

Es existieren viele nicht automatisierte oder digitalisierte Arbeitsschritte

Ein etwas anderer Fall als bei den letzten Punkten - hier geht es um die eigentliche Produktion. Je geringer der Automatisierungs- und Digitalisierungsgrad beim Testen, Dokumentieren, Berechtigungsmanagement, etc. ist, desto mehr Zeit geht an diesen Stellen verloren. Die Anzahl an Nicht-Entwicklern wie z.B. manuellen Testern und Business Analysten ist an diesen Stellen ein Indikator für langsame und schwerfällige Prozesse.


Dass derartige Konstellationen existieren hat seine Ursache fast immer in einem falsch verstandenen Effizienzdenken. Die zuvor genannten Phänomene gehen oft auf die Annahme zurück, dass Software-Entwickler produktiver sind wenn sie nur Code schreiben und nichts anderes tun. Die Auslagerung von allem anderen in eigene Silos, Prozesschritte, Hierarchie-Ebenen und (Hilfs-)Teams ist die Folge davon. Dass stattdessen die Effizienz sinkt ist dann eine unangenehme Überraschung.

Donnerstag, 19. Juli 2018

Sommer, Sonne, Schlendrian

FS
Bild: Wikimedia Commons / Duncan Galbraith - CC BY 3.0
Ferien! Es ist Sommer, die Sonne scheint und die Büros werden leer. Ein Grossteil der Mitarbeiter fährt in den Urlaub und es bleiben nur wenige zurück, die eher einen Notbetrieb aufrecht halten als geregelt zu arbeiten. Mitunter kommen die Zurückgebliebenen dann auf die Idee, für die Ferienzeit das eigene Vorgehen "pragmatisch anzupassen". Und damit beginnen die Probleme.

Sowohl in der Produktion als auch in der Methodik sind die Möglichkeiten für den kleinen und grossen Murks unbegrenzt. Die Backend-Entwickler sind in Spanien? Kein Problem, die Frontendler produzieren schonmal "auf Halde". Es sind keine Tester verfügbar? Nicht schlimm, dann gibt es nach den Ferien eine Bugfixing-Phase. Der Product Owner ist auf Kreuzfahrt? Dann wird eben der Scrum Master zeitweise zum Scroduct Ownster. Alles nicht so wild, was soll schon passieren?

Was passieren kann (und sehr häufig auch passiert) ist, dass durch derartige Konstellationen in den Ferien technische und organisatorische Schulden angehäuft werden. Nicht integrierte Komponenten, ungetestete Features oder "verschlankte" Prozesse können langfristige Folgen von erstaunlichem Ausmass haben - vom unkorrigierbar erratischen Verhalten einer Anwendung bis zum kryptisch fragmentierten Backlog ist alles möglich und alles bereits vorgekommen.

Die folgerichtige Frage ist: wie können auch mit reduzierter Besatzung genug Strukturen und Standards aufrechterhalten werden? Verschiedene Maßnahmen machen Sinn. Am Einfachsten ist es natürlich wenn nur Teile des Teams zur selben Zeit in den Urlaub fahren (oder aber alle gleichzeitig). Und für alle Tätigkeiten können Stellvertreter ausgesucht und trainiert werden, mit dem Ziel, dass bestimmte Dinge nicht vermischt werden (z.B. Anforderer ≠ Entwickler und PO ≠ Scrum Master).

Auch das Backlog kann so priorisiert sein, dass die Anforderungen nur die Teile der Arbeit betreffen, die von der Ferienbesatzung beherrscht werden können (z.B. ein Refactoring der automatisierten Testfälle, wenn alle Entwickler im Urlaub sind, oder ein Proof of Concept, wenn nur Entwickler übrig geblieben sind).

In allen Fällen sollte ein Ziel im Vordergrund stehen: auch während der Ferien sollte in möglichst kurzen Zyklen der Zustand des "potentially shippable" erreicht sein. Das ist aber nur gegeben wenn es eben nicht zur Anhäufung technischer und organisatorischer Schulden kommt.

Montag, 16. Juli 2018

Agile Compliance

FS
Bild: Wikimedia Commons / Creig Pat - CC BY-SA 4.0
Wenn die Vorteile von agilen Vorgehensweisen genannt werden liegt in der überwiegenden Mehrzahl der Fälle der Schwerpunkt auf der IT, die so zu bedarfsgerechteren Produkten und schnelleren Releases kommt. Auch Betrieb (Stichwort DevOps) und andere Organisationseinheiten entdecken diese Welt mittlerweile für sich und sehen in Agilität ein anzustrebendes Zielbild. Es gibt aber auch einen weiteren Berech in dem dieser Ansatz Sinn macht, selbst wenn man ihn dort zunächst nicht vermuten würde - Compliance.

Zum besseren Verständnis muss man sich vor Augen halten was dieser Begriff bedeutet. Compliance ist in der Theorie eine Umschreibung für die Einhaltung von Gesetzen und Richtlinien während der Berufsausübung. In der Realität haben sich Compliance-Tätigkeiten allerdings in Teilen von dieser Bedeutung gelöst und auf die damit verbundene Bürokratie ausgedehnt - in fast allen auch nur halbwegs grossen Organisationen bedeutet Compliance heute, dass die eigene Arbeit möglichst lückenlos dokumentiert wird, um bei Bedarf nachzuweisen zu können, dass man sich wirklich an alle Vorschriften gehalten hat1.

Im klassischen wasserfall-artigen Vorgehen führt das am Ende eines Geschäftsjahres oder einer Projektphase zu hektischen Aktivitäten. Nicht nur muss rückwirkend dokumentiert werden, gegebenenfalls muss zuerst durch Reverse Engineering ermittelt werden was überhaupt der zu dokumentierende aktuelle Stand ist. Und im schlimmsten Fall weicht der Ist-Stand so stark von den Vorschriften ab, dass er überarbeitet werden muss. So kann klassische Compliance dazu beitragen, dass sich "fast fertige" Projekte noch erstaunlich lange ziehen.

Ein agiler Ansatz würde dieses Risiko minimieren indem die notwendigen Dokumentationen parallel zur Produktentwicklung fertiggestellt werden, idealerweise im Team selbst, möglicherweise aber auch durch unterstützende Spezialistenteams. Das bedeutet zwar, dass Juristen, Datenschutz-Beauftragte, Penetrationstester und Security-Spezialisten durchgehend verfügbar sein müssen, im Gegenzug ist der Zustand des "potentially shippable" damit durchgehend gewährleistet und nicht nur punktuell. Und die Nacharbeits-Aufwände am Ende fallen weg.

Ein in diesem Kontext sinnvolles Vorgehen wäre übrigens ein Aufbrechen von Wissensmonopolen, z.B. durch den Transfer von Security- oder Datenschutz-Know-How in die Umsetzungsteams. Auch das trägt bei zu schneller Reaktionszeit, da nicht mehr auf den Experten gewartet werden muss.


1Das einfach wegzulassen ist zwar naheliegend, wegen der Überprüfung durch Regulierungs- und Aufsichtsbehörden aber oft nicht machbar.

Donnerstag, 12. Juli 2018

Customer-Vendor Antipattern

FS
Vielleicht hat Jeff Patton Pech mit seinen Bekanntschaften aus dem agilen Umfeld. Vielleicht ist seine Aussage, dass die ausschliesslich auf die Velocity fixiert wären, nur ein rhetorischer Trick um sich als Schwimmer gegen den Strom zu inszenieren. So oder so - sein Vortrag geht auf einige wichtige Punkte ein, und sein Illustrations-Stil ist etwas Besonderes.

Jeff Patton at MTP Engage Hamburg 2018 from Mind the Product on Vimeo.

Montag, 9. Juli 2018

Jenga-getriebene Retrospektiven

FS
Bild: Flickr / RJP - CC BY 2.0
Wenn Teams sich entscheiden nach Kanban zu arbeiten statt nach Scrum fällt vieles weg, was von manchen Menschen als einengend empfunden werden kann, unter anderem die Fixierung auf Sprints von ein bis vier Wochen. Was damit allerdings auch verloren geht ist der automatisch stattfindende Feedback- und Verbesserungszyklus, der durch die am Ende jedes Sprints stattfindende Retrospektive angetrieben und am Laufen gehalten wird.

Nun ist es nicht so, dass es in Kanban keine Retrospektiven gäbe. Sie heissen zum Teil anders (z.B. Kaizen Session, Schulterblick oder KVP-Meeting), aber sie sind da, ohne sie wäre das "manage the flow" nicht möglich. Anders als in Scrum bleibt aber die Frage wann sie stattfinden sollen. "Immer wenn es nötig ist" ist zwar grundsätzlich ein guter Ansatz, bei ihm drohen sie aber vom Alltagsbetrieb verdrängt zu werden. Und feste Intervalle gehen wieder in Richtung Scrum, was oft nicht (mehr) gewünscht ist.

Ein interessanter Ansatz kommt von einem kölner Gamification-Guru und basiert auf einem Jenga-Spiel. Die Grundidee: wie beim normalen Jenga werden nach und nach die Steine aus dem Turm herausgezogen, und sobald er umfällt ist eine Retrospektive fällig. Das Team muss jetzt nur noch vereinbaren wann jeweils ein Stein gezogen wird. Mögliche Anlässe sind:
  • Ein Stein für jeden Tag seit der letzten Retrospektive
  • Ein Stein für jede Aufgabe die in die Expedite-Lane geschoben wird
  • Ein Stein für jede Überschreitung der WIP-Limits
  • Ein Stein sobald ein vereinbartes WIP-Age überschritten wird
  • etc.
Bei diesem Vorgehen würde es spätestens ca alle sechs Wochen zu einer Retro kommen, alleine wegen der Regel, dass ein Stein pro Tag gezogen wird. Je nach vereinbarten weiteren Regeln kann es aber auch deutlich schneller so weit sein, das Vorgehen ist also stark anlassgetrieben. Und zuletzt können Retrospektiven auch spontan angesetzt werden - man muss dafür nur den Turm umwerfen.

Donnerstag, 5. Juli 2018

Nicht-Newtonsche Organisationsformen

FS
Bild: Pixabay / Moho01 - CC0 1.0
Wie würde eine ideale Organisationsform eines agilen Unternehmens aussehen? Eine Frage die noch schwieriger zu beantworten ist als es zunächst den Anschein hat. Selbst wenn es klar ist, dass das Erscheinungsbild anders sein muss als in den starren, bürokratischen Strukturen der Gegenwart - fast alle Scrum Master, Agile Coaches und Unternehmensberater bleiben die Antwort auf die sich darauf anschliessende Frage schuldig: Wie dann?

Die naheliegendste Erwiederung ist die klassische, unbefriedigende Beraterantwort: es kommt immer darauf an. Grundsätzlich ist das auch richtig, nur durch die Orientierung an den im Einzelfall gegebenen Herausforderungen kann eine Organisation reaktionsfähig und somit agil bleiben. Das Problem ist die damit einhergehende Gefahr der Beliebigkeit und Planlosigkeit, die dazu führen kann, dass dauerhaft oder zeitweise in die falsche Richtung gelaufen wird. Ähnlich wie im Fall der Produktentwicklung gilt auch in der Organisationsentwicklung, dass es ein Zielbild oder eine Vision geben sollte der man folgen kann. Die wird durch ein "Kommt darauf an" nicht geliefert.

Auch die nächsthäufige Idee ist nicht ganz befriedigend: die "fluide Organisation". Dabei ist auch dieser Ansatz gut. Genau wie eine Flüssigkeit bewegt sich eine solche fluide Organisation nicht auf dem direktesten Weg Richtung Ziel (→ Zielbild/Vision) sondern auf dem Weg des geringsten Wiederstandes. Hindernisse werden nicht bekämpft sondern umflossen, und bei einer Verlagerung des Widerstandes verlagert sich auch der Fluss. Das Problem an dieser Stelle: manchmal muss man auch im agilen Kontext standhaft sein, etwa um zu Überregulierung oder Überspezifikation Nein zu sagen. Dafür sind fluide Organisation nicht gemacht.

Letztendlich bräuchte es eine Kombination der drei Typen: fluide wenn es möglich ist, mit stabileren, wiederstandsfähigeren Strukturen wenn es nötig ist und das Ganze ständig wechselnd, je nachdem was gerade Sinn macht. Eine Inspiration dafür wie das aussehen könnte liefert ein physikalisches Phänomen: die nicht-newtonschen Flüssigkeiten. Grundsätzlich verhalten diese sich wie jede andere Flüssigkeit auch und fliessen entlang des geringsten Widerstandes. Aber: wenn sie unter Druck gesetzt werden verfestigen sie sich, und zwar um so stärker je heftiger der Druck ist. Erst wenn der nachlässt verflüssigen sie sich wieder. Ein konkretes und verblüffend bekanntes Beispiel dafür kann man sich hier ansehen.

In die Realität umsetzbar ist eine derartige nicht-newtonsche Organisationsform allerdings nur wenn ihre Mitglieder erhebliches Commitment und einen hohen Reflektionsgrad haben. Sobald angefangen wird auf die Organisation Druck auszuüben müssen sie das erkennen und sich zum Widerstand zusammenschliessen, sobald der Druck nachlässt müssen sie die dafür erschaffenen Regeln und Strukturen zurückbauen und auflösen. Das immer wieder zu tun ohne irgendwann zu sehr in eine Richtung zu kippen ist eine Herausforderung.

Der Punkt ist aber auch, dass man eine nicht-newtonsche Organisation eher als ein anzustrebendes Fernziel sehen muss und nicht als den nächsten umzusetzenden Schritt. Wie oben gesagt: als Zielbild oder Vision. Selbst wenn diese vermutlich nie zu hundert Prozent erreichbar ist - sie gibt der Organisationsentwicklung die Möglichkeit zu überprüfen ob der eingeschlagene Weg noch der richtige ist oder ob er korrigiert werden sollte. Allein das ist schon viel wert.

Montag, 2. Juli 2018

Agile is not a mindset

FS
Bild: Pexels / Rawpixel - CC0 1.0
Eigentlich ist es nach dieser Überschrift bereits vorbei. Wie kann er es wagen? Häresie, Frevel, Proselytismus. Er hat Jehova gesagt! In der agilen Community ist es mittlerweile ein Allgemeinplatz, dass Agilität ein Mindset ist, eine Geisteshaltung und eben kein Regelwerk und keine Methode. Basta! Naja. Dem zweiten Teil dieser Aussage würde ich sogar zustimmen, Agilität ist tatsächlich keine durch Regeln definierte Methodik. Dem ersten Teil widerspreche ich aber, ein Mindset ist es auch nicht. Eine bestimmte Geisteshaltung ist zwar eine Voraussetzung, alleine für sich genommen bewirkt diese aber noch gar nichts.

Schauen wir uns das Ganze näher an. Das Wort "agil" hat eine Bedeutung: beweglich oder reaktionsschnell. Ohne Kontext ist das noch sehr unspezifisch. Bin ich bereits agil wenn ich in der Lage bin bei Bedarf meine Meinung schnell zu ändern? Wohl kaum. Es braucht also Zusatzparameter. Für den Kontext von XP, Scrum & Co wurden diese im legendären Manifesto for Agile Software Development geliefert, und zwar anders als man bei erstmaligem Lesen denken könnte nicht nur mit Schwerpunkt auf geistiger Haltung sondern auch mit einem klaren Fokus auf zu erzielenden Ergebnissen.

Vor den berühmten vier Gegensatzpaaren steht auf seiner ersten Seite der Satz: "We are uncovering better ways of developing software by doing it and helping others do it." und genau das ist der Punkt - im Sinn seiner Urheber definiert sich Agilität durch das Liefern von Ergebnissen (Software) und durch das ständige Verbessern dieses Lieferungsprozesses. Auf der zweiten Seite wird das sogar noch genauer ausgeführt: ... early and continuous delivery ..., ... changing requirements, even late in development ..., ... working software is the primary measure of progress ..., und so weiter. Wer mag kann es dort nachlesen.

Warum diese Betonung des Delivery-Aspekts wichtig ist erkennt man an einem in vielen Organisationen zu hörenden Spruch: "Wir sind ja agil, sind offen für geänderte Anforderungen, machen Retros, hinterfragen Regeln, etc - aber wegen der gesetzlichen Vorschriften / wegen unserer Vorgesetzten / wegen unserer veralteten Anwendungen releasen wir nur zweimal pro Jahr." Das Mindset wird an dieser Stelle zu einem Teil einer Selbsttäuschung, die man so formulieren könnte: "Dass wir nur alle paar Monate neue Funktionen zum Anwender bringen ist zwar schade, es hindert uns aber nicht daran Agil zu sein, denn wir haben ja die richtige Geisteshaltung."

Um dieser Selbsttäuschung vorzubeugen rate ich mittlerweile dazu, den Satz Agile is a mindset nicht mehr zu verwenden. In meiner Sicht der Dinge ist Agilität die Fähigkeit sich schnell und unbürokratisch an sich ändernde Rahmenbedingungen anzupassen um kontinuierlich Mehrwert liefern zu können. Wie oben gesagt, ein bestimmtes Mindset ist dafür eine von mehreren Voraussetzungen. Nicht weniger, aber auch nicht mehr. Und wenn die genannte Anpassungs- und Lieferfähigkeit nicht da ist, dann ist man nicht agil, egal wie offen und flexibel die Geisteshaltung ist.

Darum: Agile is not a mindset.

Donnerstag, 28. Juni 2018

Kommentierte Links (XXXVIII)

FS
  • Steve Denning: Ten Agile Axioms That Make Managers Anxious

    Ein Artikel der anscheinend in der Eile des inspirierten Moments geschrieben wurde. Da die Nummer 7 zweimal vorkommt sind es 11 Axiome und nicht 10, Henrik Kniberg wird zu Henrik Nyberg und auch noch weitere Kleinigkeiten ziehen sich durch den Text. Trotz dieser kleinen Fehler ist er bemerkenswert in seinen Aussagen;

    First Law Of Agile: The Law Of The Customer
    1. Firms Make More Money By Not Focusing On Making Money
    2. There Are No Internal Customers
    3. There Are No B2B Organizations
    4. Making Better Products May Not Make More Money
    The Second Law Of Agile: The Law Of The Small Teams
    5. Forget Economies of Scale: Your Market Is One Person
    6. Don’t Scale Up: Descale Complexity Down
    7. Control Is Enhanced By Letting Go Of Control
    7. Agile Is A Mindset, Not A Process
    8. Talent Drives Strategy, Not Vice Versa
    The Third Law Of Agile: The Law Of The Network
    9. The Top-Down Organizational Pyramid Is Finished
    10. Lead Like A Gardener, Not A Commander


    Kontrovers und Kontra-Intuitiv. Das alles nachzuerzählen würde zu weit führen, daher der Ratschlag: oben auf den Link klicken und selber lesen.

  • Zeit: Deadlines halten uns von wichtigeren Aufgaben ab

  • Eine Weiterführung der Debatte um Push-Prinzip und Pull-Prinzip. Das Setzen von Deadlines ist eine der klarsten Formen von Push und wird im agilen Kontext daher nach Möglichkeit abgelehnt. Meng Zhu unterfüttert das mit wissenschaftlichen Erkenntnissen. Zeitdruck erzeugt falsche Prioritäten, senkt Produktivität, führt zu Defocussierung und zum Aufschieben wichtiger aber nicht zeitkritischer Aufgaben. Das Ganze nicht etwa im anekdotischen Einzelfall sondern im Durchschnitt einer statistisch validen Testgruppe. Das sollte eigentlich eine gute Grundlage sein um gegen "aktivierende" und "fordernde" Fristen zu argumentieren.

  • FAZ: In Kalifornien kommt der Burger vom Roboter

    Über die kalifornischen Burger-Roboter hatte ich schonmal etwas geschrieben. Mittlerweile scheint man die Probleme dort in den Griff zu bekommen, mit bemerkenswerten Folgen: das Personal wird entlastet und bekommt geldwerte Leistungen und Zeit für persönliche Entwicklung und Weiterbildung. An dieser Stelle wiederholt sich die Geschichte: bereits vor über hundert Jahren führte die Einführung des Fliessbandes zu ähnlichen Effekten. Es kommt also gerade zu einer weiteren Verschiebungswelle, weg von körperlicher Akkordarbeit, hin zu besser angesehenen und weniger aufreibenden Tätigkeiten. Mit allen Folgen die das für die gesellschaftliche Entwicklung hat.

  • Jean-Pierre Lambert: Scrum Master vs. Agile Coach - same in theory, what about practice?

    Es gibt in agilen Kreisen einen sarkastischen Witz: "Was ist der Unterschied zwischen einem Scrum Master und einem Agile Coach?" "Ein um 500 € höherer Tagessatz." Jean-Pierre Lambert geht dem näher auf den Grund. Wie er richtig schreibt sollte es zwischen den beiden Rollen eigentlich keinen Unterschied geben, weder in den Tätigkeiten noch in der Entlohnung. Und doch ist er da. Woran sich in der Berufswelt Scrum Master und Agile Coach unterscheiden zeigt er an vielen Aspekten auf. Und das nicht mit ideologischem Blick sondern einfach die Realität beschreibend.

  • Mike Cohn: Six Guidelines for Saying No to a Stakeholder

    Zu den Allgemeinplätzen in Ausbildung und Coaching von Product Ownern gehört, dass sie in der Lage sein müssen Nein zu sagen. Wie das in der Realität aussehen soll und wie dabei Verärgerung und Konflikte vermieden werden können wird dagegen zu selten erklärt. Mike Cohn macht sich die Mühe und holt das nach.

Montag, 25. Juni 2018

Deine Muda: Transportation

FS
Bild: Pixabay / Skitterphoto - CC0 1.0
Vor wenigen Tagen hatte ich die Ehre auf der Inhouse-Konferenz eines Kunden einen Vortrag halten zu dürfen. Das Thema waren die Mudas (無駄), also die nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System. Bei der Vorbereitung bin ich vor allem an einer Muda hängengeblieben, der Transportation, bzw. dem Transport.

Kurz zum Hintergrund: solange Güter von A nach B transportiert werden, können sie nicht weitergegeben oder weiterverarbeitet werden, sie bilden also totes Kapital. Zusätzlich dazu verbraucht der Transportvorgang weitere Ressourcen, von der Arbeitszeit des Fahrers über das verbrannte Benzin bis hin zum Verschleiss des Fahrzeugs. Aus diesen Gründen gilt Transport als Muda.

Der irritierende Punkt - in vielen Firmen in denen ich gearbeitet habe sind Transporte noch ein Alltagsphänomen, und das obwohl es sich fast ausschliesslich um Branchen der IT- und Wissensarbeit handelt, in denen die Digitalisierung eigentlich dafür gesorgt haben müsste, dass alles zentral abgelegt oder per Mausklick um den Globus geschickt werden kann. Allein - oft ist dem nicht so. Überall wird noch Papier befördert.

Zwar seltener werdend aber noch immer zu finden sind die Laufmappen in denen die Hauspost Briefe und Formulare durch die Gegend fährt, häufig anzutreffen sind Lieferungen gedruckter (und schnell veraltender) Anleitungen, Anforderungen und Dokumentationen sowie Prospekte, Kataloge und Mitarbeiterzeitschriften. Einige besonders skurrile Sonderfälle bilden die Transporte digitaler Datenträger, etwa von Disketten und CDs.

Das all das auch gegenwärtig noch stattfindet lässt sich in der Regel mit zwei Ursachen erklären. Zum einen hängen gerade ältere Mitarbeiter noch an der haptischen Erfahrung von Papier und fordern diese immer wieder ein, zum anderen wird die Digitalisierung von Prozessen oft nicht mehr vorangetrieben, sei es weil man sie für abgeschlossen hält oder sei es weil gerade andere Vorhaben wichtiger sind.

Selbst wenn man es kaum glauben mag - auch heute sind in der IT- und Wissensarbeit die fehlende Digitalisierung und der damit verbundene Transportaufwand grosse Probleme. Diese anzugehen bietet noch immer ein grosses Potential für mehr Effektivität und weniger Transportation-Muda.

Donnerstag, 21. Juni 2018

Das Ergebnis von 60 Jahren kontinuierlicher Optimierung

FS
... kann man hier sehen. Von mehr als einer Minute verkürzt sich der Vorgang des Reifenwechselns in der Formel 1 auf nur noch wenige Sekunden:



Hinter dieser Verbesserung stecken verschiedene Faktoren: geänderte Teamzusammensetzung, geänderte Abläufe und neue Technologie, angetrieben von einem hochgradig kompetitiven Umfeld. Die Parallelen zur IT sind offensichtlich.

Montag, 18. Juni 2018

Agile Silos

FS
Bild: Wikimedia Commons / Pline - CC BY-SA 3.0
Agile ist im Augenblick ein Hype. Die Kritiker sind zwar nicht verstummt, werden aber kaum noch wahrgenommen und eine Branche nach der anderen, ein Unternehmen nach dem anderen beschliesst mitzumachen. Anders als noch vor einigen Jahren beschränken sich die Agilisierungs-Bemühungen auch nicht mehr auf die Softwareentwicklung. Auch HR, Marketing, Operations, Strategie und praktisch jedes andere Ressort will zukünftig agil sein. Das ist zunächst einmal eine gute Entwicklung - oder?

Die Antwort: im Prinzip ja, im Rahmen der Umsetzung gibt es aber immer wieder Probleme. Agile HR, Agiles Marketing, Agiler Vertrieb, etc. klingen zwar erstmal gut, in der Realität führt diese Umettikettierung aber meistens nicht dazu, dass hier wirklich effektiver gearbeitet wird. Der Grund dafür, dass viele Unternehmen schwerfällig, bürokratisch und ineffektiv sind ist nämlich nicht fehlende Agilität in den organisatorischen Silos, die blosse Existenz der Silos ist der Grund dafür.

Die Phänomene sind allgemein bekannt: der Vertrieb der schneller Aufträge akquiriert als die Produktentwicklung sie abarbeiten kann, die Personalabteilung die unsinnige Weiterbildungen organisiert weil sie zu weil weg von den Bedürfnissen in der Fertigung ist, die Strategieabteilung die Kooperationspartner heranholt deren Systeme mit der eigenen IT inkompatibel sind, all das wird nicht besser dadurch, dass es jetzt noch schneller, wendiger und effektiver stattfindet.

Wenn ein Unternehmen agil werden möchte ist die Agilisierung von Silos nicht der richtige Weg. Der bessere Ansatz wäre es die Silos aufzulösen oder aufzuweichen und stattdessen crossfunktionale Einheiten einzurichten. DevOps als Kombination von Entwicklung und Betrieb greift ja schon um sich, aber warum nicht auch Entwicklung und Vertrieb? Oder warum können Marketing und Einkauf ihre Fortbildungen nicht selbst organisieren, ohne Beantragungs- und Genehmigungsbürokratie?

Natürlich ist das in der Konsequenz viel gravierender als das blosse Einführen einer neuen Methode. Vielleicht steht am Ende eine Struktur in der manche Ressorts aufgelöst werden und andere weitreichende Kompetenzen abgeben. Und natürlich kann das unbequem sein, Egos verletzen und alte Karrierepfade verbauen. Auf der anderen Seite bringt es aber auch viel mehr als das Anbringen eines "Agilen Labels" auf einem Silo in dem die Leute genauso im eigenen Saft schmoren wie vorher.

Freitag, 15. Juni 2018

Gemeinsame Reviews

FS
Bild: Pxhere / Rawpixel - CC0 1.0
Ob in Scrum nach jedem Sprint oder in Kanban oder anderen Frameworks je nach Bedarf - Review Meetings in denen der neueste Produktfortschritt den Auftraggeben und Nutzern vorgestellt und mit ihnen diskutiert wird sind ein zentraler Bestandteil agiler Vorgehensweisen. In der Regel hat dabei jedes Team ein eigenes Review-Meeting, allerdings kann es Konstellationen geben in denen gemeinsame Veranstaltungen Sinn machen.

Am naheliegendsten in das im Rahmen agiler Skalierung. Wenn mehrere Teams an einem gemeinsamen Produkt oder in einem gemeinsamen Projekt arbeiten sind mit grosser Wahrscheinlichkeit die Themen aller Teams miteinander verwandt, vor allem dann wenn sie in Release Trains oder anderen gemeinsamen Taktungen arbeiten. Da auf diese Art ein gemeinsames Increment entsteht (oder zusammen passende Incremente entstehen) macht auch eine gemeinsame Präsentation und Diskussion Sinn.

Ein weiterer Anwendungsfall für gemeinsame Reviews ist gegeben wenn mehrere Teams an einer gemeinsamen Codebasis arbeiten in der es keine teambasierte Code Ownership gibt. Das Review kann in dem Fall der passende Ort sein um sich einen Überblick darüber zu verschaffen welches Team an welcher Stelle Änderungen vornimmt. Das Risiko bei einem solchen Vorgehen ist, dass die Veranstaltung zu technisch wird und dadurch andere Zielgruppen abschreckt. Gegebenenfalls macht daher ein gemeinsames technisches Review separat vom fachlichen Review Sinn.

Im Rahmen geografisch verteilter Firmen können gemeinsame Reviews Teil von Events sein mit denen der standortübergreifende Zusammenhalt gefördert wird. Im Rahmen von Präsentationen und Diskussionen können die Mitglieder der jeweiligen Teams direkt miteinander interagieren, was erfahrungsgemäss deutlich intensiver ist als gemeinsame Videokonferenzen. In diesem Kontext haben die Meetings damit eine zusätzliche soziale Funktion.

Zuletzt kann in Firmen mit vielen Teams ein gemeinsames Review eine Notwendigkeit sein um die Kalender der Stakeholder zu entlasten. Man kann sich das einfach vorstellen: wenn 15 Teams gemeinsam an einem Webshop bauen und jedes Ein- oder Zweiwochensprints hat, dann kämen bei separaten Sprint Reviews bis zu 60 Stunden pro Monat zusammen die man alleine in diesen Meetings verbringen könnte, Anlauf- und Abklingzeiten nicht mitgerechnet. Ein Zusammenlegen kann hier für Erleichterung sorgen (wobei aber immer noch gewährleistet sein muss, dass Austausch stattfinden kann).

Dienstag, 12. Juni 2018

Where there is no vision, the people perish

FS
Bild: Pexels / Simon Migaj - CC0 1.0
Aller Anfang ist hart, aber wenn es eine Organisation einmal geschafft hat agile Strukturen bei sich einzuführen ist sie zu Erstaunlichem in der Lage. In kurzen Abständen kann sie ihren Kurs anpassen, neue Wege in Technik und Fachlichkeit gehen, neue Kunden ansprechen und mit neuen Partnern kooperieren. Das alles vermag sie nicht nur einmal zu tun sondern beliebig oft, immer wieder und wieder. Und wenn sie Pech hat wird es dann genau so kommen.

So schön die mit Agilität einhergehende Reaktionsgeschwindigkeit auch ist, sie kommt mit einem Preis. Fertige Features wieder auszubauen oder bereits beschlossene Pläne zu verwerfen wird immer dazu führen, dass gewisse Aufwände umsonst gewesen sind und ggf. sogar mit Zusatzaufwänden rückgängig gemacht werden müssen. Wo das regelmässig passiert (und das ist an mehr Stellen als man denken sollte) führt es zu hohem Ressourcenverbrauch und zu zurückgehender Motivation der Mitarbeiter, die das Gefühl bekommen umsonst zu arbeiten. Ein solcher Zickzack-Kurs sollte also möglichst vermieden werden.

Eine gute Möglichkeit dem entgegenzuwirken ist die Schaffung einer übergreifenden Produktvision für die beteiligten Teams, z.B. "Wir wollen für unsere Kunden alle Bankdienstleistungen auf dem Handy verfügbar machen". Die hilft zum einem dabei unnötige Features zu identifizieren und gar nicht erst zu bauen (etwa eine nur auf dem Desktop verfügbare Anwendung), zum anderen kann dadurch erkennbar werden wo noch zu füllende Lücken in der Anwendungslandschaft sind die die Teams noch unter sich aufteilen müssen (z.B. wenn auf dem Handy noch keine Kontoauszüge einsehbar sind).

Um die Teams nicht zu sehr einzuengen (was Agilität und Reaktionsgeschwindigkeit reduzieren würde) sollte eine Produktvision nicht zu stark ausformuliert sein. Zwar sind unter dem einen, plakativen Satz häufig noch einige erklärende Zeilen zu finden, sobald diese aber mehrere Absätze (oder noch schlimmer: Seiten oder Kapitel) umfassen ist das ein klares Zeichen für einen zu hohen Detaillierungsgrad. Wenn sie es wollen können Teams sich aus der grossen Vision kleinere Teilvsionen ableiten, aber wenn das geschieht sollten sie es selbst tun, nicht ein Manager oder Koordinator. Das würde die Selbstorganisation untergraben.

Wer die übergreifende Produktvision formuliert kann übrigens von Produkt zu Produkt und von Firma zu Firma unterschiedlich sein, vom Firmeninhaber bis zu einer PO-Community ist alles denkbar. Demjenigen oder denjenigen sollte nur klar sein, dass es ein Balanceakt ist. Wie oben erwähnt: ohne klare Vision droht Beliebigkeit, bei zu viel Details erstarren die Strukturen. Der anzustrebende Punkt liegt irgendwo in der Mitte dazwischen.

Donnerstag, 7. Juni 2018

Features entsorgen

FS
Bild: Wikimedia Commons / Hyena - CC0 1.0
Eine der besten Definitionen von Agilität ist die, dass eine agile Organisation in der Lage ist in kurzen Abständen nutzbare Funktionen zum Kunden oder Benutzer zu bringen, unmittelbar dessen Feedback einzuholen und dieses sofort in die Entwicklung der nächsten Funktionalität einfliessen zu lassen. Deliver, inspect, adapt, deliver, inspect, adapt, etc., etc., etc. Ein immerwährender Strom neuer, immer besser werdender Produktincremente.

So richtig und wichtig dieses Vorgehen auch ist, wird es genau so durchgeführt verursacht es aber auch Probleme. Die Codebasis wird immer grösser, die Seitenauswirkungen der Weiterentwicklung werden unvorhersehbarer, die Regressionstests umfangreicher, die Zielgruppen diverser und die die Kundenfeedbacks zahlreicher und uneinheitlicher. Infolge dessen muss ein immer grösserer Teil der Entwicklungszeit für Instandhaltung, Qualitätssicherung und Abstimmungen verwandt werden. Die Durchlaufzeiten werden höher, die Incremente kleiner, die Agilität sinkt.

Die beste Möglichkeit dem entgegenzuwirken ist eine regelmässige Reduzierung des Funktionsumfangs. Den zuvor genannten Entwicklungen wird damit entgegengewirkt, die Produkte werden schlanker und beweglicher und mit ihnen die gesamte Organisation. Die spannende Frage ist jetzt: welche Features sollte man entsorgen? Die leidige Antwort: es kommt drauf an. Naheliegend ist es, die am wenigsten genutzten zuerst auszubauen, aber auch andere sind möglich - die am wenigsten gewinnbringenden, die wartungsaufwändigsten, die am wenigsten zur Firmenidentität passenden und gegebenenfalls noch viele mehr. Egal welche es letztendlich sind - einige müssen daran glauben. Müssten. Eigentlich.

Das alles findet leider nur sehr selten statt, in der Regel deshalb weil ein solches Vorgehen nicht zu den Grundsätzen passt nach denen in vielen Firmen Produktentwicklung stattfindet. Ressourcen und Kapazitäten werden dorthin geleitet wo es Kunden und Umsätze zu gewinnen gibt, nicht dorthin wo Komplexität reduziert wird. Und wenn sogar eine kleine aber treue Benutzergruppe verloren gehen würde werden Diskussionen oft vom jeweils zuständigen Management-Team abgeblockt. An diesen Stellen braucht es Gesamtverantwortung und systemisches Denken. Nur wer die hat erkennt, dass die globale Verbesserung die lokale Verschlechterung aufwiegt.

Wie in vielen anderen Aspekten sind auch hier die kalifornischen IT-Unternehmen vorbildlich. Mit iGoogle, dem Google Reader, Facebook Paper, Instagram Maps, Twitter Vine und vielen mehr gibt es mittlerweile eine erstaunliche Menge entfernter Features und sogar ganzer Produkte, darunter auch solche mit treuen Usern und andere die früher sogar als strategische Zukunftsprojekte galten. Sucht man also nach Beispielen und Argumentationshilfen in dieser Sache - hier findet man sie reichlich. Du willst sein wie Google und Facebook? Dann fang an indem Du die Axt an die eigenen Features legst.

Montag, 4. Juni 2018

Innovation is about collective genius

FS
Wenn es um die Themen Innovation und Kreativität geht glauben viele Menschen, dass diese in erster Linie in den Köpfen einzelner Menschen entstehen. Dass es sich stattdessen um eine Teamarbeit handelt (und wie man diese befördert) wird hier von Linda Hill beschrieben:

Donnerstag, 31. Mai 2018

Kommentierte Links (XXXVII)

FS
  • Martin Aziz: Business Agility has little to do with Scaling Agile

    Etwas merkwürdig an diesem Artikel ist, dass agile Skalierung in ihm nicht vorkommt, die Überschrift ist also irreführend. Was hingegen sehr gut beschrieben wird sind die für Business-Agilität notwendigen Strukturen auf den verschiedenen Organisationsebenen: auf der obersten Ebene wird eine sich ständig anpassende Strategie verfolgt um mit dem bestehenden Leistungsvermögen den grösstmöglichen Ertrag in einem Marktsegment zu erwirtschaften, in der Mitte werden die einzelnen Produkte und Dienstleistungen immer weiter entwickelt und an die Kundenbedürfnisse angepasst, auf der untersten Ebene sorgen die Teams für transparente Abläufe und hohe Durchlaufzeiten im eigentlichen Produktionsprozess. Klingt ganz einfach. Eigentlich.

  • Luís Gonçalves: How to Calculate Cost of Delay So You Know Where You’re Losing Money

  • Ein Argument das immer wieder vorgebracht wird wenn es um den Mehrwert von agilen und lean-Vorgehensweisen geht ist die Cost of Delay, bzw. deren Reduzierung. Da Kosten sich beziffern lassen sollten stellt sich die Frage, wie das im Fall der Cost of Delay aussehen soll. Diese Aufschlüsselung von Luís Gonçalves ist sehr hilfreich, sie bietet sowohl mehrere Möglichkeiten der Berechnung als auch verschiedene Erscheinungsformen mitsamt des damit verbundenen Dringlichkeitsgrades.

  • Fagner Brack: Not Every Company Is a Software Company

    Wer hätte es gedacht, nicht jede Firma ist eine Software-Firma. Aber: ab einer bestimmten Grösse aufwärts (grösserer Mittelstand) stellt jede Firma Software her, und wenn auch nur durch das Customizing eingekaufter Standard-Produkte. Das Problem: in den meisten Unternehmen ist das dem Management nicht bewusst, und wenn doch kann es die damit verbundenen Implikationen nicht erkennen und bewerten. In der Konsequenz wird ein Software-Entwicklungsprozess von Leuten gesteuert denen die Auswirkungen ihres Tuns nicht in Gänze klar sind. Was das bedeutet und was das für Folgen nach sich ziehen kann wird hier detailliert erläutert.

  • Ben Mancini: Fixing the certification problem

    Ich gestehe, ich bin zertifiziert. Mehrfach. Trotzdem kann ich der damit verbundenen Industrie immer weniger abgewinnen, zu offensichtlich ist es mittlerweile, dass es sich hier im Wesentlichen um ein Tauschgeschäft von Geld gegen Titel handelt. Ben Mancini macht sich sehr kluge Gedanken darüber wie ein besseres Zertifizierungs-System aussehen müsste und was dafür an den bestehenden Zuständen zu ändern wäre. Das Problem das ich sehe - so lange es ein solches Millionengeschäft ist werden die aktuell beteiligten Firmen nicht auf das Geld verzichten wollen. Und wie er selber schreibt: für die Erstellung eines besseren Systems bekäme man zwar Dank, der Aufwand würde aber nicht bezahlt werden. So spricht vieles dafür, dass es bleibt wie es ist.

  • Ron Jeffries: Developers Should Abandon Agile

    Irgendwann habe ich mal geschrieben, dass Konzerne nicht versuchen sollten agil zu werden sondern sich stattdessen auf die notwendigen Verbesserungen konzentrieren sollten: kurze Time to Market, hohe Reaktionsgeschwindigkeit und Vermeidung sinnloser Arbeit. Ron Jeffries überträgt das auf die Software-Entwickler - statt sich auf agile Frameworks zu konzentrieren sollten sie an inkrementeller Fertigstellung, kurzen Lieferzeiten, Clean Code und intensiver Kommunikation mit Fachabteilungen und Management arbeiten. Die Pointe ist in beiden Fällen die gleiche: wenn man das macht ist Agilität die Folge, egal ob beabsichtigt oder nicht.

Montag, 28. Mai 2018

Datengetriebene Retrospektiven

FS
Bild: Pexels / Lukas - CC0 1.0
Nachdem ich in der letzten Woche von Klaus Leopold in dessen unverwechselbarer Art mit Zahlen bombardiert wurde möchte ich dieses Thema auch hier aufgreifen. Agile Vorgehensweisen nehmen für sich in Anspruch, dass sie empirisch basiert und datengetrieben sind, und die naheliegendste Verwendung der erhobenen Zahlen ist ihre Nutzung als Teil des ständigen Verbesserungsprozesses. Ein guter Moment dafür sind die Retrospektiven, in denen die Metriken gemeinsam analysiert werden können. Erfahrungsgemäss bieten sich dann je nach Art der Metrik unterschiedliche Massnahmen an.

Cycle Time

Die Zeit zwischen dem Beginn einer Umsetzung und deren Ende, wobei am Ende ein Produktinkrement stehen sollte das jederzeit live gehen könnte. Im Sinn der Agilität sollte diese Zeit möglichst kurz sein, sollte das Team sie als zu lang empfinden können Massnahmen beschlossen werden um das zu beschleunigen. Dazu gehören z.B. das Kleinerschneiden von Anforderungen oder das Automatisieren von Tests.

Lead Time

Entspricht der Zeit zwischen dem ersten Aufkommen einer Anforderung und dem Ende der Umsetzung (also Cycle Time plus vorgelagerte Prozesse), was bedeutet, dass häufig andere Teams oder Abteilungen beteiligt sind. Auch diese Zeitspanne sollte so kurz wie möglich sein, zu den möglichen Verbesserungsmassnahmen gehören die Harmonisierung von Übergaben zwischen den Phasen oder die Verbesserung der Kommunikation zwischen den Teams und Abteilungen.

Throughput

Eine der häufigsten und einfachsten Metriken: erfasst wird die Zahl der vervollständigten Arbeitspakete pro Zeiteinheit (z.B. pro Monat). Da diese Zahl durch eine Vielzahl von Faktoren beeinflusst werden kann gibt es keine Verbesserungsmassnahmen die naheliegender sind als andere, hier kommt es auf den Einzelfall an.

Velocity

Im agilen Kontext wird dieser Begriff vor allem von Scrum Teams benutzt (obwohl er kein offizieller Teil von Scrum ist). Unter ihm wird die Summe der Story Points aus allen im letzten Sprint fertiggestellten User Stories verstanden. Da Story Points keine exakte Schätzung sind und ggf. nicht alle Items im Sprint so geschätzt werden ist diese Zahl mit Vorsicht zu behandeln, sie kann aber die Ausgangsbasis für eine Problemanalyse sein.

Work in Progress

Die Menge verschiedener Aufgaben an denen ein Team gleichzeitig arbeitet. Das mit zu viel paralleler Arbeit verbundene Multitasking führt in der Regel zu Konzentrationsverlust und höherer Cylcle Time, umgekehrt kann bei Arbeitsprozessen die sich über mehrere Phasen erstrecken zu wenig Arbeit in einer Phase dazu führen, dass die nachgelagerten Phasen leerlaufen. Die Gegenmassnahmen sind Ober- oder Untergrenzen, die so genannten Work in Progress-Limits oder WIP-Limits.

WIP-Age

Eine Ableitung der Lead Time. Konkret geht es darum, wie hoch die bisherige Lead Time der Aufgaben ist, die im aktuellen Moment, bzw. im aktuellen Sprint bearbeitet werden. Ist diese Wert zu hoch, die Cycle Time innerhalb der Umsetzungsphase aber niedrig, kann das bedeuten, dass in den vorgelagerten Prozessschritten Staus bestehen weil dort zu viel vorgearbeitet wird. Um das zu beheben kann es Sinn machen WIP-Limits einzuführen die über alle Phasen harmonisiert sind und dabei auch die jeweiligen unterschiedlichen Cycle Times berücksichtigen.

Blocked Days/Hours

Sowohl hohe Lead Times und Cycle Times als auch hohes WIP-Age können darauf zurückgehen, dass Arbeiten unterbrochen werden müssen um auf Zulieferungen oder Abnahmen zu warten, die von Personen ausserhalb des Teams vorgenommen werden. Ist die Anzahl der dadurch entstehenden Verzögerungstage oder -stunden zu hoch kann das dadurch ausgeglichen werden, dass das Team diese Arbeiten selbst erledigt (und das ggf. erlernt).

Bug Rate/Incident Rate

Eher unschöne Metriken, da sie die Folge von früher gemachten Fehlern und Versäumnissen sind. Dementsprechend sollten Verbesserungen am besten auf die Qualitätsaspekte der Produktentwicklung abzielen, etwa auf Testabdeckung und Code Reviews.

Bugfix Time

Auch das ist klar, je länger es dauert Bugs zu beheben desto mehr Probleme treten auf, und das sowohl bei der Systemstabilität als auch bei der Nutzerzufriedenheit. Die Bugfix Time als Sonderfall der Lead Time oder Cycle Time ist daher von besonderer Bedeutung. Die beste Gegenmassnahme ist eine Zero Bug-Policy.

---

Voraussetzung für all das ist natürlich, dass die jeweiligen Metriken permanent erhoben werden, entweder digital durch die jeweiligen Tools oder von Hand. Das ist zwar ein gewisser Aufwand, allerdings einer der sich definitiv lohnt.

Freitag, 25. Mai 2018

How to do safety differently

FS
Zu den häufigsten Einwänden gegen vollkommen autonome und selbstorganisierte Teams gehören Sicherheitsbedenken aller Art. Wenn es da nicht Vorschriften und Regeln geben würde, dann wäre alles riskant und gefährlich, heisst es. Dass das so nicht stimmt zeigt der folgende Film. In ihm sieht man, dass selbstorganisierte Teams sogar für mehr Sicherheit sorgen können. Sehenswert.

Dienstag, 22. Mai 2018

Definition of Done

FS
Bild: Pexels / Daria Shevtsova - CC0 1.0
Praktisch jeder der jemals an der Erstellung eines komplizierten oder komplexen Produkts mitgewirkt hat dürfte sie kennen - die Diskussionen um die Rand-, Umgebungs- und Kontextfaktoren der Produktentwicklung und darum ob diese abnahmerelevant sind. Die Kompatibilität mit bestimmten (Produktions-)Daten gehört dazu, Schnittstellen-Anbindungen, Dokumentation, Absicherung durch Tests und vieles mehr. "Das hätte man sich doch denken können.", "Das ergibt sich aus dem gesunden Menschenverstand" und ähnliche Argumente tauchen immer wieder auf und belegen, dass die Verständnisse an diesen Stellen weit auseinandergehen.

Um dem entgegenzuwirken gibt es in Scrum (und auch in vielen Teams die andere agile Vorgehensweisen bevorzugen) die Definition of Done (DoD), eine verbindliche Regelung, die definiert was alles gegeben sein muss damit eine Abnahme stattfinden kann. Wichtig ist dabei nicht etwa, dass die DoD umfassend alle Eventualitäten regelt. Das würde zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen wären. Besser sollten dort nur die Bereiche geregelt werden bei denen die Teammitglieder ein unterschiedliches Verständnis haben. Dieses durch gemeinsame Entscheidungen des gesamten (Scrum) Teams zu vereinheitlichen ist der eigentliche Mehrwert.

Ich würde immer empfehlen mit einer sehr schlanken Definition of Done zu beginnen, die z.B. nur definiert auf welcher Umgebung eine Abnahme stattfindet und dass mindestens zwei Personen an jeder Anforderung gearbeitet haben müssen (Vier Augen-Prinzip). Mit der Zeit können dann weitere Kriterien dazukommen, etwa das notwendige Ausmass von Testautomatisierung und Dokumentation oder die Sprachen in denen das Produkt verfügbar sein muss. Es ist erfahrungsgemäss immer einfacher einen geringen Umfang zu erweitern als einen grossen zurückzuschneiden, zumindest gilt das für neue oder noch unerfahrene Teams. Bei ihnen nimmt der Umfang der DoD häufig über einige Monate immer weiter zu.

Erfahrene Teams tun sich mit der Reduzierung auf das Wesentliche leichter. Viele Teams mit denen ich gearbeitet habe haben ihre DoD früher oder später auf wenige Sätze zusammengestrichen, die dann eher einen Sinn reflektiert haben als konkrete Vorgaben zu machen. Eines meiner Lieblingsbeispiele ist ein Team dessen DoD aus nur einem Satz bestand: "Eine Anforderung ist abgenommen wenn der Product Owner Kuchen mitbringt". Das ganze Team hatte ein einheitliches und sehr hohes Qualitätsverständnis, und der PO war bekannt dafür, den "Abnahme-Kuchen" nur dann mitzubringen wenn das neue Feature diesem Verständnis zur Gänze entsprach und niemand mehr Widerspruch einlegte. In diesem Zusammenhang reichte dieser eine, zunächst wunderlich klingende Satz als DoD völlig aus.

Bleibt noch die Frage: was ist wenn mehrere Teams an einem gemeinsamen Produkt arbeiten, sollte man die Definition of Done in einem solchen Fall nicht vereinheitlichen? Die Antwort darauf ist ein klares Ja. Aber: der Knackpunkt ist das Wort "man". Mit ihm ist nicht etwa ein Manager, eine QA-Abteilung oder eine sonstige übergeordnete Person oder Struktur gemeint. Die gemeinsame DoD muss gemeinsam von den beteiligten (Scrum) Teams entwickelt werden. Nur so kann sichergestellt werden, dass sie bedarfsgerecht, unbürokratisch und von den Beteiligten nicht als Fremdkörper empfunden ist (das sieht auch der Scrum Guide so). Alles andere wäre ein Antipattern.

Donnerstag, 17. Mai 2018

Decision Stories

FS
Bild: Pixabay / Qimono - CC0 1.0
Eine der eher nervtötenden Tätigkeiten in Organisationen jeglicher Grösse ist das Nachvollziehen von Entscheidungen, die vor längerer Zeit getroffen worden sind. Selbst wenn alle Beteiligten noch immer anwesend sind kann es zu einer echten Herausforderung werden rückwirkend zu klären warum und unter welchen Bedingungen ein Beschluss gefasst wurde. Grundsätzlich ist das erklärbar, gerade in einem agil arbeitenden Umfeld sind Entscheidungen so häufig nötig, dass der Einzelfall in der Erinnerung verschwimmt. Man muss also dokumentieren. Und damit beginnen weitere Probleme.

Im besten Fall wird die Entscheidung im Rahmen eines Meeting-Protokolls festgehalten. Diese sind in der Regel knapp gehalten und Ergebnis-orientiert, was dann so aussehen kann (angelehnt an einen echten Fall):
Man sieht - die Entscheidung ist festgehalten, es sind auch die an der Diskussion beteiligten Personen genannt und es wird sogar auf die besprochenen Them eingegangen. Trotzdem ist im Rückblick völlig schleierhaft was letztendlich den Ausschlag für eine Option gegeben hat. Und wie gesagt, das ist noch ein gutes Beispiel. Schlimmer sind Fliesstexte, die häufig so aussehen:
Die Ausschreibung erfolgte unter den im Vergabeportal registrierten Preferred Suppliern mit Fristende auf dem letzten Tag von Q4. Basierend auf den in der Evaluierungsphase gesammelten Kriterien (vergleiche Kriterienkatalog PA30005 in der Version vom 26.11. und Procurementrichtlinie ITBesT28, Version 32.05) konnte die Auswahl auf drei Bieter eingeengt werden (siehe Entscheidungsvorlage Bieter Q4 final mit Aufschlüsselung auf die 49 als relevant identifizierten Schlüsselkriterien). Basierend auf der im Vergleich höheren Fach- und Branchenexpertise der QWERT AG und im Hinblick auf zu erwartende Synergieeffekte mit dem vom selben Bieter unterstützten Oktopus-Projekt konne in einem ersten Pitch der postive erste Eindruck bestätigt werden ...
Und so kann es über mehrere Seiten weitergehen. Schwer zu lesen, schwer zu ertragen und schwer nachzuvollziehen. Letztendlich wird die Entscheidung hier eher verschleiert als nachvollziehbar gemacht. So sollte es also nicht sein. Aber wie dann?

Eine bessere Möglichkeit die in den letzten Tagen durch meinen Newsfeed gerauscht ist greift die Idee hinter der User Story und der Vision auf und überträgt sie: wenige, in verständlicher Sprache verfasste Sätze fassen sowohl die Entscheidung als auch die dazugehörenden Kontextinformationen zusammen. Ein Beispiel:
Basierend auf der Annahme, dass der Personalbestand weiterhin um 10 % pro Quartal wächst wird die angemietete Bürofläche um 500 m2 erweitert, um während des gesamten Folgejahres eine Co-Location mit 12 m2 je Mitarbeiter gewährleisten zu können. Ein Plan-Ist-Abgleich findet einal pro Quartal statt, um ggf. Anpassungen der Flächengrösse vornehmen zu können.
Sechs Informationen sind hier enthalten: zugrundeliegende Hypothese, abgeleitete Massnahme, erwarteter Mehrwert, Prüfkriterien, Überprüfungsintervall und mögliche Korrekturmassnahme. Eine auf diese Weise dokumentierte Massnahme ist jederzeit nachvollziehbar, validierbar und bei Bedarf korrigierbar, ohne dass gross diskutiert oder überlegt werden müsste. Würden Entscheidungen durchgehend nach diesem Format dokumentiert würden die Unklarheiten deutlich abnehmen.Und falls das Ding einen Namen braucht - analog zur User Story würde sich die Decision Story anbieten.

Montag, 14. Mai 2018

On Site Customer

FS
Bild: Pexels / Rawpixel - CC0 1.0
Nicht alles was im agilen Kontext Sinn macht muss notwendigerweise aus Scrum oder Kanban kommen. Auch andere Ansätze haben Good Practices herausgebildet, die grossen Mehrwert stiften können. Einer davon ist der sogenannte On Site Customer aus dem Extreme Programming, bzw XP. Ein Vertreter der Kunden oder Anwender der beim Umsetzungsteam anwesend ist und mit ihm zusammenarbeitet.

Wie häufig in derartigen Fällen ist die Einrichtung des On Site Customers die Reaktion auf einen Missstand. Bedingt dadurch, dass komplexe Themen nicht immer einfach zu erklären sind und verstärkt dadurch, dass Kunde und Entwickler so unterschiedliche Hintergründe haben können, dass sie quasi verschiedene Sprachen sprechen, sind in der Produktentwicklung Missverständnisse praktisch unvermeidbar. Diese zu beheben kostet dann Zeit und Geld. Der einfachste (und in vielen Fällen einzige) Weg um diese Situation aufzulösen ist die Anwesenheit eines Kunden, bzw. Endanwenders vor Ort, der unmittelbares Feedback geben kann ob die Umsetzung den Bedürfnissen entspricht.

Was dabei zu beachten ist: dieser Kundenkontakt sollte nicht nur in den Rewiew- oder Demonstrationsmeetings erfolgen (wobei das zumindest besser ist als nichts) sondern auch darüber hinaus. Ein Kunden- oder Benutzervertreter kann in Refinements seine Sicht der Dinge erläutern, kann Teams und Product Owner beraten welche Anforderungen dringend sind, welche einen hohen Business Value haben oder ein grosses Risiko beseitigen, kann MVPs und Prototypen begutachten, sich an Akzeptanztests beteiligen, eine Schnittstelle zu anderen Teilen seines Unternehmens bilden, etc.

Um das Verständnis zu klären: der On Site Customer ist nicht notwendigerweise eine immer gleiche Person, es kann auch sein, dass es mehrere gibt die sich in dieser Rolle abwechseln oder gemeinsam erscheinen. Es kann sogar sein, dass das Umsetzungsteam komplett zu den Kunden/Nutzern zieht und dort eingebettet arbeitet. Im Grunde sind die Konstellationen nicht begrenzt, alles was möglich ist kann ausprobiert werden. Nur von einer Idee ist abzuraten - davon, dass nicht die eigentlichen Benutzer des Produkts zu On Site Customern werden sondern deren Vorgesetzte. Das schafft erfahrungsgemäss direkt wieder neue Kommunikationsprobleme.

Ein Sonderfall tritt ein wenn das mit der Umsetzung betraute Team ein verteiltes Team ist, also eines das nicht an einem Ort sitzt sondern geografisch verstreut angesiedelt ist. Da solche Teams in der Regel über Videokonferenzen und Screensharing kommunizieren kann man einen On Site Customer auch auf diese Weise einbinden. Dass damit Effektivitäts- und Effizienzverluste verbunden sind ist zwar richtig, allerdings sind diese dann durch Teamstruktur verursacht und nicht durch die Kunden-Kooperation.
Powered by Blogger.