Ep. 8 - Stefan Roock & Henning Wolf / it-agile - Agile Geschichte in Deutschland

Stories Connecting Dots with Markus Andrezak

Episode 8: Stefan Roock und Henning Wolf / it-agile und die Geschichte von Agil in Deutschland

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 meine 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 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! Viel Spaß mit dieser Folge und dem gesammelten wissen von Stefan Roock und Henning Wolf.

Kapitel

1. 00:02:38 - Jahre 1995 bis 2000
2. 00:29:52 - Jahre 2001 bis 2005
3. 00:47:38 - 2005 Ops und Produkte spielen eine Rolle, Disziplinen spalten sich ab?
4. 00:52:04 - 2008 Transition bei mobile.de beginnt, wir drei lernen uns kennen, lustige Anfänge
5. 01:08:28 2009 Kanban, David Anderson, Don Reinertsen
6. 01:21:58 2009+: Fokus auf Produkt: Luke Hohmann, Roman Pichler, Lean Startup
7. 01:31:53 2011 Continuous Delivery, DevOps
8. 01:36:48 2011 bis heute Skalierung; SAFe, Less und Anderes
9. 01:49:34 Ausblick: Wie geht es weiter mit agil?

Kapitelnotizen 00:02:38 Jahre 1995 bis 2000

Erstes Scrumpaper Das Wort agil gibt es noch nicht Viele machen noch Rational Unified Process oder andere schwere Prozesse, nur ein paar arbeiten anders. Alls war „wir coden". 1999 „Extreme Programming explained" erscheint

00:29:52 Jahre 2001 bis 2005

2001 XP Buch Roock und Wolf

Schwaber Beedle „Software Development with Scrum"

Schwaber „Agile Project Management with Scrum"

Erste XP Konferenz, Sardinien, Italien - Gepäck geht verloren, man sitzt nass in den Konferenzräumen auf Sardinien Erste XP Days Deutschland

00:47:38 Jahre 2005 bis 2007 Ops/Produkte spielen eine Rolle, Disziplinen spalten sich ab?

„Man kann doch nicht erwarten, dass die Leute in 2-3 Wochen etwas erreichen wofür 12, 15 Jahre gebraucht haben"

00:52:04 - 2008 Transition mobile.de beginnt, wir drei lernen uns kennen, lustige Anfänge

Eine Menge unreifes Scrum.

„… wir haben uns in Projekten belohnt mit Storypoint, z. Bsp für Bugfixing. Mein Gott, hatten wir Velocity."

„Rezepte": Es war klar, dass man das macht, es gibt interne, die Feuer fangen mit denen man arbeiten kann. Es war klar, wer die anderen sind, mit denen man reden muss. Der Kunde hat nicht die Idee, dass die Coaches da sind und die Probleme lösen.

Muster: „Transitionen sind dann erfolgreich, wenn sich interne Mitarbeiter in das Thema Einfräsen. Schwierig wird es immer, wenn sich solche Mitarbeiter nicht finden. Die Energie, die dazu notwendige ist, kann nicht dauerhaft von aussen zugeführt werden."

Change Modelle hatten wir noch nicht. „Wir sind da einfach reingestolpert. Ich habe mit allen möglichen Leuten geredet um mich abzustimmen. Ich habe ich ständig mit dem CTO häufig abgestimmt und fokussiert. Wäre das Warum nicht klar gewesen, hätte das wahrscheinlich nicht geklappt und ich wäre frustriert gewesen und mir wäre nicht klar gewesen warum das nicht klappt."

01:08:28 2009 Kanban, David Anderson, Don Reinertsen

Auf welchen Umwegen it-agile Kanban entdeckt und für sich entwickelt. Ein Stahlwerk spielt eine Rolle und ein großes Versehen.

Dissonanzen zwischen Scrum und Kanban. „So wie Scrum ein verweichlichtes XP zu sein schien, schien Kanban ein verweichlichtes Scrum zu sein."

Erste Kanbanschulung mit David Anderson in Deutschland.

Diskussionen mit der Scrum-Community: Ist der Schutz noch da,

Kanban vs. Scrum Tree Hugging

Kanban als Möglichkeit mit Operations umzugehen.

Arne Roock wird Mr. Kanban Germany und schreibt unglaublich viel, organisiert die erste LKCE Konferenz.

01:21:58 2009+: Fokus auf Produkt: Luke Hohmann, Roman Pichler, Lean Startup

Lean Startup March bei it-agile intern.

Feststellung: „Wir sind einem Missverständnis aufgesessen, dem viele aufgesessen sind, die damals das Eric Ries Buch gelesen haben. Wir haben das Gefühl gehabt, wir müssten unheimlich viel quantitativ validieren."

„Wir haben Adwords Kampagnen geschaltet und dann hat da keiner uraufgedrückt. Und dann weisst Du nicht was los ist. Gibt’s das Bedürfnis nicht? Ist Deine Lösung doof? Oder hast Du nur falsche Keywords benutzt? Wie lange muss man denn warten? Ist es schlimm wenn nach 24 Stunden noch keiner raufgedrückt hat? Sollen wir noch warten? … Was wir am Ende den gemerkt haben war, dass quantitative Auswertung viel zu früh ist und wir auf qualitative Auswertung umsteigen müssten."

01:31:53 2011 Continuous Delivery, DevOPs 01:36:48 2011 bis heute Skalierung; SAFe, Less und Anderes

Grund: Die Umgebungen in denen agil angewendet wird werden komplexer, große Teams und Teams von Teams arbeiten zusammen.

„Das größte Mistverständnis ist: Viele skalieren an der falschen Stelle. Wie kann ich 150 Leute binnen 2 Monaten agil kriegen? Aber das wann dann bekommen ist wahrscheinlich doch etwas mechanisch. … eine Tücke an diesem Skalieren ist, dass die Leute es ist so schnell wollen."

„In dem was wir gemacht haben sind ja auch eine Menge Techniken eingesetzt worden, die heute in SAFe drin sind. Aber sie sind eben nur da eingesetzt werden wo sie notwendig waren und nur so lange wie sie notwendig waren."

„Und das ist auch eine Geschichte davon, dass Du dienen Softwareentwicklungsprozess selber besitzen musst."

„Im Komplexen kommt man nicht drumrum dass man selber denken muss. Es gibt zwar Hilfestellungen, aber die eigentliche Arbeit muss man selber machen."

„Die einzelnen Entwicklungsschritte in den Firmen sind nicht nachzuvollziehen, wenn man die Geschichte der vorangehenden Schritte nicht kennt."

Skalieren Firmen an den richtigen Stellen? Sollten Banken eventuell alles auf den Kopf stellen und bei den Cobol-Systemen anfangen zu agilisieren?

01:49:34 Ausblick: Wie geht es weiter mit agil?

Alle Großkonzerne werden einsteigen. Management und Leadership wird eine größere Rolle bekommen und auch die Theorie darüber wie Transitionen funktionieren. Scrum geht dahin zurück wo es herkommt: Zur Hardware-Entwicklung. Es gibt eine zweite Welle der Agilisierung für die Bestandteile der Unternehmen, die nicht software-Entwicklung ist. Die kleinen Startups in Berlin als Feigenblatt werden nicht für immer für die großen Konzerne funktionieren. Wahrscheinlich muss man doch an die verkrusteten Strukturen ran.

Wrap Up: Ein paar Muster

Ein paar Dinge, die bei mir hängen geblieben sind und die vielleicht auch nur erzählt werden können um klar zu machen, wie zufällig vieles im Moment wirkt und wie klar es im Nachhinein dann doch sein kann. Und auch wie stark das mit den Erwartungen an einen eventuell industrialisierteren Beratungsprozess kontrastiert, wie es sie heute vielleicht oft gibt.:

• In vieles snd wir einfach hineingestolpert und haben vieles einfach probiert.
• An vielem sind wir im ersten Anlauf gescheitert und haben es erst im Laufe der Zeit herausgefunden
• Im Nachhinein war alles klar und einfach.
• „Transitionen" klappen besser wenn
  • der Grund klar ist
  • commitment zur Transition klar ist und nicht in Frage gestellt werden kann
  • auch wenn das „Wie“ noch nicht klar sein kann
  • sich interne Mitarbeiter finden, die für das Theme wirklich brennen und die Freiheiten haben das Notwendige zu machen. Dazu gehört es auch, immer wieder Unbequemes anzusprechen und zu diskutieren. sonst ist Verbessern nicht möglich.
• Nichts klappt schnell, Eile im Umbau ist kontraproduktiv
• Man muss den (Software-Entwicklungs-)Prozess selber besitzen. man muss selber nachdenken und die Arbeit machen.
• Man wendet nur die wenigen Mittel an, die man gerade braucht und nur so lange man sie braucht.

Ein paar Links aus der Episode

it-agile, die Firma -

Stefan Roock auf twitter, Bücher von Stefan bei amazon

Henning Wolf auf twitter, Autorenseite bei amazon

„XP explained" von Kent Beck

Ken Schwaber bei Wikipedia

„Kanban" von David Anderson, deutsche Ausgabe -

„The Lean Startup" von Eric Ries -

„Continuous Delivery" von Jez Humble -

Blog von Arne Roock, Stefan’s Bruder und deutscher Kanban Pionier -

LKCE Konferenz