Donnerstag, 23. März 2017

Broken Window

FS
Bild: Pixabay/Taken - CC0-1.0
Wenn kleinere Schäden an einem Objekt nicht sofort behoben werden, werden sich Menschen eingeladen fühlen weitere Beschädigungen an ihm durchzuführen. Unversehrte Objekte werden dagegen mit großer Wahrscheinlichkeit von Vandalismus verschont bleiben. Die Richtigkeit dieser Theorie wurde im Jahr 1969 vom amerikanischen Psychologen Philip Zimbardo anhand zerbrochener Fensterscheiben nachgewiesen, weshalb sie heute als Broken Windows Theory bezeichnet wird. Auch kleine Beschädigungen zu verhindern und ggf. sofort zu reparieren gilt seitdem als effektives Mittel gegen den Verfall und Niedergang von sozial gefährdeten Nachbarschaften und Stadtteilen.

Die Broken Windows Theory ist allerdings nicht auf die Stadtsoziologie beschränkt sondern lässt sich auch auf das Change Management übertragen: wenn eine neue Methode (egal ob agil oder nicht) eingeführt wird und auf den eingespielten Konzern-Anarchismus trifft entstehen häufig Schneeball-Effekte - sobald an einer Stelle die Vorgaben aufgeweicht werden folgt schnell eine zweite, eine dritte, und so weiter. Tatsächlich ist es auch schwer dagegen zu argumentieren, wenn die Betroffenen die berechtigte Frage stellen "warum müssen wir uns an alles halten und die Nachbarabteilung nicht?". Schon wird ein weiteres mal eine Ausnahme gemacht, und nochmal, und nochmal, bis von der ursprünglichen Idee nichts mehr übrig ist.

Die Alternative besteht darin, auf die Einhaltung der Regeln zu bestehen. Das führt zwar zu einer Vermeidung des Broken Window-Effekts, kann aber schnell andere ungewünschte Auswirkungen haben. In dem Moment in dem die Mitarbeiter das Gefühl haben, dass nur aus Prinzip auf Regeln bestanden wird und nicht weil sie Sinn machen, steigt der Widerstand gegen sie nämlich exponentiell an. Um das zu verhindern muss durchgehend und immer wieder aufs neue erklärt werden warum diese Regeln einen Mehrwert bringen und warum auch "pragmatische Anpassungen" nicht wirklich zielführend sind.

Ein nützlicher Nebeneffekt dieses Vorgehens ist, dass sich die zu verteidigende Methode in einem Prozess der permanenten Überprüfung befindet. Wird dieser angenommen lassen sich zwei Vorteile aus ihm ziehen: zum einen wird sichergestellt, dass der Lösungsansatz tatsächlich noch zu dem Problem passt (wenn nicht sollte man ihn abschaffen), zum anderen lassen sich so Vorgaben identifizieren die nur scheinbar auf die Methode zurückgehen, in Wirklichkeit aber optional sind (vor allem im Fall von Scrum ist das häufig der Fall). Die können ggf. wirklich weggelassen werden, wobei aber erneut klar kommuniziert werden sollte, dass das eben keine Aufweichung des vorgesehenen Vorgehens ist. Wird das vergessen tritt der Broken Window-Effekt nämlich sofort wieder ein.

Montag, 20. März 2017

How to hire an Agile Coach

FS
Bild: Flickr/Mike Mozart - CC-BY-2.0
Wenn man sich die Ausschreibungen für die Stellen von Scrum Mastern oder Agile Coaches ansieht (egal ob Festanstellung oder Freelance) sind sie fast immer nach dem selben Muster aufgebaut. Welche Rolle wird gesucht, was sind die Aufgaben, welche Qualifikationen werden erwartet, was sind die Rahmendaten. So weit so gut. Aber: Das Ganze ist in den allermeisten Fällen so allgemein gehalten, dass es auf praktisch jede andere Stellenausschreibung auch zutreffen würde. Ein Beispiel:
Gesucht: Scrum Master für ein Standardsoftware-Projekt im Banking-Umfeld

Aufgaben:
• Methodische Unterstützung eines agilen Projektteams
• Management von Hindernissen und Problemlösungsprozessen
• Moderation von Regelmeetings (Planning, Refinement, Review, Retrospektive)

Qualifikationen:
• Erfahrung als Scrum Master für Software-Entwicklungsprojekte
• Erfahrung in Moderationstechniken
• Erfahrung mit agilen Projekten in einer eher Wasserfall-geprägten Organisation
• Beherrschung der üblichen Tools (Jira, Confluence, HP ALM)
• Optional: Branchenerfahrung

Rahmendaten:
• Projektstart: asap
• Projektdauer: 6 MM++
• Einsatzort: Luxemburg
• Kapazität: Vollzeit 5 Tage, davon max 1 Remotetag
• Sprachkenntnisse: Deutsch, Englisch, optional Französisch
Alles nicht falsch, und trotzdem - alles auch nicht besonders aussagekräftig. Man kann deutlich sehen, dass hier einfach ein standardisierter Textbaustein genommen wurde, bei dem lediglich Branche und Einsatzort angepasst wurden. Welche Herausforderungen hier wirklich warten kann man bestenfalls erahnen. Gerade das wäre aber eigentlich der zentrale Punkt. In einem stark Nachfrage-orientierten Markt sollte man hervorheben warum die zu vergebende Position besonders interessant oder anspruchsvoll ist, nur so zieht man die richtigen Leute an. Und umgekehrt sollte auch zumindest zu erahnen sein ob es ein "Pain in the ass-Job" ist, sonst ist der gefundene Kandidat schnell wieder weg und die Suche muss wieder von vorne beginnen.

Wie man es besser machen kann zeigt eine Ausschreibung die ich vor ein paar Monaten erhalten habe. Offen, ehrlich, anspruchsvoll, individuell und spezifisch. So sah sie aus:
Gesucht: Agile Coach für ein Unternehmen der Energiewirtschaft

Aufgabenstellung:
Das Team hat sich vor einem Jahr entschieden ohne externe Unterstützung auf Scrum umzusteigen. Rückblickend betrachtet keine gute Entscheidung, ein Audit hat ergeben, dass die Methode unvollständig und zum Teil fehlerhaft umgesetzt wurde. Die gelieferten Ergebnisse entsprechen folgerichtig nicht den Erwartungen. Gesucht wird ein Agile Coach der diese Mißstände erkennen und benennen kann, bei ihrer Beseitigung hilft und das Team und die Stakeholder aus ihrer Frustration herausführt.

Qualifikationen:
• Langjährige Erfahrung als Agile Coach oder Scrum Master in komplexen Team-Setups
• Erfahrung in der Restrukturierung fehlerhafter Scrum-Implementationen
• Hohe Methodenkompetenz in Moderation und Konfliktlösung
• Hohe Methodenkompetenz in der Motivation von Teams und Einzelpersonen
• Gute Kommunikations- und Präsentations-Skills
• Starke Persönlichkeit und hohes Durchsetzungsvermögen
• Belastbarkeit und Stressresistenz
• Optional: Erfahrung im Bereich agiles Testen/Testautomatisierung

Rahmendaten:
• Projektstart: asap
• Projektdauer: 10 MM++
• Einsatzort: Frankfurt
• Kapazität: Vollzeit, 5 Tage vor Ort
• Sprachkenntnisse: Deutsch
Ein Knaller. Man muss die Ausschreibung nur einmal lesen und weiss sofort worum es geht: hier wurde beim potentiellen Kunden in großem Maßstab Mist gebaut, der Job wird wirklich, wirklich anstrengend. Aber - wenn man auf der Suche nach einer echten Herausforderung ist und sich einen großen Namen machen will ist man hier genau richtig. Unabhängig davon, dass die Situation sicherlich ein Extremfall ist - mit der offenen Kommunikation der Problemstellung und der in diesem konkreten Fall nötigen Skills ist das hier ein positiver Ausnahmefall. Würden Ausschreibungen immer so formuliert sein würden offene Positionen deutlich besser besetzt werden als es heute häufig der Fall ist.

Donnerstag, 16. März 2017

Scaled Agile: Integrations-Teams

FS
Bild: Flickr/Craig Anderson - CC-BY-SA-2.0
Lange Zeit war die Scrum-Welt einfach. Wann immer es darum ging, dass irgendjemand die vielen Rollen der alten Welt in die neue Welt übertragen wollte konnte man auf den Scrum Guide verweisen: es gibt den Product Owner, es gibt den Scrum Master und es gibt das Entwicklungsteam, in dem alle anderen Personen einfache Mitglieder sind. Wie der Guide so schön sagt: Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment. Punkt.

Seit eineinhalb Jahren ist die Sache aber nicht mehr ganz so klar, denn mit dem Nexus-Framework von Ken Schwaber und Scrum.org gibt es erstmals einen Skalierungsansatz der von einem der Verfasser von Scrum stammt, der damit also "quasi-offiziell" ist. Und in dem taucht auf einmal etwas Neues auf, das Integrations-Scrum Team (offiziell "Nexus Integration Team"). Ein Team mit Product Owner, Scrum Master und Team-Mitgliedern, das dafür sorgen soll, dass die Ergebnisse der anderen Teams zusammenpassen. Was jetzt passiert ist war erwartbar - plötzlich kleben sich alle mittleren Manager und Koordinatoren dieses Label auf: die Architekten? Sind ein Integrations-Team. Das Testmanagemet? Ist ein Integrations-Team. Das Rollout-Management? Ist ein Integrations-Team. Und so weiter.

Natürlich ist das nicht das was Nexus will. Nexus Teams sind volatil, sie setzen sich bei Bedarf neu zusammen, ihre Mitglieder arbeiten in den normalen Scrum Teams mit wenn sie dort gebraucht werden und versuchen so viel wie möglich von ihrem Wissen dorthin zu verlagern. Auch der Nexus Guide ist eindeutig: Nexus Integration Team Members ensure that practices and tools are implemented, understood, and used to detect dependencies, and frequently integrate all artifacts to a definition of “Done.” Nexus Integration Team Members are responsible for coaching and guiding the Scrum Teams in a Nexus to acquire, implement, and learn these practices and tools. Machen wir uns nichts vor - das ist nichts was klassische Management-Teams tun, egal wie sie sich jetzt nennen.

 Was soll man also jetzt machen? Diesen "Etikettenschwindel" enttarnen? Ihn anprangern? Ihn bekämpfen? Vielleicht. Ich würde aber das Gegenteil empfehlen: ihn willkommen zu heissen. Ein unterschätzter Effekt der Selbst-Deklaration zu einem (speziellen) Scrum Team ist nämlich, dass agiles Arbeiten auch dort Einzug hält. Auf einmal müssen auch Architekten, Testmanager, Rollout-Manager und ähnliche Rollen mindestens einmal pro Monat Ergebnisse abliefern. Auf einmal müssen auch sie diese Ergebnisse in Reviews präsentieren. Und auf einmal müssen auch sie sich dem Feedback ihrer Stakeholder stellen - zu denen auch die "einfachen" Scrum Teams gehören. Populistisch gesagt - sie müssen herabsteigen aus ihrem Elfenbeinturm.

Ich korrigiere den letzten Satz. Sie dürfen herabsteigen aus ihrem Elfenbeinturm. Zu denjenigen die am meisten unter ihrer Realitätsferne gelitten haben gehören nämlich die mittleren Manager und Koordinatoren selbst. Statt nur theoretische Konzepte zu entwerfen dürfen sie selbst an der Umsetzung teilhaben. Statt nur final (wenn es oft zu spät ist) Abnahmen durchzuführen können sie frühes Feedback geben und nehmen. Ich habe viele Fälle erlebt in denen die Betroffenen von dieser neuen Art der Zusammenarbeit begeistert waren. Natürlich, es gibt auch Personen die lieber weitergemacht hätten wie bisher und jetzt destruktiv reagieren. Aus meiner (subjektiven) Erfahrung würde ich aber sagen, dass sie die deutliche Minderheit sind.

Montag, 13. März 2017

Remote-Arbeit passt nicht zu agiler Software-Entwicklung

FS
Bild: Startup Stockphotos - CC0-1.0
Eine mitgenommenes Thema vom Barcamp Bonn: die Vereinbarkeit von agiler Software-Entwicklung und Remote-Arbeit. Die Aussage aller Anwesenden - sie ist gering, zumindest wenn man an der hohen Produktivität interessiert ist, wegen der man diese Methoden überhaupt anwendet. Das ist für viele überraschend, da Heimarbeit als irgendwie modern gilt und Scrum & Co auch, weshalb automatisch davon ausgegangen wird, dass beides harmonieren müsste. Tatsächlich sorgt eine Kombination aber eher für Probleme.

Der Grund ist einfach: wenn in kurzen Abständen von 1 - 3 Wochen funktionierende Software erzeugt werden soll, muss während der Arbeitsvorgänge eine schnelle und unkomplizierte Kommunikation möglich sein. Selbst wenn jeder Informationsaustausch um nur 30 Minuten verzögert würde gingen dadurch in Summe ganze Tage verloren - aufgrund der kurzen Zyklen ein zu großer Zeitverlust. Das Ziel muss also sein, die Zusammenarbeit so zu gestalten, dass diese Verluste so weit wie möglich minimiert werden. Dafür gibt es eigentlich nur eine Lösung: Colocation, also das gemeinsame Arbeiten in einem Raum.

Zusammensitzende Teams können Informationen auf die einfachste denkbare Art und Weise verteilen - sie reden miteinander. Ohne Mails, ohne Videokonferenzen, ohne Telefon, ohne Chat. Dass das in einem gemeinsamen Raum auch alle anderen mitbekommen wird nicht nur toleriert sondern ist sogar notwendig: wäre das nicht der Fall müsste man ggf. alle anderen im Anschluss benachrichtigen oder um ihre Meinung bitten, mit erneuten Zeitverlusten als Folge. Natürlich erfordert es Disziplin und Focus, damit nicht ein permanenter Lärmpegel entsteht, erfahrene Teams sind dazu aber in der Lage.

In vielen Firmen kollidiert diese Art zu arbeiten mit Bestrebungen, durch Heimarbeit Büroflächen einzusparen. Letztendlich muss aber klar sein, dass diese Einsparungen nur scheinbare sind. Wer weniger Miete zahlt, dafür aber deutlich an Produktivität verliert, hat seine Situation nicht wirklich verbessert.

Donnerstag, 9. März 2017

Resilience and Antifragility (and Einheit)

FS
Man kennt das: Man klickt auf einen Link, sieht ein Video, ist irgendwie fasziniert und schaut es sich bis zum Ende an. In diesem Fall eine Stunde und zwanzig Minuten.



Was mich auf der Stelle gefesselt hat ist wohl die unwahrscheinliche Kombination dreier Faktoren: des Themas der resilienten und antifragilen Organisationen, des gleichsam faszinierenden wie undefinierbaren Dialekts von David J. Anderson und last but not least des Sakkos von Uli Stieleke, das irgendwie seinen Weg nach Kalifornien gefunden hat. Ein Gesamtkunstwerk.

Montag, 6. März 2017

Deine Muda (ist gar keine)

FS
Bild: Wikimedia Commons - Public Domain
In den seltensten Fällen ist "Agilität" die erste Methode die meine Kunden bei sich eingeführt haben1. Meistens gab es bereits vorher Transitionsversuche, und einer der mir häufig begegnet ist der Richtung Lean Management. In den meisten Fällen ist davon nicht mehr viel übrig, sonst müsste man ja keinen neuen Versuch unternehmen (meine These: wenn Lean Management wirklich funktioniert ist Agilität bereits enthalten, zumindest wenn wir von der IT reden). Wenn überhaupt etwas geblieben ist, ist es meistens ein eher untergeordneter Aspekt, das Vermeiden von Verschwendung (warum das untergeordnet ist kann man hier nachlesen). Im Regelfall wird aber nicht einmal dieser Grundsatz richtig eingesetzt - "das ist Verschwendung" ist eher ein Totschlagargument gegen alles was man nicht versteht.

In der Initiierungsphase von Scrum- oder Kanban-Implementationen sitzen aufgrunddessen oft Stakeholder mit am Tisch für die erstmal alles Neue dem Verdacht unterliegt Verschwendung zu sein2. Plannings alle zwei Wochen? Verschwendung! Retrospektiven? Verschwendung! Backlog Refinements? Verschwendung! Reviews? Verschwendung! Und so weiter. Schließlich wird in dieser Zeit ja nichts produziert. Die Ironie der Geschichte: in anderen Kontexten könnten sie sogar recht haben, beispielsweise bei der Produktion von seriell gefertigter Hardware, oder beim Betrieb eines Callcenters. Dort wo Software entwickelt wird ist es jedoch grundlegend anders.

Anders als im Fall der beiden gerade genannten Beispiele besteht Software-Entwicklung nicht aus der Wiederholung immer gleicher Arbeitsschritte, die so effizient gestaltet sind, dass man von ihnen nicht abweichen sollte. Die kann es nur dort geben wo ein standardisiertes Produkt in hoher Stückzahl auf standardisierte Weise erstellt wird. Bei Software wäre eben das die Verschwendung - warum sollte man den Erstellungsprozess permanent wiederholen, wenn es doch ausreicht den Code einfach mit Copy & Paste zu duplizieren? Dementsprechend macht das auch niemand. Was in Software-Projekten erstellt wird sind Prototypen: noch nie zuvor hat jemand für dieses Problem und mit dieser Technologie eine Lösung gebaut. Bestenfalls gibt es ähnliche Probleme, deren Lösungen man "nur noch" anpassen muss - auch das ist dann aber wieder prototypisch.

Aber heisst das nicht, dass es Lean Management in der IT gar nicht geben kann? Keineswegs! Es sieht hier nur anders aus. Da im Entwicklungsprozess permanent und an allen Enden neue, bis dahin noch nicht voraussagbare Probleme auftauchen benötigt man permanente Analyse- und Lösungs-Prozesse. Diese durch verschiedene Hierarchie- oder Eskalations-Ebenen zu schicken würde zu Overhead führen: entweder wären die oben sitzenden Entscheider permenent überlastet oder es würden so viele von ihnen benötigt, dass sie sich koordinieren müssten, mit Bürokratie als Folge. Das kann also nicht der Weg sein.

Lean in diesem Kontext kann nur bedeuten: permanent auftauchende neuartige und einzigartige Probleme müssen möglichst weit unten in der Hierarchie gefunden, analysiert und behoben werden, und zwar mit möglichst individuellen Lösungen. Das ist dann aber nicht anderes regelmässiges inspect & adapt in Form von Plannings, Retrospektiven, Refinements und Reviews. Mit anderen Worten: in der IT ist Lean von Agil nicht zu trennen. Siehe oben.

Bleibt nur noch eine Frage: was soll die Überschrift dieses Artikels? Die ist ist ein Wortspiel. Sorry, aber manchmal muss das sein.


1Die Diskussion ob Agile eine Methode ich spare ich mir an dieser Stelle
2Ja, mir sind tatsächlich Leute begegnet, die Lean Management und Kanban für unvereinbar gehalten haben

Donnerstag, 2. März 2017

No Estimates

FS
Schon seit einiger Zeit habe ich versprochen etwas zum Thema No Estimates zu veröffentlichen, also zum bewussten Verzicht auf das Schätzen von Aufwand und/oder Komplexität von Arbeitspaketen. Ich mache es mir diesesmal einfach und binde hier einfach Vasco Duarte, den Begründer dieser Bewegung, ein. Praktisch: der Titel seines Vortrags, "How you can predict the release date of your project without estimating" geht auch direkt auf den größten Kritikpunkt ein, dass ohne Schätzungen keine Planung möglich wäre. Das eingebettete Video springt direkt zur 29. Minute, in der das eigentliche Thema beginnt. Wer Zeit hat kann sich auch den Teil davor ansehen, er bietet zusätzlichen Kontext.



Und btw: ich habe No Estimates bereits selbst eingesetzt, es funktioniert wirklich. Warum ich den von mir gecoachten Teams trotzdem eine Storypoint-Estimation empfehle ist ein Thema für sich, dazu schreibe ich irgendwann einen separaten Text.

Dienstag, 28. Februar 2017

Kommentierte Links (XXII)

FS
  • Thorbjørn Sigberg: Agile doesn’t scale

    Ironie der Geschichte. Eigentlich als Kritik und Beschimpfung gedacht beschreibt der Satz "Agile Methoden skalieren nicht" ziemlich genau eines ihrer Erfolgsgeheimnisse. Probleme werden hier eben nicht gelöst indem man immer weitere Ressourcen daraufkippt (dazu ein aktuelles Beispiel) sondern indem man fokussiert arbeitet, große Aufgaben in kleine herunterbricht und früh Prototypen und MVPs ausliefert. Ich würde Sigbergs Text noch ergänzen um einen weiteren Erfahrungswert: Wenn Du im kleinen Maßstab nicht lieferfähig bist, dann bist Du es im großen erst recht nicht.

  • Chris Edwards: How to Fail Your TDD Rollout and Piss Everyone Off. A Train Wreck Story

  • Diese Geschichte passt nicht nur zu TDD sondern auch zu jeder anderen agilen (oder nichtagilen) Methodeneinführung. Wenn den Leuten der Sinn der Einführung nicht klar wird werden sie alles was ihnen komisch vorkommt (und das ist sehr viel) in Frage stellen und nur zögerlich umsetzen, vielleicht auch gar nicht. Wenn das dann dazu führt, dass die neuen Ideen mit Druck oder Zwang eingeführt werden entsteht Widerstand und alles reibt sich in einem fruchtlosen Kleinkrieg auf. Aus meiner Erfahrung: erstaunlich viele Scrum Master und Coaches tun sich mit der Beantwortung dieser Sinnfragen schwer. Eine Geschichte für sich.

  • Katrina Clokie: Test Manager vs. Test Coach

    Meine Zeit als agiler Testmanager ist mittlerweile ein paar Jahre her, aber das hier kann ich unterschreiben und es entspricht dem was ich versucht habe umzusetzen. Vermutlich wäre es seinerzeit besser gewesen meine Rolle in Test Coach umzubenennen, ich bin permanent mit der Erwartungshaltung aus der umgebenden Organisation kollidiert, dass ich mich doch wie ein klassischer Testmanager benehmen sollte. Andererseits habe ich vor gar nicht zu langer Zeit mit einem "QA Coach" zusammenarbeiten müssen der in seinem Selbstverständnis alles zusammenfasste was im klassischen Testmanagement dysfunktional ist. Letztendlich ist das Verständnis wichtiger als die Bezeichnung.

  • Mark Poppenborg: Wie lautet die Spielanleitung Deines Unternehmens?

    Das hier geht mehr in Richtung Change Management, greift aber ein Grundproblem hinter den letzten beiden verlinkten Beiträgen auf: viele Menschen verhalten sich einfach nicht so wie es eigentlich sinnvoll wäre sondern sind bockig und scheinbar irrational. Was zu oft vergessen wird - dieses Verhalten hat Gründe, die sich oft in der Unternehmenskultur, bzw. in der "Spielanleitung" des Unternehmens wiederfinden. Die dann umzugestalten ist die Herausforderung, z.B. mit Culture Codes.

  • Jurgen Appelo: Stop Your “Agile” Transformation! Right. Now.

    Etwas populistisch aber im Kern richtig. Wer eine agile Transformation nach dem Copy & Paste-Muster durchführen will, der wird mit großer Wahrscheinlichkeit einen Fehlschlag hinlegen. Mein Reden. Was Appelo macht ist darüber hinaus didaktisch interessant: er bettet seine Erklärungen in popkulturelle Kontexte ein die man als 35 - 45 Jahre alter Mensch aus seiner Jugend kennt. Ein geschickter Schachzug - das ist in etwa die Altersgruppe derjenigen die heute die agilen Transformationen verantworten.
Powered by Blogger.