Donnerstag, 30. März 2017

Kommentierte Links (XXIII)

Grafik: Pixabay / Geralt - Lizenz
  • Christian Becker: Management vs. Produkt. Der ewige Kampf.

    Man lernt immer wieder dazu. Christian Becker zitiert hier aus The Art of Action, dem Buch eines Militärhistorikers namens Stephen Bungay. Basierend auf einem Organisationsmodell der preußischen Armee (woran erinnert mich das?) werden dort drei Wissenslücken beschrieben, mit denen in komplexem Umfeld operierende Organisationen konfrontiert sind:
    1. Knowledge Gap: The difference between what we would like to know and what we actually know.
    2. Alignment Gap: The difference between what we want people to do and what they actually do.
    3. Effects Gap: The difference between what we expect our actions to achieve and what they actually achieve.
    Im Grunde wäre diese Ausgangslage ideal für agile Vorgehensweisen geeignet, im klassischen Management ist aber im Regelfall das Gegenteil der Lösungsansatz - mehr Berichtspflichten, mehr Vorschriften, mehr Kontrolle. Ausführlicher steht das bei Bungay selbst.

  • Leon Tranter: The myth of culture change

  • Weise Worte von Leon Tranter: eine Unternehmenskultur kann man nicht nur durch Anordnungen ändern, dazu ist sie zu tief in den Prozessen verankert. Was bringen zum Beispiel alle Bekenntnisse zu einer Kultur der Verantwortungsübernahme und Selbstorganisation wenn immer noch die Einhaltung aller Vorgaben, Detailreporting und Gruppenkonformität verlangt werden? Im Sinne eines Function follows Form-Ansatzes geht Tranter davon aus, dass erst geänderte Arbeitsbedingungen eine neue Kultur ermöglichen, bzw. sie zum Resultat haben. Erst wenn die Mitarbeiter selbst entscheiden können (und müssen) welche Arbeit sie bis wann erledigen wollen wird sich überall die entsprechende Kultur herausbilden. Das kann man so sehen, es kollidiert aber z.T. mit anderen Sichtweisen (zum nächsten Absatz bitte).

  • Lars Vollmer: Organisationskultur ist keine Frage der Entscheidungen

    Man kann sich mit vollem Recht fragen: warum muss eine Firma immer eine einheitliche Organisationskultur haben? Sind die Menschen dafür nicht zu unterschiedlich? Und hätte das nicht zur Folge, dass ein Teil der Mitarbeiter sich immer verbiegen muss um den Erfordernissen der Firmenkultur zu entsprechen? Vollmer erklärt das hier am Beispiel von zwei unterschiedlichen Abteilungen (Elektrotechniker und Biologen), aber selbst innerhalb einzelner Abteilungen kann man die Frage stellen wie zielführend eine Einheitskultur ist. Welche Auswirkungen eine Vereinheitlichung auch da haben kann hat fast zeitgleich Sal Freudenberg unter der treffenden Überschrift When the culture becomes the cult aufgeschrieben. Nicht zum Nachmachen empfohlen.

  • Nico Rose: Der Mitarbeiter, das Versuchskaninchen?

    Menschenversuche. Klingt böse, ist aber letztendlich nichts anderes als die konsequente Umsetzung von Inspect & Adapt in der Organisationsentwicklung. Was Nico Rose hier schreibt ist nämlich State of the Art der Wissenschaft: nur durch den Vergleich mehrerer Versuchsgruppen kann man erkennen, welche Lösungsansätze funktionieren und welche nicht. Und darüber hinaus: nur durch eine zufällige Auswahl nicht eingeweihter Probanden lassen sich Laboreffekte vermeiden. In der Realität großer Organisationen dürften solche Experimente allerdings an der Geheimhaltung scheitern. Was dagegen vorkommen kann ist das Arbeiten nach verschiedenen Methoden aufgrund politischer und/oder historischer Ursachen. Auch das lässt sich auswerten: Ich habe einmal ein Nebeneinander von agilen und nichtagilen Teams erleben dürfen. Am Ende waren die agilen Teams den anderen um ein Jahr voraus.

  • Retrospective.co: Brilliant Jerks Cost More Than They Are Worth

    [Edit: Link ist mittlerweile tot]
    Vor einigen Jahren war es ein kurzzeitiger Hype bei einigen meiner Kunden "Rockstars" anzuheuern, worunter Entwickler verstanden wurden, die (angeblich) so gut waren, dass sie kritische Situationen im Alleingang retten konnten. Das Problem: sie neigten auch dann zu Alleingängen wenn das gar nicht nötig war und waren dann meistens nicht kritikfähig. Neben den in diesem Artikel genannten zersetzenden Auswirkungen auf die Arbeitsatmosphäre führte das zu verschiedenen Formen von Code Ownership. Meines Wissens nach spielen alle diese "Rockstars" heute Solotourneen.

Mittwoch, 29. März 2017

Walk the Board

Was soll ich sagen? Es ist Frühling, die Sonne scheint und ich habe ein kleines Motivationsloch was das Schreiben betrifft. Zum Glück habe ich noch ein paar Videos als Backup, diesesmal zu einem Thema das einfach scheint aber nicht immer einfach ist: wie führe ich ein Daily Standup durch? Enjoy.



Donnerstag, 23. März 2017

Broken Window

Bild: Pixabay / Taken - Lizenz
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

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: Nexus Integration Teams

Bild: Pexels / Yan Krukow - Lizenz
Lange Zeit war die Scrum-Welt einfach, zumindest wenn es um die Rollen ging. Es gab den Scrum Master, es gab den Product Owner und es gab das Entwicklungsteam. Mehr war nicht nötig, schliesslich müssen laut Scrum Guide in einem Scrum Team alle Qualifikationen vorhanden sein die nötig sind um ein Produkt zu entwickleln und zu integrieren. Wer auch immer es ist (Tester, Architekt, UX-Designer, Data Scientist, etc.) er gehört in das Entwicklungsteam. Punkt.

Seit 2015 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"), das dafür verantwortlich ist, dass die Ergebnisse der anderen Scrum Teams am Sprintende integriert werden.

Für Menschen die Erfahrungen im klassischen IT-Projektmanagement haben kann diese Rolle auf den ersten Blick bekannt erscheinen, da sie eine ähnliche Aufgabe wie die klassischen "Integratoren" hat. Deren Aufgabe ist es, den fertig entwickelten Feature- oder Komponenten-Code anderer Teams zu übernehmen, in den Master Branch zu integrieren und durch Regressionstests abzusichern. Auf den zweiten Blick arbeitet das Nexus Integration Team anders: es übernimmt diese Arbeit nicht selbst.

Die in Scrum grundlegende Regel, dass in einem Team alle Qualifikationen vorhanden sein müssen die nötig sind um ein Produkt zu entwickleln und zu integrieren gilt auch in Nexus weiter, hier wird aber das in skalierten Vorhaben häufige Phänomen berücksichtigt, dass die einzelnen Teams unterschiedlich erfahren sind. Das Integration Team soll das ausgleichen indem es die anderen Teams bei Bedarf schult, coacht oder anleitet.

Besonders das letzte kann zu dem Antipattern führen, dass sich bestehende Management- oder Koordinations-Einheiten wie z.B. die Architekten, das Test-Management oder das Release-Management zu einem Integration Team erklären (oder sich in ihm erneut herausbilden) und aus dieser Position heraus die Selbstorganisation der Scrum Teams untergraben. Um dem vorzubeugen hat auch das Integration Team einen Scrum Master, der ggf. gegensteuern soll.

Ein weiterer Mechanismus der dieser Fehlentwicklung vorbeugen soll ist die Möglichkeit, dass die Mitglieder des Integration Teams immer dann wenn sie dort gerade nichts zu tun haben in einem der anderen Scrum Teams mitarbeiten können. Dadurch wird verhindert, dass sich ein unbeschäftigter Integrationshelfer Arbeit sucht und bei sich behält die eigentlich in eines der anderen Teams gehört hätte und von da an dort fehlt und extern angefordert werden muss.

Ähnlich wir Scrum selbst dürfte auch Nexus kontinuierlich weiterentwickelt werden, man kann also davon ausgehen, dass auch das Nexus Integration Team basierend auf Umsetzungserfahrungen noch optimiert werden wird. Für eine erste Version ist es aber ein interessanter und brauchbarer Ansatz, der vielen grösseren Scrum-Projekten weiterhelfen dürfte.

Montag, 13. März 2017

Remote-Arbeit passt nicht zu agiler Software-Entwicklung

Bild: Wikimedia Commons / Fuelrefuel - CC BY-SA 3.0
Ein 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)

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)

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 nichts Anderes als 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

The Principles of No Estimates

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.
[Edit: das ursprüngliche Video wurde mittlerweile gelöscht, stattdessen ist hier ein sehr ähnliches, das kutz danach veröffentlich wurde]



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. [Nachtrag: es sind sogar drei geworden, sie sind nachzulesen hier, hier und hier, ausserdem zwei zum Thema No Estimates, hier und hier]