XP Days Germany 2013: Die zwei Perspektiven des „Wie“

Die diesjährigen XP Days boten aus meiner Sicht eine gute Balance, um die beiden Aspekte des „Wie“ in agilen Projekten angemessen zu berücksichtigen. Die zwei Konferenztage erzeugten viele wertvolle Impulse für den anschließenden Community Day (und hoffentlich weit darüber hinaus).

Ein agiles Entwicklungsteam ist in einem Scrum-Projekt für das „Wie“ verantwortlich, d.h. für die Auswahl und Verwendung von Technologien, Werkzeugen und Methoden, mit denen es die fachlichen Anforderungen in lauffähige Software zu transformieren gedenkt. Eine Entscheidung für ein Vorgehen nach Scrum ist die zweite „Wie“-Entscheidung, die eine großen Einfluss auf die Arbeitsweise des Teams hat. Folgerichtig beschäftigten sich die XP Days Germany, die in diesem Jahr wieder turnusgemäß in Karlsruhe stattfanden, mit beiden Aspekten des „Wie“. Da mein Hauptinteresse dem Prozess gilt, habe ich mich vornehmlich in den thematisch passenden Vorträgen getummelt – oder dem Netzwerken gefrönt.

Generation Agile

Das Netzwerken gestaltete sich in diesem Jahr unerwartet anders, weil viele Agilisten, die ich in den vergangenen Jahren regelmäßig auf den XP Days getroffen habe, nicht da waren. So wurde aus dem erwarteten Klassentreffen ein neugieriges Kennenlernen – was  genauso viel Spaß gemacht hat. Viele Teilnehmer gehörten der nächste Generation von Wissensarbeitern an, die mit einer agilen Grundeinstellung und frischen Ideen in ihren Unternehmen und auf Konferenzen wirken. So zumindest die Einschätzung von Jens Himmelreich, der sich am ersten Konferenztag umschaute, mich dann anschaute und feststellte: „Mann, sind wir alt.“ Das stimmt – aber wir sind auch erfahren. Und weiterhin neugierig!

Abgesang auf den agilen Coach

Erster Höhepunkt am ersten Konferenztag war Johannes Links Geständnis „Ich will kein Agiler Coach mehr sein“ – ein Vortrag wie ein Paukenschlag, in dem Johannes zunächst mit seiner agilen Vergangenheit abrechnete, dann aber zum Glück wieder konstruktiv wurde und die Bedingungen nannte, unter denen er zukünftig gerne beraten möchte. Besonders wichtig ist es ihm, bei seiner Tätigkeit „die eigene Haut zu Markte zu tragen“ – wirklich involviert zu sein, die Erfolge und Misserfolge selber zu spüren (auch finanziell). Leider hat er noch keinen Kunden gefunden, der sich auch vertraglich darauf eingelassen hat.

Johannes‘ Bekenntnisse wirkten bei vielen Teilnehmern (vor allem Beratern) lange nach und führten zu vielen Diskussionen. Schade, dass Johannes keine Zeit hatte, zum Community Day zu kommen, denn dort hätte man seine Ideen ausführlicher diskutieren können.

Agil – quo vadis?

Markus Gärtner richtete den Blick noch weiter in die Zukunft. Wie, so seine Frage, wird die agile Softwareentwicklung in zehn Jahren aussehen? Diskutiert wurde im Fishbowl-Format. Der Bogen der behandelten Themen war groß – von der Selbstverständlichkeit verteilten Arbeitens (weil endlich gute Werkzeuge zur Verfügung stehen, die diese Arbeitsweise unterstützen) über Agilität jenseits der Softwareentwicklung (Beyond Budgeting und andere Ansätze) bis hin zu der Frage, ob „Agil“ nicht das neue „Bio“ ist: ein Label, das demjenigen, der sich damit schmückt, das gute Gefühl vermittelt, genau das Richtige zu tun. Und das ganz ohne den Zwang, seine Grundeinstellung überdenken zu müssen.

Wo sind die Tester?

Verwunderung erzeugte bei mir Jens Schauders Einführung in ScalaTest. Das lag nicht am Thema (spannend) oder an der Art der Präsentation (live und locker). Aber jedes Mal, wenn Jens Alternativen oder Ergänzungen zu ScalaTest erwähnte und das Plenum fragte, wer das genannte Werkzeug (z.B. Hamcrest oder JUnit Rules) kennt, gingen nur wenige Hände nach oben. Wo waren plötzlich all die agilen testinfizierten Entwickler, die den Weg zu den XP Days gefunden hatten? Vielleicht in einem der parallel stattfindenden (technischen) Workshops.

Anschließend durften Rolf Dräther und ich wieder Heinz von Foerster zu Wort kommen lassen. Die Zeitlosigkeit der Aussagen dieses wunderbaren Weit- und Querdenkers fasziniert mich immer wieder aufs Neue.

Der Abend klang aus bei Hoepfner-Bier und tollen Gesprächen.

Why Agile doesn’t scale

Der zweite Konferenztag begann mit einem Geburtstagsständchen, das die XP Days Germany wahrlich verdient haben. Dan North gratulierte der Konferenz zum Zehnjährigen – und legte dann los. „Why Agile doesn’t scale“ lautete seine Eingangsfrage. Die Skala, die Dan dabei meinte, ist die Größe des Projekt- und Programmportfolios eines Unternehmens. Seine Antwort auf diese Frage: Agile Projekte haben die lokale Optimierung zum Ziel. Das Management jedoch kümmert sich um die optimale Gestaltung des gesamten Unternehmens. Und außerdem spricht es eine andere Sprache als wir Agilisten, wie Dan uns in einem kurzen Rollenspiel anschaulich vor Augen führte („Wann werdet Ihr das nächste Release liefern?“ „Nun, wir haben auf der Basis der Schätzwerte aus den vergangenen Sprints eine Velocity errechnet, die folgende Prognose zulassen…“ „Hä?! Noch einmal die Frage: Wann werdet Ihr das nächste Release liefern?“ „Also, unser Burndown Chart…“). Auch Sprache sei übrigens eine lokale Optimierung, so Dan North. Die nächste Herausforderung für den agilen Wandel sieht er im Überwinden des Grabens zur Governance. Von diesen Vortrag hätte ich gerne ein Video, denn ich war leider nicht in der Lage, all den guten in Höchstgeschwindigkeit vorgetragenen Gedanken zu folgen.

Unterhaltung und Wissenswertes in 6 Minuten und 40 Sekunden

Ich liebe Pecha Kucha. Dieses Kurzvortragsformat hat es mir wirklich angetan, und mittlerweile bietet fast jede (agile) IT-Konferenz mindestens einen Vortragsblock an, in dem sich Vortragende der Herausforderung stellen, in 20 Folien á 20 Sekunden ein Thema oder eine Nachricht zu transportieren. Alle vier Pecha Kuchas waren gut, aber am schönsten fand ich Rolf Dräthers Ausführungen über die Bedeutung von Rhythmus in Scrum. Damit nicht genug, hat er das Publikum den Scrum-Rhythmus mit Hilfe von Body Percussion am eigenen Leibe spüren lassen. Ein tolles Gefühl, wenn der ganze Vortragssaal im vorgegebenen Takt schnippt, klatscht und stampft.

Abgerundet wurde dieser Vortragsblock durch Andi Scharfstein, der uns mitnahm auf eine Reise in die Welt der esoterischen Programmiersprachen: Von Programmen in der Sprache „Chef“, die man auch kochen oder Backen kann, über höllisch schwere Sprachen und Programmiergemälde bis hin zu „Hello World“ in C-Dur reichte die Bandbreite, die mir vor allem eines gezeigt hat: in vielen Programmierern schlummert ein enormes kreatives Potenzial. Vielleicht hilft ein Hinweis auf diese Projekte, um mit dem Vorurteil vom Pizza verschlingenden technikverliebten Kellerkind aufzuräumen – vielleicht bewirkt es aber auch das Gegenteil…

Was braucht mein Management?

Frank Schlesinger begann seinen Vortrag mit den „Orga Smells“, die er einst in seinem Unternehmen wahrgenommen hatte: Die nicht agilen Organisationseinheiten konnten mit der agilen Softwareentwicklung nicht mehr Schritt halten. Es gab Priorisierungskonflikte zwischen den Teams. Statt Feedback-Schleifen zu durchlaufen, wurden Reporting-Kanäle bedient. Letzteres Problem nahm er mit einem Team in Angriff, indem er sich und seinem Kollegium zunächst ein paar Fragen stellte: Machen wir das Richtige (was ist der Business Value dessen, was wir erschaffen)? Machen wir es richtig (wie viel Aufwand fließt in welche Aktivitäten)? Wie geht es uns? (hier können Retrospektiven Antworten liefern) Wie kommen wir voran (was sagt uns unser Scrum Board)? Ausgehend von diesem Fragen wurden verschiedene Maßnahmen ins Leben gerufen, Konzepte erarbeitet und in die Tat umgesetzt – alle mit dem Ziel, ein besseres Gespür für den Gesundheitszustand der Firma zu bekommen. Dabei gab es manch überraschende Erkenntnis. So hatte niemand mit dem großen Interesse für den Happiness Index gerechnet – ein Zeichen dafür, dass in diesem Unternehmen nicht allein die Geschäftszahlen zählen.

Product Owning Kanzler und Scrum Master Präsident

„Würde ich mit diesem Sprint-Ergebnis wiedergewählt werden?“ Mit diesem Satz rückte Udo Wiegärtner die agile Softwareentwicklung nahe an die Bundespolitik. Mit den anderen Parallelen, die er in seinem Vortrag „Scrum im Bundestag“ zog, gelang ihm das nicht ganz so gut, aber das war auch nicht sein Ziel. Vielmehr ging es ihm darum, durch den Perspektivenwechsel eine neue Sicht auf bekannte Dinge zu erzeugen, die uns Agile aus unseren gewohnten Umlaufbahnen werfen und uns wieder (selbst)kritisch machen sollte. Dieses Experiment ist meiner Meinung nach gelungen.

Open Space – but…

Der Community Day war gut besucht. Alle Wiederholungstäter freuten sich auf einen Open-Space-Tag – aber dann kündigte Florian Eisenberg ein „Open Space – but…“ an. Verwirrung. Dann Neuorientierung: wir sind agil und heißen Veränderungen willkommen. Und da Florian für die Mittagspause eine Retrospektive geplant hatte, ließen wir uns auf das Experiment ein.

Die von den Teilnehmern eingereichten Themen landeten zunächst auf einem Backlog, wo sie von allen per Dot Voting priorisiert wurden. Die am höchsten bewerteten Themen verteilte das Organisations-Team auf die Räume und die 40-Minuten-Slots, und schon ging es los.

Die erste Session behandelte die Stukturierung von Ideen, Konzepten und Aufgaben. Dies scheint nicht nur für mich eine Herausforderung darzustellen. Die gemeinsam erstellte Sammlung von Werkzeugen und Techniken bot kaum Überraschungen: Wiki, Mindmap und Notizzettel aller Art rangierten ganz oben auf der Liste, wenngleich nicht alle gleichermaßen glücklich mit diesen Werkzeugen waren. Was oft hilft, ist die Verbesserung des Werkzeugs (z.B. ein Mindmapping-Tool, das in ein Github-Repository speichern kann, oder die Atoma-Notizbücher mit umsortierbaren Seiten) oder der bessere Umgang mit dem Werkzeug (z.B. die Nutzung der Wiki-Suche und das regelmäßige Wiki-Gärtnern). Oder man trainiert den vorhandenen Speicher (das Gehirn), um ihn besser nutzen zu können.

Als Scrum Master mit systemischen Fragen zu arbeiten – das wollte ich in der zweiten Session lernen. Stattdessen bekam ich einen knappen Überblick über offene Fragetechniken, die uns zu der Diskussion führte, wie viel systemisches Grundverständnis ein Scrum Master braucht, um seinem Team dienen zu können, und wann der Scrum Master sich für nicht zuständig halten und einen Experten empfehlen sollte (z.B. bei persönlichen Problemen). Fazit: Systemisches Coaching lernt niemand, indem er ein kurzes Buch zum Thema liest. Nicht ohne Grund dauert eine gute Coaching-Ausbildung mehrere Jahre. Inspirierend war die Session aber allemal.

Anschließend diskutierten wir das Management-Dilemma, das ich aus verschiedenen Vorträgen der vergangenen zwei Tage abgeleitet hatte: auf der einen Seite sollen wir die Erwartungen des Managements erfüllen, auf der anderen Seite wollen wir gemeinsam neue Wege gehen. Irgendwo dazwischen, so meine These, könnte der gemeinsame Nenner liegen, der als Ausgangspunkt geeignet ist. Also machten wir uns auf die Suche.

Eine Erkenntnis, die ich aus der Diskussion gewonnen habe: der Wunsch vieler Manager nach immergrünen Projekten ist nichts anderes als deren Komfortzone. Mit unserer Transparenz hinsichtlich Fortschritt und Risiken bereiten wir diesem Wunschdenken ein jähes Ende – kein Wunder, dass wir dabei nicht auf Gegenliebe stoßen. Bevor wir nun übereinander schimpfen (eine Verhaltensweise, die nicht sonderlich neu ist), sollten wir versuchen, einander tatsächlich zu erreichen und zu verstehen. Es hilft, gut zuzuhören, dazulernen zu wollen und allen gute Absichten zu unterstellen. Und vielleicht mal auf jene Konferenzen zu gehen, die unsere Manager besuchen, anstatt zu erwarten, dass sie zu uns kommen.

Am Nachmittag entdeckte ich ein Format, von dem ich schon viel gehört, aber das ich noch nie erlebt hatte: Mit „Lean Coffee“ können viele (durchaus unterschiedliche) Themen innerhalb kurzer Zeit diskutiert werden. Nach einer Priorisierung der Themen werden diese in kurzen Zeiteinheiten behandelt. Ist die Zeit abgelaufen, dann wird gemeinsam entschieden, ob man dem Thema eine weitere Timebox widmen möchte. Auf diese Weise haben wir innerhalb von einer Stunde acht (?) verschiedene Themen besprochen, von „wie werde ich Sprecher auf einer Konferenz?“ über „Wie wird mein Team performanter?“ bis „Wie löse ich als Scrum Master einen Dauerkonflikt im Team?“. Tolles Format, gute Diskussionskultur und wertvolle Antworten auf spannende Fragen.

Abschließend bot ich für alle Erschöpften eine Lesung aus den „Geschichten vom Scrum“ an – als Sneak Preview auf die zweite Ausgabe, die noch in diesem Jahr erscheinen wird. Das hat offenbar nicht nur mir viel Spaß gemacht.

Das Experiment „Open Space – but…“ hat ein gemischtes Echo hervorgerufen. Mir wurde deutlich, wie gut gewählt die Regeln von Open Space sind. Die vielen kleinen Veränderungen haben das Format meiner Meinung nach nicht besser gemacht. Trotzdem war es wichtig, dieses Experiment gewagt zu haben.

Fazit

Rückblickend haben mir die XP Days wieder viele tolle Ideen und neue Kontakte geschenkt und damit mein agiles Universum bereichert. Mein Dank gilt den Organisatoren sowie allen Teilnehmern, die mit ihrer Offenheit und Neugierde wieder einmal dafür gesorgt haben, dass die XP Days keine Themenberieselungsmaschine sind, sondern ein Community Event.