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.

Freitag, 2. Juni 2017

Timeboxing

FS
Bild: Pixabay / Annca - CC0 1.0
Wenn Anforderungen geschätzt werden müssen haben Entwicklungsteams die Auswahl zwischen verschiedenen Ansätzen. Zeiteinheiten, Story Points, T-Shirt-Größen, No Estimates oder sonstige Einheiten machen es möglich annäherungsweise zu bestimmen wann eine Aufgabe fertiggestellt sein wird. Ein Problem tritt allerdings auf wenn Arbeiten anliegen deren Umfang so unklar ist, dass eine Schätzung nicht möglich ist. Die Analyse eines schlecht dokumentierten Legacy-Systems könnte ein solcher Fall sein. Wie geht man damit um?

Viele Teams versuchen auch in diesen Fällen ihre Standard-Methode anzuwenden, beispielsweise indem sie "nach Bauchgefühl" Story Points vergeben. Diese Werte sind natürlich wild geraten und werden nur in den seltensten Fällen mit der Realität übereinstimmen, wodurch die langfristige Velocity verfälscht und verzerrt werden kann. Eine andere Möglichkeit ist es überhaupt keine Bewertung abzugeben und einfach "so lange zu arbeiten bis es fertig ist". Auch das ist ein riskanter Ansatz, da er die Gefahr in sich birgt, dass Arbeiten unnötig detailliert ausgeführt werden und zu lange dauern.

Empfehlenswerter ist es in solchen Situationen mit Time Boxes zu arbeiten. Das Team beschließt z.B. für eine bestimmte Aufgabe zwei Tage zu investieren. Das bedeutet natürlich nicht, dass die Arbeit nach zwei Tagen abgeschlossen ist. Es macht es aber möglich anzuhalten, den erreichten Zwischenstand zu betrachten und basierend darauf zu entscheiden wie es weitergehen soll.

Vielleicht ist die verbliebene Unklarkeit so klein, dass eine Schätzung jetzt möglich ist. Vielleicht lässt sich bereits sagen, dass die untersuchte Software nicht den Anforderungen entspricht, so dass weitere Untersuchungen wegfallen können. Vielleicht muss aber einfach eine weitere Timebox in den nächsten Sprint geschoben werden, auch das ist möglich. In jedem Fall ermöglicht das Timeboxing aber ein strukturiertes Umgehen mit einer schwer strukturierbaren Situation.

Ein manchmal auftretender Aufwand an dieser Stelle ist, dass man doch nicht verschiedene Methoden (z. B. Time Boxes und T-Shirt-Größen nebeneinander verwenden kann. Die Antwort: doch man kann. Man muss es nur wollen.
Powered by Blogger.