Huch! Schon so spät?
Kaum ist der Sommer vorbei naht auch schon das Jahresende.

Rolf und Peter haben sich für einen Termin Anfang November entschieden – knapp zwei Wochen vor dem Barcamp in der Spinnerei.
Kaum zu glauben: das war das letzte agiLE-Meetup für 2017.

Wir waren zu Gast im Basislager. Wir konnten einige neue Gesichter begrüßen. Drei von ihnen haben Sessions angeboten.

Wie immer hatten wir zwei Durchgänge, unterbrochen von einer Pizza-Runde.
Aufgrund der überraschend niedrigen Teilnehmerzahl haben wir nur zwei Sessions parallel abhalten können.
Die vier Themen bestimmte die Gruppe per Magischer Priorisierung.

Dieses Meetup war ausdrücklich auch dazu gedacht, ein Thema für das Barcamp zu verproben. Wer noch zweifelt, hatte die Möglichkeit, in diesem Meetup einen ersten Markttest vorzunehmen.

Mein persönlicher Favorit “Asmimov’s Principle” hat es nicht in die engere Auswahl geschafft. Aber Sveto ist mit dieser Session ohnehin für’s Barcamp gefeatured. Ich bin guter Dinge, dass ich sie dort erleben werde. Hoffentlich wird sie nicht parallel zu der Session liegen, die ich anbieten möchte.

/erster Durchgang

Dadurch, dass ein parallel liegendes Meetup im Basislager nicht zustande kam, hatten wir zwei Räume über die wir uns ausbreiten konnten.
Die nachfolgenden Berichte orientieren sich an der Reihenfolge, wie im Anschluss die Erkenntnisse vorgetragen wurden.

/Overcommitment

Das Phänomen, das in der ersten Session besprochen wurde ist weithin bekannt als “Overcommitment”. Teams nehmen sich zu viel vor und übertragen ihre Lieferschulden immer wieder in die nachfolgenden Iterationen. Auf diese Weise wird eine Bugwelle vor sich hergeschoben.
Das Bild eines Schneeräumfahrzeuges im Einsatz kommt dem auch recht nahe.

Alles kann einmal passieren. Wenn aber Themen zu lang auf sich warten lassen, führen permanente Nachläufe zu ernsthaften Probleme beim anschließenden Merge in die CI-Umgebung.
Der vermeintliche Vorteil durch einen zeitlichen Aufschub wird durch spätere Mehraufwände unnötig teuer erkauft.

Im konkreten Fall hatte Thomas S. einen großen Datenschatz im Zugriff. Er hat die Sprintergebnisse von 400 bzw. 50 Sprints zur Auswertung heranziehen können. Es gab einzelne Teams, denen die wünschenswerte Punktlandung wiederholt gelang. Andere Teams schleppten regelmäßig Stories über mehrere Sprints mit sich herum. Neben der permanenten Belastung im Team, kamen noch kolleterale Auswirkungen zum Tragen. Die bereits angesprochenen Probleme beim Stabilhalten der CI-Umgebung waren die offensichtlichsten.

Wir tasteten uns vor bis zu der Bedeutung, die dem Status “in progress” in seinem Umfeld beigemessen wird. Überraschenderweise kam es den Stakeholdern anscheinend weniger auf den status “done” als auf “in progress” an. Wenn ein Team auf Nachfrage zu einer bestimmten Story “ist in Arbeit” antwortete, dann schien dies ausreichend zu sein. Nun tendieren alle Menschen in Gruppen dazu, das zu liefern, was ganz offensichtlich gewünscht wird. Und hier hat sich nun ein Kommunikationsmuster eingeschlichen, in dem “in Arbeit” die gewünschte Antwort zu möglichst vielen Punkten auf der Liste ist. Ohne weitergehende Reflektion hat die Organisation die falschen Anreize gesetzt. Mit den beschriebenen Folgen.

20% in to do and 80% in progress is nothing to ship!

Jetzt, wo die Situation reflektiert und analysiert wurde, hat man etwas, womit und woran man arbeiten kann. Eine Umstellung der Präferenzen und Fragestellungen könnte in der naheliegenden Zukunft zu einer Verbesserung der Ergebnisse führen.

Wie also sollten Stakeholder ihre Nachfragen besser formulieren?

• Wann beginnt Ihr mit der Umsetzung?
• Wann ist diese Story fertig zur Auslieferung?
• Wieviel wird in diesem Sprint fertig?

Oftmals hat ein Verschleppen von Stories auch andere Ursachen. In Ermangelung fertiger Stories (Stichwort “DoR”), werden halbgare Arbeitspakete begonnen, um überhaupt etwas tun zu können. Andernfalls droht ja der berüchtigte “Out of Story-error”.
Hier kann ein Besprechen und Überdenken der Glaubenssätze wahre Wunder bewirken.

Was wird in der Organisation höher bewertet?
Beschäftigt zu sein (oder zumindest so zu wirken) oder etwas zum Abschluss zu bringen?

Ein Spitzenthema für eine Retro …

/Retromüde

Sophie G. hat das Thema für die parallele Session geliefert. Es wurde besprochen, dass in einer Organisation die Mitglieder der Entwicklungsgruppen mit Müdigkeit und Unlust auf das Angebot von Retrospektiven reagieren.

Es stellte sich heraus, dass die Ursachen dafür außerhalb der einzelnen Teams zu suchen sind. Es sind strukturelle Probleme, die aus Zielrichtungen herrühren, die nicht miteinander in Einklang stehen.

Externe Einflüsse bspw. aus dem Vertrieb führen dazu, dass mehr Arbeit akquiriert wird, als geleistet werden kann. Die Gründe dafür sind nachvollziehbar und keinesfalls verwerflich. Die Auswirkung aber ebenfalls ernst zu nehmen. Wenn dieser Zustand über einen längeren Zeitraum anhält, kann die punktuelle Frustration zu “Burn-Out” und den damit verbundenen Auswirkungen in Fluktuation und Krankenstand führen.

Um es klar zu sagen: jeder handelt in einer solchen Situation mit den besten Absichten. Solange aber keine Klarheit über die gegenseitigen Abhängigkeiten und die Auswirkungen des jeweiligen Handels geschaffen werden, wird diese Konfliktsituation nicht zu überwinden sein.

Es bleibt dann dabei

Ziel muss es also sein, eine Synchronität über Entwicklungsgruppen und angrenzende Einheiten herzustellen.
Agilität ist keine Sache eines einzelnen Teams, sondern der ganzen Organisation.

Bei der Besprechung dieses Ergebnisses hat Matthias (?) eine Anregung aus seiner Erfahrung gegeben. Er hat beim allseits beliebten Starfish einen Kreis eingezeichnet. Auf diese Weise wurde klar, welche Dinge das Team selbst in die Hand nehmen kann und wo der Schmerz von äußeren Faktoren herrührt.

Jetzt, da man weiß wo die Ursachen liegen, kann man sich darauf besinnen, wie man mit ihnen umgehen möchte.
Lösen oder aushalten? Aber das ist eine andere Geschichte …

/Pizzapause

Um die Sessions herum habe ich mit Julia geplauscht … Glückwunsch!

Außerdem habe ich mich mit Sveto über die Geschichte ausgetauscht, wie es zu “Asimov’s Principle” als Session-Angebot für das Barcamp kam. Wir rissen dann noch Asimovs Geschichte insgesamt, SciFi (Stanislaw Lem) und ein wenig unser gemeinsames Interesse für die neu entstandene Meetup-Gruppe “Blockchain for Society” an.

/zweiter Durchgang

Weitere spannende Themen folgten im zweiten Durchgang.

/Ist Konzipieren bei “Agile” erlaubt?

Falk bot ein immer wiederkehrendes Thema im Umgang mit “dem Neuen” an.

Es kommt recht oft vor, dass eine Aufgabe nicht eingeschätzt werden kann. Zur Einschätzung ist tieferes Verständnis für die Materie erforderlich. Nicht nur die gewünschte Funktion sollte gedanklich erfasst werden. Oftmals benötigen Entwickler auch eine Vorstellung davon, wie sich die gewünschte Vorstellung umsetzen lässt. Welchen Einfluss wird eine möglicherweise noch in Teilen unbekannte Technik oder ein neues Werkzeug auf die Umsetzung haben?

Kurz gesagt

ein Konzept erhöht die Planungssicherheit.

Jetzt haben wir aber die Situation, dass am Ende des Sprints “potential shippable software” entstanden sein soll – keine Dokumente. Sprintlänge und sonstige Rahmenbedingungen sind stabil und vorgegeben. Allerdings fehlen Erfahrungswerte, wie eine Story dort hinein passt und wieviel Raum sie benötigt. Eine verlässliche Zusage (“Commitment”) kann nicht ausgesprochen werden.

Die Abhilfe: Spiking

Es wird ein bestimmter Anteil an verfügbaren Zeitressourcen des nahenden Sprints dafür reserviert und darauf verwendet, eine Exploration vorzunehmen. Ein Teil oder das gesamte Team macht sich mit dem zukünftigen Terrain vertraut. Daraufhin kann man die Erkenntnisse festhalten und die erkannten Grundprinzipien beschreiben. Das gewonnene Wissen kann nun vermittelt, verteilt und in der Praxisanwendung vertieft werden.

Wie immer im Zusammenhang mit “Lernen” ist Hektik und Zeitdruck kontraproduktiv für das Ergebnis. Zumindest, wenn es sich um menschliches Lernen handelt. So empfiehlt es sich, den Spike mehrere Sprints vor der eigentlichen Umsetzung durchzuführen. So bleibt genug Zeit, um das Gelernte zu “verdauen”.

Natürlich wollen die Beteiligten möglichst rasch Ergebnisse sehen. Am liebsten wäre den Stakeholdern eine sofortige Verfügbarkeit des Angeforderten. Auch die Mitglieder aus dem Kreis des Entwicklungsteams fühlen sich oft unwohl damit, Unwissenheit zuzugeben.

Aber wie so oft

In der Ruhe liegt die Kraft.

Anstatt vorschnelle Zusagen zu treffen, um diese im Anschluss doch zu brechen, empfiehlt es sich, die Zeit zu nehmen und im Anschluss Zusagen einzuhalten.
Das ist jedoch eine Frage des Umgangs miteinander und damit mal wieder eine ganz andere Geschichte …

/mein Nutzen ist größer als Deiner!

Ich nahm im zweiten Durchgang an einer anderen Session teil. Es war die Zusammenlegung der Themen ‘Bestimmung von Business Value’ (Frank S.) und der Wettstreit von Themen um Entwickler-Kapazitäten (Thomas L.).

Während es bei der Schätzung des Umfangs einer Story darum geht, die Aufgaben möglichst klein zu schneiden (1,2,3 … 13), geht es bei der Bestimmung des Geschäftswerts darum, den möglichst größten Wert bspw. als Kundennutzen (Bild rechts) zu identifizieren.
Wenn man die unechte Fibounacci-Reihe zur Grundlage nimmt, dann ist die bevorzugte Reihenfolge in etwa 100, 60, 40, 20. Man kann natürlich auch gern Prozentschritte suggerieren und 100, 80, 60 … als Metrik verwenden.

Wichtig bei einer Konkurrenz über Teamgrenzen hinweg ist, die selbe Metrik und das selbe Vorgehen zur Bestimmung zu verwenden. Nur so entsteht wirkliche Vergleichbarkeit. Entweder man priorisiert die konkurrierenden Themen gemeinsam oder man verwendet einen durch alle akzeptierten und über alle Themen anwendbaren Algorithmus zur objektiven Bestimmung eines Geschäftswerts. Das können bspw. Parameter wie erzielbare Kundenreichweite und Umsatzpotenzial sein.

Achtung!

Bei der Verwendung eines diskreten Algorithmus läuft man Gefahr, einseitig zu priorisieren und sich einer “Pseudo-Objektivität” hinzugeben. Durch die Einführung eines Berechnungsverfahrens wird zwar die Bestimmung der Werte vereinfacht, der Raum für Missbrauch, Fehleinschätzungen und Unzufriedenheit wird dafür umso größer. Der Algorithmus mag stabil sein, die bestimmenden Parameter sind es nicht …
Ferner wiegen “Deployment-Probleme” bei der Anpassung an veränderte Umstände schwer.

Auch hier ist die “Magische Priorisierung” durch die Konkurrenten ein probates, alternatives Mittel. Durch die gleichzeitige Anwesenheit der Konkurrenten hat jeder die Möglichkeit, seine Einschätzung mit seinen Mitstreitern zu teilen und zu einem Unternehmenszweck ins Verhältnis zu setzen.

Ein als wichtig identifizierter, weiterer Aspekt ist noch die Detailtiefe bei der gegenseitigen Abwägung.
Eine Konkurrenz auf Story-Ebene kann dann leicht dazu führen, dass man ein Vorhaben unnötig in die Länge zieht und zu viele Vorhaben parallel “in progress” geraten – s. oben.
Eine Konkurrenz auf der Abstraktionsebene “Theme” bis runter auf “Epic” erschien uns da geeigneter.

Wie auch immer man den Geschäftswert also bestimmt, in einer Konkurrenz-Situation sollte man die gleichen Maßstäbe an die Elemente des gesamten Arbeitsvorrats – Company/Program Backlog – anlegen. Andernfalls landet man bei willkürlichen Kriterien wie “first come – first serve” oder “wer kann am lautesten?”

/Abschluss

Am Ende der Zusammenfassung gab Rolf einen kurzen Ausblick auf das Barcamp in knapp zwei Wochen.
Das nächste agiLE-Meetup erwarten wir im Januar. Es gibt schon Kandidaten für die Rolle des Hosts.

Bis dahin

Stay calm and iterate!

/etc

Alles, was ich sonst noch für teilenswert ansehe gibt es auf meinem twitter-Kanal.

/Inspiratoren

• Asimov
• Turing
• Lem

/weiterführende Quellen

• Who is “Spike“?
• KANO-Modell
• It’s all about alignment
• Understanding of Importance Conflicting with Success

/Lebewohl

Lebe lang, in Frieden und Wohlstand.
Mögen sich alle Bedürfnisse in Realität auflösen.

/ berühmteletzteworte

Das Leben verläuft in Kreisen. Manche sind größer, andere kleiner.
An Ihrem Ende findet sich kein Ende, sondern ein neuer Anfang.

Sprich zu denen, die es angeht und teile, was Dir wichtig ist.
Sharing is caring.