Dienstag, 26. September 2017

How to convince your boss to be agile

FS


Ein Vortrag der nicht nur inhaltlich gut ist sondern auch hohen Unterhaltungswert hat. Kann man sich ansehen.

Donnerstag, 21. September 2017

Scaled Agile: Release Trains

FS
Bild: Wikimedia Commons / David Gubler - CC BY-SA 3.0
Die Idealwelt ist die von der man hört wenn von Netflix, Zalando und Spotify die Rede ist. Statt einer großen, monolithischen Anwendung gibt es viele kleine Module (Microservices), die unabhängig voneinander deploybar sind und ihren Teams dadurch hohe Autonomie sichern. Die Realität ist häufig eine andere - Microservices existieren nicht (oder sind ungünstig geschnitten), so dass es doch dazu kommt, dass verschiedene Teams ihre Features gemeinsam auf Produktion bringen müssen. Wie passt das zu agiler Softwareentwicklung?

Der typische Management-Reflex ist "Koordination", womit in den meisten Fällen gemeint ist, dass ein koordinierender Manager eingesetzt wird, der den Teams vorgibt wann sie was fertigzustellen haben. In der Theorie sorgt das dafür, dass zusammengehörende Features gleichzeitig fertigwerden, in der Realität ist das leider seltener der Fall. Eher kommt es hier zu den aus dem Wasserfall bekannten Effekten: es passieren ungeplante Entwicklungen, die Geschwindigkeiten der Teams laufen auseinander, es kommt zu Leerlauf, Merge-Konflikten, etc.

Es könnte auch anders laufen, und um zu wissen wie braucht man nur auf einen ähnlichen Fall zu schauen - auf zu erreichende Deadlines. Auch damit können agile Teams zurechtkommen indem sie auf Komfortfunktionen verzichten, einfache Lösungen bevorzugen oder auf andere Art den Scope reduzieren. Ein langsameres Team kann auf diese Weise seinen zeitlichen Rückstand wieder aufholen. Umgekenrt kann gegebenenfalls das schnellere Team einen Gang zurückschalten und mehr Zeit in Refactoring, Bugfixing oder Wissenstransfer stecken, auch dadurch erreichen alle gleichzeitig den gemeinsamen Release-Zeitpunkt.

Als Analogie bietet sich der Bahnverkehr an: wenn in Hamm die Züge aus Duisburg und Köln zusammengekoppelt werden sollen, dann kann der langsamere (in diesem Fall aus Duisburg) schlimmstenfalls einen der vielen Stops im Ruhrgebiet ausfallen lassen, etwa den in Bochum. Umgekehrt könnte der schnellere (in diesem Fall der aus Köln) auch einen Zusatzhalt in Dortmund einlegen. In beiden Fällen würden beide gleichzeitig ankommen und gemeinsam ihre Fahrt nach Berlin fortsetzen.

Bleibt nur die Frage: könnte das nicht auch von einem koordinierenden Manager orchestriert werden? Nur bedingt. Da es erfahrungsgemäß nicht nur zu einer ungeplanten Entwicklung kommt sondern zu mehreren müssen im Zweifel alle beteiligten Teams permanent (in Scrum jeden Sprint, d.h. alle 1 bis 4 Wochen) Korrekturen vornehmen, das mit den Stakeholdern und anderen Teams abstimmen und die Planungen entsprechend aktualisieren. Schon bei zwei Teams wäre das für einen Koordinator eine Herausforderung, bei noch mehr Teams kaum zu schaffen.

Direkt miteinander kommunizierende autonome Teams können sich dagegen ohne Entscheidungs-Engpässe oder Stille Post-Effekte abstimmen und jedes für sich Kurs und Geschwindigkeit so anpassen, dass Vorsprünge und Verspätungen sich ausgleichen. Das Zusammenkoppeln kann dann reibungsloser stattfinden und der gemeinsame "Release-Zug" Fahrt aufnehmen.

Montag, 18. September 2017

Wenn der Agile Coach überall Cargo Cult sieht

FS
Bild: Wikimedia Commons / Thorsten Bachner - CC BY 3.0
Das Leben als Agile Coach kann großartig sein. Dann nämlich wenn man sieht wie die eigenen Ratschläge zu höherer Produktivität, höherer Kundenzufriedenheit oder höherer Mitarbeiterzufriedenheit führen. Andererseits kann es manchmal auch frustrierend sein, dann nämlich wenn man damit konfrontiert ist, dass unwillige Teams oder Manager eigentlich alles beim Alten lassen wollen und überall nur "Agile" als Buzzword-Label draufkleben.

Das Risiko das sich daraus ergibt ist, dass irgendwann reflexhaft jede (scheinbar) falsche Verwendung der Begriffe Agile und Agilität als Cargo Cult abqualifiziert wird. Ich sehe das manchmal an mir selbst, vor allem dann wenn ich gerade nicht bei einem Kunden unterwegs bin und mich daher (unbewusst) nicht an die selbst auferlegte Sorgfaltspflicht gebunden fühle. In solchen Situationen rutscht mir mitunter ein schnelles Urteil durch, eines für das ich mich im Nachhinein ein bisschen schäme.

Um dem entgegenzuwirken versuche ich regelmässig meine eigenen Ansichten zu reflektieren, mich selber zu hinterfragen und mich auf andere Standpunkte einzulassen. Gerade bei Menschen die nicht so tief und dauerhaft in der Thematik stecken wie ich kann eine falsche Benennung von Begriffen ja leicht vorkommen. Auf der anderen Seite ist aber auch deren missbräuchliche Verwendung eine immer wiederkehrende Realität. Und manchmal verschwimmen auch die Grenzen. Einen Schritt zurückzutreten und alles nochmal in Ruhe zu betrachten macht fast immer Sinn.

Was sich immer wieder als hilfreich herausgestellt hat sind "Selbsthilfegruppen" mit anderen Agile Coaches, sei es im Rahmen einer (Un)Konferenz, eines Coaching Retreat oder einer Kollegialen Fallberatung. Und sei es nur um festzustellen, dass andere genau die gleichen Probleme haben wie ich.

Donnerstag, 14. September 2017

Relationale Schätzungen

FS
Bild: Wikimedia Commons / mossi889 - CC BY 3.0
Ob das relationale Schätzen wirklich eine agile Methode im eigentlichen Sinn ist wird immer wieder diskutiert. Tatsache ist, dass die meisten agilen Teams (und fast alle Scrum Teams) derartige Ansätze nutzen um die Größemschätzung ihrer Arbeitspakete durchzuführen. Aber was ist das eigentlich, dieses relationale Schätzen?

Die grundlegende Einsicht dahinter ist, dass das menschliche Gehirn bei Schätzungen bestimmte Schwächen und bestimmte Stärken aufweist. Zu den Schwächen gehört dabei leider eine Schätzung in Zeitaufwänden. Ob eine Arbeit drei oder vier Stunden in Anspruch nehmen wird oder vier oder fünf Tage ist kaum zu sagen, schon gar nicht bei so komplexen und unberechenbaren Aufgaben wie der Neuentwicklung von Software. Zu den Stärken gehört dagegen die Einschätzung von Relationen. Jeder Mensch wird ohne Nachzudenken sagen können, dass eine Walnuss schwerer ist als eine Haselnuss, oder dass das Bauen einer Bank länger dauert als das Bauen eines Stuhls.

Um sich diese Stärke zu mutze zu machen kommt das relationale Schätzen zum Einsatz: neue Aufgaben werden in Bezug gesetzt zu älteren, bereits erledigten. "Wenn das Verarbeiten von Emails mit Word-Anhängen Größe X hatte, ist dann das Verarbeiten von Emails mit Excel-Anhängen ähnlich, größer oder kleiner?" Beruhend darauf ist eine Einschätzung nicht nur einfacher sondern auch wesentlich verlässlicher.

Erfahrungsgemäß hilft es den Beteiligten noch mehr, wenn auch bei diesen Relationsvergleichen keine Zeiteinheiten verwendet werden. Die Frage "Wenn das Erstellen einer Word-Verarbeitung 5 Tage gedauert hat, wie lange dauert dann die Excel-Verarbeitung?" ist zwar einfacher zu beantworten als "Wie lange dauert das Erstellen einer Excel-Verarbeitung?", trotzdem werden sich viele Menschen schwer tun. Leichter fällt es den meisten bei neutralen Einheiten, die nicht sofort mit Zeiteinheiten zu verbinden sind.

Die üblichste dieser neutralen Einheiten sind so genannte Story Points (meistens eine abgewandelte Fibonacci-Reihe), aber es gibt auch T-Shirt-Größen, Tierarten (wie im Symbolbild oben) oder andere selbstentwickelte Einheiten. Das kann jedes Team für sich optimieren.

Montag, 11. September 2017

Erfolgs-User Stories

FS
Bild: Wikimedia Commons / Abdulrahman Raofi - CC BY 4.0
Wieder etwas dazugelernt: in einem zur Zeit von mir gecoachten Team wird eine Art von Anforderungsbeschreibung verwendet die ich noch nicht kannte - die Erfolgsgeschichte, bzw. Erfolgs-User Story. Sie beschreibt einen (noch nicht eingetretenen) Fortschritt der Produktentwicklung aus der Sicht desjenigen, der ihr Ergebnis bereits benutzen kann. Ein Beispiel:

"Zum Glück sind ist die Performance unseres Systems besser geworden, gerade noch rechtzeitig vor der Einspeisung der Partnerdaten. Jetzt können wir sie nutzen ohne durch lange Ladezeiten aufgehalten zu werden."

Wie im Fall normaler User Stories gibt es auch hier präzisierende Akzeptanzkriterien, allerdings in einer neuen Form: "Das war nur möglich weil der Datenbankindex angepasst wurde." "Das war nur möglich weil Duplikate bereinigt wurden.", etc.

Bei genauerer Betrachtung steckt etwas Ähnliches dahinter wie im Fall einer normalen User Story, nämlich der grundlegende Use Case mit angehängtem Business Value, bei Bedarf ergänzt um eine Rolle. Auch die Akkzeptanzkriterien sind trotz der neuen Formulierung inhaltlich mit den alten vergleichbar. Der Mehrwert dieses neuen Ansatzes ergibt sich aus seinem Einsatz in der Zusammenarbeit mit Kunden, Anwendern und Auftraggebern.

Im Rahmen von Anforderungs-Workshops kann man jetzt Fragen stellen wie "Welche Erfolgsmeldung würden sie als nächstes hören wollen?" oder "Welche Erfolgsmeldung möchten Sie als nächstes verkünden können?". Anders bei der klassischen Frage "Was brauchen Sie alles?" ist in einer Antwort darauf bereits eine Priorisierung eingeflossen. Darüber hinaus wird auch die (implizite) Erwartungshaltung aufgelöst, eine Anforderung umfassend beschreiben zu müssen.

Auch hier bedarf es natürlich einer gewissen Übung, damit ein Stakeholder nicht auf die Idee kommt ein "Zum Glück ist alles fertig"zu verfassen. Sobald das geschafft ist kann eine Erfolgs-User Story aber eine gute Ergänzung zu der klassischen Form sein.

Donnerstag, 7. September 2017

Why agile: Gesetzesänderungen

FS
Bild: Pixabay / Jörg Elman - CC0 1.0
"Warum sollen wir jetzt agil werden? Uns betrifft das doch nicht. unser Tagesgeschäft läuft stabil, keine großen Neuerungen, kein intensiver Wettbewerb." Äusserungen wie diese gibt es immer wieder aus Firmen, Behörden und sonstigen großen Organisationen. Tatsächlich ist es auch in vielen wirklich so, dass die Rahmenbedingungen sehr stabil und unveränderbar scheinen. Dass es aber auch in einem scheinbar ruhigen Umfeld zu unerwarteten Änderungen kommen kann zeigt ein aktuelles Beispiel.

Vor gerade erst zwei Monaten hat der Bundestag die Ehe für alle beschlossen, so dass bald auch gleichgeschlechtliche Paare heiraten dürfen. Ab dem ersten Oktober können sie zum Standesamt gehen und sich dort trauen lassen, werden danach aber auf ein technisches Problem stossen: in der dort verwendeten Software befinden sich weiterhin Felder für Ehemann und Ehefrau. Für eine Eintragung von zwei Ehefrauen oder zwei Ehemänndern muss diese Software angepasst werden, und das dauert voraussichtlich (festhalten) bis Herbst 2018. Vierzehn bis sechzehn Monate nach der Gesetzesänderung.

Dieses Beispiel erscheint extrem, es ist aber gewöhnlicher als man denken sollte. Gerade bei älterer Software können die Planungs-, Umsetzungs oder Rolloutprozesse so langwierig sein, dass es selbst bei kleineren Änderungen länger als ein Jahr dauern kann bis neue Versionen in Betrieb genommen sind. Gründe dafür sind umständliche Genehmigungsvorschriften, schlechte Dokumentation der bestehenden Anwendungen, schlechte Absicherung durch Tests und vieles mehr.

Da in diesem Fall der Staat selbst von seiner Gesetzgebung betroffen ist werden sich die Konsequenzen im überschaubaren Rahmen halten, es braucht aber nicht viel Phantasie um sich Konstellationen vorzustellen in denen er strikt auf der zügigen Umsetzung bestehen würde. Mögliche Beispiele finden sich vor allem in stark regulierten Branchen wie im Finanzwesen und der Stromerzeugung, und spätestens beim Thema Verbraucher- oder Umweltschutz ist so ziemlich die ganze Wirtschaft betroffen.

Würde in solchen Fällen mehr als ein Jahr vergehen bis gesetzliche Vorgaben umgesetzt werden, es könnte für die jeweiligen Unternehmen unangenehm werden. Von daher ist die Fähigkeit zur schnellen Anpassung der eigenen Systeme (→ Agilität) etwas das man auch in einem scheinbar stabilen Umfeld haben sollte.

Montag, 4. September 2017

Ein Bild sagt mehr als 1000 Worte (XIX)

FS
Auf dieses Bild gibt es zwei Reaktionen. Menschen die nicht in der Softwareentwicklung arbeiten: Wow, so viel? Menschen die in der Softwareentwicklung arbeiten: Wow, so wenig?

Donnerstag, 31. August 2017

Kommentierte Links (XXVIII)

FS
  • Tendayi Viki: Lessons From Kodak’s Bankruptcy - How Can Large Companies Sustain Innovation?

    Direkt zu Beginn dieses Textes wird die Tragik des Untergangs von Kodak auf den Punkt gebracht: die Firma ging nicht nur unter weil ihre Erzeugnisse durch den technischen Wandel obsolet wurden, sie hatte diesen Wandel selbst begonnen, wollte dann aber doch nicht auf ihre traditionellen Erfolgsprodukte verzichten. Tendayi Viki geht davon aus, dass ein solches Management-Verhalten seinen Ursprung in einer falschen Ausbildung der Manager an den Universitäten und in den Firmen hat, wo vermittelt wird, dass eine Fokussierung auf ein einziges Geschäftsfeld sinnvoll ist. Sein Gegenvorschlag besteht darin bis zu 30 % der Ressourcen auf neue und disruptive Geschäftsmodelle mit noch unklaren Erfolgschancen zu verwenden und diese möglichst früh validierbar zu machen. Klingt gut, es bleibt aber die Frage wie das mit kurzfristigen Shareholder-Interessen in Einklang zu bringen sein wird.

  • Ron Jeffries: Business Agile - Built Upon Sand

    Ob Business Agility und agiles Projektmanagement wirklich neue Trends sind und ob sie grundsätzlich das Risiko in sich tragen die eigentliche Agilität mit zu viel Prozessen einzuengen würde ich hinterfragen. Ron Jeffries hat aber Recht damit, dass es eine spürbare Tendenz gibt agile Transformationen als rein organisatorische Vorhaben zu sehen und die technischen Implikationen auszublenden. Bei vielen Managern gibt es den Irrglauben, dass eine zweitägige Zertifizierung oder eine zweiwöchige Begleitung durch einen Coach ausreichen um ein Team "agil zu machen". In meiner Erfahrung sind eher mehrere Monate nötig, aber das muss erstmal jemand bezahlen wollen. Wobei klar ist - wer eine billige Transition will zahlt meistens drauf.

  • Jurgen Appelo: Frameworks are like Radio Stations

  • Da Jurgen Appelo zur Zeit an einem Framework-unabhängigen Methodenbaukasten arbeitet sind seine in letzter Zeit zunehmenden Äusserungen über die Starrheit und Unflexibilität dieser Frameworks mit Vorsicht zu betrachten. Einen zutreffenden Kern haben sie aber, hier werden Freiheiten und Optionen bewusst durch Leitplanken eingegrenzt. Ich bin auch bereit zu hinterfragen ob agile Teams diese Leitplanken wirklich brauchen, erfahrungsgemäß ist das oft nicht der Fall. Wenn aber auf der anderen Seite unerfahrene Teams versuchen die Methoden anzupassen endet das sehr oft in Verschlimmbesserungen. Harikiri, wie ich es nenne. Frameworks haben ihren Sinn, man muss ihn sich nur bewusst machen statt ihnen kritiklos zu folgen.

  • Urs Enzler: Problem-Centric User Stories

    Einer der klassischen Fehler die man bei User Stories machen kann ist, dass bereits Lösungen beschrieben werden statt der Bedürfnisse des Benutzers oder des Kunden. Übertroffen wird das gelegentlich noch durch die Beschreibung von Bearbeitungsschritten ("Als Sachbearbeiter möchte ich auf einen Knopf drücken ..."). Der Lösungsansatz von Urs Enzler ist der Richtige, da er das Erarbeiten der Lösung beim Team lässt. Die Voraussetzung dafür ist allerdings, dass in dem auch wirkliche Software-Entwickler sitzen und nicht nur Coding Monkeys. (siehe auch: "As a User" needs to stop).

  • Mind the Product: Scaling Autonomous Teams

    Mit ihrer Aussage "It's all about Business Agility" gibt Debbie Wren scheinbar eine Gegenthese zu Ron Jeffries (weiter oben) ab. Wo sie wieder mit ihm zusammenkommt: um das zu erreichen ist (unter anderem) "technische Agilität" notwendig. Erst das, in Kombination mit Autonomie und Empowerment, macht Business Agility möglich.

Montag, 28. August 2017

Die verlorene agile Disziplin - Domain Driven Design (DDD)

FS
Vor einiger Zeit gehörte Christoph Baudson zu einem Entwicklungsteam das ich coachen durfte. Deshalb freut es mich um so mehr, dass ich heute auf ihn, bzw. seinen Vortrag auf der Froscon 2017 verlinken kann.



Auch jenseits persönlicher Sympathie ist das Video sehenswert, da DDD in der Tat relativ selten diskutiert wird. Und wie Christoph richtig sagt: man muss es nicht als Konkurrenz zu Frameworks wie Scrum sehen sondern als mögliche Ergänzung.

Donnerstag, 24. August 2017

Warum Konzerne nicht versuchen sollten agil zu werden

FS
Bild: Max Pixel / Freegreatpicture - CC0 1.0
Es passiert jeden Tag. Überall auf der Welt. Immer wieder. In gepolsterten Sesseln um einen langen Konferenztisch sitzend schauen sich die Manager großer Konzerne tief in die Augen und versichern sich gegenseitig "Wir werden Agil". Sie treten vor ihre Belegschaft, schreiben Rundmails, geben Interviews und sprechen auf Kickoff-Veranstaltungen um die Botschaft hinauszutragen in das eigene Unternehmen. Die Mitarbeiter verstehen, sie haben den Auftrag Agil zu werden. Die Umsetzung beginnt. Und dann passiert das genaue Gegenteil.

Das Problem in vielen Organisationen ist, dass sie ein falsches Verständnis von Agilität haben. Agilität wird gleichgesetzt mit den Rollen und Meetings von Scrum, SAFe und Spotify. Gibt es in den IT-Teams statt Teamleitern Scrum Master? Check. In den Fachabteilungen statt Business Analysten Product Owner? Check. Der Statusbericht heisst jetzt Daily Standup? Check. Die Architektur- und QA-Teams heissen jetzt Gilden? Check. Das Problem: es sind die gleichen Rollen, Personen und Strukturen wie früher. Das bloße Umbenennen ändert gar nichts.

Was hier passiert ist nichts anderes als eine Umkehrung von Mittel und Zweck. Eigentlich sind agile Methoden nur ein Mittel um den eigentlichen Zweck zu erreichen: kurze Time to Market, hohe Reaktionsgeschwindigkeit, Vermeidung sinnloser Arbeit. Nur dafür wurden die Frameworks, Rollen und Events erfunden und nur wenn sie darauf ausgerichtet sind machen sie Sinn. Wenn sie stattdessen als Selbstzweck eingeführt werden ist dieser nicht mehr gegeben. Einen Product Owner zu benennen nur damit er da ist bringt niemandem etwas.

Um diese Zustände zurück auf die Füße zu bringen kann es sinnvoll sein die Begrifflichkeiten der Agilität fallenzulassen und den eigentlichen Zweck wieder in den Mittelpunkt zu stellen. Wenn kurze Time to Market, hohe Reaktionsgeschwindigkeit und Vermeidung sinnloser Arbeit erreicht werden sollen, dann kann man das auch so benennen. Und die dahinführenden Maßnahmen werden automatisch die sein müssen die man aus Scrum & Co kennt: Nähe zum Kunden, flache Hierarchien, schlanke Prozesse und Automatisierung sich wiederholender Tätigkeiten.

Am Ende ist es fast ein Paradoxon. Sich das Ziel zu setzen Agil zu werden führt viele Konzerne in eine Sackgasse. Auf diese Bezeichnung zu verzichten kann Agilität dagegen fördern.

Montag, 21. August 2017

Team-Urlaub für einen Sprint

FS
Bild: Pixabay / Walkerssk - CC0 1.0
Als Agile Coach besuche ich bei einem meiner Kunden in unregelmässigen Abständen die Scrum Teams bei ihren Sprintwechseln. Auch letzte Woche war es wieder soweit, allerdings nur in kleinster Runde - neben dem Product Owner waren nur ein Entwickler und ein Business Analyst anwesend, das restliche Team (den Scrum Master eingeschlossen) befand sich in den Sommerferien. Naheliegenderweise war das auch das Thema der Retrospektive: wie kann unter solchen Bedingungen noch ein geregelter Arbeitsbetrieb aufrechterhalten werden?

Diese Frage dürfte bei so gut wie jedem Scrum Team regelmässig auftreten, und das nicht nur im August sondern in allen üblichen Ferienzeiten, z.B. Ende Dezember. Jedesmal wenn sich ein Teil der Teammitglieder für einige Tage oder Wochen verabschiedet fehlen Erfahrungswerte, unerwartete Mehraufwände fallen schwerer ins Gewicht und Arbeitstechniken wie Pair Programming oder Code Reviews können ggf. gar nicht mehr angewandt werden, weil wie im gerade genannten Beispiel nur ein Entwickler übrig ist.

Ein Lösungsansatz den ich bei einem anderen Kunden gesehen habe war, dass ein Team sich entschieden hat geschlossen in den Urlaub zu gehen, und zwar für genau einen Sprint. Nach der Retrospektive des Sprints davor gingen alle in ihre Ferien. Nach der Rückkehr gab es ein kurzes Backlog Refinement um sicherzustellen, dass sich in der Zwischenzeit nichts Neues ergeben hatte, danach ging der normale Rhythmus mit einem Planning wieder los.

Der Vorteil dieses Vorgehens war, dass die oben genannten negativen Effekte auf diese Art vermieden werden konnten. Statt mehrere Sprints mit ausgedünnter Personaldecke zu haben war das Team mit Ausnahme dieser zwei Wochen durchgehend voll besetzt, der "Urlaubssprint" wurde in der Sprintplanung ignoriert und auch in der Berechnung der Velocity nicht berücksichtigt. Dass das Review ausfallen würde wurde den Stakeholdern rechtzeitig vorher mitgeteilt.

Was dieses Vorgehen in diesem Fall begünstigt hat war eine besondere Rahmenbedingung: das Team war Teil eines Tribes, so dass andere Teams einspringen konnten wenn Bugfixing- oder Support-Aufgaben zu erledigen waren. In Konstellationen in denen das nicht der Fall ist müsste man über Ausgleichsmaßnahmen nachdenken. Eine die ich an anderer Stelle miterlebt habe war z.B. die, dass ein Team-Mitglied sich bereiterklärt hat seinen Urlaub später zu nehmen. Während des Urlaubssprints arbeitete er aber in einem anderen Team mit, wodurch die Auswirkungen der Ferienzeit auch dort abgeschwächt wurden.

Donnerstag, 17. August 2017

Scaled Agile: Chapter (Querschnittsorganisationen)

FS
Bild: Flickr / iMorpheus - CC BY 2.0
Die Verwendung des englischen Begriffs "Chapter" für eine Untergruppe einer größeren Organisation ist in Deutschland noch immer ungewöhnlich, sie kommt vor allem im Zusammenhang mit Rocker-Clubs wie den Hells Angels oder den Bandidos vor. Im englischen Sprachraum ist er dagegen viel normaler und wird für Gruppen jeglicher Art verwandt. Auch im Kontext agiler Skalierung ist er in Mode gekommen und bezeichnet hier in der Regel eine Querschnittsorganisation zur Koordination verschiedener Entwicklungsteams.

Genau wie der Begriff des Tribes ist der des Chapters durch den Skalierungsansatz der Firma Spotify bekanntgeworden, wo diese beiden Konzepte auch in Verbindung miteinander stehen. Ein Tribe ist dort eine Gruppe von Teams die an einem gemeinsamen (Teil)Produkt arbeiten, weshalb sie durch gegenseitige technische und fachliche Abhängigkeiten verbunden sind. Um sich nicht gegenseitig zu behindern ist eine Koordination zwischen diesen Teams nötig. Da der klassische Lösungsweg (die Einsetzung eines koordinierenden Managers) zu Hierarchien und Flaschenhälsen führen würde, wurde ein anderer Ansatz entwickelt, die Chapter.

In einem Chapter sind aus allen beteiligten Teams die Verantwortlichen für jeweils ein Spezialgebiet zusammengefasst. Häufig sind das Frontend, Backend und QA, es sind aber auch andere Konstellationen möglich, z.B. UX oder SEO. Zusammen haben sie die Aufgabe an übergreifenden Architekturen und gemeinsamen Standards und Tools zu arbeiten. Im Grunde eine ausdifferenzierte Version eines Scrum of Scrums, gewissermassen mit jeweils einem davon für jedes Spezialgebiet. Über Frequenz und Intensität der gegenseitigen Abstimmung entscheidet jedes Chapter dabei selbst.

Was ein Chapter ausserdem noch von einem Scrum of Scrums unterscheidet ist die Rolle des "Chapter Lead". Sie wird von einem der beteiligten Entwickler in Teilzeit ausgeübt und übernimmt das was von den klassischen Management-Tätigkeiten übrigbleibt: Personalentwicklung/Coaching, Gehaltsverhandlungen, Koordination des Recruitings, etc. Explizit nicht zu ihren Aufgaben gehört dagegen das Entscheiden fachlicher und technischer Konflikte oder das Vorgeben von Architekturen und Standards.

Wenn andere Organisationen versuchen Spotify zu kopieren ist die Rolle des Chapter Lead eine häufige Bruchstelle an der Probleme auftreten. Oft wird sie mit Personen besetzt die vorher Manager, Teamleiter, Architekt oder Lead Developer waren und sich aus ihrer alten, weisungsbefugten Rolle nur schwer lösen können. In solchen Fällen kann die helfende oder hemmende Begleitung durch einen Scrum Master oder Agile Coach Sinn machen.

Montag, 14. August 2017

Organizations that are fit for the Future

FS
Das Internet hält offensichtlich einen nie versiegenden Nachschub mitreißender Redner bereit. Die neueste Entdeckung ist Gary Hamel, der sich das Thema der zukunftsfähigen Organisationen zu eigen gemacht hat:

Gary_Hamel from Speaking.com on Vimeo.


Wie viele professionelle Konferenzredner ist er nicht nur rhetorisch brilliant sondern verfügt auch über das Wissen wie man gute, den Vortrag unterstützende und trotzdem nicht ablenkende Powerpoint-Präsentationen erstellt. Und sein ab Minute 07.40 vorgestelltes Beispiel von "Reverse Accountability" in einer indischen Firma ist wirklich inspirierend.

Donnerstag, 10. August 2017

Why agile: Feature-Wettrennen

FS
Bild: Pixabay / Macayran - CC0 1.0
Zu agiler Softwareentwicklung in der Lage zu sein kann vor allem für Firmen in umkämpften Märkten Vorteile bringen. Kurze Time to Market, schlanke Prozesse und schnelle Feedbackzyklen sind zwar eigentlich immer erstebenswert, besonders aber in einer Situation: wenn mehrere Unternehmen vergleichbare Produkte entwickeln und sich dabei einen Wettlauf um neue Features liefern. Jede der beteiligten Firmen versucht Kunden zu gewinnen und an sich zu binden indem sie zum Einen alle Funktionen der Konkurrenz kopiert und zum Anderen das eigene Produkt immer schneller weiterentwickelt, um so dauerhaft einen Vorsprung zu haben. Um konkurrenzfähig zu bleiben müssen die anderen mitziehen, und so geht es weiter und weiter, bin einer nicht mehr mithalten kann und aufgeben muss.

Die beiden Firmen die diese Vorgehensweise am weitesten perfektioniert haben dürften vermutlich Facebook und Google sein, die sich bereits mehrere solche Wettläufe geliefert haben. Facebook hat einen solchen im Jahr 2009 sowohl gegen Twitter als auch gegen StudiVZ gewonnen und führt im Augenblick einen gegen Snapchat. Google hat alle anderen Suchmaschinen (Altavista, Yahoo, Lycos, Ask, Bing, etc.) weit hinter sich gelassen und 2009 seinen Landkartendienst gegen Apple um die Wette entwickelt. Der aktuelle Wettstreit findet gegen ein Unternehmen namens Pinterest statt, das im Nischenmarkt der Bildersuche und -kuratierung ein Konkurrent ist. Beide Firmen arbeiten zeitgleich an Bilderkennung und Schnittstellen, wodurch z.B. Kuchenbilder sowohl mit ähnlichen Aufnahmen als auch mit Rezepten verknüpft werden können.

Pinterest vs. Google

Auf lange Sicht bedenklich ist, dass die beiden Großunternehmen durch ihre Fähigkeit Feature-Wettrennen zu gewinnen praktisch jede neue Konkurrenz marginalisieren können. Selbst disruptive Technologien und Ideen bringen wenig wenn ein bereits etablierter Wettbewerber sie in kürzester Zeit kopieren und in sein Produkt einbauen kann. Auf der anderen Seite kann man gespannt sein ob der ständige Nachbau von Konkurrenzprodukten nicht irgendwann zu überladenen Funktionsumfängen und Codebases führen wird. Die wiederum wären für Agilität hinderlich.

Montag, 7. August 2017

Diversität

FS
Bild: pxhere - CC0 1.0
Der Sturm der in den letzten Tagen durch das Wasserglas der Tech-Industrie gegangen ist drehte sich um die Firma Google, genauer gesagt um deren Maßnahmen zur Diversitätsförderung. In einem kontroversen und viralen Diskussionsbeitrag wurden diese von einem Mitarbeiter in Frage gestellt, da sie aus seiner Sicht zwar gut gemeint aber schlecht umgesetzt sind [Edit: Da ich es anscheinend nicht deutlich genug formuliert habe - nein, ich teile diese Meinung dieses Herrn nicht]. Selbst in diesem Beitrag wird Diversität aber als etwas grundsätzlich Notwendiges betrachtet, eine Sicht der Dinge die immer populärer wird. Es stellt sich die Frage - warum ist das so? Warum ist Diversität unter den Mitarbeitern etwas Erstrebenswertes? Und bringt sie einem Unternehmen wirklich einen Mehrwert? Ja, das tut sie, und zwar aus mehreren Gründen.

Zunächst deshalb, weil diverse Teams in der Regel eine größere Vielfalt an möglichen Innovations- oder Lösungsoptionen erarbeiten können. Entgegen einer häufigen Annahme allerdings nicht weil Diversität das befördert sondern weil Gleichartigkeit das behindert. Je homogener eine Gruppe ist, desto einmütiger denkt sie und verhält sie sich. Dieses Phänomen, das so genannte Group Think, wird durch diverse Teams aufgebrochen.

Als Zweites kommt ein wirtschaftlicher Aspekt dazu. In Zeiten des Fachkräftemangels ist es nahezu fahrlässig wenn weite Teile der Bevölkerung einem Segment des Arbeitsmarktes nicht zur Verfügung stehen. Man muss dazu nicht nach Kalifornien blicken, es reicht ein Blick in eine Maschinenbau-, IT- oder Buchhaltungsabteilung eines beliebigen deutschen Unternehmens. Frauen und Gastarbeiter-Kinder sind hier sehr, sehr, selten. Angesichts zahlloser unbesetzter Stellen ist das ein Zustand den zu ändern sich lohnen würde.

Zuletzt kann Diversität zu einer besseren (weil ausgeglicheneren) Firmenkultur führen. Es ist ein tiefer Griff in die Klischee-Kiste, aber rein männliche Teams neigen häufig zu einer gewissen Ruppigkeit im Umgang, Teams aus älteren Mitarbeitern hinterfragen Routinen seltener und rein deutsche Teams sind tendenziell weniger sensibel gegenüber kulturellen und religiösen Befindlichkeiten ausländischer Mitarbeiter (und Kunden). In diversen Teams ist all das meistens besser.

Natürlich ist Diversität nicht die Wunderlösung für alles, die gibt es nicht. Gerade in agil arbeitenden Unternehmen, solchen also in denen Offenheit und Anpassungsfähigkeit eminent wichtig sind, ist sie ein wichtiger Baustein für Erfolg und Wettbewerbsfähigkeit. Dass man damit auch Kontroversen auslösen kann zeigt das oben genannte Beispiel Google [Edit: Siehe dazu auch diesen Beitrag in der Zeit, diesen aus der FAZ oder diesen aus der New York Times]. Allerdings ist davon auszugehen, dass sich auch hier mittels Inspect & Adapt eine Lösung finden lassen wird.

Samstag, 5. August 2017

lean-agility.de

FS
Bild: Flickr / Chris Dlugoz - CC BY 2.0
Eine Nachricht aus dem Maschinenraum: da sich in der letzter Zeit die Beschwerden über die schwer zu merkende Blogspot-URL dieser Website gehäuft haben hat jetzt ein Umzug stattgefunden. Die neue URL ist http://www.lean-agility.de und hoffentlich einfacher im Gedächtnis zu behalten.

Die bisherige Blogspot-URL besteht immer noch, leitet aber auf die neue Web-Adresse weiter. Es ist also nicht nötig gesetzte Links anzupassen, sie sollten weiterhin funktionieren.

Zusammen mit der URL wurde auch der Seitenname angepasst, er hat jetzt mehr Bezug zu den hier behandelten Themen. Auch das ist ja von Zeit zu Zeit kritisiert worden.

Soviel dazu, Maschinenraum Ende.

Donnerstag, 3. August 2017

Make Rules Explicit

FS
Bild: Wikimedia Commons / Emon Khan - CC BY-SA 4.0
Manchmal ergeben sich die spannendsten Diskussionen dort wo man sie am wenigsten erwarten würde. Im Rahmen eines Kanban-Workshop bei einem Kunden gab es den größten Gesprächsbedarf zu dem Grundsatz, dass alle Regeln unzweideutig formuliert werden müssen. Eigentlich eine Selbstverständlichkeit - bevor eine Organisation ihre Prozesse optimieren kann müssen alle ihre Mitglieder das selbe Verständnis haben wie diese Prozesse überhaupt aussehen, sonst versuchen verschiedene Personen "in verschiedene Richtungen zu optimieren", was selten gut geht.

In diesem Fall ergab sich allerdings an dieser Stelle starker Widerspruch. Es wäre Best Practice und seit je her üblich, dass Regeln "hinreichend unscharf"formuliert sein müssten. Nur dadurch könne man sicher sein, im Zweifel nicht unnötig in der eigenen Entscheidungsfreiheit eingeengt zu werden. In der Vergangenheit habe es zwar immer wieder Versuche gegeben die Regeln zu verschärfen, das sei aber immer wieder an der Realität gescheitert. Damit jetzt wieder anzufangen wäre unnötig und kontraproduktiv.

Ein Blick in die firmeninternen Regelwerke zeigte deutlich was mit "hinreichend unscharf" gemeint war. Immer wieder tauchten Einschränkungen oder Verallgemeinerungen auf, wie etwa "so weit wie möglich", "falls machbar", den üblichen Standards entsprechend", "erfahrungsbasiert" oder "je nach Erfordernis". Letztendlich hätte man sich die kompletten Dokumente sparen können, unterschwellig zog sich durch alle die Aussage "jeder macht was er will und keiner fragt genau nach".

Nach längerer Diskussion schälte sich langsam die wirkliche Begründung dieses Zustands heraus. Ohne diese Relativierungen und Verallgemeinerungen wären die Vorgaben einfach nicht erfüllbar gewesen. An einer Stelle liefen sie beispielsweise darauf hinaus, dass die Übergabe neu programmierter Features an die nächste Abteilung erst erfolgen durfte wenn die Auswirkungen ihrer Integration in das Altsystem klar waren. Das Problem - Integrationstests fanden erst noch später in der Prozesskette statt, die Auswirkungen konnte also noch niemand wissen.

Das unzweideutig machen der Regeln (das dann doch beschlossen wurde) führte in diesem Fall zu der für viele schockierenden Erkenntnis, dass ein Großteil der eigenen Prozesse aufgrund ihrer eigenen Widersprüchlichkeit gar nicht funktionieren konnte. Als logischer nächster Schritt wurde ein Großteil davon gestichen, das übrigens gegen den erbitterten Widerstand des eigenen Qualitätsmanagements. Wie sich herausstellte hatte das seine Aufgabe vor allem darin gesehen den Teams immer härtere Auflagen aufzudrücken ohne sich um deren Umsetzbarkeit zu kümmern.

Dieses wildgewordene Qualitätsmanagement einzufangen ist jetzt die nächste große Herausforderung in diesem Unternehmen. Und dass man sie angeht (und damit einiges verbessert) wäre bei den alten, "hinreichend unscharfen" Formulierungen vermutlich nicht passiert. Das unzweideutig machen der Regeln hat sich bereits ausgezahlt.

Montag, 31. Juli 2017

Kommentierte Links (XXVII)

FS
  • Foreign Policy: 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.

  • TechBeacon: 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

    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

FS
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

FS
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

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.

Donnerstag, 22. Juni 2017

Rolling Wave-Planung

FS
Bild: Unsplash / Tim Marshall - CC0 1.0
"Agil? Das ist doch nichts anderes als die Rolling Wave-Planung, das machen wir schon seit langem. Halt nur unter anderem Namen." Diesen Satz bekomme ich immer wieder aus dem (v.a. mittleren) Management meiner Kunden zu hören, meistens als Begründung dafür, dass man gar nichts ändern muss. Es ist ja bereits alles da. Aber - ist es das wirklich?

Zunächst eines vorweg: Rolling Wave-Planung (auch Rollierende Planung) scheint unter den klassischen Management-Ansätzen derjenige zu sein, der der Agilität am nächsten ist. Die zu Beginn durchgeführten Planungen werden in festen Intervallen überprüft und angepasst. Gegebenenfalls kann im Vorgriff darauf auf die Detailplanung späterer Zeiträume verzichtet werden, das wird dann in den späteren "Wellen" nachgeholt. Ist das nicht genau das was mit agilem Arbeiten erreicht werden will? Diplomatisch gesagt - auch. Natürlich wird in Scrum & Co die Planung immer wieder an die aktuelle Situation angepasst, man könnte also Sprints und Wellen gleichsetzen. Der Unterschied ist die Grundlage auf der das geschieht.

In der Rolling Wave-Planung ist diese Grundlage das parallel zur eigentlichen Arbeit laufende Monitoring. Auf Basis der hier durchgeführten Fortschrittsmessung (in der Regel anhand der Abarbeitung von Arbeitspaketen) wird entschieden ob die Planung angepasst werden muss oder nicht. An den Markt oder die Anwender geliefert wird in diesem Modell weiterhin gegen Ende, wenn die Durchführung der Arbeit weitgehend abgeschlossen ist.

Im agilen Vorgehen ist das anders: die Grundlage für Änderungen sind in diesem Fall die in kurzen Abständen erfolgenden Lieferungen funktionierender Produkte, bzw. Teilprodukte (MVPs, Inkremente, etc). Im Idealfall sind diese so geschnitten, dass sie sofort dem Markt, bzw. dem Anwender zur Verfügung gestellt werden können. Geschieht das können User- und Marktfeedback sofort in die weitere Produktplanung einfließen.

Letztendlich kann man sogar ein Gegensatzpaar bilden: auf der einen Seite Planung in Intervallen bei gleichzeitiger durchgehender Produktion (rollierend), auf der anderen Seite durchgehende Planung bei gleichzeitiger Produktion in Intervallen (agil). Klingt ähnlich, ist aber etwas anderes.

Montag, 19. Juni 2017

Selbstorganisierte und sich selbst weiterentwickelnde Teams

FS
Bild: Wikimedia Commons / Ron Scheffler - CC BY-SA 2.0
Mit etwas Verspätung komme ich im Moment dazu Managing for Happiness von Jurgen Appelo zu lesen, ein Buch das ich jedem nur empfehlen kann. Einer der vielen guten Denkanstöße aus ihm ist die Unterscheidung zwischen selbstorganisierten und sich selbst weiterentwickelnden Teams (für das letzte benutzt er die Begriffe self developing und self educating). Ich habe diese Unterscheidung bisher nicht bewusst gemacht, würde sie aber aufgrund meiner Erfahrungen voll bestätigen.

Selbstorganisierte Teams haben die Inhalte und Ziele ihrer Arbeit, die Eigenheiten ihrer Software (oder ihres sonstigen Arbeitsgegenstandes) und die Funktionsweise ihres Organisationsframeworks (Kanban, Scrum, etc.) verstanden und können das Erlernte anwenden. Arbeit nach dem Pull-Prinzip, realistische Commitments und ständige Optimierungen durch Retrospektiven o.ä. sind gegeben. Was ich bei derartig selbstorganisierten Teams aber mehrfach erlebt habe war, dass sie durch sich ändernde Rahmenbedingungen völlig aus der Bahn geworfen wurden. Beispiele dafür waren neue Technologien, neue Produkte, neue Mitarbeiter oder neue Organisationsprinzipien. Die erlernten Lösungswege passten nicht mehr, häufig mit Chaos, Stillstand oder Rückfall in Kommandostrukturen als Folge.

Sich selbst weiterentwickelnde Teams sind mit den selben Herausforderungen konfrontiert, sind aber in der Lage sie zu überwinden. Was sie von den "nur" selbstorganisierten Teams unterscheidet sind das Ziel und das Ergebnis des ständigen Verbesserungsprozesses. In ihm geht es nicht nur darum Bestehendes zu optimieren sondern auch darum sich an Neues anzupassen, Neues zu lernen und Neues auszuprobieren. Im besten Fall werden sogar neuartige Ansätze proaktiv ausprobiert, selbst wenn es noch keine offensichtliche Notwendigkeit dafür gibt. Wenn sie dann da ist gibt es bereits Erkenntnisse auf deren Basis man mit der neuen Situation umgehen kann.

Wenn ich für das Coaching eines Teams genügend Zeit bekomme ist in meinem Transitionsmodell das Herausbilden der Fähigkeit zum sich selbst weiterentwickeln Teil der Experimentierphase, nach der das Team keine Unterstützung mehr brauchen sollte. Häufig wird sie von meinen Auftraggebern weggespart, wodurch oft Teams entstehen die durch unbekannte Entwicklungen wie oben beschrieben aus der Bahn geworfen werden können. Dem Management zu vermitteln was für ein Risiko das ist gehört zu meinen anspruchsvolleren Aufgaben, an denen ich weiterhin wachse.

Freitag, 16. Juni 2017

Agile Product Ownership in a Nutshell

FS
Seit mehreren Jahren schicke ich dieses Video immer wieder wieder an von mir gecoachte Product Owner. Zeit, dass es auch hier eingebunden wird.

Dienstag, 13. Juni 2017

Agile Planungshorizonte

FS
Bild: Pixabay / Ryan McGuire - CC0 1.0
Wenn eine Organisation als Ganzes agil werden möchte steht sie schnell vor dem Problem, dass die Idee ein- bis vierwöchiger Iterationen (Sprints) an ihre Grenzen stößt. Langfristige Planung ist mitunter unumgänglich und muss auch in den neuen Arbeitsweisen möglich sein. Umgekehrt können aber auch Situationen auftreten in denen das Warten auf den nächsten Sprintwechsel unverhältnismässig lange dauern würde. Manche Sachen haben eben nicht Zeit bis nächste Woche. Um zu verstehen welche Planungshorizonte und Reaktionsgeschwindigkeiten zu welchem Themenfeld passen empfiehlt sich eine Kategorisierung, zum Beispiel die nach Strategisch, Taktisch, Operativ und Situativ. Die Auswahl des passenden Vorgehens lässt sich dadurch deutlich vereinfachen.

Strategischer Planungshorizont

Der Name sagt es bereits: auf dieser Ebene geht es um langfristige Weichenstellungen. Das kann etwa bedeuten, dass das Unternehmen sich ein neues Tätigkeitsfeld sucht. Ein gutes Beispiel dafür ist Nokia, das als Papierfabrik begann, später Gummiprodukte herstellte und schliesslich zu einem Technologiekonzern wurde. Eine andere langfristige Umstellung ist die agile Transformation selbst, wie z.B. die der ING. Langfristige Orientierung bedeutet übrigens nicht, dass es keine kurzfristigen Entscheidungen geben kann, sie sollten aber auf das strategische Ziel einzahlen.

Taktischer Planungshorizont

Hier geht es um die mittelfristige Planung, zum Beispiel wenn für eine Produktneuheit das Weihnachtsgeschäft noch mitgenommen werden soll oder wenn sich zum Jahresende die Gesetzeslage ändert. Gegebenenfalls bedeutet das, das man früher mit einem kleineren Funktionsumfang live geht oder Ressourcen von einem Produkt zu einem anderen verschiebt. Vor allem in Unternehmen die ihr Budget bisher jahresweise verplanen ist das eine Umstellung die größer ist als man im ersten Moment denken sollte, nicht zuletzt weil es Jahresziele und Erfolgsboni in ihrer bisherigen Form unmöglich machen kann.

Operativer Planungshorizont

Hier sind sie, die Sprints. Planung für ein bis vier Wochen, Review, Retrospektive, neue Planung, etc. In den meisten Fällen wird es auf dieser Ebene keine größeren Weichenstellungen mehr geben, sondern nur noch Anpassung und (Re)Priorisierung von Sprintzielen und Sprintinhalten. Auch das Abbrechen von Sprints gehört hierhin. In vielen Teams ist diese Planungstiefe und -frequenz die Einzige, was allerdings ein Antipattern darstellt das man beseitigen sollte.

Situativer Planungshorizont

Ein Grenzfall. Kann man bei kurzfristigen Änderungen noch von Planung sprechen? Ja, man kann, wenn das große Ganze dabei im Blick bleibt. Jidōka (das Beheben einer Fehlers sofort nach seiner Entdeckung) gehört in diesen Bereich, aber auch das Beheben von Impediments oder das Aufteilen von sich als zu groß herausstellenden Arbeitspaketen in kleinere.

Was übrigens bei diesen Planungshorizonten klar sein muss - sie entsprechen nicht notwendigerweise Hierarchiestufen. Strategische Weichenstellungen können auch zusammen mit den an der Umsetzung beteiligten Teams erarbeitet werden und umgekehrt können Manager sich als Stakeholder an Sprint-Reviews beteiligen. Agil zu arbeiten bedeutet, dass auch solche Konstellationen möglich sein müssen.

Donnerstag, 8. Juni 2017

Organisation als Kommunikation

FS
Was dieses Video auf den ersten Blick beeindruckend macht sind die Visualisierungen, deren Erstellung Stunden in Anspruch genommen haben muss. Darüber hinaus enthält die Beschreibung von Organisationen als Ergebnis von Kommunikation die Vorarbeit verschiedener wissenschaftlicher Pioniere (ich meine u.a. Luhmann, Weick und Shannon/Weaver erkannt zu haben). Inspirierend, tiefsinnig und trotzdem verständlich aufbereitet. 17 gut investierte Minuten.

Dienstag, 6. Juni 2017

Organisierte Verantwortungslosigkeit

FS
Bild: Flickr / Nologo Phptpgraphy - CC BY-SA 2.0
Eines der beherrschenden Nachrichtenthemen der letzten Tage war ein Polizeieinsatz in einer Nürnberger Berufsschule. Polizisten hatten einen afghanischen Jugendlichen aus dem Unterricht abgeholt um ihn abzuschieben, woraufhin sich viele Mitschüler spontan mit ihm solidarisierten. Es kam zu Sitzblockaden und Befreiungsversuchen, die Polizei setzte Reizgas und Kampfhunde ein. Nun ist das Thema Asyl und Abschiebung sicher zu komplex um hier behandelt zu werden, eines kann man aber sagen: der Einsatz hätte in dieser Form besser nicht stattfinden sollen. Dass er doch stattfand lässt sich durch ein Phänomen erklären, dass man als "organisierte Verantwortungslosigkeit" bezeichnen kann und das in ähnlicher Form auch in vielen Unternehmen vorkommt.

Eines kann man mit hoher Sicherheit voraussetzen: niemand hat die Anweisung gegeben, dass ein auszuweisender ausländischer Berufsschüler aus einem laufenden Unterricht herauszuholen ist. Zu groß sind die Risiken, dass dabei genau solche Situationen entstehen wie die aus der letzten Woche in Nürnberg. Dass es trotzdem passiert ist lässt sich dadurch erklären, dass der Abschiebe-Vorgang durch eine hohe Gewalten- und Arbeitsteilung geprägt ist. Zunächst entscheidet das Bundesamt für Migration und Flüchtlinge (BAMF) über die Gewährung des Asylantenstatus, bei Ablehnung organisiert die Zentrale Ausländerbehörde (ZAB) die Abschiebung, durchgeführt wird sie schließlich von der Polizei. Die Polizei Mittelfranken hat diese Vorgangskette bestätigt. Was jetzt anscheinend passiert ist: Die Behörde 1 (das BAMF) hat den Abschiebevorgang eingeleitet, die Behörde 2 (die ZAB) hat das Datum festgelegt, die Behörde 3 (die Polizei) bekam die Anweisung zur Durchführung der Abschiebung. Dass der Asylbewerber sich zu diesem Zeitpunkt in der Berufsschule aufhalten würde war unklar, als es bekannt wurde hatte der Einsatz bereits begonnen.

Von organisierter Verantwortungslosigkeit kann man an dieser Stelle sprechen weil alle beteiligten Behörden sich darauf berufen können nicht verantwortlich für die eskalierende Situation zu sein, da jede einzelne von ihnen lediglich den organisatorischen Teilvorgang abgewickelt hat für den sie zuständig war, und zwar genau so wie es vorgeschrieben gewesen ist. Man kann nicht einmal wiedersprechen: der stark arbeitsteilige Prozess dürfte eine gewisse Zwangsläufigkeit gehabt haben, da zum kritischen Zeitpunkt (dem Moment in dem klar war, dass der Zugriff in einer Schule stattfinden würde) die Sachbearbeiter in BAMF und ZAB (die einen Aufschub hätten anordnen können) ihren Teil der Arbeit bereits erledigt hatten und am Vollzug ihrer Entscheidungen nicht mehr beteiligt waren.

Ein Schritt zurück auf die Meta-Ebene. Dass niemand eine Gesamtsicht auf alle Vorgänge und eine Kompetenz zum Aufschieben des Zugriffs hatte ist genau so gewollt gewesen. Wer auch immer diese Prozesse designed hat, hat es genau so vorgesehen, weil er sich davon irgendetwas versprochen hat - Effizienz, Neutralität der Beteiligten, was auch immer. Derartige gut gemeinte, in der Anwendung aber oft verheerende Vorschriften findet man in nahezu jeder Organisation, egal ob Behörde, Unternehmen, NGO oder sonstiges. Und wenn alle nur ausführen und niemand wirklich verantwortlich ist, ist häufig eine darauffolgende zweite klassische Fehlerquelle die Konsequenz: das "Ballistische Entscheidungsverhalten" bei dem Entscheidungen schnell abgefeuert werden, ihr "Einschlag" aber ausserhalb des Sichtbereiches stattfindet.

Die Lösung kann in solchen Fällen nur sein, Positionen mit Gesamtsicht zu schaffen, Feedback der unteren Ebenen zuzulassen und den Zuständigen im Einzelfall Entscheidungsfreiraum zu geben. Dort wo das nicht der Fall ist, ist die Ausbreitung der organisierten Verantwortungslosigkeit vorprogrammiert - mit allen Konsequenzen.
Powered by Blogger.