Donnerstag, 27. Juli 2017
Visionen
 |
| Bild: Wikimedia Commons / Ludwig Wegmann - CC BY-SA 3.0 DE |
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 |
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 |
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 |
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 |
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
 |
| Bild: Wikimedia Commons / Cherie Cullen - Public Domain |
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ässiges Überprüfen von Ursachen und Wirkungen kann versucht werden entstehender Betriebsblindheit entgegenzuwirken. In allen drei Fällen sind agile Vorgehensweisen sehr geeignet.
