Welche Geschichte hört man typischerweise über Agilität? Genau, meistens klingt es in etwa folgendermaßen: Agilität wurde von einigen frustrierten Entwicklern erfunden, die die Nase von nicht funktionierenden Prozessen voll hatten und von Dutzenden an Artefakten, die nicht die Bohne zum finalen Produkt beigetragen haben. Sie bekämpften all die schrecklichen V-Modelle, RUPs und wie auch immer diese schwerfälligen und überladenen Prozess-Monster hießen, indem sie einige schöne leichtgewichtige und agile Prinzipien erfanden, die sie dann Scrum, XP und so weiter nannten. Und seitdem haben sie nicht von ihrem heroischen Kampf abgelassen, die Entwickler von ihrer tonnenschweren Prozesslast zu befreien und die Agilität in diese Zentren der Rückständigkeit zu tragen, d.h. in das Management und die Fachbereiche, mit dem Ziel, eines Entwicklers Leben wieder lebenswert zu machen. Das ist doch die Geschichte, die wir so kennen, oder?
Nun, hier bei codecentric kennen wir eine ganz andere Geschichte. Indem wir bereits seit längerer Zeit agil Software entwickeln, hatten wir schon einige Male die Gelegenheit, Teil des ersten agilen Projekts zu sein, das die jeweiligen Kunden umgesetzt haben. Meistens mussten die Kunden eine harte Terminvorgabe einhalten oder etwas ähnliches, das mit ihren normalen Prozessen nicht funktioniert hätte und sie hatten etwas über die Produktivitätserhöhung durch Agilität gehört. Nun, um die Geschichte abzukürzen: Zu irgendeinem Zeitpunkt waren wir dann mit dabei, um das entsprechende Projekt auf eine agile Art und Weise umzusetzen. Aber während der Umsetzung dieser Projekte machten wir dann Erfahrungen, die häufig ganz anders waren als die, die man auf Basis der „bekannten Geschichte“ erwartet hätte:
Die Fachbereiche *liebten* die Agilität! Sie waren superglücklich über die kurzen Feedback-Zyklen und dass sie jemand hatten, der bereit war, wirklich mit ihnen zu kommunizieren, anstatt sie bei jedem Problem oder Anforderung immer nur aufzufordern, ein weiteres formales Dokument zu schreiben. Sie liebten es, wenn sie sehen konnten, wie ihre Vision in kurzen Iterationen heranwuchs und sie die Möglichkeit hatten, ihre eigenen Ideen dabei nachzujustieren. Sie fanden es sogar klasse, wenn sie bemerkten, dass sie mit ihren ursprünglichen Ideen auf dem Holzpfad waren, da sie die Möglichkeit hatten, diese Fehler einfach zu korrigieren und so das finale Produkt massiv verbessern konnten. Sie waren schlicht und ergreifend glücklich und hätten sie die Wahl gehabt, hätten sie nie wieder ein nicht-agiles Projekt gemacht.
Das Management mochte Agilität auch recht gerne. Das Management der Fachseite mochte es, weil seine Fachbereiche es liebten und das IT-Management mochte es, weil sich das Management der Fachseite nicht mehr über zu späte Liefertermine, zu hohe Belastung für ihre Leute oder ähnliches beschwerte. Okay, es war nicht immer Liebe auf den ersten Blick beim IT-Management. Oftmals waren sie schon recht misstrauisch gegenüber dem ganzen agilen Kram, weil sie keine Ahnung hatten, was auf sie zukommen würde, wenn das ein richtig dicker Erfolg werden sollte. Manchmal wünschten sich diese Manager hinter vorgehaltener Hand, dass das Projekt scheitern würde, denn dann hätten sie den ganzen Fachbereichs-Leute gezeigt, dass dieser agile Kram auch nicht funktioniert und man deshalb bei dem altbekannten und etablierten Vorgehen bleiben kann.
Und dann waren da noch die Entwickler, diese Leute aus den IT-Abteilungen des Kunden, die nach all den Jahren überglücklich sein sollten, dass sie endlich agil arbeiten durften, nicht wahr? Überraschenderweise waren die meisten von ihnen überhaupt nicht glücklich! Sie liebten ihre Prozesse und Artefakte sehr und die meiste Zeit drängten sie auf „mehr Formalismus“. Sie fühlten sich sicher in der Welt, die sie sich über die Jahre geschaffen hatten. Wann immer in den vergangenen Jahren etwas schiefgegangen ist, haben sie ein weiteres Stück Formalismus hinzugefügt, einen weiteren Prozessschritt, ein weiteres Artefakt. Sie hatten sich ihre eigene, sehr komfortable Welt innerhalb der Grenzen ihrer Prozesse geschaffen. Alles hatte seinen Platz und seine Ordnung. Alles war in ihren Prozessen beschrieben und Dinge, die nicht in den Prozessen beschrieben waren, waren schlicht und ergreifend verboten. Und das Beste daran: Niemand musste wirklich Verantwortung für irgendeinen Fehler übernehmen. Solange man sich an die Prozesse gehalten hat, hat man alles richtig gemacht und wenn etwas schiefgegangen ist, musste es der Fehler von jemand anderen sein. Also, tue einfach brav, was immer der Prozess Dir vorschreibt und Du bist sicher! Uff, was für eine Erleichterung!
Man kann sich sicherlich vorstellen, dass Agilität mit seinem Fokus auf Ergebnissen anstatt Prozessen, mit eigenverantwortlichen Teams, die Verantwortung für das Ergebnis übernehmen, mit seinem Druck, mit Fachbereichsleuten zu sprechen, um Dinge zu klären anstatt einfach eine Spezifikation zurückzuweisen, dass dieses ganze seltsame agile Ding nicht wirklich das war, auf das diese Entwickler gewartet haben. Tatsächlich hat es ihnen richtig Angst gemacht! Sie fühlten sich verdammt unwohl damit. Sie wussten nicht, wie sie damit umgehen sollten und hatten immer dieses angsteinflößende Gefühl, dass sie schuld sein könnten, falls irgendetwas schief gehen würde. Nein, sie waren überhaupt nicht glücklich!
Okay, ich gebe zu, dass ich es ein wenig überspitzt dargestellt habe, um den Punkt herauszuarbeiten, aber: Das ist kein spezifisches Problem irgendeines unserer Kunden; das ist ein Phänomen, das man quer durch die ganze Branche beobachten kann. Wir hatten eine Menge Unterhaltungen und Diskussionen mit vielen anderen agilen Protagonisten, die uns unsere Beobachtungen bestätigt haben. Und es ist nicht so, dass die beschriebenen Entwickler Agilität nicht mögen, weil sie „böse“ oder „ewiggestrig“ oder was auch immer wären. Sie fühlen sich schlicht unsicher. Sie haben sich über Jahre hinweg ihre wohlorganisierte Komfortzone aufgebaut oder sind in diese Komfortzone hineingedrängt worden und sie haben einfach noch nicht gelernt, mit dieser Agilität umzugehen.
Und was ist die Moral von der Geschicht‘? Ja, es bedarf einer Menge Change Management, um Agilität erfolgreich in einem Unternehmen zu etablieren, aber … *aber* ziemlich häufig sind es nicht die Fachbereiche, die wir auf die Agilität vorbereiten müssen; es sind die IT-Abteilungen, die wir auf die Agilität vorbereiten müssen. Seltsam, oder? … 😉
PS: Ich rede nicht über *alle* Entwickler. Ich weiß, dass viele von Euch agil denken und es lieben, in einer agilen Weise zu arbeiten. Aber auf der anderen Seite gibt es immer noch diese große Masse an Entwicklern, die nicht agil arbeiten wollen oder zumindest nicht wissen, wie sie sich dahin entwickeln sollen und ich denke, es sind diese Leute, auf die wir unsere Veränderungsbemühungen konzentrieren müssen, nicht auf die Fachbereiche.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Uwe Friedrichsen
16.10.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Uwe Friedrichsen
CTO
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.