Der Agile Day auf der JAX 2017

Was tun, wenn agile IT-Projekte an organisatorische Grenzen stoßen?
Kommentare

Der Agile Day auf der JAX 2017, moderiert von Mirko Schrempp, stand ganz im Zeichen der agilen Unternehmenskultur und Organisation. Agile sind nämlich heute fast alle – aber wenn es um die Kommunikation mit Stakeholdern oder die agile Skalierbarkeit geht, dann kommen schon mal Probleme auf, wie die Speaker am Montag berichteten. Wir blicken zurück auf Trends und Themen.

Sieben Vorträge und zehn Speaker: Das war der Agile Day der JAX 2017. Unter Moderation von Mirko Schrempp, Redakteur von Entwickler.de und des Windows Developers, wurden dort am Montag ganz unterschiedliche Einblicke in die agile Arbeitswelt gegeben. Neben vielen Tipps und Tricks aus der Praxis ging es zentral um die Frage, wie die Transformation ganzer Unternehmen und komplexer Organisationsstrukturen hin zu einem agilen Mindset gelingen kann. In unserem Rückblick beleuchten wir die verschiedenen Perspektiven, die von den Speakern zu dieser Frage aufgezeigt wurden.

Wie transformiert man ein ganzes Unternehmen?

Volker Schmidt von der Cegeka Deutschland GmbH hat in seiner Session die Aussage geprägt, dass Organisationen mit mehr als 400 Mitarbeitern eigentlich keine Kunden mehr bräuchten, sondern sich ausreichend mit sich selbst und der eigenen Verwaltung beschäftigen können. Wie der Hindernislauf gegen die eigene Bürokratie dennoch gewonnen werden kann? Agil natürlich!

In einem agilen Mindset sollen solche Hindernisse selbstredend abgebaut werden. Genau darüber hat Volker Schmidt dann auch gesprochen: Was tut man, wenn agile IT-Projekte an organisatorische Grenzen stoßen? Das Problem dabei ist, so erklärte der Speaker, dass agile Methoden heute zwar beinahe überall eingesetzt werden, oft aber nicht richtig umgesetzt sind. Aus dem Scrum Master wird dann schnell ein Teamleiter, aus dem Product Owner ein Projektleiter. Und dann? Der Vorschlag des Plenums, in solchen Fällen einfach zu kündigen, wurde für nicht tauglich befunden – immerhin drehe man sich damit nur im Kreis.

Devs fight your battle! A pledge for cross-functional teams

mit Steffen Behn & Tina Dreimann (die kartenmacherei)

Bausteine erfolgreicher Retrospektiven in agilen Prozessen

mit Tobias Ranft (Beratung Judith Andresen)

Stattdessen legte Schmidt nahe, Stärken und Schwächen der angewandten agilen Arbeitsweise zu analysieren und Probleme dann gezielt mithilfe eines kundigen agilen Coaches anzugehen. Warnzeichen dafür, dass es nicht funktioniert, wären beispielsweise Storypoints, die zur echten Währung werden, oder lange Reports, die für die Stakeholder geschrieben werden müssen. Dann wäre es doch besser, wenn der Stakeholder einfach mal an der Retrospektive teilnimmt!

„Ausgerechnet die DB Systel!“

Auch die DB Systel befindet sich auf dem Weg zur Agilität, wie Martin Strunk, Fachbereichsleiter bei der DB Systel, berichtete. Und auch hier galt es durchaus einige Steine aus dem Weg zu räumen! Zur agilen Arbeitsweise gehört dort nämlich ganz fest die Handlungsorientierung – Strunk zitierte dazu den Ausspruch „Hast du was gemacht oder nur PowerPoints gebastelt?“ Agiles Arbeiten ist nämlich davon geprägt, dass man Dinge einfach mal ausprobiert.

Um die Mitarbeiter dazu zu ermutigen, veranstaltet man bei der DB Systel unter anderem sogenannte F*Up Nights, bei denen Manager Projekte und Ideen präsentieren, die zu grandiosen Fehlschlägen geführt haben, berichtete Strunk. Das solle zu einer positiven Fehlerkultur führen – bei der dann auch mal fünf von zehn Ideen scheitern dürfen, wenn die anderen fünf gelingen. Nur so lernt man das agile Arbeiten richtig!

Allerdings konnte auch Strunk davon berichten, dass nicht jedem Stakeholder und mittleren Manager diese Arbeitsweise leicht fällt. Er hat in seiner Session von zwei Typen des Widerstands dargestellt: Die einen betreiben eine Art des inneren Widerstands und sabotieren die agile Arbeitsweise damit; die anderen sind ganz offen gegen Agile. Hier empfahl Strunk, erstere an die Hand zu nehmen und durch den Prozess des agilen Wandels zu führen. Freiheiten für die Teams seien nicht für jeden leicht zu akzeptieren und auch, wenn der agile Wandel eigentlich von unten kommen sollte, so müsse doch auch ein Angebot zur Begleitung da sein, so der Speaker.

Wer jedoch gar nicht agil werden möchte, sollte gegebenenfalls auch mal überdenken, ob er in einer agilen Struktur richtig aufgehoben ist. Manchmal, auch darüber sprach Strunk, stellen Manager allerdings auch fest, dass ihr alter Job ihnen gar nicht so viel Spaß gemacht hat und dass sie in einem agilen Mindset glücklicher sind, weil sie zum Beispiel lieber mit Menschen arbeiten oder eher einen Fokus auf das Produkt legen können.

Stakeholder – die unbekannten Wesen

Fertig ist so ein agiler Wandel aber nie, das ist klar, und auch bei der DB Systel ist der agile Wandel ein Weg, der auch nach drei Jahren nicht abgeschlossen ist, berichtete Strunk. Auch die Tatsache, dass heute eigentlich jedes Unternehmen ein Softwareunternehmen ist, wie es Karsten Glied und Tobias Ranft von der Beratung Judith Andresen in ihrer Session formulierten, trägt dazu bei, dass es wieder und wieder zu Differenzen zwischen Stakeholdern und Entwicklern kommt.

In ihrem Vortrag zu Stakeholdern, den unbekannten Wesen, erklärten Ranft und Glied, dass ein Teil des Problems darin besteht, dass heute jeder Mitarbeiter mit den technischen Lösungen der IT arbeitet und somit sehr auftragsvergabefreudig ist. Natürlich arbeiten aber nicht alle Kollegen anderer Abteilungen bereits agil; trotzdem ist jeder Kollege überzeugt, dass die eigenen Prioritäten die wichtigsten sind, schilderten die Speaker ihre Erfahrungen.

Somit sind Stakeholder nicht nur unbekannte Wesen, auch ihre Menge ist unbekannt. Um Karsten Glied zu zitieren: „Die Stakeholder haben wir nicht erzogen, die haben keine Transparenz, wie Anwendungsentwicklung funktioniert.“ Auch hier lautete das Fazit, dass es sinnvoll ist, die (tatsächlichen) Stakeholder mit in die Retrospektive zu nehmen, um einerseits durchaus auch mal stolz auf Erfolge sein zu können, andererseits aber auch um den Kontakt zur Fachabteilung herzustellen und zu zeigen, wie agile Arbeit funktioniert.

Retrospektivenwerkzeugkasten

Wenn eine Retrospektive aber zum Pflichttermin verkommt und in der Kantine abgehalten wird, kann auch das nicht dabei helfen, das agile Mindset jenseits des Teams zu vermitteln. Eine Retrospektive, so stieg Konstantin Diener in seinem Vortrag zum Retrospektivenwerkzeugkasten ein, sei eine vertrauliche Sache, in der Mitarbeiter sich wohl fühlen und offen über anfallende Probleme sprechen können müssen.

Etwas zu essen anzubieten ist dabei aber durchaus eine gute Idee, um eine angenehme Atmosphäre zu schaffen – bei der cosee GmbH, wo Diener als CTO tätig ist, gibt es oft sogar ein kleines Buffet zur Retrospektive, wie er uns im Talk verraten hat.

Das Ziel einer guten Retrospektive ist immer die Veränderung im Sinne der Verbesserung. In Scrum bedeutet das, dass am Prozess gearbeitet wird – aber auch außerhalb von Scrum sind Retrospektiven sinnvoll. Immerhin kennt man das ja sogar aus dem Alltag. Wer schon mal Neujahrsvorsätze hatte, hat quasi eine Single-Person-Retrospektive durchgeführt und dabei Verbesserungspotential in mehr oder minder konkrete Ziele übergeleitet.

Allerdings sind Neujahrsvorsätze oft nicht besonders erfolgreich und somit vielleicht nicht das beste Beispiel für eine Retrospektive. Konstantin Diener erklärte darum auch gleich, dass eine gute Retrospektive mehrere Phasen hat – wer glaubt, das Problem bereits zu kennen, macht schon etwas falsch! Die Identifikation von Problemen und Lösungen gehören fest zur Retrospektive, aber auch die Besprechung vorheriger Retrospektiven gehört dazu. Welche Ziele waren gut, welche nicht so sehr? Was hat geklappt? Das hilft dabei, den eigenen Prozess wirklich zu reflektieren, so erläuterte es der Speaker.

Ein geflügeltes Wort aus den Retrospektiven der cosee GmbH gab uns Konstantin Diener auch noch mit auf den Weg: „Körperliche Gewalt nur nach Ankündigung!“ Was salopp klingt, hat einen ernsten Hintergrund: Retrospektiven sind ein Ort, an dem nicht nur sachlich, sondern durchaus auch emotional diskutiert wird. Und das darf seinen Platz haben, wie wir in dieser Session gelernt haben.

Von „Scrum but“ zu Nexus und Featureteams

Lars Gerhard (B/S/H) und Markus Kehle (Freiberufler) berichteten darüber, wie Scrum skaliert werden kann. Mit Nexus wollen sie das Unternehmen B/S/H wirklich agil machen. Nexus, so erklärten die Speaker, ist ein agiles Framework, das auf Scrum aufbaut und damit durchaus große Ähnlichkeit hat.

Allerdings werden die typischen Events der Arbeitsweise hier gleich mit skaliert. Damit die ganze Organisation agil werden kann, gibt es nicht nur das morgendliche Standup, sondern zwei davon: An einem nehmen Vertreter aller Teams teil, sodass übergreifende Probleme besprochen werden können; das andere findet ganz normal innerhalb des Teams statt. Auch Retrospektiven werden angepasst und wachsen einfach mit: Nicht nur die Teams und ihre jeweiligen Stakeholder führen Retrospektiven durch, auch der Gesamtprozess an sich wird über Retrospektiven kontrolliert und adaptiert, so beschrieben die Speaker uns die Vorzüge von Nexus.

Mythen, Trends und Best Practices

Diese Beweglichkeit und Bereitschaft zur Veränderung rückte auch Wolfgang Pleus von PLEUS Consulting in Sachen agilem Wandel direkt zu Beginn seiner Session in den Mittelpunkt des Geschehens. Alles ist in Bewegung, Märkte verändern sich und Unternehmen müssen sich anpassen, wenn sie mithalten können wollen. Der Speaker berichtete sogar davon, dass die Generation Y in der IT-Branche aktiv nach Agile fragt und dieses Mindset einfordert – wer nicht wirklich agil ist, habe es in Zeiten des Fachkräftemangels also schwer.

Auch Pleus erklärte uns außerdem, dass das agile Mindset nicht auf die IT-Abteilung begrenzt sein sollte; dort geht es zwar los, muss sich dann aber ausbreiten, damit es nicht zu Konflikten kommt. Wenn die agile Kultur des Lernens aus Fehlern nämlich mit einer streng hierarchischen Struktur, die nach Schuldigen fragt, kollidiert, engt das auch das agile Team ein.

Agile entsteht Bottom up, betonte Wolfgang Pleus, und verwies darauf, dass ein von oben diktierter agiler Prozess Probleme bereiten wird. Stattdessen sollten agile Teams organisch wachsen, wie durch Zellteilung: Aus einem Team werden durch zusätzliche Mitarbeiter zwei, die dann wieder zu Multiplikatoren werden. Das Management, auch auf mittlerer Ebene, müsse dabei aber mitziehen – es bestimme die Kultur ja wesentlich mit, entscheide über die grundsätzliche Richtung, so Pleus. Dafür sollte das mittlere Management geschult werden. An der organisatorischen Ebene scheitern agile Transitionen nämlich seiner Erfahrung nach am häufigsten.

Mein Scrum ist kaputt!

Wenn es auch nach dem Coaching und mit den besten Absichten noch immer nicht klappt, dann ist das Scrum einfach kaputt. Das sagten Sebastian Bauer (inovex GmbH) und Dominik Ehrenberg (Infineon Technologies AG) in ihrer Session. Zu den Warnzeichen, die die Speaker uns präsentiert haben, gehörten beispielsweise Retrospektiven, aus denen der Product Owner ausgeschlossen wird oder unfertige Stories, die trotzdem abgenommen werden. Auch dann, wenn technische Schulden in Form einer 8000 Zeilen langen Klasse gemacht werden, die sich keiner mehr anzufassen traut, stimme was nicht, befinden Bauer und Ehrenberg.

Ein Problem kann „Hempels Product Backlog“ sein. Das sind Backlogs, die dem Bürokühlschrank ähneln: Keiner weiß so genau, was drin ist; und warum es da drin ist, das weiß man erst Recht nicht. Auch hier können Konflikte zwischen der organisatorischen Ebene und in der Stakeholder-Kommunikation wieder auslösend sein! Wenn der Product Owner nämlich jeden Wunsch einfach auf das Backlog schreibt, um nicht „Nein“ zum Stakeholder sagen zu müssen, wird das Backlog schnell viel zu lang.

Das war der Agile Day 2017

Die Sache mit dem „Nein“ war ein Aspekt, der immer wieder und auch im Abschlusspanel noch einmal zur Sprache kam. Wieder und wieder werden agile Entwickler-Teams, aber auch Product Owner und Scrum Master, mit Anforderungen konfrontiert, die so nicht erfüllbar sind. Ein fixer Abgabetermin bei festem Budget und Scope; die sehr dringende Anforderung an der Kaffeemaschine, am besten zu gestern – viele Entwicklerteams kennen solche Schwierigkeiten!

Die Speaker des Agile Days der JAX 2017 waren sich in dieser Sache einig: Ein „Nein“ ist an der richtigen Stelle gar nicht schlimm. Volker Schmidt verwies bereits in seinem Talk darauf, dass man sich als Entwickler kaum Sorgen darum machen müsse, seinen Job zu verlieren – und, wie im Abschlusspanel zur Sprache kam, erst Recht nicht dann, wenn man Recht hat. Agile funktioniert nämlich nur dann, egal ob auf Team- oder auf Organisationsebene, wenn eine ehrliche Kommunikation stattfindet und nicht zu bewältigende Anforderungen offen benannt werden. Die 59. Idee des Stakeholders sollte man also lieber ablehnen, falls man eh nicht vor hat, sie jemals anzugehen. Das ist besser für den gesamten Prozess und alle Beteiligten.

Java-8-Nachlese – Wie hat Java 8 die Java-Welt verändert?

mit Klaus Kreft (Angelika Langer Training/Consulting)

Java Enterprise Summit 2017

Java EE 8 – What’s New and Noteworthy

mit Thilo Frotscher (Freiberufler)

Microservices mit Java EE. Das geht? Und wie!

mit Lars Röwekamp (OPEN KNOWLEDGE)

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -