Der Agile Day auf der JAX 2017

Was tut man, wenn agile IT-Projekte an organisatorische Grenzen stoßen?

Ann-Cathrin Klose

(c) Shutterstock / Rawpixel.com

 

Der Agile Day auf der JAX 2017 steht ganz unter dem 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 unsere Speaker berichteten.

In insgesamt 7 Vorträgen plus Abschlusspanel haben sich die Speaker des diesjährigen Agile Days der JAX der Frage gewidmet, wie agile Methoden funktionieren – oder auch nicht. Neben vielen Tipps und Tricks aus der Praxis ging es ganz zentral auch um die Frage, wie die Transformation ganzer Unternehmen und komplexer Organisationsstrukturen hin zu einem agilen Mindset gelingen kann.

Zu dieser Frage prägte Volker Schmidt die Aussage, 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önnten. Wie der Hindernislauf gegen die eigene Bürokratie gewonnen werden kann? Agil natürlich!

Wie transformiert man ein ganzes Unternehmen?

In einem agilen Mindset sollen solche Hindernisse selbstredend abgebaut werden. Genau darüber hat Volker Schmidt in seinem Vortrag gesprochen: Was tut man, wenn agile IT-Projekte an organisatorische Grenzen stoßen?

Agile Methoden werden heute beinahe überall eingesetzt, sind oft aber nicht richtig umgesetzt: Aus dem Scrum Master wird 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.

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

„Ausgerechnet die DB Systel!“

Auch die DB Systel ist auf dem Weg zur Agilität, wie Martin Strunk berichtet. Und auch hier gibt es stellenweise Schwierigkeiten damit, dass das agile Mindset nicht jedem Manager liegt. Zur agilen Arbeitsweise bei der DB Systel gehört ganz fest die Handlungsorientierung – Strunk zitiert 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äsentierten, die zu grandiosen Fehlschlägen geführt haben. Das soll 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 kann auch Strunk davon berichten, dass nicht jedem Stakeholder und mittleren Manager diese Arbeitsweise leicht fällt. Er berichtet von zwei Typen des Widerstands: Die einen betreiben eine Art inneren Widerstand und sabotieren die agile Arbeitsweise damit; die anderen sind ganz offen gegen Agile. Hier empfiehlt Strunk, erstere an die Hand zu nehmen und durch den Prozess des agilen Wandels zu führen. Freiheiten für die Teams sind nicht für jeden leicht zu akzeptieren und auch, wenn der agile Wandel eigentlich von unten kommen soll, so muss doch auch ein Angebot zur Begleitung da sein.

Wer jedoch gar nicht agil werden möchte, muss gegebenenfalls auch mal überdenken, ob er in einer agilen Struktur richtig aufgehoben ist. Manchmal, das kann Strunk berichten, stellen Manager aber 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. Auch die Tatsache, dass heute eigentlich jedes Unternehmen ein Softwareunternehmen ist, wie es Karsten Glied und Tobias Ranft in ihrer Session formulieren, 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ären sie, 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 nicht alle Kollegen anderer Abteilungen bereits agil; natürlich ist aber jeder Kollege überzeugt, dass die eigenen Prioritäten die wichtigsten sind, erzählen die Speaker aus ihrer Erfahrung,

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 agilen Teams zu vermitteln. Eine Retrospektive, so steigt Konstantin Diener in seinem Vortrag zum Retrospektivenwerkzeugkasten ein, ist 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 durchaus eine gute Idee, um eine angenehme Atmosphäre zu schaffen – bei der cosee GmbH, wo Konstantin 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 zu kennen, macht bereits 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.

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 aber einen ernsten Hintergrund: Retrospektiven sind ein Ort, an dem nicht nur sachlich, sondern durchaus auch emotional diskutiert wird. Und das darf seinen Platz haben.

Von „Scrum but“ zu Nexus und Featureteams

Lars Gerhard und Markus Kehle berichteten darüber, wie Scrum skaliert werden kann. Mit Nexus wollen sie das Unternehmen B/S/H wirklich agil machen. Nexus, so erklären 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.

Mythen, Trends und Best Practices

Diese Beweglichkeit ist es, die Wolfgang Pleus in Sachen agilem Wandel direkt zu Beginn seiner Session in den Mittelpunkt des Geschehens rückt. Alles ist in Bewegung, Märkte verändern sich und Unternehmen müssen sich anpassen, wenn sie mithalten können wollen. So berichtet er, dass die Generation Y in der IT-Branche aktiv nach Agile fragt und dieses Mindset einfordert – wer nicht wirklich agil ist, hat es in Zeiten des Fachkräftemangels also schwer.

Auch Pleus berichtet davon, dass das agile Mindset nicht auf die IT-Abteilung begrenzt ist; dort geht es zwar los, muss sich dann aber ausbreiten, damit es nicht zu Konflikten kommt. Wenn die agile Fehlerkultur 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, betont Wolfgang Pleus, und verweist 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, muss dabei aber mitziehen – es bestimmt die Kultur ja wesentlich mit, entscheidet über die grundsätzliche Richtung. 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, sagen Sebastian Bauer und Dominik Ehrenberg in ihrer Session. Warnzeichen dafür sind beispielsweise Retrospektiven, aus denen der Product Owner ausgeschlossen wird oder unfertige Stories, die trotzdem abgenommen werden. Auch wenn technische Schulden in Form einer 8000 Zeilen langen Klasse gemacht werden, die sich keiner mehr anzufassen traut, stimmt was nicht.

Ein Problem dabei 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“ ist etwas, das auch im Abschlusspanel noch einmal zur Sprache kommt. Wieder und wieder werden agile Teams, aber auch Stakeholder 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 muss, 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.

 

Verwandte Themen:

Geschrieben von
Ann-Cathrin Klose
Ann-Cathrin Klose
Ann-Cathrin Klose studiert allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz. Seit Februar 2015 verstärkt sie als redaktionelle Mitarbeiterin die Redaktion bei Software & Support Media. Zuvor war sie als freie Autorin tätig und hat erste redaktionelle Erfahrungen bei einer Tageszeitung gesammelt.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.