Guten Tag {Vorname},

Anfang Februar durfte ich auf der OOP-Konferenz einen Vortrasg zur „Agilen Zukunft“ halten. Das führte bei mir dazu, dass ich mir einmal intensiver Gedanken dazu gemacht habe, was ich denn eigentlich annehme, wie es weitergeht. Dazu findest du unten mehr. Deine eigene Meinung zum Thema würde mich sehr interessieren.

Im letzten Newsletter gab es den ersten Beitrag der neuen Coaching-Tipp-Kategorie. Der hat nicht ganz allen gefallen, aber doch den meisten. Danke für dein Feedback dazu.

In diesem Monat findest du folgende Themen im Newsletter:

• Der Norden Agil zu Scrum skalieren: kostenloser Vortrag mit Bas Vodde „More with LeSS“  am 16. März 2016 in Hamburg
• OOP-Nachklapp: Vortrag zu „Agiler Zukunft“ von Henning Wolf
• Veränderungen, die gelingen: Lean Change Agent Workshop 
• Agile Metriken: Kurze Auswertung der Umfrage
• Agiler Tipp aus Erfahrung: Offene Priorisierung
• Aktuelle Schulungstermine
• und das Schiff des Monats: Perfect

Viel Spaß beim Lesen! Schreib mir gerne, wenn dir etwas fehlt.

Ich wünsche dir einen agilen März und uns allen eine agile Zukunft, 
Henning

P.S.: Es gibt ein neues Zertifikat der Scrum Alliance, den „Certified Scrum Team Coach“ (CTC). Wenn das für dich interessant klingt, dann nimm doch bitte an unserer kurzen Umfrage teil, hinterlege deine E-Mail-Adresse dort und wir halten dich auf dem Laufenden, wie it-agile dir helfen kann, das Zertifikat zu erlangen.

P.P.S: Ich bin mit meinem Kollegen Alex Bepple am 18.4. auf der Agile Leadership Konferenz in Nürnberg, und wir haben einen Vortrag und einen Workshop zu Agiler Skalierung dabei. Vielleicht auch was für dich?

Unsere Vortragsreihe „Der Norden Agil“ wird in Hamburg prima angenommen. Dieses mal lohnt sich bestimmt sogar die Anreise aus Berlin oder Hannover. Denn wir haben Bas Vodde in Hamburg, einen der beiden Begründer von LeSS, dem Large-Scale Scrum Framework.

Bas wird in seinem Vortrag aus seiner Projektpraxis berichten und uns an seinen Erfahrungen der Anwendung von LeSS teilhaben lassen. Das wird bestimmt super! Ich freue mich schon sehr darauf. Ich bin ein großer Fan von LeSS, weil ich finde, dass es den agilen Gedanken und die agilen Prinzipien auch noch in größeren Kontexten wahrt. Im Gegensatz zu anderen Saklierungsframeworks, die mit strikten Koordinationsregeln und Release-Trains einiges der Agilität auf Teamebene wieder zerstören, wenn man ihnen blind folgt. 

Bitte beachte: Der Vortrag findet wegen des erwarteten großen Andrangs nicht bei uns im Büro statt und ist auf Englisch.


Wenn dich das Thema so wie mich noch mehr interessiert, könntest du auch noch einen der begehrten Plätze in der Schulung mit Bas Vodde vom 15.-17. März bei uns in Hamburg ergattern.
 

Auf der OOP-Konferenz in München Anfang Februar habe ich einen Vortrag zu „Agiler Zukunft“ gehalten. Das war für mich in der Vorbereitung spannend, weil ich mir so noch mal explizit Gedanken darüber gemacht habe. Dazu habe ich ein wenig meinen eigenen agilen Werdegang seit 1998 reflektiert und bin zu dem Schluss gekommen, dass die agile Zukunft wohl ein Mix aus den folgenden 3 Szenarien wird:

• Die großen Beratungen übernehmen, Agilität wir genauer spezifiziert, kann nach Blaupause eingeführt und durchexerziert werden, es gibt jede Menge neuer Zertifizierungen und spezifischer agiler Rollen. Die Veränderung ist ein einziger großer Fake.
• Die dogmatischen Agilisten gewinnen, „das ist nicht agil“ wird zum Totschlag-Argument, Teams geht es gut, aber das macht in vielen Fällen Fimen und Projekte und Produkte nicht erfolgreich. Die Veränderung ist einseitig auf das Wohl der Teams ausgerichtet und vernachlässigt Unternehmens- und Kundenbedürfnisse. 
• Alles wird gut: Unternehmen und Manager verstehen, wo ihnen Agilität echte Vorteile verschafft, es etabliert sich eine echte Verbesserungskultur, das Mindset ändert sich und Fach- und IT-Abteilungen kooperieren miteinander. Die Veränderung ist im Sinner der Begeisterung von Endkunden und Mitarbeitern zum Wohle der Unternehmen.

Du kannst dir meine Folien dazu ja mal anschauen, ich bin mir allerdings nciht so sicher, ob sie aussagekräftig genug sind ohne die Tonspur. Aber in der nächsten agile review, die Anfang April erscheint, wird es auch einen Artikel dazu geben.

Was glaubst du, wir die agile Zukunft kommen wird? Ich möchte mit meinen Kolleginnen und Kollegen bei it-agile daran arbeiten, dass die letzte Variante den stärksten Einfluss gewinnt. Bist du im Boot? 

Welche Meinung hast du zum Thema? Was beobachtest du an Trends? Schreibe mir doch gerne dazu.
 

Als ScrumMaster, Coach oder Veränderer ist es nicht immer ganz leicht, sich auf die wichtigen Probleme zu fokussieren. Häufig gibt es viele Dinge, die geändert werden könnten. Aber welches sind die wirklich relevanten?

Der Ansatz eines Lean Change Agent verbindet dabei verschiedene agile Gedanken, um Antworten auf diese Fragen zu finden. Der Lean Startup Ansatz setzt darauf, Business-Modelle anhand von Daten von Nutzern zu validieren, bevor man weiteren Aufwand dafür verwendet, diese Ideen weiter zu verfolgen. Das gleiche versuchen auch Lean Change Agents.

Für Veränderungen sind Change-Canvases genauso wie Visual Management hilfreiche Tools, um die Richtung für die Veränderungen und die wichtigen Maßnahmen schnell ableiten zu können. Dabei setzt Lean Change außerdem darauf, dass von Veränderungen Betroffene diese Maßnahmen mitgestalten können und in Konsequenz die Veränderungen besser mitgetragen werden.

Mein Kollege Markus Gärtner bietet am 3. und 4. Mai einen Lean Change Agent Workshop in Hamburg an. Dort lernst du den Einsatz dieser Tools, um nachhaltig Veränderungen im Unternehmen zu etablieren.
 

Im letzten Newsletter hatten wir eine Umfrage zu Agilen Metriken. Die habe ich später auch noch mal per Twitter verbreitet. Trotzdem gab es nur 34 Rückmeldungen, aber immerhin. Vielen Dank für die Teilnahme!  Hier eine kurze Zusammenfassung der Ergebnisse.

Es gibt eine deutliche Diskrepanz zwischen der Zufriedenheit mit dem Thema Agile Metriken und der Bedeutung, die das Thema hat: 8,8% der Befragten waren zufrieden oder sehr zufrieden mit ihren Metriken, während gleichzeitig 52,9% das Thema für wichtig oder sehr wichtig für ihren Arbeitskontext hielten.

Auf den ersten Blick nicht so überraschen: 85,3% gaben an, dass das Management an Metriken stark interessiert ist. Aber bei 35,3% interessiert sich auch das Team stark. Das würde ich mir noch höher wünschen, schließlich können Metriken helfen zu erkennen, ob Verbesserungsmaßnahmen funktionieren.

Bei den eingesetzten Metriken gibt es ein überraschend uneinheitliches Bild. Die häufigsten Metriken sind die Velocity (von 79,4% angegeben) und die Anzahl Bugs (61,7%). In beiden Fällen sind aber jeweils nur knapp über die Hälfte der Befragten der Meinung, dass ihnen diese Metrik auch wirklich nützt.

Die TOP 5 der zukünftig geplanten Metriken sind

• erzielter Business-Value (32,4%)
• Kundenzufriedenheit/NPS (29,4%)
• Lead-Time (29,4%)
• Durchlaufzeit (29,4%)
• Mitarbeiterzufriedenheit/Happiness-Index (26,5%) 

Ein paar weitere Details habe ich dir in einer Seite PDF zusammengestellt, falls du da für dich noch etwas Interessantes entdeckst, lass es mich doch bitte auch wissen! Danke.
 

Ein it-agile-Kollege hat bei einem unserer Kunden folgendes erlebt:
Der Kunde stellt ein Produkt her und hat seine Produktentwicklung in Teams organisiert, die jeweils für die Entwicklung bestimmter fachlicher Aspekte des Produktes zuständig sind. Alle Teams hatten damit zu kämpfen, dass es sehr viele Stakeholder gab mit sehr vielen (bestimmt guten) Ideen. Da waren die Fachabteilungen, das Marketing, der Kundenservice und auch noch die anderen Teams. Das führte zu sehr langen Listen von Wünschen, was dei Teams erledigen sollten, vielen Umprioriserungen auf dieser Liste und vielen Nachfragen, wann denn mit bestimmten Features zu rechnen sei.
Du kannst dir vielleicht vorstellen, dass all diese Wunschlisten, Umpriorisierungen und Nachfragen weder das Team schneller noch die Stakeholder glücklicher gemacht haben.
Eines der Teams hat deshalb für sich beschlossen, dass es so nicht weitergehen könne. Sie haben im Entwicklungstakt von zwei Wochen ein offenes Priorisierungsmeeting anberaumt. Zu diesem Meeting waren alle Stakeholder und letztlich alle in der Firma herzlich eingeladen. Das Team hatte die Erfahrung gemacht, dass es sinnvollerweise nicht an mehr als 2-3 neuen Features gleichzeitig arbeiten kann und noch nie mehr als 6 neue Features in zwei Wochen fertiggestellt hat. Beim ersten Priorisierungsmeeting war der Entwicklerraum voll mit Stakeholdern und das Team erklärte seine neuen Spielregeln: Keine Liste mehr, hier und jetzt wird über die zwei Sachen entschieden, die wir definitiv als erstes bearbeiten und mit sehr hoher Wahrscheinlichkeit in zwei Wochen fertig haben. Zusätzlich nehmen wir gerne noch 3 weitere Themen mit und beginnen mit denen, wenn es geht. Wenn nicht, bringen wir es ins nächste offene Priorisierungsmeeting wieder mit und müssen gemeinsam neu entscheiden.
Was sich im Folgenden entspann war eine sehr nützliche Diskussion der Stakeholder untereinander, welches Feature für das Unternehmen am wichtigsten sei. Das war für die ersten 2-3 Features meist einfach zu entscheiden. Und insbesondere war es für die Stakeholder einfacher zu entscheiden als für das Entwicklungsteam.
Diese Art der Priorisierung war für die Stakeholder eine Umstellung, aber insgesamt ist sie sehr erfolgreich. Ich habe letzte Woche mal nachgefragt, das TEam macht es heute noch genauso. Es ist eines der erfolgreichsten und beliebtesten Teams, weil es sehr zuverlässig liefert. Dank der offenen Priorisierungsmeetings sogar zuverlässig das wichtigste, was gerade ansteht.    


Mein Kommentar: So ist es clever! Die Stakeholder erkennen so, dass es nicht primär am Entwicklungsteam liegt, wenn sie etwas nicht (jetzt) bekommen, sondern an den anderen Stakeholdern und unternehmensweiten Priorisierungen. Zudem müssen sie sich selbst darum kümmern, dass ihre für sie und das Unternehmen wichtigen Themen erledigt werden. Das hält sie vermutlich auch davon ab, sich parallel noch mehr Dinge auszudenken. Oder die neuen Ideen dann auch schon selbst als ihre neuen allerwichtigsten Themen mitzubringen.
Ich weiß aber auch, dass du jetzt vielleicht denkst, dass das so bei dir und eurer Konstellation leider nicht möglich ist. Das glaube ich auch. Gleichzeitig solltest du aber die Anregung mitnehmen, darüber nachzudenken, wie die Stakeholder untereinander ihre Prioritäten im Sinne des Gesamtinteresses selber abgleichen können. Zudem würde ich dir empfehlen, nicht der Verwalter von Stakeholderideen zu werden. Das sollten und können sie gut selber erledigen.


Hattest du in deiner agilen Praxis ein Aha-Erlebnis, das du teilen magst? Dann schreibe mir doch gerne.    
 

Mit nicht mal 25m Länge ist so ein Schlepper wie Perfect im Vergleich zu den durchaus 15 mal längeren Containerschiffen eher kurz. Trotzdem kann er mit zwei Dieselaggregaten mit jeweils 2100kW dafür sorgen, dass die Containerschiffe sicher ihren Liegeplatz im Hamburger Hafen erreichen  und wieder verlassen können.

Ich habe mich in dieser Rubrik mindestens bei der MOL Brilliance und der YM World schon geäußert, welchen Reiz eine Verbesserung in Richtung Perfektion auf mich ausübt. Dazu haben mir auch einige Leute nützliches Feedback gegeben, weswegen ich das Thema gerne noch einmal aufgreifen möchte. Zunächst bin ich nach meiner eigenen Wahrnehmung nur in wenigen Bereichen Perfektionist und mein persönliches Ziel ist es auch nicht, dass alles perfekt sein sollte. Vielmehr richte ich gerne mein Handeln in Rchtung immer besser werden in Richtung Perfektion aus. Es ist für mich einfach sehr motivierend, Verbesserungen zu finden und umzusetzen (und dann ihre Wirkung beobnachten zu dürfen). Das hat für mich erst einmal nichts mit dem Druck zu tun, der dadurch vielleicht auf andere entsteht. Allerdings demotivieren mich (Team-)Kollegen, wenn sie gar nicht zu Verbesserungen/Veränderungen bereit sind. Und diese Kollegen empfinden meinen Veränderungsdruck bestimmt oft als eine persönliche Kritik an ihrer Arbeit. In vielen Firmen fühlen sich die Mitarbeiter ja ständig unter einem Druck höher, schneller, weiter, billiger, mehr, genauer arbeiten zu sollen. Wenn dieser Druck zu konstruktiven Diskussionen und gemeinsamen Veränderungen führt, ist es ja auch OK. Wenn er aber eben nur als persönlicher Druck die Kollegen belastet, ist er kontraproduktiv.
Ich habe mir deshalb vorgenommen, dass ich es erstmal damit versuche, mit meiner Begeisterung andere mitzureißen. Wo mir das nicht gelingt, will ich mich weniger demotivieren lassen und nicht mior Druck reagieren, sondern schauen, welchen Schritt ich ganz alleine gehen kann, um weiterzukommen. 

Was ist deine Meinung dazu? Schreibe mir gern. Perfekt!


Wenn du eine größere Aufnahme des Schiffs des Monats sehen willst, klicke einfach auf das nebenstehende Bild.