Donnerstag, 15. September 2016

Scrumkoch-Zertifikat

Meine Zertifikats-Liste ist um einen imposanten Eintrag reicher: mit einer leichten Verspätung von nur neun Monaten hat Chefkoch.de mit der Verteilung der Scrumkoch-Zertifikate begonnen. Wenn das nicht ein unschlagbares Zeugnis meiner umfassenden Qualifikationen ist - was dann?

Montag, 12. September 2016

Abstimmung mit den Füssen

Bild: Unsplash / David Lee - Lizenz
Über die Jahre habe ich einige Scrum-Projekte miterlebt: große, kleine, langlebige, kurzfristige, solche an denen ich beteiligt war, solche die ich auditieren durfte und solche die ich von aussen betrachten konnte. In weit über der Hälfte von ihnen ist das Vorgehen irgendwann nicht mehr agil gewesen. Nach einer kurzen Euphoriephase wurde den Verantwortlichen der Kontrollverlust unheimlich und das Management artete immer stärker in Detailsteuerung und Detailkontrolle aus. Die vorhersehbaren Folgen - die Auslieferungszyklen wurden länger, Flaschenhälse und Silos entstanden, die Kultur wandelte sich kontinuierlich in Richtung Blaming und Cover your Ass. R.I.P. Agilität.

Sollte mir das Sorgen machen? Ja das tut es. Es zeigt, dass agile Transitionen schwer sind und häufig scheitern. Es zeigt, dass das Management häufig noch nicht bereit ist für einen Rollen- und Verhaltenswechsel. Es zeigt, dass Cargo Cult und Dark Scrum verbreitet sind und sich weiter ausbreiten. Eine ganz bestimmte Sorge habe ich allerdings nicht: die Sorge, dass Scrum grundsätzlich scheitern könnte. Selbst wenn die Mehrheit der Führungskräfte diese Methode bewusst oder unbewusst untergräbt (und ich fürchte, dass das so ist) - letztendlich sitzen sie am kürzeren Hebel. Und der Grund dafür ist der Fachkräftemangel.

Selbst wenn Scrum eigentlich ein Framework ist, dass im Wesentlichen auf Unternehmensinteressen wie kurzen Entwicklungszyklen, wenig Verschwendung und hoher Produktqualität beruht - für die meisten Entwickler ist es etwas ganz anderes. Zu ihrem Glück ist es so, dass der beste Weg zur Erreichung der gerade genannten Ziele die Selbstorganisation ist. Viel Selbstbestimmung, wenig Befehle, keine unrealistischen Deadlines und konstruktive Zusammenarbeit gehören einfach dazu wenn man Mitglied in einem Scrum-Team ist. Wer das einmal erlebt hat will in der Regel nie mehr anders arbeiten, und wenn man das alles im aktuellen Job nicht mehr haben kann, dann wartet bereits der nächste.

Bedingt durch den IT-Fachkräftemangel sind die Unternehmen gezwungen ihren potentiellen Mitarbeitern etwas zu bieten, und Scrum ist etwas womit man sich von anderen Unternehmen abheben kann. Wer den Wettbewerb um die besten Köpfe nicht verlieren will kommt gar nicht darum herum. Auf der anderen Seite vertreibt jeder Anfall von Command and Control die Mitarbeiter zunächst in die innere und dann in die äussere Emigration. Ich habe miterlebt, dass ein Unternehmen nach der Abschaffung von Scrum über die Hälfte seiner IT-Abteilung verloren hat. Und das ist kein Einzelfall.

In vielen Unternehmen ist diese Realität gedanklich noch nicht angekommen. Hier wird noch geglaubt, man könne agile Methoden per Dekret für gescheitert erklären. Ich fürchte, dass hier ein Lernen durch Schmerzen stattfinden muss bevor sich etwas ändert. Andererseits - auch das ist ja Inspect & Adapt, oder?

Donnerstag, 8. September 2016

Hardware-Scrum mit 3D-Druckern

Bild: Wikimedia Commons/Urfin7 - CC BY-SA 4.0
Zum ersten mal habe ich vor ca. einem Dreivierteljahr davon gehört, dass Airbus agile Methoden in der Hardware-Fertigung einsetzt, und zwar bei der Master of Future Administration-Veranstaltung in Berlin. Zu den Referenten dort gehörte ein Airbus-Manager, der erzählte, dass die Firma 3D-Drucker einsetzt um neue Typen von Kabinenhalterungen herzustellen. Für die Herstellung müsste nur das Design in den Drucker geladen werden, unmittelbar darauf könnte der Druck starten und nach einem Tag hätte man bereits die ersten Belastungstest-Ergebnisse auf deren Basis das Design wieder verbessert werden könnte. Ich wollte eigentlich schon damals darüber schreiben, allerdings ist mir das Thema immer wieder entfallen - bis jetzt.

Zufällig bin ich diese Woche auf einen Artikel aus dem letzten Juni gestossen, aus dem hervorgeht, dass Airbus mittlerweile ganze Flugzeuge im 3D-Druck erstellt. Konkret geht es um den "Thor" (Testing High-Tech Objectives in Reality), eine Drohne bei der bis auf den Antrieb, Fahrwerk und die Fernsteuerung bereits alles aus dem Drucker stammt. Im Grunde findet bei diesem Gerät nichts anderes statt als ein Integrationstest: nachdem die Einzelteile in der oben erwähnten Art und Weise hergestellt wurden werden sie zusammengesetzt und der Thor kann abheben. Wenn er fliegen und landen kann ohne beschädigt zu werden war der Test erfolgreich und die Bauteile können auch in kommerziellen Flugzeugen eingesetzt werden. Wenn er in der Luft auseinanderfällt entstehen selbst bei einem Totalschaden lediglich Materialkosten in Höhe von 20.000 €.

Zusammengenommen dürfte zwischen Designanpassungen und Jungfernflug bei dieser Art der Herstellung nur ein Zeitraum von wenigen Wochen liegen (bei herkömmlicher Fertigung können das Monate oder sogar Jahre sein, wie ich letztes Jahr in Berlin gelernt habe). In derartig kurzen Zeiträumen wäre es sogar möglich in Sprints zu arbeiten - Scrum in der Hardware-Fertigung also. Dadurch, dass es der Flugzeugbau ist der eine Vorreiterrolle bei der agilen Fertigung einnimmt schließt sich übrigens ein Kreis, schließlich wurde in dieser Branche bereits in den 50ern iterativ-inkremental development (IID) eingesetzt, einer der frühesten Vorläufer agiler Methoden. Um es mit einem meiner Liebliengslieder zu sagen: It's all just a little bit of history repeating.

Montag, 5. September 2016

Neurowissenschaften und Agilität

Beta-Blocker, Spiegelneuronen, Melatonin, Cortisol und Herzratenvariabilität - zunächst sollte man nicht denken, dass diese Themen mit der Agilität in Unternehmen zu tun haben. Dass dem doch so ist wird in diesem Vortrag herausgearbeitet, der dadurch einige völlig neue Blickwinkel öffnet. Sehenswert.

Mittwoch, 31. August 2016

Kommentierte Links (XVI)

Grafik: Pixabay / Geralt - Lizenz

Ethan Bernstein, John Bunch, Niko Canner, Michael Lee: Beyond the Holocracy Hype

Mal wieder ein Longread. Man lernt hier viel über Holocracy, eine Management-Methode die dort ansetzt wo Scrum aufhört: in den höheren Ebenen mittlerer und größerer Unternehmen. Statt fester Manager-Positionen gibt es hier flexible Rollen, die je nach Bedarf von unterschiedlichen Personen wahrgenommen werden können, wodurch eine Entkoppelung von Entscheidungs- und Umsetzungsebene verhindert wird. Über die bloße Erklärung der Rollen und Prozesse werden aber auch Grenzen aufgezeigt, bis zu dem Punkt an dem Mitarbeiter kündigen weil sie sich in den neuen Strukturen nicht mehr wiederfinden.

Lars Jensen: Ein Blatt wendet sich

Die Washington Post dürfte zur Zeit wohl eines der weltweit spannendsten Medien-Experimente sein. Seit der Übernahme durch den Amazon-Gründer Jeff Bezos wird dort in einer Art gearbeitet die sich in vieler Hinsicht an die agilen Frameworks anlehnt: datengetrieben, mit A/B-Tests, kurzen Feedback-Zyklen und IT-gestützten Prozessen. Von der Realität in den deutschen Redaktionen ist das noch Lichtjahre entfernt, bietet aber einen Blick auf eine Zukunft wie sie auch hier irgendwann eintreten könnte.

Jason Little: Why Agile Breaks Your Organization (Edit: Link ist mittlerweile tot)

Die zentrale These von Jason Little beruht darauf, dass es in großen Unternehmen zwei Organisationsstrukturen gibt: eine offizielle, die in der Theorie besser funktioniert als in der Praxis, und eine inoffizielle, die den Laden am Laufen hält (die brauchbare Illegalität, zu der ich bereits etwas geschrieben habe). Im Rahmen von agilen Transitionen werden meistens aus den bisher informellen Prozessen offizielle, da in ihnen Entscheidungen immer dorthin verlagert werden wo sie in der Praxis Sinn machen. Für das Gesamtunternehmen ist das aus wirtschaftlicher Sicht gut, aus organisatorischer Sicht aber kritisch, da die Dysfunktionalität der offiziellen Prozesse jetzt offensichtlich wird.

Patrik Höglund: Hackable Projects (Code Health)

Unter "Hackable" versteht man bei Google nicht etwa, dass ein Projekt Sicherheitslücken hat, sondern dass es jederzeit leicht modifizierbar und umplanbar ist. Konkreter definiert gilt es aus technischer Sicht als hackable sobald die folgenden Kriterien erfüllt sind:
  • Developing is easy
  • Fast build
  • Good, fast tests
  • Clean code
  • Easy running + debugging
  • One-click rollbacks
Aus diesen Kriterien werden die drei Pfeiler Code Health, Debuggability und Infrastructure abgeleitet, deren Google-Definition in einer Serie von Einträgen erläutert wird. Dieser hier ist der erste und dreht sich folgerichtig um Code Health.

Red Herring: How Zalando Tech Became Berlin’s Hottest Workplace

"Radical Agility" klingt erstmal vielversprechend. Was sich anscheinend bei Zalando dahinter verbirgt ist eine Abschaffung der klassischen Abteilungs-, Bereichs- und Teamleiter mitsamt vieler dahinterstehender Kompetenzen: Teamzusammenstellung und Auswahl der Themen an denen gearbeitet wiird erfolgen jetzt beispielsweise selbstorganisiert auf der untersten Ebene. Ich habe ähnliche Konstellationen bereits erlebt, mitsamt der damit verbundenen Herausforderungen. Sich so aufzustellen ist in vieler Hinsicht schwer, aber auch in vieler Hinsicht lohnenswert.

Montag, 29. August 2016

Scaled Agile: Scrum of Scrums und Communities of Practice

Bild: Wikimedia Commons/Caroline Léna Becker - CC BY 3.0
Zu den häufigsten Problemen auf größeren Scrum-Projekten gehört die übergreifende Koordination zwischen den Entwicklungsteams. Es muss sichergestellt werden, dass Abhängigkeiten berücksichtigt werden, dass redundante Arbeit vermieden wird und dass Erkenntnisse und Erfahrungen ausgetauscht werden. Da die Koordination durch einen oder mehrere Manager zu Hierarchie, Zeitverlust und Ineffizienz führen würde (siehe hier) tauschen die Teams sich direkt aus, in Meetings die meistens unter den Namen "Scrum of Scrums" (SoS) oder "Communitiy of Practice" (CoP) stattfinden.

Scrum of Scrums

Das Scrum of Scrums dient der Identifitierung und Auflösung von Problemen und Abhängigkeiten zwischen den Teams, bzw. zwischen mehreren Teams und Kunden, Stakeholdern oder dem umgebenden Unternehmen. Beispiele wären unklar definierte Schnittstellen oder Architektur-Standards. Ein SoS sollte regelmässig, z.B. einmal pro Woche als 15-minütiges Standup-Meeting stattfinden, teilnehmen sollte ein Vertreter jedes Teams (im Idealfall weder der PO noch der Scrum Master, es kann aber ein Scrum Master als Moderator anwesend sein).1 Um die Arbeit strukturiert und transparent zu halten kann ein Scrum of Scrum ein eigenes Backlog haben, in dem die Aufgaben gesammelt, priorisiert und sequentiell abgearbeitet werden. In diesem Rahmen kann auch mit Sprints und "Aufgaben-Ownern" gearbeitet werden, wenn das für die Beteiligten sinnvoll erscheint.

Community of Practice

Eine Community of Practice hat den gegenseitigen Austausch von Erfahrungen und Best Practices zum Ziel. Da diese sich im Einzelfall sehr stark unterscheiden können sind Format, Dauer und Teilnehmerkreis nicht vorgegeben. Für eine CoP die sich mit Erfahrungswerten zu Meeting-Moderation befasst bietet sich beispielsweise ein Lean Coffee an, für eine die sich mit Programmier-Techniken befasst ein Coding-Dojo, für wieder andere ein Expertenvortrag. Teilnehmen kann jeder der Interesse hat, die hier gelernten Techniken können in die anderen Teams übernommen werden, müssen aber nicht. In vielen Unternehmen werden Communities of Practice auch als Gilden bezeichnet.

Der Expertentipp: SoS und CoP getrennt halten

Ein häufiges Antipattern ist es, diese beiden Koordinations-Meetings zu einem zusammenzulegen um dadurch Zeit zu sparen. Wer das tut hat meistens nicht verstanden, dass Scrum of Scrums und Community of Practice grundlegend verschiedene Konzepte sind, die unterschiedliche Teilnehmer und unterschiedliche Meetingformate erfordern und unterschiedliche Ergebnisse hervorbringen. Derartige Hybrid-Meetings haben ein sehr hohes Dysfunktionalitäts-Risiko, weshalb sie nach Möglichkeit vermieden werden sollten.


1Im den Skalierungsframeworks Scrum@Scale und SAFe ist die Teilnahme am Scrum of Scrums den Scrum Mastern vorbehalten, was ein häufiger Kritikpunkt an ihnen ist

Donnerstag, 25. August 2016

Jede User Story sollte beschreiben welchen Mehrwert sie erzeugt


Über die letzten Jahre habe ich mit einer mittleren zweistelligen Zahl von Product Ownern zusammengearbeitet, mit manchen nur einige Tage, mit anderen länger als ein Jahr. Es waren gute dabei, sehr gute, schlechte und durchschnittliche, aber einen Fehler haben sie früher oder später alle gemacht: das Verfassen einer User Story oder Anforderung aus der nicht hervorging welchen Mehrwert sie erzeugen sollte.

Klassische User Stories sind nach einem einheitlichen Muster aufgebaut: "Als <Person mit Rolle X> möchte ich <Aktion Y durchführen können> um <einen Mehrwert Z zu erhalten>". Bei diesem Vorgehen ist der Mehrwert offensichtlich, er ergibt sich aus dem Zwecksatz am Ende des Story-Titels. Einige meiner Product Owner wollten sich nicht auf dieses Muster einlassen, waren aber bereit die entsprechenden Informationen in die Detail-Felder zu schreiben, was etwa so aussah: Rolle: A, Funktionalität: B, Mehrwert: C. Eine weitere Möglichkeit wendet ein Kollege an mit dem ich gerade zusammenarbeite, indem er seinen Anforderungen einen "Motivations-Satz" hinzufügt: "Um den Microservice X aus dem Monolithen herauslösen zu können muss Voraussetzung Y geschaffen werden". Diese Variante macht vor allem bei Backend-lastigen Aufgaben Sinn. Zuletzt ist in einigen Fällen der Mehrwert so offensichtlich, so dass er nicht gesondert genannt werden muss, etwa im Fall "Optimierung der Seite für den Browser Q". Und hier lauert ein Risiko.

Gerade wenn ein Product Owner mit seinem Team schon seit längerem an einem Thema arbeitet sind das Verständnis untereinander und das Verständnis der Fachlichkeit häufig so gross, dass die Beteiligten glauben, der Mehrweit sei für sie eigentlich immer offensichtlich. Der Zwecksatz, bzw. die Motivation erscheint dann als ein "Schnörkel", den man "auch mal weglassen kann". Am Anfang mag das sogar stimmen, aber sobald sich diese Angewohnheit einmal einschleift sind meistens unangenehme Effekte die Folge. Einer davon kann sein, dass der Scope ausufert und "schon mal Vorarbeiten für eine spätere Story mitgemacht werden", was besonders dann ärgerlich ist wenn diese spätere Story wegpriorisiert oder nochmal umgeschrieben wird. In diesem Fall war die Arbeit umsonst. Auch das Gegenteil kann der Fall sein, etwa wenn "nur ein Minimum Viable Product umgesetzt wird", was zwar die Ressourcen schont, aber ggf. nicht ausrollbar ist weil das neue Feature nicht dem Nutzerführungs-Konzept entspricht. Und zwischen diesen beiden Grenzfällen gibt es noch zahllose Zwischen- und Misch-Typen.

Wenn der Mehrwert in einer der oben genannten Formen spezifiziert ist kann man dagegen ganz anders an die Umsetzung herangehen. Zum einen kann man sich fragen ob der Funktionsumfang für den angestrebten Mehrwert überhaupt ausreichend ist. Beispielsweise ist die Anforderung "ich möchte eine reduzierte mobile Version der Website haben" gegebenenfalls zu unspezifisch, während "ich möchte eine reduzierte mobile Version der Website haben, damit sie auch bei einer Edge-Verbindung in unter fünf Sekunden geladen wird" wesentlich klarer ist. Zum anderen gibt die Nennung des Mehrwertes dem Team ein Gefühl dafür, was im Zweifel weggelassen und nach hinten priorisiert werden kann. Auch hier ein Beispiel: die Story "Als Kunde möchte ich Vorschau-Kacheln mit möglichen Ersatzartikeln sehen" lässt nicht erkennen was auf diesen Kacheln abgebildet sein soll; die Versuchung ist groß dort mehr abzubilden als eigentlich nötig. Im Fall der Story "Als Kunde möchte ich Vorschau-Kacheln mit möglichen Ersatzartikeln sehen, damit ich die Preise vergleichen kann" ist die Lage wesentlich klarer. Produktname, Vorschaubild, Preis - mehr braucht es nicht um den angestrebten Mehrwert zu erreichen.

Zuletzt kann auch ein ganz spezieller Fall auftreten: ich habe es auch schon erlebt, dass Product Owner mir gar nicht sagen konnten welchen Mehrwert eine Story mit sich bringt. Die sind mir ehrlich gesagt sogar die liebsten - man kann sie einfach weglassen und kommt dadurch schneller voran als gedacht.

Montag, 22. August 2016

Trost für den 'gescheiterten' Scrum Master

Bild: Flickr/Gage Skidmore - CC BY-SA 2.0
Nicht alle agilen Transitionen sind erfolgreich. Immer wieder kommt es zu Rollbacks Richtung Wasserfall, aus den verschiedensten Gründen: kontrollwütiges Management, Angst vor zu viel Transparenz, Dokumentationsverliebtheit, Bürokratie-Fetischismus, you name it. Am schwierigsten ist ein solcher Fehlschlag fast immer für den Scrum Master (wenn er denn nicht selbst Ursache dafür ist), denn als Change Agent ist es eigentlich seine Aufgabe die Transition voranzutreiben. Wenn ihm das nicht gelingt fühlt es sich häufig wie ein Scheitern an. Ich habe schon mehrfach dazu beigetragen derartig "gescheiterte" Kollegen wieder aufzubauen, indem ich ihnen klar gemacht habe, dass keineswegs "alles umsonst" gewesen ist. Denn selbst wenn ganze Projekte oder Abteilungen zurück ins Command & Control kippen bleibt doch etwas zurück, nämlich in den Köpfen der Mitarbeiter.

Wer jemals in einem auch nur halbwegs vernünftig umgesetzten Scrum-Umfeld gearbeitet hat, der hat Vieles kennengelernt was traditionell geführte Firmen viel zu selten bieten: selbstbestimmtes und angstfreies Arbeiten, Focus auf Produktentwicklung statt auf Einhaltung von Vorschriften, Respekt vor Kunden und Kollegen, Offenheit, Transparenz sowie die Bereitschaft Fehler einzugestehen und zu korrigieren. Wer einmal Teil einer solchen Welt war wird immer danach streben sie erneut wahr werden zu lassen, wird sinnlose Vorschriften und Prozesse in Frage stellen, Mut und Ehrlichkeit einfordern und zur Not mit den Füssen abstimmen und sich nach einem besseren Job umsehen - in Zeiten des Fachkräftemangels ein starkes Druckmittel. Allein dieses Mindset geweckt und gefördert zu haben ist ein Erfolg, denn in je mehr Köpfen es sich befindet, desto stärker wird die Transition vorangetrieben, und zwar in ganzen Branchen, nicht nur in einzelnen Projekten.

An aufbauende Worte dieser Art habe ich am Wochenende denken müssen. Zum Hintergrund: in den USA ist letzte Woche eine der vermutlich gesellschaftlich wichtigsten Fernsehsendungen wegen schlechten Quoten abgesetzt worden: die Nightly Show with Larry Wilmore - eine Sendung die die Diskussion über Ungleichheit und Diskriminierung in den Mittelpunkt des öffentlichen Diskurses brachte. In ihrer letzten Ausgabe trat der Satiriker und Aktivist Jon Stewart auf, der genau den oben genannten Aspekt betonte: wer es geschafft hat ein relevantes Thema auf die öffentliche Agenda zu setzen der ist erfolgreich gewesen, selbst dann wenn er sich aufgrund eines Rückschlages ein neues Forum suchen muss. Denn auch ohne ihn wird die öffentliche Debatte weitergehen und weitere Veränderungen und Verbesserungen anstossen. Da ich Stewarts Worte mehr als passend finde möchte ich sie hier wiedergeben:
"Did you resonate with an audience? I would say not only that, but in an important way, in a way that you don't realize yet and won't reveal itself for years to come, and it's this: You started a conversation that was not on television when you began. And you worked with a group of people who you invited to that conversation to collaborate with you, to sharpen that conversation, and what you don't realize is, you walk out of this room, and that conversation doesn't end. And all the people that you worked with are gonna take what they learned here and what they learned from you and the beautiful experience that they had, and you're going to start seeing them doing things in the business as well… you're going to watch that flourish, and that's gonna have you on it."
Man muss nur das "on television" durch "in the industry" ersetzen und hat die passende Trostrede für jeden Scrum Master der gerade das Gefühl hat gescheitert zu sein. Er ist es nicht, denn er hat zur Entstehung von etwas beigetragen das größer ist als er es selbst ahnt und länger anhalten wird als er zu hoffen wagt.
[/Pathos off]