Donnerstag, 18. Oktober 2018

Agile Workshops

FS
Bild: Pxhere / Rawpixel - CC0 1.0
Zu den Aufgaben die ich bei verschiedenen Kunden habe gehört das Halten von Schulungen und Workshops. Einführung in die Grundlagen agilen Arbeitens, Einführungen in Scrum oder Kanban, Product Ownership, Skalierung, Backlog Management, etc. Mitunter werde ich sogar nur für einzelne derartige Veranstaltungen gebucht. Mein Anspruch ist dabei, dass der Begriff Agile Workshop in mehr als einer Hinsicht zuteffend ist: in Bezug auf den Inhalt aber auch in Bezug auf die Durchführung.

Ein agiler Workshop im Sinn der Durchführung ist in meinem Verständnis gegeben wenn noch während seiner Laufzeit auf sich ändernde Wünsche und Fragen eingegangen werden kann. Ein Exkurs Richtung Lean Startup wird gewünscht? Ein Eingehen auf alternative Schätztechniken wie #Noestimates? Fallbeispiele für Agilität ausserhalb der IT? Alles machbar, und zwar alles sofort, aus der Veranstaltung heraus.

Dass das möglich ist liegt daran, dass ich meine Schulungs- und Workshop-Inhalte in Module eingeteilt habe. Ein Modul agile Basics, ein Modul Scrum, ein Modul User Stories & Story Points, etc. Jedes dieser Module habe ich schon mehrfach durchgeführt, so dass ich es schnell parat habe. Und (in dem Kontext noch wichtiger) sie sind so geschnitten, dass sich einzelne oder mehrere von ihnen hinzufügen, ersetzen oder in ihrer Reihenfolge vertauschen lassen.

Dieses Vorgehen bietet Vorteile für beide Seiten: die Teilnehmer können auch noch kurzfristig Themenwünsche äussern, die (sofern sie nicht zu exotisch sind) sofort erfüllt werden können, für mich bietet es die Möglichkeit hohe Flexibilität mit berechenbarer Durchführung zu verbinden. Und auch ein weiterer Punkt kommt noch dazu - wenn ich interne Scrum Master oder Agile Coaches ausbilde können sie einzelne Module erlernen und nach und nach in den Workshops übernehmen.

Ganz ohne Voraussetzungen geht das natürlich nicht. Die Module muss man parat haben und man muss in der Lage sein kurzfristig zwischen ihnen hin- und herzuschalten. Die Agenda sollte kurzfristig modifizierbar sein (ich benutze Post Its, die sich einfach umhängen und austauschen lassen). Nicht zuletzt würde ich immer von den zu statischen Powerpoint-Präsentationen abraten und stattdessen im Rahmen der Veranstaltung Flipcharts bemalen und beschreiben. Alles das muss man können.

Angesichts des deutlich gesteigerten Ausmasses an Flexibilität und Kundenorientierung sind das allerdings Mühen von denen ich überzeugt bin, dass man sie auf sich nehmen sollte wenn man agile Workshops (in beiden Begriffsbedeutungen) durchführen will. Denn eine agile Wissensvermittlung die selbst nicht agil ist - wäre das nicht ein Widerspruch in sich?

Montag, 15. Oktober 2018

Ein Bild sagt mehr als 1000 Worte (XXII)

FS
Für den nächsten, der Innovationsbemühungen abbügeln will indem er davor warnt, das Rad neu zu erfinden.


Donnerstag, 11. Oktober 2018

Wo Politik herkommt und wie man sie loswird

FS
Eine kurze Bemerkung zum Kontext: in Firmen und ähnlichen Organisationen versteht man unter Politik nicht Regierungen, Parlamente und Wahlen sondern die unnötige Verkomplizierung von Abläufen durch Machtspiele und Konflikte zwischen Personen und Gruppen. Mit dieser Information im Hinterkopf: Bühne frei für Katherine Kirk.

Montag, 8. Oktober 2018

Warum niemand zum Sprint Review kommt

FS
Bild: Pixabay / Magic Desk - CC0 1.0
Es ist eine traurige Geschichte die ich schon von vielen Scrum Teams gehört habe: der Sprint ist beendet, alle Anforderungen sind umgesetzt, alles ist in einem präsentationsfähigen Zustand - aber kein einziger Stakeholder erscheint zum Review Meeting. Nach zwei Wochen Arbeit ist das frustrierend, aber es geschieht selten ohne Grund. Folgende Ursachen habe ich bereits bei verschiedenen Teams erleben dürfen:

Es gibt keine Stakeholder

So einfach ist es manchmal. Wenn z.B. die aktuellen Entwicklungsziele die Kopfgeburt eines einzelnen Topmanagers sind, die dieser gegen den Willen aller Beteiligten durchgesetzt hat, dann ist es nicht verwunderlich wenn ausser ihm keiner erscheint.

Es wurden keine Features entwickelt, sondern Komponenten

Wenn das was entwickelt wurde nicht benutzbar und bewertbar ist, warum sollte dann jemand zum Review kommen wollen? Es gibt ja nichts worüber man reden könnte (und ganz nebenbei hat dieses Vorgehen auch nicht viel mit Scrum zu tun).

Es gab kein Sprintziel / keinen Fokus im Sprint


Wenn ein Sprint kein Ziel hat sondern stattdessen unterschiedliche Anforderungen hineingestopft werden stellen viele Stakeholder die Sinnfrage. Lohnt sich ein zweistündiges Meeting wirklich, wenn für jeden nur ein Feature dabei ist, das von Interesse ist? Eher nicht.

Es ist kein Review sondern eine Demonstration

Manche Teams führen kein Sprint Review durch sondern ein Demo-Meeting. Der Unterschied: Neuerungen werden nur vorgeführt und nicht diskutiert. Wird den Stakeholdern so die Möglichkeit zum Feedback geben genommen sinkt erfahrungsgemäss die Teilnahmebereitschaft.

Es gab keine Ankündigung

Da nicht jedes Thema für jeden gleich interessant ist kommen viele Stakeholder nicht zu jedem Review. Um sie zu aktivieren hilft es, wenn die Inhalte mit einigen Tagen Vorlauf kommuniziert werden, so dass klar ist ob sich das Erscheinen lohnt.

Die Vorführung der neuen Features ist konfus oder lustlos

Wer die Teilnehmer eines Meetings nicht ernstnimmt muss sich nicht wundern wenn sie wegbleiben. Und ein nicht vorbereitetes, unstrukturiertes oder widerwillig durchgeführtes Review ist ein Zeichen, dass dieses nicht ernst nehmen stattfindet.

Es gibt keine gemeinsamen Reviews

Ein Sonderfall für Projekte oder Produkte mit mehreren Teams. Wenn es den Anschein hat, dass zu viele Meetings stattfinden neigen, Stakeholder dazu nicht mehr alle zu besuchen. Die einzelnen Reviews zusammenzulegen kann dem entgegenwirken.

---

Natürlich gibt es noch viele weitere mögliche Gründe dafür, dass Sprint Reviews schlecht besucht sind, diese hier sind mir aber vergleichsweise häufig aufgefallen. Behebt man sie ist zumindest die Wahrscheinlichkeit, dass sich weitere Teilnehmer einfinden, deutlich höher.

Freitag, 5. Oktober 2018

Red Flag Laws

FS
Bild: Wikimedia Commons / Santeri Viinamäki - CC BY-SA 4.0
Zu den vermutlich skurrilsten gesetzlichen Regelungen der Technikgeschichte gehören die so genannten Red Flag Laws, die im späten 19. Jahrhundert in Grossbritannien und Teilen der USA erlassen wurden. In ihnen wurde geregelt, dass jedem motorisierten Fahrzeug eine Aufsichtsperson vorauslaufen und dabei eine rote Fahne schwenken musste. Das zu dieser Zeit gerade erst erfundene Auto, dessen Stärke ja gerade die Geschwindigkeit war, wurde damit praktisch unbrauchbar.

Dass diese Gesetze erlassen wurden hatte natürlich einen Grund: die Parlamente befürchteten, dass von motorisierten Fahrzeugen eine erhöhte Unfallgefahr ausgehen könnte. Anders als ein Pferd würden sie schliesslich nicht von sich aus vor einem Hindernis stehen bleiben. Als die Erfahrungen zeigten, dass diese Sorge unberechtigt war, war der Schaden bereits angerichtet - andere Länder hatten sich einen technischen und wirtschaftlichen Vorsprung erarbeitet.

Das Problem der Red Flag Laws ist, dass sie zwar auf den ersten Blick wie ein Anachronismus aus einer längst vergangenen Zeit wirken, auf den zweiten aber hochaktuell sind. Der Unterschied ist nur, dass es sich heute nicht mehr um Autos handelt, die aus Sorge vor Unkontrollierbarkeit überreguliert werden, sondern um andere Aspekte des technischen oder organisatorischen Fortschritts.

Gerade in den Konstellationen agiler Transitionen sind gut gemeinte aber in ihren Auswirkungen verheerende Regulierungen häufig. Ein Product Owner der alleine Produktentscheidungen treffen darf? Den kontrolliert man besser durch ein Lenkungsgremium. Automatisierte Tests und Deployments? Nur wenn jeder von ihnen durch einen Menschen manuell überprüft wurde. Selbstorganisierte Teams wählen ihre Tools selber aus? Ja, aber nur aus denen die vorher von einer zentralen Stelle zertifiziert wurden.

Die Folgen sind die gleichen wie damals im 19. Jahrhundert: zunächst fühlt sich die Veränderung besser (weil beherrschbarer) an, aber irgendwann dämmert die Erkenntnis, dass man sich ohne Not gerade die Potentiale verbaut hat wegen derer die neuen Methoden und Techniken überhaupt eingeführt wurden. Und währenddessen sind die Wettbewerber mit weniger Berührungsängsten schon längst vorbeigezogen und haben Marktanteile übernommen.

Nach Red Flag Laws im eigenen Unternehmen zu suchen und sie abzuschaffen kann ein schmerzhafter Prozess sein, da es fast immer bedeutet, dass man sich eingestehen muss, aus bestem Willen heraus Mist gebaut zu haben. Das nicht zu tun wäre aber noch schlimmer, was man sich an einem einfachen Beispiel vor Augen führen kann: wie wäre es wohl heute um Grossbritannien bestellt wenn noch immer vor jedem Auto ein Mensch mit eine einer roten Fahne herlaufen müsste?

Dienstag, 2. Oktober 2018

Eine Entscheidungshilfe für Scrum Master-Communities

FS
Was sich in den Unterlagen der vergangenen Jahre so findet. In diesem Fall eine Entscheidungshilfe für die Scrum Master-Community eines ehemaligen Kunden. Besagte Community hatte die Tendenz sich in ausufernden Debatten darüber zu verlieren, ob ein Probem, bzw. Impediment wichtig genug wäre um die gesammelten Kraft aller Scrum Master in Anspruch zu nehmen oder nicht. Um diese Diskussionen zu verkürzen entstand das folgende Bild:
Zu den einzelnen Verzweigungen. Bereits die erste ist weniger selbstverständlich als man denken sollte. Manche Probleme lassen sich eben gar nicht lösen, beispielsweise der Baustellen-Lärm vom Nachbargrundstück. Ist das der Fall, ist jede Diskussion vergebens und man kann sie einfach sein lassen. Sie bringt nichts. Auch an der zweiten Verzweigung halten sich manche Scrum Master länger auf als es Sinn macht. Wenn jemand anders ein Problem besser lösen kann als man selbst sollte man es vertrauensvoll dorthin übergeben, beispielsweise die Überprüfung der Eingänge auf Barrierefreiheit an den Gleichstellungs-Beauftragten. Nur wenn es niemanden gibt der besser geeignet ist sollte man selbst tätig werden.1

Selbst wenn ein Problem in den eigenen Einflussbereich fällt, gibt es aber noch eine weitere Frage zu beachten: betrifft es wirklich alle Teams oder nur einen Teil von ihnen? Ist das letzte der Fall sollte man davon absehen Regeln für alle Teams einzuführen, sonst würde einigen von ihnen eine Lösung aufgenötigt für die sie kein Problem haben - es wäre Überregulierung. Ein Beispiel dafür wäre die Qualitätssicherung von Anforderungen durch die Einführung einer Definition of Ready. Betroffene Teams können sich selbst eine geben, anderen brächte sie zwar Aufwand aber keinen Mehrwert.

Entscheidungshilfen wie diese scheinen auf den ersten Blick zwar banal zu sein, trotzdem kann es Sinn machen sie im Teamraum einer Scrum Master-Community gut sichtbar aufzuhängen. Auch die besten Scrum Master können mitunter Züge von Betriebsblindheit, Helfersyndrom und Selbstüberschätzung aufweisen und Group Think entwickeln. Gegen diese Phänomene ist die oben zu sehende Grafik zwar kein Allheilmittel, sie kann aber ein Anstoss zur Selbstreflektion und zu einer realistischeren Betrachtung der Umstände sein. Oft ist das schon genug um die Situation zu verbessern.


1Es sei denn, der besser Geeignete hat keine Zeit.

Samstag, 29. September 2018

Kommentierte Links (XXXXI)

FS
  • Markus Raitner: Die modernen Hofnarren

    Einerseits ist das was Markus Raitner hier schreibt absolut richtig - dadurch dass ein Scrum Master (bis zu einem gewissen Grad) von den Konventionen und sozialen Barrieren eines Unternehmens entbunden ist kann er Dinge ansprechen die von anderen nicht angesprochen werden können. Andererseits ist eine Konstellation in der das zutrifft hochgradig dysfunktional, bedeutet es doch, dass "normale Angestellte" eben nicht die Erlaubnis haben Kritik zu üben. Der Scrum Master-Hofnarr kann demnach zwar in einer Übergangsphase seine Berechtigung haben, als ständige Institution wäre er aber ein Anzeichen dafür, dass die agile Transition gescheitert ist.

  • Trish Khoo: Make a technical debt payment plan

  • Eine grossartige Idee! Wenn die finanziellen Schulden eine passende Inspiration für die Metapher der technischen Schulden sind, dann kann auch der Abbau technischer Schulden mit einem Begriff aus dem finanziellen Umfeld beschrieben werden. Ein Rückzahlungsplan wie man ihn für die Befreiung aus erdrückenden Verbindlichkeiten benötigt macht in der IT genau so viel Sinn wie bei der Haushaltsplanung: welche Schulden sind die drängendsten und dringensten, mit welchen Schritten kann ihr Abbau angegangen werden und wer wird sich dieser Schritte annehmen? Peter Zwegat wäre begeistert.

  • Krishna Kandala: Business agility for speed to market - Applying design & agile thinking to drive consumer value

    Der beste Weg in Richtung Zukunft ist die beständige Lieferung kleiner, funktionsfähiger, Mehrwert stiftender Neuerungen und Erweiterungen. Der Versuch in wenigen, grossen, seltenen Schritten riesige Fortschritte zu erzielen macht schwerfällig und vervielfacht das mit Fehlentscheidungen einhergende Risiko. Was in der IT Common Sense ist versucht Krishna Kandala auf die Business-Welt zu übertragen. Ein zentraler Punkt seiner Überlegungen: grosse Unternehmen haben in der Regel kein Problem mit der Entwicklung neuer Ideen, sie tun sich aber sehr schwer damit, daraus vermarktbare Produkte zu machen - und zwar weil sie ihre grossen Visionen nicht in kleine Incremente herunterbrechen können.

  • Mike Cohn: What Does It Mean to Be Potentially Releasable?

    Einer der wichtigsten Sätze im Scrum Guide ist: "The increment must be in useable condition regardless of whether the Product Owner decides to release it." Was für diesen Zustand nötig ist und was nicht ist Gegenstand umfassender und beständig wiederkehrender Debatten. Die Gedanken die sich Mike Cohn hier macht umfassen vieles davon und gehen an einer wichtigen Stelle noch einen Schritt weiter - was sollte man tun wenn man merkt, dass ein Increment nicht "potentially releasable" sein wird? Sein Ratschlag: die Arbeit daran unterbrechen, bzw. beenden. Interessant ist auch was er nicht empfiehlt: den Sprint-Abbruch.

  • Ron Jeffries: XP revisited

    Einmal mehr ein typischer Ron Jeffries-Text. Sehr lang, sehr gehaltvoll, sehr zu empfehlen. Im Mittelpunkt die Frage: wenn Extreme Programming heute neu erfunden, bzw. neu eingeführt werden würde - was wären seine Kernelemente?

Dienstag, 25. September 2018

Warum Agile/Scrum ohne Testautomatisierung nicht funktioniert (III)

FS
Bild: NASA - Public Domain
Mitunter bekommt man als Agile Coach die aberwitzigsten Probleme mit. Ein derartiger Fall ist mittlerweile schon etwas her aber immer noch bemerkenswert: er dreht sich um eine Anwendung eines grossen Konzerns, deren Entwicklung irgendwie agil werden sollte, wobei aber ein nicht ganz unwesentliches Hindernis im Weg stand - die Regressionstests wurden noch weitgehend manuell durchgeführt. Es waren viele. Sehr viele.

Es handelte sich um ein System mit mehreren über die Jahrzehnte zugekauften und integrierten Teilsystemen, die durch zahlreiche Schnittstellen verbunden waren. Insgesamt 75.000 Testfälle (!) mussten jedes mal durchgeklickt werden um sicherzustellen, dass neuentwickelte Features nicht versehentlich bestehende Anwendungsteile beschädigt hatten. Eine ungeheuerliche Zahl, deren Bewältigung nur möglich war weil Offshore-Testing in irgendeinem asiatischen Land mit niedrigen Löhnen betrieben wurde.

Die Durchführung eines solchen Regressionstestzyklus dauerte etwa ein Jahr, bei den letzten Malen waren dabei jeweils knapp 7000 kritische Bugs (→ funktionale Fehler ohne möglichen Workaround) entdeckt worden. Da nach dem Beheben dieser Bugs ein weiterer Regressionstestzyklus zu lange gedauert hätte wurden die Bugfixes gleichzeitig mit neuen Features eingecheckt, was natürlich Merge-Konflikte verursachte. Die Folge war das erneute Auftreten tausender Fehler, womit der Kreislauf von neuem begann.

Warum in diesem Fall nicht einmal im Entferntesten an agile Softwareentwicklung zu denken war ist offensichtlich: ein einziges, dazu noch Bug-verseuchtes, Grossrelease pro Jahr? Das ist weit, weit, weg von der Auslieferung nutzbarer Inkremente mehrfach pro Monat. Um weitgehend fehlerfreie Anwendungen auszuliefern hätte man sogar mindestens einen Regressionstestzyklus einer Bugfix-Welle abwarten müssen, in Summe hätte es dann zwei Jahre gedauert.

Wie man denn aus dieser Situation hauskommen könnte, war die Frage. Ein nachträgliches Automatisieren der Testfälle wäre wegen fehlendem Budget nicht möglich, ob es denn andere Wege gäbe agil zu arbeiten? Als das verneint wurde war relativ schnell klar, "dass Agil wohl nicht das Richtige für uns ist." Quod erat demonstrandum. Zwei Jahre später kam es zu einem zufälligen Treffen mit einem Kollegen des Testmanagers, der sich so geäussert hatte. Mittlerweile waren es keine 75.000 Testfälle mehr. Die Zahl war deutlich höher.

Freitag, 21. September 2018

Die agile Legion

FS
Dass die Agilität einen Grossteil ihrer Ursprünge in der Kriegsführung hat ist eine jener unangenehmen Wahrheiten die man gerne verschämt unter den Tisch fallen lässt. Und doch ist es so - von den Abhandlungen des Generals von Clausewitz bis zu den selbstorganisierten mongolischen Reiterhorden des Dschingis Khan zieht sich eine lange Spur erfolgreicher militärischer Anwendungen agiler Ansätze durch die Geschichte. Ein weiterer, noch länger zurückliegender betrifft eine der bekanntesten Armeen der aller Zeiten: die römischen Legionen. Anschaulich erklärt wird es in diesem Video:



Was durch Beispiele wie dieses klarer wird: Agilität ist keine Mode, kein Hype und kein Trend, sondern ein uralter (mindestens 2000 Jahre alter) Organisationsgrundsatz: dezentrale und anpassungsfähige Organisationen sind auf Dauer den zentralisierten, auf Planerfüllung ausgerichteten überlegen, und zwar selbst dann wenn sie zu Beginn noch in einer eher unterlegenen Position waren. Spätestens dann wenn "das Terrain unwegsam wird" bringen Grösse und Kraft alleine keinen Vorteil mehr.

Montag, 17. September 2018

It's all about People

FS
Ich habe Gitte vor einigen Jahren auf einem Agile Coach Camp kennengelernt und kann bestätigen: sie umarmt Menschen, auch solche die sie nicht kennt. Das dürfte im Zusammenhang damit stehen, dass sie Agilität sehr stark von der menschlichen Seite aus betrachtet. So wie in diesem Talk.

Donnerstag, 13. September 2018

Maximum Work in Progress

FS
Bild: Flickr / Alexander Baxevanis - CC BY 2.0
Ein häufiges Problem in Organisationen jeglicher Grösse ist das Untergehen in zu viel gleichzeitig begonnener Arbeit. Das Wechseln zwischen den verschiedenen Kontexten kostet Konzentration und begünstigt Verwechselungen und darauf folgende Fehlentscheidungen, die Menge paralleler Aufgaben sorgt dafür, das Übersichtlichkeit verloren geht und die Vielzahl wartender Stakeholder führt zu Konflikten und Meeting-Overhead. Derartige Zustände müssen verhindert werden, und zum Glück gibt es dafür auch einen Lösungsansatz.

Die Menge der übernommenen Aufgaben lässt sich in den Griff bekommen indem man sich selbst eine Obergrenze setzt (das ist sowohl für einzelne Personen als auch für ganze Teams möglich). Ist diese Grenze erreicht wird kein weiteres Arbeitspaket angenommen. Erst dann wenn eine der begonnenen Tätigkeiten abgeschlossen wird kann eine neue begonnen werden. Diese Obergrenze (das Maximum Work in Progress Limit) ist ebenso einfach wie wirksam - und fast nirgendwo gelingt es sie einzuhalten.

Angesichts des wunderbar einfach anmutenden Werkzeug des Maximum Work in Progress Limit gerät schnell in Vergessenheit, dass hinter gleichzeitigem Arbeiten an zahlreichen Aufgaben in der Regel keine Fahlrässigkeit steckt sondern Notwendigkeit. In arbeitsteilig geprägten Organisationen ist fast niemand mehr in der Lage eine Aufgabe alleine abzuschliessen, immer wieder muss auf Zulieferungen, Genehmigungen, Abnahmen oder Informationen gewartet werden. Manchmal stundenlang, manchmal wochenlang, manchmal noch länger. Um in dieser Zeit nicht untätig sein zu müssen fängt man eben mit der nächsten Tätigkeit an. Und der übernächsten. Und so weiter.

Wirksame Obergrenzen bedeuten demnach in der Regel nicht, dass man sich selber diszipliniert. Wirksame Obergrenzen bedeuten, dass man sich um vorgelagerte, nachgelagerte und parallele Prozesse kümmern muss. Erst wenn die so beschleunigt werden, dass man nicht mehr gezwungen ist auf sie zu warten kann man sich auf wenige gleichzeitige Tätigkeiten beschränken ohne dadurch immer wieder in Phasen der unfreiwilligen Untätigkeit zu geraten.

Um diese Beschleunigung umgebender Prozesse zu erreichen können je nach Kontext verschiedene Massnahmen sinnvoll sein. Die Aufstockung von Ressourcen, der Abbau von Vorschriften oder die Rücknahme lokaler Optimierungen können helfen, meistens können diese Massnahmen aber nicht selbst eingeleitet werden sondern nur von den jeweils betroffenen Einheiten. Mit Glück sind diese auch dazu bereit und in der Lage, mit Pech sind sie es nicht. Es bleibt dann nur noch ein Ausweg: selber machen.

Sowohl viele der vorgelagerten Schritte (Anforderungserhebung, Design, Abstimmung) als auch nachgelagerte Tätigkeiten (Test, Rollout) können von den meisten Entwicklungteams selber übernommen werden, wenn ihnen der nötige Freiraum und die nötigen Werkzeuge gegeben werden. Das genehmigt zu bekommen ist die eigentliche Herausforderung beim Versuch ein Maximum Work in Progress zu etablieren. Und die damit verbundenen Schwierigkeiten sind der Grund dafür, dass man wirksame Obergrenzen so selten finden kann.

Montag, 10. September 2018

Der Empfangstest

FS
Bild: Wikimedia Commons / Deniz Gültekin - CC BY-SA 3.0
Eines der grössten Probleme in der Produktentwicklung ist zu geringes oder zu spätes Nutzer-Feedback zu den entwickelten Features. Zahllose Produkte sind am Markt vorbeientwickelt worden und haben nichts als finanzielle Verluste und Demoralisierung der Entwicklungsteams erzeugt. Um all das zu vermeiden gibt es nur einen Weg: einem potentiellen Kunden möglicht früh eine erste Version vorlegen und ihn nach seiner Meinung fragen.

Der klassische Weg das zu tun ist die Beauftragung eines internen oder externen Partners, der dann in den Fussgängerzonen der Grossstädte Passanten anspricht und in einen Befragungsraum bittet. In Bezug auf Professionalität und Reichweite noch immer der beste Ansatz, allerdings mit dem Nachteil behaftet, dass damit ein relativ hoher Zeitaufwand verbunden ist. Die Marktforscher müssen gebrieft werden, die Ergebnisse konsolidiert werden, etc.

Ein schnellerer und direkterer Weg ist eine "interne Marktforschung" im eigenen Unternehmen. Vor allem in grösseren Firmen mit hunderten oder tausenden von Mitarbeitern können sich so schon erste Feedbacks zu Verständlichkeit, Usability und Nachfrage ergeben, die man in die weitere Planung einfliessen lassen kann. Damit ist aber auch das Risiko verbunden, dass Betriebsblindheit in das Feedback einfliesst, da die eigenen Mitarbeiter keinen unbefangenen Blick mehr haben.

Eine gute Massnahme um dem entgegenzuwirken ist die Auswahl von Gesprächspartnern aus thematisch möglichst weit entfernten Unternehmensteilen. Bestenfalls mit einer so grossen Distanz, dass ihnen nicht nur die Entwicklungsabteilung fremd ist sondern auch die branchenspezifische Fachsprache, die bisherigen Altprodukte und der Markt mit seinen Konkurrenzanbietern.

Sehr gute Erfahrungen haben wir bei einem Kunden mit dem Empfangspersonal der verschiedenen Gebäude gemacht (für diese Interviews setzte sich schnell der Begriff "Empfangstest" durch). Die dort arbeitenden Damen und Herren standen in ihrem täglichen Alltag so weit ausserhalb der Arbeit der Produktentwicklung, dass sie einen unvoreingenommeneren und neutraleren Blick hatten als alle anderen Kollegen des Unternehmens.

Sich auf die Suche nach solchen Mitarbeitern zu machen ist hochgradig sinnvoll wenn um der Geschwindigkeit willen die ersten Nutzerbefragungen intern durchgeführt werden sollen. In den meisten Firmen gibt es auch mehr von ihnen als man denkt, man muss nur die Augen offenhalten - zum Beispiel beim Betreten des Gebäudes.

Donnerstag, 6. September 2018

Untertanenkultur

FS
Bild: Public Domain Pictures - CC0 1.0
Zu den Demonstrationen von Rechtsradikalen und "besorgten Bürgern" die in den letzten Tagen in Chemnitz stattgefunden haben ist eigentlich schon alles gesagt worden (und Politik soll auch nicht das Thema dieser Website werden). Es gibt aber einen Aspekt der gesondert herausgehoben werden kann, weil er auch über die Politik hinaus eine Bedeutung hat: die von einem Teil der Demonstranten geäussterte unspezifische Erwartung, "irgendjemand" müsste sofort "irgendetwas" tun um die Gesamtsituation zu verbessern (ein Beispiel hier).

Hinter einer solchen Erwartung stehen mehrere verschiedene Grundeinstellungen. Zum einen die, dass derjenige der sich so äussert nicht selbst aktiv werden möchte. "Jemand anders soll tätig werden, nicht ich." Paradoxerweise ist das verbunden mit einem Gefühl der Dringlichkeit. "Es muss etwas passieren, und zwar jetzt." Zuletzt ein offenes Desinteresse an einer Beteiligung an der Lösungsfindung. "Was gemacht wird interessiert mich nicht, solange dadurch alles besser wird."

Diese Grundeinstellungen sind vor allem in grossen Organisationen wie Behörden oder Konzernen immer wieder anzutreffen. Die Ursache dafür (die auch die Verbindung zu den in der DDR großgewordenen "besorgten Bürgern" bildet) ist die private und/oder berufliche Sozialisation in hierarchischen, von Befehl und Gehorsam geprägten sozialen Systemen. Man spricht in diesem Zusammenhang von einer "Untertanenkultur", einem Begriff der eine nähere Betrachtung wert ist.

Geprägt wurde er von den beiden amerikanischen Politikwissenschaftlern Gabriel Almond und Sidney Verba in ihrem Werk "The Civic Culture". Basierend auf tausenden von Interviews in mehreren von einer Untertanenkultur geprägten Ländern konnten sie aufzeigen, dass diese auf vier Annahmen beruht:
  • Der einzelne Mensch ist schwach und nichts bewirken
  • Das Gesamtsystem ist stark und kann alles erreichen
  • Der Einfluss des Einzelnen auf die Hierarchie ist winzig
  • Der Einfluss der Hierarchie auf den Einzelnen ist gewaltig
Es ist erkennbar: wer ein Weltbild hat das auf diesen vier Annahmen beruht wird fast zwangsläufig die Erwartungshaltung entwickeln, dass "die da oben" von sich aus darauf kommen müssen, wie eine als problematisch wahrgenommene Situation verbessert werden kann. passiert das nicht wird es als Systemversagen wahrgenommen, was zu Frustration und Wut führen kann.

Um die Betroffenen aus dieser Wut und Frustration in ein konstruktives Miteinander zurückzuführen ist ein Kulturwandel nötig, der in diesem Modell durch eine Widerlegung der besagten Annahmen herbeigeführt werden kann. Den Menschen muss klar werden, dass sie Gestaltungsspielraum haben, dass ihre Ideen gehört werden und dass das Gesamtsystem auf diesen Input angewiesen ist um funktionieren zu können. Das sagt sich leicht, umzusetzen ist es schwer. Aber es lohnt sich.

Wenn dieser Wandel stattfindet kann aus der Untertanenkultur (und der Erwartung "irgendjemand anders" müsste "irgendwie" alle Probleme beseitigen) eine partizipierende Kultur werden, in der jeder von sich aus dazu beiträgt, dass permanent an Verbesserungen gearbeitet wird. Dadurch wird nicht nur das Gesamtsystem leistungsfähiger, es werden auch die ihm angehörenden Menschen zufriedener. Und "besorgte Bürger" spielen dann keine Rolle mehr.

Montag, 3. September 2018

Silver bullets can hurt

FS
Ein Vortrag über eines der grössten Risiken agiler Transitionen, die Methodengläubigkeit. Die Kernaussage, die ich auch unterschreiben würde: die gängigen Methoden und Frameworks sind gute Sammlungen von verwertbarem Wissen und Erfahrungen, aber keines von ihnen ist als Problemlösung ausreichend. Werden sie mit dieser Erwartung eingeführt richten sie eher Schaden an.

Donnerstag, 30. August 2018

Kommentierte Links (XXXX)

FS
  • Steve Denning: For Agile, It's The Best And The Worst Of Times

    Der Auftakt zu einer ganzen Serie von Beiträgen über die Ankunft der Agilität im Mainstream. Interessant sind zwei Gedanken. Zum einen, dass die Agilität nach ihrem "offiziellen Startschuss" (dem agilen Manifest) 15 Jahre lang "in den Schatten gelebt hat" bevor sie von den Managern und Unternehmensberatern dieser Welt entdeckt wurde. Demzufolge wurde sie im Wesentlichen ohne diese beiden Gruppen entwickelt und ausdefiniert, was man ihr heute anmerkt: statt der Hierarchie und dem Börsenwert stellt sie den Mitarbeiter und den Kunden in den Mittelpunkt. Der andere Gedanke ist der, dass die Agilität durch ihre untrennbare Verbindung mit moderner Software-Entwicklung nur schwer korrumpierbar ist - wer heute Software zu einem vertretbaren Aufwand erstellen möchte kommt an echter Agilität nicht vorbei, wodurch sie immer wieder zurück auf die Füsse gestellt wird.

  • Lars Vollmer: Denkfehler der New‑Work‑Bewegung

  • New Work ist ein ähnlich schwammig formulierter Begriff wie Agilität, man kann sehr, sehr viel in ihn hineininterpretieren. Eine verbreitete Deutung ist die, dass man arbeiten kann was man will, wann man will und von wo man will. Das ist lange Zeit  illusorisch gewesen, und in den meisten Berufen ist es das heute noch. Nur dort wo der Fachkräftemangel die Unternehmen beutelt lassen sie sich darauf ein. Vollmer geht davon aus, dass das zwar arbeitnehmerfreundlich ist, in der Regel aber auf Kosten der Wirtschaftlichkeit und der Kundeninteressen geht. So gesehen ist New Work auch nicht kompatibel mit Agilität, was überall dort zu Problemen führt wo man versucht beides gleichzeitig einzuführen.

  • Ralph Cibis: Let's charge story points

    Die meisten agile Coaches und Practitioner betrachten es als Dogma: Story Points sind eine abstrakte, fast schon fiktive Berechnungseinheit, die weder zur Schätzung von Zeit noch zur Ermittlung von Kosten herangezogen werden darf. Wie realitätsfremd das ist zeigt sich häufig an der fehlenden Antwort darauf wofür sie dann gut sind. Ralph Cibis geht einen pragmmatischeren, wenn auch nicht unriskanten Weg - wenn den Beteiligten klar ist, dass Story Points kontextbezogen, volatil und fehlbar sind, dann sind sie als Indikator brauchbar, und zwar nicht nur für Planungen sondern auch für Preiskalkulationen. Das ist auch richtig, wird aber in der Realität meistens mit dem Customer-Vendor-Antipattern kollidieren. Funktionieren wird dieser Ansatz nur dort wo die Geschäftsbeziehungen von Ergebnisoffenheit, Respekt und Verständnis geprägt sind. Das gibt es zwar, aber ganz ehrlich - wie häufig?

  • Willem-Jan Ageling: 5 controversial topics that were removed from Scrum

    Eine Geschichtsstunde. Wie oben von Denning beschrieben haben sich agile Ansätze wie Scrum über längere Zeit im Biotop der Software-Entwicklung ausdifferenziert, wobei viele der ursprünglichen Unstimmigkeiten oder Irrwege entfernt oder korrigiert wurden. Was das bedeutet sieht man an den von Ageling aufgeführten ehemaligen Elementen von Scrum, die grösstenteils zwischen 2010 und 2013 aus den offiziellen Regeln entfernt wurden (nur die Abschaffung der verpflichtenden drei Fragen ist neueren Datums. Sie fand erst 2017 statt). Wären sie noch in Kraft würde vieles wesentlich holperiger funktionieren als es heute der Fall ist.

Montag, 27. August 2018

Deine Muda: Motion

FS
Bild: Wikimedia Commons / Roger & Renate Rössing - CC BY-SA 3.0
Vierter Teil der Deine Muda-Serie. Die dritte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Bewegung, auf Englisch Motion. Da sie häufig mit der ersten Muda (Transportation) verwechselt wird macht eine Differenzierung Sinn: unter Transportation versteht man die Bewegung von Gütern, unter Motion die Bewegung von Personen.

Dass diese Personenbewegung als nicht gewinnbringende Tätigkeit gesehen wird liegt daran, dass eine Person während sie sich bewegt nicht in der Lage ist an wertschöpfenden Tätigkeiten teilzunehmen. Wer zu Fuss, mit dem Fahrrad, dem Motorrad, der Strassenbahn oder dem Auto unterwegs ist kann währenddessen nicht arbeiten - wenn er im Auftrag der Firma reist kostet er aber Geld (Zeit/Gehalt). Bis zu einem gewissen Grad kann das in einigen Fällen ausgeglichen werden (z.B. ist arbeiten im Zug eher möglich, zumindest am Computer), auch hier geht aber Zeit durch Planung, Umsteigen, etc. verloren.

Sogar innerhalb eines Gebäudes kann dieses Problem auftreten, besonders dann wenn es sich um Hochhäuser oder weitläufige Anlagen handelt. Ein Scrum Team bei dem die Entwickler im Erdgeschoss sitzen, der PO aber im 10. Stock wäre ein solcher Fall. Ein Team das seinen Arbeitsbereich im Flügel G hat, seinen Meetingraum aber im Flügel B ein anderer. Beides sind real existierende Beispiele aus deutschen Konzernen und in beiden Fällen werden erstaunliche Zeitmengen in Fluren, in Treppenhäusern und in Fahrstühlen verbracht.

Die Besonderheit der Motion-Muda ist, dass für ihre Beseitigung zwei Ansätze möglich sind: man kann die Mitglieder eines Teams oder einer Wertschöpfungskette in einen Raum setzen (oder zumindest auf einen Flur) oder man kann versuchen sie durch digitale Lösungen zu vernetzen, etwa durch Chatprogramme, Videotelefonie und Ticket-Tools. Aus Sicht eines Agile- oder Lean-Coaches wäre Ansatz eins zu bevorzugen, da er einfachere und direkte Kommunikation ermöglicht, in den meisten grossen Organisationen findet man eher Ansatz zwei, da er mit den ohnehin an jedem Arbeitsplatz stehenden Computern einfacher umzusetzen ist.

Dort wo ernsthaft an der Reduzierung von Personenbewegung gearbeitet wird tritt übrigens ein interessanter Seiteneffekt auf: in den meisten Fällen führen diese Bemühungen dazu, dass Teams kleiner, autarker und crossfunktionaler werden. Nur dann lässt sich die Anzahl der für die tägliche Arbeit nötigen Meetings herunterfahren. Der Grossteil aller Personenbewegungen hat nämlich das gleiche Ziel: einen Meeting-Raum.

Donnerstag, 23. August 2018

(Nicht) wie Spotify werden

FS
Bild: Flickr / Jon Åslund - CC BY 2.0
Ein bemerkenswerter Trend der letzten Jahre ist der, dass sich viele Unternehmen im Rahmen ihrer agilen Transition nicht mehr amerikanische Firmen als Vorbild nehmen sondern eines aus Schweden: Spotify (ein aktuelles Beispiel hier). Wie immer in solchen Fällen gibt es mehr als einen Grund dafür, z.B. den, dass Skandinavien aus europäischer Perspektive nicht so entrückt wirkt wie das Silicon Valley, oder den, dass das Produkt von Spotify (Musikstreaming) auf den ersten Blick einfach verständlich zu sein scheint. Was aber für viele Manager verlockend besonders erscheint ist etwas anderes - das mit diesem Firmennamen verbundene Skalierungsmodell.

Der durch Präsentationen und Videos bekannt gewordene Ansatz ist scheinbar einfach: gemeinsam an einem Teilprodukt arbeitende Teams bilden einen Tribe, Spezialisten innerhalb eines Tribes bilden ein teamübergreifendes Chapter und Menschen mit gleichen Interessengebieten schliessen sich unternehmensweit zu Gilden zusammen. Die Frage wie sich agile Teams koordinieren scheint damit beantwortet zu sein: durch ihre Tribes und Chapter. Beziehungsweise (und hier wird es für mittlere Manager interessant) durch ihre Tribe Leads und Chapter Leads.

Das Problem dieses Modells: niemand kann sagen ob es wirklich dauerhaft funktionieren kann, denn es es ist selbst bei Spotify nur wenige Jahre lang umgesetzt worden - und auch das nur in der IT und nur während einer explosionsartigen Wachstumsphase, die wenige Rückschlüsse auf die Umsetzung in einem stabilen Kontext zulässt. Cliff Hazell, einer der agilen Coaches und Chapter Lead bei Spotify, hat es in einem Vortrag auf den Punkt gebracht: für seine Firma ist das Tribe/Chapter/Gilden-Modell eines von gestern (ab Minute 28:10 beschreibt er wo es mittlerweile geändert wurde).

Cliff Hazell - Be best at getting better @ LKCE17 from Lean Kanban Central Europe on Vimeo.

Kurz gesagt - wer Tribes/Chapter/Gilden bei sich einführt der wird nicht so wie Spotify, sondern höchstens so wie die IT-Abteilung dieser Firma im Zeitraum 2012 - 2014 gewesen ist. In vielen Firmen führt selbst diese Erkenntnis aber nicht dazu, dass man dieses Modell nicht mehr anstrebt, im Gegenteil. Selbst das Spotify von damals erscheint vielen Betrachtern besser als der Ist-Zustand ihres eigenen Unternehmens. Ist es nicht bereits ein ausreichendes und lohnendes Ziel diesen Zustand zu erreichen? Wäre das nicht für einen ersten Schritt genug?

Die Antwort: Jein. Selbst wenn man davon absieht, dass das Tribe/Chapter/Gilden-Modell den Beweis seiner langfristigen Funktionsfähigkeit noch schuldig geblieben ist bleiben Probleme. Dass es zeitweise in Schweden funktioniert hat liegt nämlich nicht zuletzt an der mit ihm verbundenen Systemlandschaft und Software-Architektur. Erst durch die auf Microservices beruhende technische Autonomie der einzelnen Teams konnten sich die Chapter und Gilden auf fachliche Koordination und interessenbasierten Erfahrungsautausch beschränken und konnten auf die Vorgabe und Kontrolle von technischen Standards verzichten. In der klassischen Unternehmens-IT mit ihren zahllosen Abhängigkeiten würde das meistens ins Chaos führen.

Ist Spotify also kein Vorbild? Doch, ist es, nur ganz anders als erhofft. Wie oben im Video zu sehen ist das Ziel der dortigen Firmenorganisation, sich ganz im Sinn des agilen Change Managements ständig weiterzuentwickeln und nie stabil zu werden, sich ständig anzupassen, zu verändern und zu experimentieren. Das ist sehr zur Nachahmung empfohlen. Ausgerechnet für die meisten Menschen die behaupten "wie Spotify" werden zu wollen ist das aber nicht mehr das was ihnen gefällt. Ihnen fehlt darin die (scheinbare) Einfachheit.

Montag, 20. August 2018

Zeitschätzungen, Erfahrungen und Prototypen

FS
Bild: Wikimedia Commons / W. Carter - CC0 1.0
Es ist die grosse Frage nicht nur im agilen Kontext sondern auch im Rahmen der klassischen Produktentwicklung: "Sag mir, wann wirst Du fertig sein?" Seitdem zum ersten mal in der Geschichte der Zeit ein Mensch für einen anderen eine Arbeit verrichtet hat wird sie immer wieder gestellt, und zum grossen Verdruss des Fragestellers immer wieder falsch beantwortet. "Können die nicht genauer schätzen?" folgt immer wieder als Anschlussfrage. Die tragische Antwort: Nein, können sie nicht. Zumindest nicht in IT-Projekten.

Um zu verstehen warum das so ist empfiehlt sich zuerst ein Blick auf eine Industrie in der die grosse Frage sehr genau beantwortet werden kann. Nehmen wir die Auto-Industrie. Die grossen Automobilhersteller können z.T. bis auf die Minute genau kalkulieren wie lange es dauern wird ein Fahrzeug zusammenzubauen. Warum sie das können? Weil der Fertigungsprozess hochgradig standardisiert und dadurch berechenbar ist. Wenn aber die Standardisierung der Arbeitsschritte die Lösung ist, ist das nicht der Weg zu verlässlichen Schätzungen? Nochmals die tragische Antwort: Leider nein, zumindest nicht in der IT.

Die Voraussetzung der Standardisierung ist die Erfahrung. Erst durch die weiss man welche Schritte stabil immer wieder das gleiche Ergebnis bringen wenn man sie wiederholt. Und erst durch die Erfahrung weiss man in welchem Abstand zueinender zusammengehörige Schritte gestartet werden müssen, damit die so erzeugten Teilergebnisse gleichzeitig fertigwerden und ohne Verzögerung zusammengebaut werden können. Aber war diese Erfahrung schon immer da? Natürlich nicht.

Wann auch immer eine Auto-Firma (bleiben wir beim Beispiel) zum ersten mal mit einer Produktion beginnt, fehlen zu Beginn die Erfahrungswerte - sonst wäre es kein Beginn. Aufgrunddessen sind die ersten Prognosen durch die Bank unzuverlässig und die ersten Produktionsziele werden verfehlt. Erst nach Jahren ermöglichen die Erfahrungen einen reibungslosen und planbaren Ablauf. Das war so vor einem Jahrhundert bei Ford und das ist heute so bei Tesla.

Um den Exkurs Richtung Automobil abzuschliessen: die Aufwands- und Zeitschätzungen sind dann besonders genau wenn ein identisches Produkt bereits tausendfach erzeugt wurde und dadurch viele Erfahrungswerte vorliegen. Wurde es dagegen erst wenige Male erzeugt ist die Unsicherheit und Unplanbarkeit deutlich grösser, und vorherzusagen wie lange der Bau eines Prototypen dauern wird ist schwierig bis unmöglich. Und an der Stelle schlagen wir den Bogen wieder zurück zur IT - die baut nämlich nur Prototypen. Immer. Ausschliesslich. Sonst nichts.

Wenn auf vierhundert Millionen Rechnern Windows als Betriebssystem läuft, dann wurde das dafür nicht vierhundert Millionen mal gebaut sondern nur exakt einmal. Und dieses eine einzige Betriebssystem wurde dann auf alle vierhundert Millionen Rechner aufgespielt. Alles andere wäre auch wirtschaftlich unvernünftig - warum sollte man Windows in jahrelanger Arbeit für jeden Rechner neu entwickeln, wenn man es nur einmal bauen muss und dann quasi durch Copy und Paste beliebig oft vervielfältigen kann? Das Gleiche gilt auch für jede andere Software.

Wenn aber in der IT nur Prototypen gebaut (oder erweitert) werden, und wenn der für einen Prototypen nötige Aufwand nur schwierig bis gar nicht vorhersagbar ist, dann ist die Folge genau die, die weiter oben beschrieben ist. Es lässt sich nicht genau vorhersagen wann eine Software fertig entwickelt sein wird. Tragisch aber wahr. Das bedeutet natürlich nicht, dass man dem hilflos ausgeliefert ist, es gibt Möglichkeiten damit umzugehen. Aufwandsschätzungen gehören aber nur als begleitender Indikator dazu.

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.
Powered by Blogger.