6 Sessions, die es in sich haben: Mein Abend beim AGILE.RUHR Stammtisch in Essen!

Der AGILE.RUHR Scrumtisch in Essen am 24. Mai 2018

Seit einigen Jahren gibt es den monatlich stattfindenden Stammtisch¹ in Essen rund um das Thema Agilität. Der Stammtisch wird von Berthold Barth organisiert und moderiert. Ich war am Donnerstag, dem 24.5.2018 zum zweiten Mal dabei und war wieder mal über die hochkarätigen Beiträge überrascht. Da ich mir viele Notizen gemacht habe, dachte ich, vielleicht ist es eine gute Idee die Beiträge allgemein zur Verfügung zu stellen. Falls ihr Fehler findet, meldet sie mir gerne. Ich korrigiere so schnell wie möglich.

Wie funktioniert so ein Stammtisch?

Zunächst gibt es als schönes Ritual ein Bier. Sehr gut! Dann werden Themen gesammelt und bewertet. Jeder darf 6 Punkte für Themen vergeben. Die Themen werden den Punkten nach sortiert und los geht es. Für jedes Thema gibt es eine Timebox von 10 Minuten. Trifft ein Thema auf weiterhin reges Interesse, gibt es eine Verlängerung um weitere 10 Minuten. In der Regel sind so auch anspruchsvolle Themen spätestens nach 30 Minuten “gegessen”.

"Ein guter AGILE.Ruhr Stammtisch in Essen beginnt bei einem kühlen Bier!"

Klick hier für einen Tweet

Mir persönlich haben alle Themen gefallen. Da dieser Artikel leider etwas sehr lang geworden ist, schlage ich vor, dass sich jeder einfach das herauspickt, was ihm gefällt.

Als los geht es und viel Spaß beim Lesen!

4 Zungen und 4 Ohren von Berthold Barth (@bertholdb)

Berthold thematisierte das Problem der Kommunikation und beschrieb, dass auch in einem Umfeld, wo die Leute eigentlich Kommunikationsprofis sein müssten, es manchmal an dieser hapert.

Das vorgestellte Kommunikationsmodell stammt von Friedemann Schulz von Thun² und hat recht weite Verbreitung gefunden.

Bei der Kommunikation unterscheidet von Thun folgende 4 Ebenen:

1. Die Sachebene
2. Die Selbstkundgabe
3. Die Beziehungsebene
4. Die Appellebene

Hier ein schönes Beispiel aus einer fiktiven Beziehung :-)

Die Frau sagt, “Das Salz ist leer”.

Was bedeutet das auf den verschiedenen Ebenen der Kommunikation?

1. Sachebene: “Das Salz ist leer.”
2. Appellebene: “Warum wird das Salz nicht endlich aufgefüllt?”
3. Beziehungsebene: “Ich fühle mich zurückgesetzt, weil (immmer) das Salz leer ist.”
4. Selbstkundgabe: “Ich bin sauer!”

Viele Probleme in der Kommunikation entstehen, wenn die Ebenen verwechselt werden. Eine Sachfrage wird als Kritik aufgenommen und eine Selbstkundgabe als Appell. Und der Kopf denkt auch mit und interpretiert wie die Botschaften wohl ankommen.

Als Beispiel nannte Berthold ein Ereignis aus seinem beruflichen Kontext: Die Projektmanagerin fragt, warum so viel auf das Projekt gebucht ist. Der Mitarbeiter fühlte sich zu Unrecht kritisiert, dabei war es nur eine reine Sachfrage (Verständnisfrage). Das wurde aber erst erkannt, als in einem moderierten Gespräch gemeinsam die Kommunikation bewertet wurde.

"Tipp: Probiert bei Kommunikationsproblemen demnächst mal das Modell von Schulz v. Thun aus."

Klick hier für einen Tweet

Veränderung der Führung von Brigitte Haupt

Agiles Arbeiten wird oft in vereinzelten wenigen Bereichen eingeführt. Das kann beispielsweise die Softwareabteilung sein. Diese ersten agilen Teams treffen dann auf eine klassische hierarchische Organisation, die noch nicht mit Agilität umgehen kann. Die Folge: Es entstehen Reibungen und Konflikte.

Insbesondere die Führungsrollen und die Führungskultur im mittleren Management sind bei agiler Arbeit gefordert. Wie gehen diese mit Instrumenten wie Steuerung und Intervention um?

Ein Zitat von Heinrich Zille:

Jeder schließt von sich auf andere und berücksichtigt nicht, daß es auch anständige Menschen gibt. (Heinrich Zille, Berliner Zeichner und Fotograf)

Beispiele aus der Praxis

In der Gruppe wurden Beispiele diskutiert:

• Unser Scrum-Team wartet darauf, dass die Führungskraft interveniert. Das war in der Vergangenheit immer der Fall, warum sollte es sich jetzt anders verhalten.

• In meiner Firma gibt es jetzt ein erstes agiles Projekt. Die Einführung agiler Arbeitsweisen wurde vom IT-Leiter befürwortet aber die PMO war dagegen. Ihre Argumente: SCRUM ist nicht planbar. Wir haben aber einen externen Berater, der mit Instrumenten wie Bulk Estimates³ aufzeigte, dass auch in SCRUM professionell geschätzt werden kann.

Mögliche Gründe aus Führungssicht

Lebhaft wurde diskutiert, welche Motive die Führungskräfte zu ihrem Verhalten bewegten:

• Selbsterhaltungstrieb: Führungskräfte fürchten um den Verlust von Aufgaben, Status oder sogar der ganzen Position.
• Entwertung der Arbeit: Kann ich als ehemalige Führungskraft mit einem möglicherweise hohen Gehalt auch “einfachere” Aufgaben übernehmen? Ab wann wird das fragwürdig?
• Zufriedenheit mit dem Status Quo: Warum sollte ich etwas ändern, was mir persönlich gefällt?

These: Die Kombination von fachlicher und disziplinarischer Führung ist Gift für die (agile) Organisation.

Lösungsideen und Erfahrungen

Spannend ist natürlich die Frage: Und jetzt? Wie kann man das Problem angehen und die Führungskräfte überzeugen oder sogar begeistern?

• Berthold: Bei Problemen kann das Tool “Delegation Poker” sinnvoll genutzt werden. Ich habe damit gute Erfahrungen gemacht.

• Michael: Wir haben in unserer Firma bewußt auf Stellenveränderungen verzichtet. Es wurden keine Schulterklappen abgerissen. Stattdessen haben wir auf die Aufgaben geschaut. Wichtig ist, dass keine Aufgaben liegen bleiben. Dadurch waren wir arbeitsfähig auch wenn manche Führungskraft jetzt “einfachere” Aufgaben hat.

• Daniela: Wir wollten, dass alle Ihre Titel behalten. Wir haben es den Führungskräften frei gestellt, sich der agilen Bewegung anzuschließen. Dazu haben wir Tribes gebildet. Einige Führungskräfte haben mitgemacht. Der Erfolg steckt an.

• Berthold: Es gibt nicht die Führungskraft. Jeder Mensch ist anders gestrickt. Ich habe aber festgestellt, dass ungefähr jede dritte Führungskraft von sich aus motiviert ist, da mitzumachen.

Agile Großprojektleitung nach SAFe von Reinhild (@steinhild)

Über SAFe

SAFe⁴ ist ein bekanntes Framework zur Skalierung von agilen Prozessen in Unternehmen. SAFe vereint (meiner Meinung nach) klassische Praktiken des Releasemanagements mit der Orchestrierung von agilen Scrum-Teams.

Zufälligerweise brachte Reinhild ein Poster des SAFe Frameworks mit und erklärte anhand des Posters ihre Erfahrungen als externe Beraterin bei der Einführung von SAFe im Kontext einer mittelgroßen Bank mit ca. 300 Mitarbeitern.

Über Kühe, Elefanten und Baumstämme

Die IT der Bank befindet sich in der Transformation zu agilen Arbeitsweisen. Mitten in der Transformation gab es eine wichtige, kritische regulatorische Änderung, die zur Jahresfrist 2018 umgesetzt werden musste: Ein riesiger Block an Themen, ein ganzer Baumstamm an Änderungen. Auf den Baumstamm kam Reinhild später noch zu sprechen.

Eigentlich ein klassisches Großprojekt, was aber konträr zur agilen Transition stand und daher auf eine andere Art und Weise gelöst werden musst. Voller Entsetzen stellte man dann fest: Wir haben ja wegen Agile überhaupt keine Projektleiter mehr!

Der Auftrag an Reinhild als externe Projektleiterin: Hol du mal die Kuh vom Eis. Es stellte sich heraus: Die Kuh ist eine Elefantenherde und das Eis war superdünn und sehr brüchig!

"Mein Auftrag: Hole die Kuh vom Eis! Aber was ist, wenn die Kuh eine Elefantenherde und das Eis brüchig ist?"

Klick hier für einen Tweet

Am Anfang gab es zwei agile Teams, die getrennt arbeiten konnten, aber das reichte nicht, um die Masse an Anforderungen in der Kürze der Zeit umzusetzen.

Der Release-Train

Die crossfunktionalen Entwicklungsteams wurden gemäß SAFe in mehreren Zügen zusammengefasst. Ein Zug oder “Release Train” sorgt für die integrierte Lieferung von größeren funktionalen Änderungen mehrerer Teams und orientiert sich an einem Value Stream.

Ein Zug wird laut SAFe von einem Systemarchitekten, einem Produktmanager (ähnlich wie ein Product Owner, nur auf Zug-Ebene) und einem RTE (Release Train Engineer, ähnlich wie der Scrum Master des ganzen Zuges) gesteuert.

Die Frage war jetzt, welche Rolle gibt es in SAFe für den “Kuh-vom-Eis-Holer” und die übergreifende Koordination der verschiedenen agilen Teams, da ja mehrere Züge betroffen waren? Die Schlüsselrolle dafür ist der “Epic Owner”. In SAFe werden die ein Bündel von großen Features Epics genannt (Wichtig: Wir sprechen hier über Epics im Kontext von SAFe, nicht von SCRUM). Der Epic Owner verantwortet also das Gesamtportfolio und die Steuerung der Value Streams, also der großen Produktflüsse.

Vom Baumstamm zur Scheibe zum Holzspan

Wenn die regulatorische Änderung mit einem großen Baumstamm zu vergleichen ist, dann ist die Aufgabe des Epic-Owners das “zersägen” des Baumstamms in die richtigen Scheiben und die Zuordnung an die Feature-Teams im Zug.

Ein Erfolgskriterium war, dass die Produktteams im Release Train auch vom Epic Owner unterstützt werden. Dadurch werden Abhängigkeiten zwischen den Teams und viele verschieden Arten von Risiken sichtbar.

Reinhild dazu:

Die Besetzung der Rolle des Epic-Owners war für uns der entscheidende Erfolgsfaktor und hatte Pionier-Funktion.

Diskussion

Reinhild - SAFe (bzw. alle Frameworks und Methoden) funktionieren nur dann, wenn wir aktiv auf die Menschen zugehen und gemeinsam Lösungen finden.

Mittlerweile funktioniert SAFe gut. Es gibt mehrere Value Streams, die frühzeitig definiert wurden. Auch durch die zusätzlichen Rollen nach SAFe ist die Organisation gestärkt, da sich viele klassische Funktionen in der SAFe-Welt wieder finden. Aber, am Ende des Tages ist der wesentliche Erfolgsfaktor, wie wir als Menschen miteinander umgehen. Kein Framework kann das abnehmen.

Berthold - Bitte bei der Einführung aufpassen!

Wir setzen bei uns auch SAFe ein. Ich war ein großer Kritiker von SAFe, muss aber zugeben, dass es für große Organisationen ein Weg ist, überhaupt in die Agile Organisation einzusteigen.

Meine Erfahrungen:

1. Wir haben zunächst keine Value-Streams gebildet. Das war im Nachhinein ein großer Fehler. Es ist wichtig, diese richtig zu schneiden. So werfen wir alles in einen Topf.
2. Auf der obersten Kanban-Ebene wird nicht richtig gearbeitet.
3. Bei uns hat sich die Verkürzung der PIs (Produkt Inkremente) von 6 auf 4 Sprints sehr positiv ausgewirkt. Eigentlich haben wir erwartet, dass der Overhead sich nachteilig auswirkt, das Gegenteil war der Val.

Ich finde, bevor man sich auf SAFe einlässt, sollte man sich Alternativen, wie Nexus ⁵ von der Scrum.org ansehen. Aber Vorsicht: Nexus funktioniert nur zwischen 3-9 Scrum-Teams.

André - Wo ist der kontinuierliche Verbesserungsprozess?

Wo ist der kontinuierliche Verbesserungsprozess in diesem Framework? Wo wird über die Arbeit reflektiert und Verbesserungen eingebracht?

Reinhild: Es gibt an verschiedenen Stellen im Framework Feedback - Schleifen. Beispielsweise in den Retrospektiven der Scrum-Teams

Wie gehe ich mit “organisatorischen Schulden” um von Michael (@MCimiotti)?

Michael: Meine Sicht auf das Thema

Wir kennen alle technische Schulden und haben Werkzeuge, um mit diesen umzugehen. Auch das Thema ist alles andere als einfach, aber wir haben das Thema als Team in der Hand. Aber wie gehen wir mit organisatorischen Schulden um?

Organisatorische Schulden sind Probleme, die in Folge fehlender organisatorischer Anpassungen an agile Prozesse entstehen. Ich habe den Begriff zum ersten Mal auf der Agile Ruhr 2018 gehört und finde diesen sehr einleuchtend.

Michael nannte dazu ein paar Beispiele:

• Ihr kriegt einen DevOp, aber nur zu 30%. Wir brauchen ihn noch für andere Projekte.
• Das Management will trotz Agilität 6 Monate im voraus planen.
• Als Scrum Master laufe ich mit meinen Themen gegen Wände, weil die Führungsebene andere Sichten hat.

Seiner Meinung nach können organisatorische Schulden größer werden, als technische Schulden. Das wurde vielfach bestätigt!

Diskussion über organisatorische Schulden

Lösungsansatz: Leadership Action Team oder Transition Team

Im Rahmen von Change-Prozessen gibt es Lösungsansätze für den Umgang mit organisatorischen Schulden. Beispiele dafür sind das Leadership Action Team (oder Executive Action Team EAT) oder das klassische Transition-Team. Aber selbst, wenn solche Teams auf Führungsebene existieren, kann es sein, das Themen versacken. Oft können oder wollen die Führungskräfte die Probleme nicht nachvollziehen. Idealerweise sind die oben genannten Teams auch als Scrum-Teams organisiert.

Michael: Wir haben Treiber für die Agilität an mehreren Stellen in der Führung: Bei der IT oder in der Nähe der Geschäftsfährung. Aber die Unterstützer agieren nicht als TEam.

Veränderung auf Führungsebene ist hart: Beispiel GF der KONTRAST auf der Agile Ruhr

Leider war ich (André) nicht auf der wirklich spannenden Session des GF der Fa. Kontrast auf der Agile Ruhr gewesen.

Der Geschäftsführer von KONTRAST berichtete damals von seinen “Schmerzen” mit der agilen Transformation seines Unternehmens. Ein einschneidendes Erlebnis für ihn war, dass er von seinem Team aus einer Retrospektive geschmissen wurde. Es kam auch zu einer erhöhten Fluktuation: viele Mitarbeiter konnten/wollten den Weg zur Agilität auch nicht mitgehen. Das Beispiel zeigte, dass die Veränderung sehr schmerzhaft sein kann.

Agilität bei FitX in Essen: Was geht da als Coach? Von Daniela (@FollowDanniM)

![Agile@fitx: Was geht als Coach?] (agile-fitx-wie-geht-das-als-coach.png)

Daniela berichtet über die Einführung agiler Prozesse in der Fitnessbranche, und zwar bei FitX. Für alle Teilnehmer ist diese Sicht total spannend. Wie funktioniert agiles Arbeiten im Fitness-Bereich? FitX ist eine Fitnesskette aus Essen mit derzeit 63 Studios in Deutschland. Die FitX Verwaltung, in der Daniela als Agile Coach tätig ist, ist im Headquarter in Essen ansässig.

Daniela shared with us her great start and first experience at FitX as Agile Coach. Interesting example of agile in no-IT area #scrumtischessen @agileruhr pic.twitter.com/KSXS9EAsTk

— Juliana Stepanova (@Yuliana_Step) May 24, 2018

Daniela: Aktuell bin ich seit Anfang Mai der erste festangestellte Agile Coach am Standort Essen. Darüber hinaus gibt es zwei externe Coaches, die bereits seit 1,5 bis 2 Jahren das Thema vorantreiben und mich noch ein paar Monate begleiten. Wir suchen für die Standorte Essen und Berlin allerdings weitere Agile Coaches in Feststellung um alle Teams in guter Qualität betreuen zu können.

Die Tribes und Teams am Standort Essen sind mehrheitlich (aber nicht nur) abseits der IT tätig, so ist der Tribe ClassX mit seinen Teams, die sich um die komplette Kurswelt in FitX kümmern, und für den Daniela als Agile Coach zuständig ist, bereits erfolgreich agil unterwegs. Passend zu den jeweiligen Hauptaufgabenbereichen arbeiten die Teams hier mit Scrum oder Kanban und nutzen Desingsprints für die hoch kreativen Themen. Viele weitere Teams, wie z. B. aus dem HR Bereich oder Trainingskonzept, haben die agilen Methoden für sich entdeckt und organisieren sich und ihre Arbeit mit agilen Prozessen.

Unsere Erfolge

• Es macht riesig Spaß, den Change zu begleiten.
• FitX und vor allem die Menschen sind großartig und man freut sich jeden Tag darauf, das Unternehmen weiter nach vorne zu bringen.
• Agilität wirkt und breitet sich in der gesamten Organisation aus: in HR, natürlich in der IT (Essen und der komplette Standort in Berlin), ClassX und vielen weiteren Tribes.
• Aus Fehlern der Anfangsphase wird getreu dem Prinzip Inspect and Adapt gelernt und Rollen und Prozesse angepasst und nachjustiert.
• Wir sind Macher!

Unsere und meine Herausforderungen

• Meine aktuelle Herausforderung ist es, die Rolle des Agile Coaches für jedes meiner Teams passend zu definieren, ohne sie zu überstrapazieren.
• Die Auflösung der Hierarchien ist wie in den meisten Unternehmen eine Herausforderung und bedarf einer sehr sauberen und transparenten Kommunikation.
• Den teilweise noch jungen Teams die richtigen Werkzeuge an die Hand geben, Verständnis für die relevanten wirtschaftlichen Sichtweisen zu schärfen und die passende Hilfestellung bieten, um die Teams weiter erfolgreich zu machen.
• Das weiter expandierende Unternehmen eine solide und skalierbare agile Basis zu geben.

Professional Scrum mit Kanban von Andreas @a_wittler

Den Abschluss bildete der Vortrag von Andreas zum Thema PSK. Die Vertreter von SCRUM.ORG haben sich mit den Kanban-Leuten zusammengesetzt und überlegt, wie man beide Welten sinnvoll miteinander zusammenbringen kann.

There are 4 metrics in Scrum with Kanban: WIP, work item age, throwing and cycle time. Thanks to @a_wittler for short introduction to PSK #scrumtischessen #kanban #metrics pic.twitter.com/qn08KpT5qY

— Juliana Stepanova (@Yuliana_Step) May 24, 2018

Ich gebe zu, ich war bei dem Vortrag zu Beginn sehr skeptisch, aber war dann wirklich positiv überrascht.

Der Bericht

Das Konzept gibt es noch nicht lange. Ein Papier zu dem Thema wurde erst vor wenigen Wochen veröffentlicht.

Der Workflow und die SLE (Service Level Expectations)

Das zentrale “Ding” ist die Definition of Workflow. Dieser besteht aus folgenden Elementen:

• Der Workflow selbst mit klaren Zuständen (Spalten) und Definitionen, wann ein Zustand gewechselt werden darf.
• Service Level Expectation: Eine klare Vorhersage, wie lange es dauert, bis die Working Items eines Sprints den Prozess durchlaufen haben. Andreas sagt: Auf die Uhr packen bedeutet, das ca. 85% geschafft werden soll. Das ist übrigens das Kernding.
• Klare Limitierungen für Work in Progress (WIP)
• Das Alter von Items wird gemessen und bewertet.

Die 4 Metriken

• Work in Progress (WIP): Die Anzahl der Punkte, die gestartet aber noch nicht beendet wurden.
• Durchlaufzeit: Die Zeit, die ein Punkt von Anfang bis Ende braucht.
• Alter. Die Zeit, die seit dem Start eines Items verstrichen ist.
• Durchsatz: Die Anzahl der Punkte, die pro Zeiteinheit fertig werden.

Die grundlegende Idee von Kanbon für Scrum besteht in der Beschleunigung der Arbeit und in der Verbesserung der Kommunikation. Bei Problemen ist Swarming ein wichtiger Lösungsansatz. Es wird nicht einfach das nächste Ticket gegriffen, sondern das Team wird zur Lösung der Probleme aufgefordert.

Und was wird im Daily Scrum abgefragt?

Spannend fand ich, was Andreas zu dem Daily Stand-Up berichtete. Die Fragen wurden bewusst so formuliert, dass der Fluss der Arbeit möglichst aufrechterhalten werden.

Die Fragen lauten:

• Welche Work Items (Punkte) sind blockiert und was kann das Team tun, um die Blockaden zu lösen?
• Schaut auf das Alter der Work Items. Welche Items gefährden die Service Level Expectations und was kann das Team zur Lösung unternehmen.
• Gibt es irgendwelche Ereignisse, die das Team davon abhalten, die heutige Arbeit zu vollziehen, die nicht bereits am Board hängen?

Spannend für mich ist, dass die Fragen alle bewußt teambezogen gestellt sind. Das ist viel besser als das, was ich noch von SCRUM kenne (Ich habe, ich mache ich brauche, ich, ich, ich…),

Retrospektive kann jederzeit gemacht werden

Die Retrospektive läuft anders, als im Scrum. Sie kann jederzeit erfolgen, wenn es klemmt. Das erinnert mich sehr an das Toyota-Prinzip, wo jeder Mitarbeiter am Band die Reißleine ziehen konnte, wenn es irgendwo klemmte.

"Im Professional Scrum for Kanban kann jeder im Team die Reißleine ziehen und es gibt eine Retrospektive. So werden Themen zeitnah gelöst!"

Klick hier für einen Tweet

In der Retrospektive kann sogar der Workflow angefasst werden! Aber Vorsicht: Wenn das gemacht wird, werden alle gesammelten Metriken wertlos. Das ist auch eine Besonderheit des Prozesses. Alles steht und fällt mit einem gut ausgearbeiteten Workflow.

Diskussion über PSK

Michael berichtet von seinen Erfahrungen mit Kanban:

“Wir haben schnell auf Kanban umgestellt. Das war erforderlich, weil wir sehr viele Fehler und Ereignisse hatten, die schnell bearbeitet werden mussten. Ein Sprint hätte zur Bereinigung zu lange gedauert. Wir haben aber Scrum-Praktiken beibehalten.”

“Bei Kanban hatten wir das Problem, dass durch die starke Orientierung an Tickets wir Probleme in der Teamarbeit bekamen. Viele schauen nur auf Ihre eigenen Tickets.”

Puh, jetzt ist aber Schluß

Unglaublich, wie dicht die Themenfülle an so einem Abend sein kann. Falls ihr

• Anregungen habt,
• Korrekturvorschläge,
• oder einen guten Agile Coach mit Schwerpunkt IT sucht,

wendet euch gerne an mich :-)