Dienstag, 28. Februar 2017

Kommentierte Links (XXII)

  • 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.

Donnerstag, 23. Februar 2017

Kanban-Boards (box hide answer)

Bild: Flickr / Dennis Hamilton - CC BY 2.0
Manchmal kommen die kleinen Highlights ja unvermutet. Vor wenigen Tagen erreichte mich die Mail eines alten Studienfreundes, in der er sich unter anderem über ein Ärgernis aus seiner Arbeit aufregte. Zur Zeit ist eine Unternehmensberatung bei ihm in der Firma, die dort geradezu Ungeheuerliches macht:
Ich werde am 23.02. von einigen Consultants durchoptimiert. Die haben eine "tolle neue" Erfindung. Projektplanung und -übersicht mit Hilfe einer Tafel und Klebestickern, statt Excel-Tabellen oder MS Project. Man fasst es nicht, wofür wir Geld ausgeben...
Ich habe ihm mitgeteilt, dass diese "tollen neuen Methoden" auch zu meinem Berufsalltag gehören - bei unserer nächsten Begegnung sehe ich schon ein längeres Gespräch auf mich zukommen. In gewisser Weise in Vorbereitung darauf: warum machen wir das eigentlich, warum benutzen wir nach Möglichkeit Kanban-Boards statt Computerprogrammen?

Die Antwort darauf ist im Grunde nichts anderes als das "big Picture". Die Darstellung großer Wertströme durch verschiedene Phasen könnte man zwar auch digital umsetzen, es wäre dann aber kein Bildschirm groß genug um das alles so wiederzugeben, dass es auf einen Blick sichtbar ist. Jeder der schon einmal Excel, Jira, Redmine, Trello oder ein ähnliches Tool auf seinem Rechner gesehen hat kennt das Phänomen: immer ist irgendetwas ausserhalb des sichtbaren Bereichs. Erst durch ständiges Scrollen wird es sichtbar, wodurch sich aber andere Elemente aus dem Schirm herausbewegen. Es gibt sogar Abschnitte an denen man nur selten bis gar nicht vorbeikommt, und was dort hängt wirde gerne vergessen. Was noch dazu kommt: wenn der Rechner aus ist oder ein anderes Fenster geöffnet ist sieht man gar nichts mehr. Aus den Augen, aus dem Sinn, oder mit den Worten eines Toyota-Managers: "When you put problem in computer, box hide answer. Problem must be visible!"

Beispiele für große Boards habe ich auf meinen Projekten schon einige gehabt, und sie sind bis zu sechs Meter breit und bis zu zwei Meter hoch gewesen. Wie hätte man darauf navigieren wollen, wenn sich das irgendwo in digitaler Form befunden hätte? Wie oft hätten Aufgaben oder Probleme (zeitweise) in Vergessenheit geraten können wenn wir sie nicht permanent vor Augen gehabt hätten? Und wie wäre es uns gelungen Managern und Stakeholdern eine "schnelle Übersicht" zu geben, wenn wir dafür ewig hätten hin- und herscrollen müssen? Boards und Post Its sind zwar weder neu noch innovativ, für den Blick auf das Große Ganze aber unverzichtbar.

Montag, 20. Februar 2017

It's the business, Scrum Master

Bild: Unsplash/Olu Eletu - CC0 1.0
Beim Bonner Scrumtisch letzte Woche war meine Session diejenige mit dem wenigsten Zuspruch. Vielleicht waren die anderen interessanter, vielleicht bin ich unbeliebt, vielleicht lag es aber auch am Thema: es war "Business Value". Bei derartigen Meetups machen Scrum Master und Agile Coaches den Großteil der Teilnehmer aus, und mein Erfahrungswert ist der, dass die meisten sich bei diesem Thema nicht zuständig fühlen. Für den Business Value wird im besten Fall auf den Product Owner verwiesen (der dann oft auch untätig ist), im schlechtesten Fall heisst es "der kann für unsere Anwendung nicht berechnet werden".

Die Folgen dieser Haltung sind offensichtlich: ich habe in den letzten Jahren eine mittlere zweistellige Zahl an Scrum Teams begleiten dürfen, mir fallen aber keine fünf ein in denen Anforderungen anhand ihres Geschäftswertes priorisiert wurden1. Genau das was mit Scrum erreicht werden sollte trat dann oft nicht ein: die frühe Lieferung benutzbarer und Mehrwert schaffender Software. In den betroffenen Unternehmen wurde der Ruf der Methode dadurch beschädigt - man hatte zwar "shippable Code", der tatsächliche Mehrwert entstand aber so spät, dass behauptet werden konnte, dieser Zeitpunkt wäre mit einem Wasserfall-Vorgehen genauso schnell erreicht worden.

Ja aber, haben mir Scrum Master an dieser Stelle regelmäßig entgegnet, der Business Value liegt nun mal im Aufgabenbereich des Product Owners. Ich kann dem ja schlecht sagen wie er sein Backlog priorisieren soll, und wenn ich es doch tun würde, dann würde ich gegen die Aufgabenverteilung in Scrum verstossen. Allerdings lagen sie an dieser Stelle so falsch wie es falscher kaum sein könnte. Der Scrum Guide ist mehr als eindeutig: The Scrum Master serves the Product Owner in several ways, including [...] Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.

Machen wir uns nichts vor, diese Aufgabe ist nicht einfach. Die meisten Scrum Master die ich kenne waren ursprünglich Software-Entwickler, Teamleiter oder Projektmanager, die wenigsten haben einen betriebs- oder sonstwie -wirtschaftlichen Hintergrund. Und oft genug kommt man an eine Stelle an der man nicht weiter weiss: wie ist z.B. der Wert einer User Story mit der eine Seite von adaptive auf responsive Design umgestellt wird? Aber [Populismus on] wenn es einfach wäre könnte es jeder [/Populismus off]. Wie das im Detail aussieht ist dann nochmal ein eigenes Thema.

Wichtig ist die Erkenntnis, dass man als Scrum Master für den Business Value zuständig ist und sich daher intensiv damit beschäftigen sollte.


1Weitere haben sich von mir überreden lassen es zu versuchen, haben aber nach kurzer Zeit aufgegeben

Donnerstag, 16. Februar 2017

Ein Bild sagt mehr als 1000 Worte (XVI)

Heute wieder aus der Unterkategorie "Ein Bewegtbild sagt mehr als 1000 Worte".


Montag, 13. Februar 2017

The Soft Power of Scrum


Vor langer Zeit habe ich in meinem geisteswissenschaftlichen Studium etwas über die verschiedenen Dimensionen der Machtausübung gelernt. Vereinfacht gesagt gibt es in sozialen Systemen zwei wesentliche Möglichkeiten auf das Verhalten von Personen und Gruppen einzuwirken: man kann sie zwingen, der Begriff dafür ist Hard Power. Wesentlich effektiver ist es aber wenn die eigenen Ziele, Lösungswege und Verhaltensmuster für die Betroffenen so attraktiv sind, dass sie von sich aus gewollt werden. Diese Attraktivität wird als Soft Power bezeichnet. Das klassische Beispiel für diese beiden Dimensionen war der kalte Krieg: während die kommunistischen Staaten ihre Bevölkerung mit Polizei- und Militärgewalt in Kommunismus und Planwirtschaft zwingen mussten (Hard Power) beteiligte sich die Bevölkerung der westlichen Staaten freiwillig an Demokratie, Marktwirtschaft und Konsumkultur (Soft Power). Tatsächlich waren diese Dinge sogar so verlockend, dass auch die Menschen im Osten Wahlen, Popmusik, Hollywood-Filme und Fast Food haben wollten und sich dafür gegen die Unterdrückung auflehnten.

In Unternehmen sind die beiden Arten der Machtausübung ebenfalls anzutreffen. Hard Power entspricht hier den Wasserfall-, Top-Down- oder Command & Control-Ansätzen. Oben wird entschieden, unten wird nur ausgeführt - und wer sich dagegen auflehnt wird sanktioniert, vom Gespräch mit dem Vorgesetzten über die Abmahnung bis zur Entlassung. Die agilen Ansätze gehen dagegen von flachen Hierarchien und vom Führungsstil der Servant Leadership aus, in deren idealer Ausprägung es keine Befehlsgewalt mehr gibt. Infolgedessen ist Soft Power nötig, ohne die würden die Prozesse nicht mehr befolgt werden. Mit anderen Worten: obwohl Agilität wirtschaftliche Ziele hat (u.a. kurze Time to Market, geringe Cost of Delay) stehen in der Vermittlung häufig Mitarbeiterzufriedenheit und Mitarbeiterbindung im Vordergrund. Wenn die dazu führen, dass die agilen Vorgehensweisen befolgt werden, folgen die wirtschaftlichen Effekte von alleine.

In der Praxis sieht das so aus, dass Scrum & Co in einer Weise umgesetzt werden, die den Mitarbeitern Mitbestimmung, humane Arbeitsbelastungen und einen gewissen Coolness-Faktor bietet1. Die Teams dürfen selbst entscheiden wie viel Arbeit sie realistisch leisten können, unklare Anforderungen dürfen abgelehnt werden, Kunden und Stakeholder sind direkt erreichbar und werden nicht durch eine Management-Schicht ferngehalten. Zusätzlich dazu gibt es eine kreativitätsfördernde, Startup-ähnliche Atmosphäre mit Standup-Meetings, bunten Post Its an großen Boards und vielen spielerischen Elementen (bestes Beispiel ist das Estimation Poker). Das fördert nicht nur das Engagement und Commitment in den Teams sondern strahlt auch nach aussen ab. Genau wie die Menschen im Kommunismus sich nach dem westlichen Way of Life sehnten würden viele der "klassisch" arbeitenden Kollegen am liebsten ebenfall sofort "agil werden" wenn sie die damit verbundenen Arbeitsbedingungen sehen.

Die Herausforderung dieser Situation besteht darin, auch das Management mitzunehmen. Ohne Befehlsgewalt und Kontrollmacht haben viele Manager das Gefühl, dass die Situation unkontrollierbar und stressig wird - die Soft Power wirkt hier nicht mehr so wie auf den unteren Ebenen. An dieser Stelle muss die Vermittlung rationaler und zahlengetriebener werden und die wirtschaftlichen Effekte müssen in den Vordergrund treten. Zum Glück liefern aber auch die ausreichend gute Argumente für mehr Agilität.


1Wobei die beiden ersten ausserdem noch zu Effizienz und Produktivität beitragen

Donnerstag, 9. Februar 2017

The agile Bookshelf: Turn the Ship around

Bild: Wikimedia Commons / US Navy - Public Domain

Obwohl es erst wenige Jahre alt ist dürfte Turn the Ship Around von David Marquet bereits zu den grossen Klassikern gehören, die Managern auf der Suche nach ihrer Rolle in einem agilen Unternehmen empfohlen werden. Darüber hinaus ist es aber auch für andere Hierarchieebenen und sogar für "interessierte Laien" geeignet, da es ein grosses Kuststück fertigbringt - sowohl der Ist-Zustand in grossen Organisationen als auch die Gründe warum er sich ändern muss und die Art wie das gelingen kann werden hier einfach verständlich erklärt.


Das beginnt bereits bereits beim Hintergrund von Marquet. Als ehemaliger Kapitän des amerikanischen Atom-U-Boots USS Santa Fe kommt er nicht unbedingt aus einem Umfeld das für Delegation von Verantwortung oder Führung auf Auganhöhe bekannt ist, dafür aber aus einem von dem sich viele Menschen ein zumindest ungefähres Bild machen können, sowohl die US Navy als auch das Leben auf Unterseebooten sind schliesslich aus zahlreichen Filmen und Fernsehserien bekannt.


Durch zahlreiche Anekdoten aus dieser besonderen Welt erhält man als Leser dieses Buches Einblicke darin wie sie im Detail funktioniert und auch darin warum klassische Command & Control-Strukturen hier problematisch sein können. Das beginnt bei Soldaten die auch widersinnige Befehle unhinterfragt ausführen, geht weiter mit Offizieren deren Expertise ungenutzt bleibt weil sie nur noch die Einhaltung von zentral vorgegebenen Vorschriften überwachen und endet mit einer Führungebene der oft zu spät klar wird, dass ihre Ideen sich nicht wie gedacht umsetzen lassen.


Marquet arbeitet an vielen Beispielen die Ursachen für diese Missstände heraus, unter anderem an diesem hier: da im Voraus nicht bekannt sein kann welche Informationen die mittleren Hierarchie-Ebenen haben sind Top-Down verfasst Pläne oft sehr detailliert, um sicherzugehen, dass nichts vergessen wird. Die Mittelebene kann dadurch kaum noch etwas selbst entscheiden, was zur Verkümmerung geistiger Fähigkeiten führt, aber auch zum Verlust des Respekts durch die untere Ebene, die in ihren derartigen direkten Vorgesetzten eher Bürokraten als Anführer sieht. Als Folge schwindet die Disziplin.


Alleine das Aufzeigen derartiger Zusammenhänge ist erhellend, darüber hinaus erfährt man aber auch wie auf der USS Santa Fe an ihrer Verbesserung gearbeitet wurde. Dazu gehören zahlreiche verschiedene Praktiken die auf allen Hierarchie-Ebenen abgeschafft und eingeführt wurden, einen wesentlichen Teil nimmt aber auch ein wie der Kapitän als oberste Führungskraft seinen eigenen Führungsstil ändern musste um seiner Mannschaft besseres Arbeiten zu ermöglichen. Dabei werden auch eigene Fehler genannt und welche Lerneffekte sich aus ihnen ergaben.


Selbst wenn Marquets Umfeld mit einem Atom-U-Boot ein sehr spezielles ist - die Phänomene, Lehren und Massnahmen die er in seinem Buch beschreibt sind allgemeingültig und auf nahezu jeden grösseren Organisationskontext übertragbar. Und auch von seiner anschliessenden Beraterkarriere kann man profitieren, da er zu vielen seiner Prozessverbesserungen auch Anregungen mitgibt wie man sie sie selbst umsetzen kann, wenn auch das eigene Schiff die Fahrtrichtung ändern soll.

Montag, 6. Februar 2017

Neusprech

Bild: Flickr/Gage Skimore - CC BY-SA 2.0
Zu den vielen verstörenden Aspekten der neuen amerikanischen Regierung gehört deren Umgang mit der Wahrheit. Bereits während der ersten Tage im Amt haben Präsident Trump und seine Leute nicht nur offen die Unwahrheit gesagt, es gab auch den Versuch das ganze Konzept von Wahrheit und Unwahrheit so umzudeuten, dass es nicht mehr brauchbar ist. Konkret handelt es sich um die Umbenennung von erkennbaren Falschaussagen in "alternative Fakten" durch Trumps Beraterin Kellyanne Conway. Ein derartiger Missbrauch der Sprache macht eine ernsthafte Beschäftigung mit diesem Thema unmöglich. Die irgendwann auf Trump folgende nächste Regierung muss nicht nur Vertrauen und Glaubwürdigkeit wiederherstellen, sie wird auch bestimmte Begriffe (z.B. das Wort "Fakten") zu ihrer ursprünglichen Bedeutung zurückführen müssen, damit das überhaupt möglich ist.

Genug von der Politik. Was mich an der Thematik des Umdeutens eigentlich klarer Begriffe sofort gefesselt hat war, dass sie auch in meinem beruflichen Umfeld regelmässig auftritt. Auch hier sind zentrale Aspekte mitunter nicht mehr diskutierbar, solange man nicht aufhört die sie beschreibenden Worte falsch zu verwenden. Ein Beispiel das mir in mehreren Unternehmen begegnet ist war die "Transparenz". Eigentlich verbirgt sich dahinter die freie Zugänglichkeit von Informationen über den aktuellen Sachstand (sei es der Stand der Umsetzungen oder der Stand der Planungen). Dort wurde jedoch etwas anderes darunter verstanden: Transparenz bedeutete, dass man im Detail sagen konnte in welchem Zustand sich ein Projekt zu einem bestimmten Zeitpunkt in der Zukunft befinden würde (z.B. in einem Jahr).

Auch andere Umdeutungen durfte ich erleben: ein Klassiker sind die mitunter recht wilden Beschreibungen von Agilität: Agilität bedeutet, dass nicht geplant wird, Agilität bedeutet, dass nicht dokumentiert wird, Agilität bedeutet, dass nicht getestet wird, Agilität bedeutet, dass Change Requests kein Geld mehr kosten. Weitere Klassiker wären Qualität (umgedeutet zu Dokumentation), Planung (umgedeutet zum Zukunft vorhersagen) oder Produktivität (umgedeutet zum Produzieren möglichst vieler Lines of Code). Natürlich ist das alles Unsinn, aber gefährlicher Unsinn. Wenn das Management (oder auch nur Teile davon) ihn glauben sind Verbesserungsmassnahmen kaum noch möglich, denn Unterhaltungen laufen dann so: "Transparenz? Funktioniert mit Agil nicht.", "Agilität? Ist Mist, aufs Testen verzichten wir nicht.", "Qualität? Mehr als jetzt geht nicht, wir dokumentieren schon alles."

Wenn solche Unternehmen wirklich besser werden wollen führt kein Weg daran vorbei, in einem der ersten Schritte die Sprache zu bereinigen. Egal wie viel Tradition bestimmte Begriffsverwendungen haben - wenn man sie nicht loswird werden sie hartnäckige Hindernisse für jeden Fortschritt sein.

Freitag, 3. Februar 2017

"Was war gut" als Thema für Retrospektiven

Bild: Flickr/Aldo Rodrigo Sanchez Gonzalez - CC BY-SA 2.0
Das vermutlich häufigste Format für Sprint-Retrospektiven ist die Diskussion der beiden Fragen "Was war gut?" und "Was können wir besser machen?"1 Auch ich habe dieses Format diese Woche benutzt, woraus sich eine weitergehende Diskussion mit dem Team entwickelt hat. Nachdem wir zu beiden Fragen Themen gesammelt hatten wollten wir sie für die Diskussion priorisieren, woraufhin zwei Entwickler meinten, dass nur die aus dem Bereich "Was können wir besser machen?"diskutiert werden sollten. Nur hier könnte man schließlich besser werden, im anderen Bereich wäre ja offensichtlich alles in bester Ordnung.

Dieses Argument habe ich bereits bei mehreren Teams hören dürfen, ich versuche aber jedesmal zu vermitteln, dass ich es nicht für valide halte. Selbst da wo alles gut gelaufen ist gibt es einiges zu besprechen. Das kann zum Beispiel dort der Fall sein wo man ein Ziel nur mit Glück erreicht hat. Von dem abhängig zu sein ist nie gut, und von ihm unabhängig zu werden ein Ziel auf das man hinarbeiten kann. Ein anderer Fall liegt vor wenn ein Erfolg auf Überstunden, Wochenendarbeit oder Ähnlichem beruht, auch das ist keine nachhaltige Lösung. Und um einen positiveren Aspekt in den Mittelpunkt zu stellen: wenn ein Erfolg auf guter Arbeit, großer Sorgfalt oder kreativen Ideen beruht kann die Retrospektive genutzt werden um sich bei den Beteiligten zu bedanken.

Den größten Nutzen sehe ich aber darin, dass man darauf hinarbeiten kann Erfolge wiederholbar zu machen. Sei es dadurch, dass man sie zur Messlatte erhebt die man auch in Zukunft erreichen will (mit anderen Worten: man betreibt Benchmarking) oder ganz einfach dadurch, dass man sich noch einmal vor Augen ruft aufgrund welcher Maßnahmen man überhaupt erfolgreich gewesen ist. Nur wenn man das benennen kann ist es nämlich möglich bewusst auf eine Wiederholung hinzuarbeiten. Ohne das ist man darauf angewiesen intuitiv die richtigen Dinge zu wiederholen, was letztendlich auch wieder nichts anderes ist als Glück zu haben.

Mein Team hat sich dann doch entschieden die Themen aus dem Bereich "Was war gut?" zu diskutieren. Das Ergebnis war, dass die in letzter Zeit besonders enge Zusammenarbeit mit Endanwendern und Stakeholdern ein großer Erfolgsfaktor gewesen ist. Um das beizubehalten und auszubauen konnten wir gleich mehrere Maßnahmen ableiten und in den nächsten Sprint einplanen. Ich bin zuversichtlich, dass wir an seinem Ende wieder einige Erfolge in der Retrospektive diskutieren können.

1Ich habe ja eine Theorie warum das so ist