Guten Tag {Vorname},

oben siehst du ein Foto eines Teils unseres neuen Konferenzstands, den wir letzte Woche zum ersten Mal im Einsaz hatten auf dem Scrum Day 2017 in Filderstadt. Er ist aktuell modular aus 24 Boxen zu jeweils 50 x 50 x 50 cm zusammengesetzt; kann aber skalieren. Uns gefällt der Stand sehr gut und auch den Konferenzbesuchern ist er deutlich ins Auge gesprungen. Das wiegt dann auch die Schlepperei und Umstände beim Transport wieder auf, die so ein Stand hat. Vielleicht sehen wir uns ja auch einmal an unserem Stand wieder.

Diese Themen findest du im Newsletter:

• Vortragsfolien von der SEACON 2017 und dem Scrum Day 2017 zum Download für dich
• Certified Agile Leader am 12./13. Juli 
• Podcast „Stories Connecting Dots“ von Markus Andrezak zur Geschichte der Agiltität in Deutschland
• Umfrage der BTU Cottbus zu „Nachhaltig Entscheiden in der Agilen Softwareentwicklung“
• Aktuelle Schulungstermine
• Agiler Tipp: Stories mit den Entwicklern schreiben
• Schiff des Monats: Shippable Product Increment (ein halbes Schiff!)

Viel Spaß beim Lesen! Schreibe mir, wenn dir hier etwas fehlt.

Viele Grüße, 
Henning

P.S.: Meine Kollegen Sandra Reupke-Sieroux und Wolf-Gideon Bleek geben am 13./14. Juli eine Management 3.0 Schulung in Hamburg. Das ist eine tolle Trainer-Kombi, denn Wolf-Gideon war vor seiner Zeit bei it-agile einige Jahre als Manager tätig und Sandra ist aktuell Company-Coach bei it-agile. Da wirst du viele spannende Geschichten hören, da bin ich mir sicher. 
 

Im Mai waren wir auf SEACON und Scrum Day, wie in den letzten Newslettern schon berichtet. Beide Veranstaltungen haben mir in diesem Jahr wider sehr gut gefallen. Auf der SEACON durfte ich eine Keynote halten (und habe den selben Vortrag auch beim Scrum Day erneut gehalten).

Unsere drei Vorträge von it-agile-Kollegen findest du zum Download unten:

• Dr. Wolf-Gideon Bleek: Entkoppelt, schnell, flexibel – Agile Enterprise Architekturen
  Wolf-Gideon beschreibt in seinem Vortrag sehr anschaulich gängige Architekturprinzipien und warum kontraintuitiver Weise für große Archtitekturen oft andere Prinzipien hilfreicher sind. Schließlich müssen Nutzen zentraler Konzepte und dem gegenüberstehende Kosten für viel mehr Koordinationsaufwand berücksichtigt werden.   
• Henning Wolf: Der Agile (Selbst-)Manager
  In meinem Vortrag geht es um meinen Blick auf Agilität, den nötigen Rahmen (Klarheit über Verbesserungsrichtung, Fokus) und das Übernehmen von Verantwortung, dass bei jedem von uns bei uns selbst anfängt.
• Ilja Preuß: Entscheidungen treffen in Agilen Organisationen
  Ilja hat in seinem Vortrag einmal herausgearbeitet, warum wir eigentlich anders Entscheidungen treffen wollen in Agilen Organisationen und die Methoden Mehrheitsentscheid, systemisches Konsensieren, Konsent, konsultativer Einzelentscheid und Notfallentscheid vorgestellt und jeweils eingeordnet, welche Güte diese Entscheidungen haben und welches Commitment sie erzeugen.

Wenn dir die Folien alleine nicht weiterhelfen, melde dich bei uns. Vielleicht machen wir mal eine Webseite oder einen Artikel für die agile review draus, wenn es Interesse gibt. Und wir können die Vorträge auch bei euch intern halten.
 

Ich habe ja schon in den letzten Newslettern von unseren Certified Agile Leader Schulungen (CAL 1) berichtet. Mittlerweile haben zwei stattgefunden, eine öffentliche Schulung und ein Inhouse-Training. Insofern wissen wir heute schon wieder ein bisschen mehr, was den Teilnehmern gefällt und wichtig ist und können noch knapper beschreiben, was die Schulung ausmacht:

In der CAL-1-Schulung lernen die Teilnehmer die verschiedenen Aspekte agiler Führung kennen: vom Coaching und Mentoring individueller Mitarbeiter über mögliche Interventionen gegenüber agilen Teams bis hin zu agilen Organisationsformen und geeigneten Change-Ansätzen. Dabei lernen die Teilnehmer auch, dass effektive Leadership auch eigene Persönlichkeitsentwicklung erfordert.

Vielleicht etwas für dich oder deinen Chef oder den Chef-Chef?
Meine Kollegen Stefan Roock und Norbert Hölsken freuen sich drauf!
 

Schon seit einiger Zeit produziert Markus Andrezak von überproduct den Podcast „Stories Connecting Dots“. In Folge 8 nun hat er sich mit Stefan Roock und mir zur Geschichte von Agilität in Deutschland unterhalten.

So beschreibt Markus diese Folge:
„Episode 8 ist für mich eine ganz besondere und sehr persönliche Folge. Und das hat mit den Gästen zu tun. Ich habe die Folge mit Stefan Roock und Henning Wolf in den wunderbaren Büros Ihrer weithin bekannten Firma it-agile am Hamburger Hafen aufgenommen. it-agile ist für mich DIE Firma für agile Kultur, Methoden, Techniken und Transitionen. Mit den beiden und ihrer Firma verbindet mich unglaublich viel: wir sind Kollegen, Partner und Freunde. Wir arbeiten zusammen, wir geben hie und da gemeinsam Trainings. Stefan und Henning haben aber als meine ehemaligen Coaches in der Transition von mobile.de einen unglaublichen Einfluß auf mich, meine Arbeit und mein Leben gehabt, der bis heute wirkt. Stefan hat mich – ein kleines Beispiel – zu meinen ersten Vorträgen überredet.
Diese Folge ist vor allem ein entspanntes Gespräch über die Zeit von 1995 bis heute und über das was im agilen Umfeld so passiert ist. Es hat sich natürlich angeboten, mit den beiden die so lange in diesem Geschäft sind, einen Rundumschlag und Überblick über das anzugehen was in der gesamten Szene und Bewegung in all den Jahren passiert ist. Um das Ganze ein wenig zu strukturieren gehen wir anhand von Büchern und Ereignissen zumindest grob chronologisch vor.
Ein paar Muster habe ich erkannt und werde sie am Ende noch einmal zusammenfassen.
In dem Gespräch streifen wir alle möglichen Themen angefangen von keinem Prozess, über Extreme Programming (oder was wir daraus gemacht haben), Scrum, Kanban, DevOPs, Kultur und Leadership, Transitionen und Skalierung. Es kommen die möglichsten und unmöglichsten Anekdoten zu Erfahrungen, Erfolgen und Misserfolgen auf. Ich will jetzt gar nicht zu viel vorwegnehmen!“

Wem die ca. 2 Stunden Podcast zu lang sind, der kann sich auch Markus' tolle Zusammenfassung am Ende seines Blogposts zur Podcast-Folge durchlesen. Danke, Markus!
 

Ab und zu fragen wir dich, ob du an einer Umfrage teilnehmen magst. Heute ist es einmal keine Umfrage von it-agile, sondern von der Brandenburgischen Technischen Universität (BTU) Cottbus.

Hier ein paar Infos von Mathias Schubanz zur Umfrage. Er wäre froh, wenn du daran teilnehmen magst (ca. 15 min.):

Ein zentraler Aspekt agiler Entwicklungsmethoden ist die direkte und informelle Kommunikation in eng vernetzten Entwicklungsteams. Sie steht formalisierten Berichten und komplexer Dokumentation entgegen. Das Agile Manifest titelt dazu “Working software over comprehensive documentation”. Nichtsdestotrotz werden in der Softwareentwicklung Entscheidungen getroffen, die richtungweisend für die weitere Entwicklung, die spätere Wartung sowie die Evolution der Software sind. 

Um den Umgang mit Entscheidungen in der Praxis besser zu verstehen, führt die Brandenburgische Technische Universität (BTU) zu dieser Problematik aktuell eine Umfrage durch. Welche wichtigen Entscheidungen gilt es wirklich zu dokumentieren? Was heißt es, die Dokumentation auf das Notwendige zu reduzieren? Wann und wie sollen Entscheidungen dokumentiert werden? Entscheidungen können beispielsweise Architekturentscheidungen, Entwurfsentscheidungen, Technologieentscheidungen zu eingesetzten Frameworks und Bibliotheken, oder Entscheidungen im Anforderungsmanagement sein. 

Es ist das Forschungsziel der Mitarbeiter von Prof. Lewerentz aus Cottbus, eine Methode herauszuarbeiten, die die Erfassung und Wiederbenutzung von relevanten Entscheidungen in agilen Entwicklungsmethoden unterstützt. Im Fokus der Forschung steht hierbei Scrum.
 

In diesem Monat stammt der Tipp von meinem Kollegen Benjamin Igna.

Das Problem
Unser Kunde war ein großes Finanzinstitut, der sich seine IT von einer großen Firma machen lassen hat. Externe Entwickler sollten also die Produkte umsetzen, die sich unser Kunde ausgedacht hatte. Dazu kam die Tatsache, dass die Entwickler aus einem ganz anderen kulturellen Kontext kamen, und zwar aus Indien. Wir hatten also Kommunikationsprobleme. Der Fachbereich hat Stories geschrieben und in das Planning gebracht. Nur wenige Tage nach dem Planning konnten sich die Teammitglieder nicht mehr genau an die Details aus dem Planning erinnern.

Die Lösung
Jetzt hätte man hier mit mehr Dokumentation Abhilfe schaffen können, doch wie das mit Dokumentation so ist, hat erstens kaum einer Lust dazu und zweitens müssen die Entwickler die Dokumentation dazu später auch noch suchen/finden/lesen und ganz wichtig: verstehen.
Wir haben uns für eine andere Vorgehensweise entschieden. Wir schreiben die Stories alle gemeinsam. Das bedeutet, unser Product Owner kommt in das Backlog-Refinement mit einem ersten Wurf der Story, stellt diese vor und wir formulieren gemeinsam die Story für das Backlog. Das erzeugt einen höheren Wiedererkennungswert bei den Teammitgliedern, was wiederum dazu führt, dass wir weniger dokumentieren müssen. 
Nachdem wir das einige Zeit lang gemacht haben lernten wir, dass es viel weniger auf das gemeinsame „schreiben“ ankommt als darauf, die gemeinsame Kundenperspektive einzunehmen und darüber zu diskutieren, sich also gegenseitig kennen zu lernen. Die Stories funktionieren nun als Schlüssel für unsere Köpfe. Wir schreiben teilweise nur noch Stichworte auf und wissen genau, was sich dahinter verbirgt. 

Die Wirkung
Natürlich kostet das gemeinsame Aufschreiben und die Diskussionen viel Zeit. Doch ich bin davon überzeugt, dass sich diese Investition lohnt. Denn heute sind wir besser abgestimmt, haben weniger Nachfragen sowie mehr Alignment für das Team.


Welchen Tipp hast du für alle? Kannst du uns den aufschreiben (vielleicht mit dem Team gemeinsam)?
 

Hier als Service für dich unsere nächsten Schulungs- und Workshoptermine, in denen es noch freie Plätze gibt:

Agiles Management:

• Management 3.0 4./5. Juli in Hamburg
• Management Agiler Teams 4.-6. Juli in München
• Management Agiler Teams 12.-16 September in Hamburg

Effektive Kommunikation und Meetings:

• Eine Frage der Retrospektive 20. Juni in München
• Kommunikation & Konfliktbearbeitung 18./19. Juli in München

Kanban:

• Kanban Management Professional 1 (KMP I) 10./11. Juli in Hamburg
• Kanban Management Professional 1 (KMP I)  21./22. August in Hamburg
• Kanban Management Professional 2 (KMP II) 23./24. August in Hamburg
• Kanban Management Professional 1 (KMP I)  4./5. September in Hamburg
• Kanban Management Professional 2 (KMP II) 6./7. September in Hamburg
• Team Kanban Practitioner (TKP) 6. September in Hamburg
• Kanban Management Professional 1 (KMP I)  20./21. September in München
• Certified Scrum Master + Kanban (CSM) 25.-27. September in Hamburg

Scrum-Specials:

• Scrum Basics 25. Juli in Hamburg

Scrum-Zertifizierungen:

• Certified Scrum Developer (CSD) 12.-14. Juni in Hamburg
• Certified Scrum Master Deluxe (CSM) 26.-28. Juni in Hamburg
• Certified Scrum Developer (CSD) 11.-13. Juli in München
• Certified Agile Leader (CAL-1) 11./12. Juli in Hamburg
• Cetified LeSS Practitioner 1.-3. August in Hamburg
• Certified Scrum Master Deluxe (CSM) 16.-18. August in Hamburg
• Certified Scrum Product Owner Deluxe (CSPO) 4.-6. September in Düsseldorf
• Certified Scrum Developer (CSD) 5.-7. September in München
• Certified Scrum Master Deluxe (CSM) 7./8. September in Hamburg
• Certified Scrum Product Owner (CSPO) 21./22. September in Hamburg
• Certified Scrum Master + Kanban (CSM) 25.-27. September in Hamburg

Dieses halbe Schiff ist schon vor einer ganzen Weile mal vor unserem Büro von zwei Schleppern (einem Schubschlepper und einem normalen Schlepper) in Richtung Werft gezogen worden. Leider weiß ich sonst nicht mehr darüber.

Das der Begriff Shippable Product Increment aus Scrum auch für Schiffe gilt, hatte ich mir schon gedacht. Allerdings habe ich eher an einen Rumpf ohne Aufbau oder Motor oder so gedacht und nicht ein halbes Schiff: Vorne scheint fertig.
In Scrum sind uns die shippable product increments, also die auslieferbaren Produktinkremente so wichtig, weil wir an ihnen unseren Fortschritt viel realistischer messen können: Was man sieht ist fertig und wäre bereit, ausgeliefert zu werden bzw. live gestellt zu werden. Keine weiteren Nacharbeiten nötig, deren Umfang wir nicht einschätzen können.
Durch die kurzen Sprints entstehen allerdings zuweilen zwar von der Qualität her shippable product increments, die aber vom Featureset her für die Anwender noch keine echte Verbesserung darstellen. Das ist zugegeben eben auch keine ganz leichte Aufgabe, die Funktionalitäten in so kleine und dann noch jeweils sinnvoll zusammenspielende Einheiten runterzubrechen. Es lohnt sich aber in jedem Fall, daran immer weiter zu arbeiten.   

Welche Erfahrungen hast du mit shippable product increments gemacht?  Schreibe mir gern dazu.


Für eine größere Aufnahme des Schiffes, klicke einfach auf das nebenstehende Bild.