„Agilität bedeutet, dass man keine Prozesse hat.“

„Wenn wir agil sind, haben wir alle Freiheiten.“

Das Missverständnis

Solche Sätze und viele mehr hört man fälschlicher Weise immer wieder, wenn man sich mit Entwicklern unterhält, die von agilen Projekten berichten. Meiner Erfahrung nach wird nicht nur von Entwicklern, sondern auch von anderen Rollen in einem Projekt Agilität mit Grenzenlosigkeit verwechselt. Doch die Abwesenheit eines starren Projektplans bedeutet nicht, dass es keine Struktur gibt.

Hand aufs Herz!

Ich erinnere mich an ein Gespräch bei einem Kundenprojekt mit einem anderen Berater, der sagte: „Paul, Hand aufs Herz: Warst du jemals in einem agilen Projekt, das wirklich gut lief?“

Auch wenn mich die Frage überraschte, kann ich verstehen, warum sie gestellt wurde. Ich wusste genau, auf welche Probleme der Kollege sich bezog. Ich habe bspw. schon viele Fälle gesehen, in denen Unternehmen „agile Inseln“ ins Leben gerufen haben. Projekte, die nominell agil sein sollten, sich aber im Unternehmen regelmäßig an der nicht-agilen Umwelt gerieben haben. Ich war jedoch froh, ehrlich antworten zu können: „Ja, das habe ich!“

Nach dem Gespräch habe ich angefangen, darüber nachzudenken, warum diese Projekte gut liefen. In diesen Projekten hat nicht nur die Umwelt gepasst. Es hatte auch etwas mit dem Mindset der Teammitglieder zu tun.

Agile Entwickler sind freie Entwickler?

“ Sind agile Entwickler freie Entwickler?“ war die erste Frage, mit der ich mich in meinen Überlegungen beschäftigte. Ich kam jedoch schnell zu dem Schluss, dass meine vergangenen gut laufenden Projekte nicht dadurch gut liefen, dass ich besonders viele Freiheiten und keine Verbindlichkeiten hatte. Nein, eigentlich mussten die anderen Teammitglieder und ich sehr diszipliniert in diesen Projekten arbeiten.

Die Projekte waren agil, aber sie hatten eine klare Struktur. Wir haben Kundenanforderungen und -feedback bekommen, haben diskutiert und Architektur mitgestaltet, aber das alles nie in einer chaotischen Form. Dazu hat es auch immer mal jemanden mit Veto-Recht gebraucht oder jemanden, der eine Diskussion der Effizienz zu Gunsten abgekürzt hat. Dabei war der Umgang aber immer wertschätzend.

Freiheiten im Rahmen des Ziels

Ein weiterer Punkt, der sich in meinen Überlegungen aufgedrängt hat, war, dass alle Teammitglieder das Produkt in den Vordergrund gesetzt haben und sich darauf konzentriert haben, das Beste herauszuholen. Mir ist dabei aufgefallen, wie sehr diese Projekte mich an mein Hobby „American Football“ erinnern.

American Football ist ein sehr taktischer Sport und für mich der ultimative Teamsport. Im Football versuchen elf gegen elf Spieler als Gruppe mit einem Ball bis in einen bestimmten Bereich Raumgewinn zu erzielen bzw. zu verhindern. Im Gegensatz zu anderen Sportarten wird der Ball aber während eines Spielzugs nur von einem Bruchteil der Spieler berührt. Das Ganze in einem verbindlichen Rahmen von vier „Quartern“ mit 15 Minuten Spielzeit.

Der Erfolg hängt von allen elf Spielern auf beiden Seiten ab. Jeder hat seine persönliche bzw. positionsbezogene Aufgabe. Die eigene Aufgabe zu kennen, ist jedoch das absolute Minimum. Richtig erfolgreich ist man nur, wenn man seine eigene Aufgabe kennt, die seiner Mitspieler und das Konzept und Ziel des kompletten Spielzugs. Der Grund ist einfach: Was nach dem Beginn des Spielzugs passiert, wie die gegnerischen elf Spieler darauf reagieren, ist nicht vorhersehbar und man muss im Verlauf des Spielzugs und im Rahmen des eigenen Konzepts spontan auf Gegebenheiten reagieren, um das Beste herauszuholen.

Um der unvorhersehbaren Komplexität zu begegnen, arbeiten Footballspieler wie auch Entwickler in Iterationen an ihrem Ziel. Ein Spielzug oder Sprint findet statt, jeder erledigt seine Aufgaben so gut wie möglich. Auf ungeplante Ereignisse muss mit den Zielen vor Augen reagiert werden. Im Anschluss wird reflektiert, wo man steht, welche Probleme es gab und was man als nächstes tut, um sein Ziel zu erreichen.

Ich glaube, dass das Commitment zur eigenen Aufgabe und die Disziplin im Sinne des Ziels zu handeln, wenn ungeplante Ereignisse passieren, ist, was uns als Entwickler in Projekten erfolgreich gemacht hat. Natürlich gab es Störfaktoren und Hindernisse zu bewältigen, aber die Bereitschaft, auf spontane Ereignisse mit Disziplin und dem Ziel im Fokus zu reagieren, hat dazu geführt, dass diese Projekte gut liefen und erfolgreich waren.

Fazit: Sind agile Entwickler also frei?

Um die eingehende Frage zu beantworten, muss man differenzieren. Agile Entwickler sind nicht frei von Verbindlichkeiten oder Verantwortung. Ein zeitlicher Rahmen, definierte Rollen und ein klares Projektziel sind nur ein paar Beispiele. So wie man beim Football nicht frei von seinen positionsbezogenen Aufgaben, konkreten Spielzügen oder dem zeitlichen Rahmen ist.

Doch zur Wahrheit gehört auch, dass es Freiheiten gibt und geben muss. Agil sein bedeutet, anpassungsfähig zu sein. Die Freiheiten sind jedoch an den Zielen eines Projekt ausgerichtet und erfordern Disziplin. Denn Freiheiten gibt es nicht ohne Verantwortung. Ist das immer einfach? Nein, definitiv nicht. Es ist jedoch die Art und Weise, wie ich gerne an Projekte und meine Arbeit herangehe.

Ich kann nur jeden dazu einladen, sich bei seinen Entscheidungen während der Arbeit einen Moment Zeit zu nehmen und sich zu fragen, ob diese Entscheidung wirklich das Ziel im Blick hat.

Ich bin Paul Kwaziwai Deuster Softwareentwickler und Footballspieler bei den Hannover Grizzlies aus Leidenschaft!

Empfehlung

Wenn du mehr darüber wissen willst, wie man in einem dynamischen Umfeld Produkte entwickelt, empfehle ich den Artikel Strategie: Komplexe Produktentwicklung in dynamischen Umgebungen von meinem Kollegen Philipp Pelka