Montag, 31. Juli 2017

Kommentierte Links (XXVII)

Grafik: Pixabay / Geralt - Lizenz

  • Paul Rosenzweig: Bad Code Is Already a Problem. Soon, Companies Will Be Liable.

    Ein noch zu wenig bedachter Aspekt der aktuellen technischen Entwicklungen. Das "Internet der Dinge" und künstliche Intelligenz machen fehlerhafte Software zu einem immer größer werdenden Risiko, z.B. in selbstfahrenden Autos, automatisierten Kraftwerken oder Flugzeug-Leitsystemen. Paul Rosenzweig geht in diesem Artikel davon aus, dass es nur noch eine Frage der Zeit ist bis IT-Firmen gesetzlich verpflichtet werden ihre Anwendungen einfach und verständlich zu strukturieren, sie updatefähig zu halten, regelmässig zu testen, über Schnittstellen zugänglich zu machen und Fehlfunktionen unverzüglich zu beheben. Sollte das so kommen wäre es de facto ein juristischer Zwang agil zu arbeiten.

  • Melissa Perri: Product Manager vs. Product Owner

    Eigentlich behandelt Melissa Perri in diesem Text zwei Themen. Zum einen das Scaled Agile Framework (SAFe) und seine Dysfunktionalität in Bezug auf kunden- und benutzerorientiertes Produktmanagement, zum anderen die grundsätzliche Differenzierung zwischen Product Manager und Product Owner. Zum ersten Thema muss man nicht viel sagen, ausser, dass sie Recht hat. Das zweite lautet in einem Satz zusammengefasst: Product Owner ist eine Rolle in Scrum, Product Manager ist ein Beruf den man behält, auch wenn die Methode sich ändert. Und: ein Product Manager kann auch andere Rollen ausfüllen, die nichts mit Scrum zu tun haben. Das ist ein wichtiger Punkt - viele POs sind "One Trick Ponies" und ohne das umgebende Framework relativ hilflos. Daran zu arbeiten sollte Teil der Personalentwicklung jedes agilen Unternehmens sein.

  • Stephen Frein: Donning the agile camouflage - 5 ways to tell if you're agile in name only

    • Ich habe es in mehr als einem Unternehmen selbst erleben dürfen - nicht überall wo Agil (bzw. Scrum) draufsteht ist auch Agil drin. Viel zu häufig handelt es sich doch nur um Cargo Cult. Damit Unternehmen selbst feststellen können ob sie in einer solchen Situation sind hat Stephen Frein fünf Anzeichen dafür gesammelt und aufgeschrieben:
    • Es gibt innerhalb der Entwicklungsteams Sub-Teams (z.B. Design, Entwicklung, Test) die sich in Form von Mini-Wasserfällen organisieren.
    • Es gibt eine weit in die Zukunft reichende Detailplanung der Sprints, die wenig Raum für Anpassungen lässt.
    • Am Ende der Sprints gibt es zwar einen Fertigstellungs-Fortschritt, der aber keine benutzbare Funktionalität erzeugt hat.
    • User Stories sind zu groß für einen Sprint und werden entweder gar nicht oder nach Phasen (z.B. Design, Entwicklung, Test) geteilt.
    • Retrospektiven sind formalisierte Zeremonien die ohne Überzeugung abgehalten werden und zu keinen Veränderungen führen.
    Sich selbst an diesen Kriterien zu messen würde im Fall vieler Teams und Unternehmen sehr erhellend sein, aber auch sehr deprimierend.

  • Klaus Leopold: Zwischen den Zeilen – Swimlanes am Portfolioboard [Edit: Link ist mittlerweile tot]

    Ein kurzer aber wichtiger Text. Wenn Unternehmen ihre Change-Vorhaben visualisieren (was Bestandteil jeder agilen Transition sein sollte), dann können diese nach verschiedenen Kriterien angeordnet sein: entsprechend den Abteilungs- oder Bereichsgrenzen, nach Wichtigkeit oder Dringlichkeit oder nach Impact auf die Positionierung am Markt. Während Variante 1 zu einer Abart von Conway's Law führen kann und Variante 2 schnell in abstrakte Diskussionen abgleitet führt Variante 3 den Focus zurück auf den Grund warum eigentlich etwas geändert werden soll. Nach meiner Erfahrung ist diese Variante leider auch die seltenste. Im Grunde nachvollziehbar, schließlich fordert sie den Beteiligten die größte Änderung im Denken ab.

  • Jeff Sutherland: How to Optimize Your Kanban

    Als Beitrag zu einer Diskussion um optimale und dysfunktionale Kanban-Systeme gibt Jeff Sutherland einige Ideen zum Besten. Wie man es vom Begründer von Scrum erwarten kann bestehen die aus der Einführung von Scrum-Elementen. Letztendlich geht das in die selbe Richtung wie die Bemühungen von David Anderson seinen Essential Kanban Condensed Guide zu etablieren. Es scheint einen Bedarf dafür zu geben Kanban zu formalisieren.

Donnerstag, 27. Juli 2017

Visionen

Bild: Wikimedia Commons / Ludwig Wegmann - CC BY-SA 3.0 DE
Wenn ich beim Aufbau neuer agiler Teams helfe gehört zur Initiierungsphase in der Regel auch ein Workshop zur Produktvision, in dem geklärt wird welches Problem mit dem Produkt gelöst werden soll, welcher Bedarf befriedigt oder welcher neuen Markt erschaffen werden soll. Auffällig ist dabei, dass viele Teams oder Unternehmen Schwierigkeiten haben zwischen einer Produktvision und sonstigen Visionen zu unterscheiden. Sie werden regelmässig verwechselt oder vermengt. Um besser differenzieren zu können lohnt sich daher ein näherer Blick: welche Arten von Visionen können Teams oder Unternehmen überhaupt haben? Die folgenden würden mir einfallen:

Innovationsvision

Sie kann noch einen Schritt vor der Produktvision liegen. In ihr wird grundlegend geklärt welches neuartige Angebot angedacht ist, allerdings auf einem hohen Abstraktionslevel. Das bekannsteste Beispiel kommt von der Firma Google und lautet "To provide access to the world’s information in one click". Die einzelnen Produktvisionen (um bei Google zu bleiben: Suche, Gmail, Maps, etc.) lassen sich davon ableiten.

Produktvision

Der Name sagt es, hier geht es um das Zielbild eines einzelnen vermarktbaren Produkts. Das kann noch immer auf hohem Level sein, wie etwa beim iPod von Apple, der auf dem einen Satz "1000 Songs, right in my Pocket" beruht. Man erkennt sehr gut den Unterschied zu Konzept oder Spezifikation - es sind noch keine Umsetzungsdetails enthalten, die gehören hier nicht hin.

Erfolgsvision

Wieder etwas anderes. Ich weiss welche Innovation ich erschaffen will und ich habe eine Idee für mein Produkt, aber wie erfolgreich soll es sein? Auch das kann ich in eine Vision packen, die bekannteste dieser Art ist wohl die folgende von Microsoft: "A personal computer in every home running Microsoft software". Zugegeben, klingt größenwahnsinnig. Aber sie wurde erreicht. Visionen können ambitioniert sein.

Prozessvision

Ein Unternehmen kann sich nicht nur Gedanken darüber machen was es will, es sollte auch darüber nachdenken wie es arbeiten möchte. Eine gute Prozessversion kommt von der ING und lautet "Deliver some value to customers in max 90 days". Was hier gut gemacht wurde: man hat nicht einfach gesagt "Wir wollen agil werden", man hat es direkt mit einem Zweck verbunden.

Kulturvision

Eine weitere Vision zum Thema "wie", aber diesesmal nicht bezogen auf Umsetzungsprozesse sondern auf den zwischenmenschlichen Umgang. Auch hier kann man Google als Beispiel anführen, dessen Verhaltenskodex auf dem einfachen Satz "Don't be evil" beruht. Auch das scheint zunächst unkonkret, geht aber tiefer als man zunächst denkt. Die Behandlung der eigenen Kunden und Mitarbeiter durch viele Unternehmen würden nicht standhalten wenn man sie an dieser schlichten Aussage messen würde.


Vermutlich existieren noch weitere Visionstypen die man hier nennen könnte, der Punkt ist aber klar: es gibt nicht nur eine Art von Vision sondern viele. Und wenn ein Team oder Unternehmen einen Visionsworkshop macht sollte klar sein um welche Art es geht.

Montag, 24. Juli 2017

Stakeholder-Landkarten

Bild: Flickr / Doc Chewbacca - CC BY-NC-SA 2.0
Sobald Teams Teil von größeren Projekten, Abteilungen oder Unternehmen werden besteht die Gefahr, dass sie die Übersicht über ihre Stakeholder verlieren. Wie in vielen anderen Fällen auch kann man sich in dieser Situation durch Visualisierung eine bessere Übersicht verschaffen. Ein guter Ansatz ist dabei die Verwendung von großen Landkarten, zum Beispiel solchen die früher im Geografieunterricht an der Wand hingen. Auf ihnen lassen sich die verschiedenen Gruppen anordnen und zueinander in Beziehung setzen. Etwa so:


Diese (von einem realen Beispiel inspirierte) Stakeholder-Landkarte ist die des Teams "Blue Men Group". Man sieht die Verbindungen zu den Kunden für die man produziert, zu den anderen "blauen" Teams, mit denen man gemeinsame Schnittstellen hat, und zum Management, in dem man besonders eine Person (den "Blue Ambassador") als Fürsprecher hat. Auf der rechten Seite befinden sich weitere Teams mit denen man nicht direkt in Verbindung steht, darunter das Team "Enemies at the Gate", mit dem ein Konflikt besteht (z.B. weil es der Blue Men Group eine andere Architektur aufdrängen will). Damit das nicht passiert achtet eine Abordnung des Managements (die "Border Watch") darauf, dass das Enemies-Team nicht versucht in die Blue Men Group hinenzuregieren.

Auch weitere Faktoren lassen sich darstellen, wie z.B. Abhängigkeiten zwischen anderen Teams, aus denen sich indirekte Betroffenheiten ergeben können. Je nach Phantasie kann die Karte auch zur Visualisierung weiterer Sachverhalte genutzt werden. So könnte die Platzierung des "Blue Islands Team" auf Sardinien und Korsika bedeuten, dass seine Anwendungen aus eigenständigen Microservices bestehen, oder die des "Land's End Team" in Apulien, dass dessen Anwendung in einer technischen Sackgasse steckt.

Aufgehängt werden sollte eine Karte gut sichtbar im Arbeitsbereich des Teams, idealerweise in Sichtweise der Personen die mit den Stakeholdern zusammenarbeiten. Dabei sollte man auch bedenken, dass ausserhalb des Teams stehende Personen die Karte zu Gesicht bekommen können oder sogar sollten (man kann die abgebildeten Personen auch fragen, ob sie sich in der Anordnung genauso sehen würden). Gegebenenfalls macht es daher Sinn die verschiedenen Gruppen neutraler zu benennen als im oben zu sehenden "Enemies at the Gate"-Beispiel.

Donnerstag, 20. Juli 2017

Soziale Ursachen technischer Probleme und Lösungen

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

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?

Bild: Unsplash / Brooke Cagle - Lizenz
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)

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

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.