Donnerstag, 20. Juli 2017

Soziale Ursachen technischer Probleme und Lösungen

FS
Irgendwann rauschte das hier gestern durch meinen Newsfeed. Obwohl aus der Perspektive eines einzelnen Entwicklers gehalten enthält dieser Vortrag viele Ratschläge die auf Zusammenarbeit in agilen Kontexten einzahlen: veröffentliche (unfertige) Ergebnisse so früh wie möglich, arbeite früh mit anderen zusammen, sei bereit Fehler einzugestehen die von diesen anderen gefunden werden, lerne daraus, teile Dein Wissen.

Montag, 17. Juli 2017

Scaled Agile: Tribes

FS
Bild: Wikimedia Commons/Jialiang Gao - CC-BY-SA-3.0
Dass der Begriff "Tribe" in agil arbeitenden Unternehmen verbreitet geworden ist, ist wohl vor allem der Firma Spotify zu verdanken. In ihrem Skalierungsansatz ist ein Tribe eine Gruppe von Teams die an einem gemeinsamen (Teil)Produkt arbeiten. Da immer mehr andere Firmen diesen Ansatz zu kopieren versuchen lohnt sich ein näherer Blick.

Spotify-Tribes beruhen auf zwei Grundlagen: zum einen fachlicher Zusammengehörigkeit in Form des bereits genannten gemeinsamen (Teil)Produkts, zum anderen auf einer beschränkten Größe von maximal 100 Mitgliedern. Diese geht zurück auf die so genannte Dunbar-Zahl, welche die Maximalgröße einer Gruppe markiert in der alle Mitglieder noch soziale Beziehungen zueinander aufbauen können. Da diese Größenordnung vor allem in Stammesgesellschaften (soziologischer Fachbegriff: Horden) auftritt wurde bei Spotify für sie der Begriff des Stammes (Tribe) gewählt.

Tatsächlich gehen die Gemeinsamkeiten der agilen Tribes mit den Stammesgesellschften aber über die bloße Größe hinaus. Stämme gelten als größte gesellschaftliche Einheit in der eine Ranggleichheit aller Mitglieder (Akephalie) möglich ist. Das bedeutet nicht, dass es keine Führungspersonen gibt, Führung findet aber immer nur vorübergehend und durch je nach Aufgabe andere Personen statt und es ist den anderen selbst überlassen ob sie sich führen lassen wollen. Auch in selbstorganisierten agilen Teams ist das die bestmögliche Organisationsform.

Ausserdem bilden Stämme üblicherweise eine gemeinsame Kultur heraus, ein Phänomen das sich auch in agilen Tribes beobachten lässt. Wie das im Einzelnen aussieht ist von Fall zu Fall verschieden, mögliche Beispiele wären Meeting-Kultur, Gesprächskultur, Konsenskultur oder Wettbewerbskultur, aber auch technische Programmierkulturen können sich herausbilden. Beispiele hierfür wären eine Fokussierung auf Test Driven Development oder (als Antipattern) der Verzicht auf Planung oder Verbesserung.

Zuletzt sind Stämme in der Regel autark, was heisst, dass sie unabhängig von anderen Stämmen existieren und wirtschaften können. Im Fall von Spotify trifft das in technischer Hinsicht auch auf die Tribes zu, deren Anwendungen so entkoppelt sind, dass sie unabhängig von anderen entwickelt und in Produktion gebracht werden können (Microservices).

Im Alltag ist dieser theoretisch-soziologische Überbau selten präsent, in der Organisationsentwicklung sollte man von ihm zumindest gehört haben. Selbst wenn seine Übertragbarkeit Grenzen hat kann er zu einem besseren Verständnis von Gruppenprozessen und -dynamiken beitragen. Und ganz nebenbei trägt er dazu bei, dass man das Spotify Modell nicht einfach kopiert sondern sich über dessen Sinnhaftigkeit Gedanken macht.

Donnerstag, 13. Juli 2017

Wer moderiert die Scrum Meetings?

FS
Bild: Max Pixel / Freegreatpicture.com - CC0-1.0
Für viele Teams ist die Frage nach der Moderation der Scrum-Meetings klar beantwortet: das macht der Scrum Master, schließlich ist das sein Job. Dieses Missverständnis ist weit verbreitet, aber es ist eben nichts anderes als das - ein Missverständnis. Der Scrum Guide ist auch in dieser Angelegenheit klar, wenn auch auf den zweiten Blick anders als auf den ersten. Er besagt: "The Scrum Master serves the Development Team and the Product Owner in several ways, including [...] Facilitating Scrum events as requested or needed." Und das bedeutet eben nicht, dass er alle Meetings moderiert.

Der entscheidende Punkt liegt in der Formulierung "as requested or needed". Natürlich kann es sein, dass die Unterstützung des Scrum Masters angefordert wird, etwa um bei Konflikten zu vermitteln. Und natürlich kann es sein, dass seine Beteiligung notwendig ist, etwa dann wenn das Team noch unerfahren ist und sich noch nicht sicher ist welche Inhalte in welches Meeting gehören und welche nicht. Aber es kann eben auch sein, dass die Durchführung auch ohne ihn wunderbar funktioniert. In diesem Fall kann es eine Option sein sich zurückzuziehen und "Coaching from the back of the room" zu betreiben.

Wer stattdessen moderiert kann je nach Fall unterschiedlich entschieden werden. Im besten Fall bedarf es gar keiner Moderation. So sollte etwa jedes erfahrene Scrum Team in der Lage seine Daily Standups unmoderiert durchzuführen. Auch bei allen anderen Meetings ist das im Idealfall so, wobei es hier deutlich schwieriger werden kann. Spätestens wenn Personen teilnehmen, die nicht zum Team gehören (z.B. Stakeholder im Review oder Kundenverteter im Refinement) kann es hilfreich sein jemanden zu bestimmen der für Struktur sorgt.

Ein häufiger (wenn auch nicht zwingender) Ansatz ist es, den Product Owner als Moderator auszuwählen wenn Stakeholder anwesend sind mit denen er auch ausserhalb der Regelmeetings zusammenarbeitet (wie oben erwähnt kann das v.a. in Refinements und Reviews vorkommen). Seine Bekanntheit mit diesen Personen kann dabei helfen sie einzubinden oder bei Bedarf auch zu bremsen. Zudem ist es auch ein gutes Training für die Moderation von Stakeholdermeetings ausserhalb des Scrum Teams.

Bei rein internen Meetings ist es häufig so, dass auch Mitglieder des Development Teams die Moderation übernehmen. Tatsächlich ist es sogar sinnvoll das zu tun, alleine damit bei Urlaub oder Krankheit des Scrum Masters jemand in der Lage ist ihn zu vertreten. Gegebenenfalls kann das für einzelne Teammitglieder auch ein Testlauf sein um zu erkennen ob der Scrum Master Job (bzw. diese Facette dieses Jobs) etwas für sie wäre.

Zuletzt kann bei Bedarf auch jemand von ausserhalb gebeten werden die Moderation zu übernehmen, sei es um einfach einen neuen Impuls einzubringen oder sei es weil er über bestimmte Erfahrungen verfügt (z.B. die Moderation von Videokonferenzen). Das sollte allerdings nicht ohne vorherige Zustimmung des Teams passieren.

Montag, 10. Juli 2017

Ein Bild sagt mehr als 1000 Worte (XVIII)

FS
Fun Fact: bräuchte man ein Bild zur Visualisierung agiler Transformationen, es sähe genauso aus wie dieses hier. Manche Probleme sind eben verwandt miteinander.

Bild: {turnoff.us} / Daniel Stori - CC-BY-NC-ND-4.0

Donnerstag, 6. Juli 2017

Warum Scrum sich nicht ständig ändert

FS
Bild: Flickr / Ignacio Palomo Duarte - CC-BY-2.0
Von Zeit zu Zeit gibt es Links die geballt in meiner Timeline auftauchen, anscheinend also bei vielen Menschen einen Nerv treffen. In den letzten Tagen war es wieder soweit und diesesmal war es dieser Artikel der immer wieder geteilt wurde: Agile Methodologies Are Not Agile von Jurgen Appelo. Die zentrale Aussage ist, dass agile Frameworks wie Scrum, SAFe und Holocracy selbst nicht agil sind, da sie lediglich in Rhythmen von mehreren Jahren upgedated werden. Würden sie agil sein würden diese Anpassungen ständig erfolgen.

Zunächst möchte ich SAFe und Holocracy an dieser Stelle weglassen, die Frage ob diese beiden Ansätze überhaupt agil sind würde hier zu weit führen.Stattdessen Focus auf Scrum. Müsste sich das nicht permanent an die Gegebenheiten anpassen, je nachdem welche das gerade sind? Wäre das nicht die Voraussetzung dafür, selbst agil zu sein? Vielleicht. Ich würde es aber trotzdem nicht für sinnvoll halten, aus den folgenden zwei Gründen:

Zum einen sehe ich das Risiko, dass Scrum aufgebläht werden würde. Der Scrum Guide ist bewusst schlank gehalten, und erst letzten Monat hat Ken Schwaber, einer seiner Verfasser, geschrieben, dass das mit Absicht so ist. Mit jeder Erweiterung würde Scrum einzelfallspezifischer und damit für immer weitere andere Einzelfälle nicht mehr anwendbar. Es ist sein Minimalismus der es universell anwendbar macht. Dass der bei permanenten Modifikationen erhalten bleiben würde glaube ich nicht.

Zum anderen besteht einer der großen Vorteile von Scrum darin, dass es Leitplanken vorgibt ohne einengend zu sein. Vereinfacht gesagt legt es lediglich eine Art von Gewaltenteilung im Team fest und gibt Intervalle vor in denen über Planungen, Arbeitsfortschritte und Prozessverbesserungen gesprochen werden muss. Ohne dass Detailvorgaben gemacht werden können die Herausbildung von Hierarchien und das Aufkommen von Schlendrian so vermieden werden. Ich wage die Voraussage: diese Leitplanken würden sofort zum Objekt von Verschlimmbesserungen werden.

Aber heisst das, dass Scrum überhaupt nicht angepasst werden darf (bzw. von jemand anderem als den Verfassern)? Doch, natürlich geht das. Der Scrum Guide sagt es selbst: although implementing [...] parts of Scrum is possible, the result is not Scrum. Mit anderen Worten - ändere was Du willst, aber nenne es dann nicht mehr Scrum. Dieser Begriff ist aus guten Gründen (siehe oben) dem bisherigen, weitgehend unveränderbaren Framework vorbehalten.

Montag, 3. Juli 2017

Die Rumsfeld-Matrix

FS
Bild: Wikimedia Commons / Chad McNeeley - Public Domain
„There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – there are things we do not know we don't know.“ (Donald Rumsfeld, 2002)

Dieses mittlerweise weitgehend vergessene Zitat des ehemaligen amerikanischen Verteidigungsministers Rumsfeld gehört zu den besten, weil differenziertesten, Annäherungen an das Konzept der Unbestimmtheit. Grundlegend beruht es darauf, dass sich komplexe Systeme unvorhersehbar entwickeln. Diese Unvorhersehbarkeit beherrschbarer zu machen ist Ziel der Rumsfeld-Matrix, die hinter dem oben genannten Zitat steht.

Aufgrund der sprachlichen Unterschiede zwischen dem Englischen und dem Deutschen ist die Matrix nur schwer zu übersetzen, annäherungsweise gelingt es aber mit den Begriffen Wissen und Kennen.

Known Knowns (Dinge von denen wir wissen, dass wir sie kennen)

Der einfachste Fall. Der jeweilige Sachverhalt ist uns bekannt und wir sind uns dessen auch bewusst. Wir können also bereits im Voraus festlegen wie wir mit ihm umgehen werden (🡢 Planung ist möglich). Beispiel: wie organisieren wir die Arbeitsvertretung in den Weihnachtsferien.

Known Unknowns (Dinge von denen wir wissen, dass wir sie nicht kennen)

Schon etwas schwieriger. Wir wissen, dass der Sachverhalt existiert, kennen uns aber nicht wirklich mit ihm aus. Bestenfalls können wir im Voraus festlegen wie wir uns ihm annähern sobald er auftaucht (🡢 Planung ist eingeschränkt möglich). Beispiel: wie organisieren wir die Arbeitsvertretung wenn eine Krankheitswelle auftritt.

Unknown Unknowns (Dinge von denen wir nicht wissen, dass wir sie nicht kennen)

Der schwierigste Fall. Nicht nur kennen wir uns mit einem Sachverhalt nicht aus, wir wissen nicht einmal, dass er existiert. Das einzige was wir im Voraus unternehmen können ist es, die Prozesse so schlank zu halten, dass wir schnell reagieren können wenn er auftaucht (🡢 Planung ist nicht möglich). Beispiel: der Eintritt neuartiger und disruptiver Wettbewerber in einen Markt, wie etwa Uber oder AirBNB.

Unknown Knowns (Dinge von denen wir nicht wissen, dass wir sie kennen)

Ein etwas widersprüchlicher Fall. Wir kennen eigentlich einen Sachverhalt, nehmen ihn aber aufgrund von Desensibilisierung nicht mehr wahr und werden daher von seinen Auswirkungen überrascht (🡢 Planung ist nicht möglich). Beispiel: permanente Überstunden führen zu schleichender Frustration in einer Belegschaft, die sich in einer Kündigungswelle entlädt.


Vor allem im Fall der Unknown Unknowns aber auch im Fall der Known Unknowns besteht der Lösungsweg daraus, eine schnelle und effektive Reaktionsfähigkeit zu haben. Planung hilft nicht, egal in welcher Detailtiefe und mit welchem Vorlauf. Im Fall der Unknown Knowns kommt dazu noch eine Resensibilisierung - durch regelmässiger Überprüfen von Ursachen und Wirkungen kann versucht werden entstehender Betriebsblindheit entgegenzuwirken. In allen drei Fällen sind agile Vorgehensweisen sehr geeignet.

Freitag, 30. Juni 2017

Kommentierte Links (XXVI)

FS
  • Ron Jeffries: Done, and Sprint Length

    Ein weiser alter Mann blickt zurück und erklärt, was unter zwei der zentralen Begriffe von Scrum zu verstehen ist. Das Besondere: Ron Jeffries ist einer der Pioniere agiler Softwareentwicklung, gehört zu den initialen Unterzeichnern des agilen Manifests und kennt die Erfinder von Scrum persönlich. Man kann also davon ausgehen, dass er weiss wovon er spricht. Besonders seine Interpretation von "Done" gefällt mir: "in every regard, in good enough condition to be shipped to customers". Eben nicht perfekt, eben nicht "zu Ende entwickelt", sondern gerade gut genug um zum Kunden gebracht zu werden, damit aus dessen Feedback gelernt werden kann.

  • Ken Schwaber: Scrum Improvements

  • Apropos Erfinder von Scrum. Ken Schwaber (einer der beiden) erklärt warum nicht viel mehr von den good practices und best practices in den Scrum Guide aufgenommen wurden. Seine Antwort: damit er nicht zu spezifisch wird. Je spezifischer, desto größer die Gefahr, dass er für manche Teams zu einengend wird und für andere gar nicht mehr anwendbar. Tatsächlich sehe ich in einigen von mir gecoachten Teams, dass die Frage "Ist das noch Scrum oder kann das weg?" sehr unterschiedlich beantwortet wird. Warum sollte man hier durch eine einheitliche Zwangslösung funktionierende Vielfalt beschneiden? Ich wüsste keinen Grund.

  • Ron Eringa: Evolution of the Agile Manager

    Eine Frage die ich mit meinen Kunden seit Jahren diskutiere ist: "Was machen die Manager wenn hier alles agil ist?" Eine einfache Antwort darauf gibt es nicht (warum müssten wir sonst jahrelang diskutieren) aber viele gute Ansätze. Ron Eringa sammelt einige davon und ordnet sie in ein Phasenmodell ein, das dem jeweiligen Manager eine schrittweise Evolution ermöglicht. Für mich wichtig ist dabei der systemische Ansatz. In Eringas Worten: "Each of the stages has a relation to the maturity-level of the Scrum team. An Agile Manager cannot grow when the Scrum Master, Product Owner and Development Team are not growing along."

  • Leon Tranter: Agile metrics: you’re doing it wrong

    Ein weiteres Dauerbrennerthema. Und das Problem wird durch Tranter gleich zu Beginn auf den Punkt gebracht: "The wrong people are doing the measuring, and the wrong things are being measured". Mit anderen Worten, es wird erneut versucht command & control auf Ebene einzelner Arbeitsschritte zu machen. Die Folgen dessen sind seit über 20 Jahren bekannt - am Ende wird nur noch für Zahlen gearbeitet, nicht mehr für Ergebnisse. Die Alternative besteht darin, sich bewusst zu machen welchem Geschäftszweck das Produkt überhaupt dient und die Messung hier anzusetzen.

  • [Edit] TechBeacon: Why your execs don't get agile and what you can do about it

    Ursprünglich stand hier ein Link zum t3n-Artikel Der Weg ist das Ziel. Eine nett geschriebene Einführung, nichts Spezifisches. Der TechBeacon-Artikel von Matthew Heusser ist sehr spezifisch und sehr wichtig, da er um Probleme kreist an denen viele agile Transitionen scheitern: fehlende Einbeziehung und fehlendes Verständnis des Managements. Er arbeitet sehr gut die Hintergründe und Ursachen heraus, wird aber leider gegen Ende etwas dünn. Sein Lösungsansatz lautet nämlich (vereinfacht gesagt), dass man die erkannten Probleme einfach lösen soll. Wenn es so einfach wäre. Allerdings ist alleine die Erkenntnis der Probleme schon viel, viel wert.

Dienstag, 27. Juni 2017

A Culture of Experimentation

FS
Dieser Eintrag hier ist gedacht für einige bestimmte Leser, die mir in letzter Zeit erzählt haben, die Erfolge der Firma Spotify würden auf deren organisatorischem Aufbau (Tribes, Gilden, etc.) beruhen. Hallo Damen und Herren, Ihr wisst wer Ihr seid.



Die tiefere Aussage hinter der Einbindung dieses Videos auf dieser Seite: Spotifys Erfolg beruht auf vielen weiteren Faktoren, wie in diesem Fall auf umfangreichem A/B-Testing. Das wiederum beruht auf der Fähigkeit Software in sehr kurzen Intervallen auf Produktion zu bringen, die beruht auf einer hohen Automatisierungsrate (Tests, Deployments), die wiederum auf technischer Exzellenz, diese entsteht aus einer bestimmten Kultur, etc. Long Story short: die Einführung von Tribes und Gilden (oder Microservices) reicht nicht aus um besonders agil und/oder erfolgreich zu werden. Es gehört viel, viel mehr dazu.
Powered by Blogger.