Das Märchen vom agilen Entwickler

2 Kommentare

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.

Uwe Friedrichsen

Uwe Friedrichsen ist ein langjähriger Reisender in der IT-Welt. Als Fellow der codecentric AG ist er stets auf der Suche nach innovativen Ideen und Konzepten. Seine aktuellen Schwerpunktthemen sind Skalierbarkeit, Resilience und die IT von (über)morgen. Er teilt und diskutiert seine Ideen regelmäßig auf Konferenzen, als Autor von Artikeln, Blog Posts, Tweets und natürlich gerne auch im direkten Gespräch.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Niklas Schlimm

    19. März 2010 von Niklas Schlimm

    Hallo Uwe,

    mich beschäftigt schon länger folgende Frage: muss der agile Entwickler im Allgemeinen ein höheres Skill-Niveau haben, als der der „normale Entwickler“? Folgende Fähigkeiten würde ich vielleicht von einem erfolgreichen agilen Entwickler erwarten:

    1. Er ein Kommunikationstalent: in agilen Prozessen wird viel wert darauf gelegt, dass sich Personen miteinander unterhalten. Dabei muss der Entwickler verschiedene Kontexte bedienen können. Sich mit dem anderen Eclipse-Freak nebenan zu unterhalten ist einfacher als sich auf den Blickwinkel eines Fachbereichsmitarbeiters einzulassen. Das erfordert Flexibilität und eine gewisse Anpassungsfähigkeit. Außerdem „fordert“ der Fachbereichskollege, er will gute Lösungen vom Entwickler sehen. Der Entwickler hat also eher ein angespanntes Verhältnis zum Fachbereich? Sicher ist das Verhältnis schwieriger als zum Freak nebenan.

    2. Er kennt die wichtigsten agilen Techniken: dazu gehört für mich vor allem Test Driven Development. Ein „Anfänger“ hat es damit SEHR schwer, weil das Pferd gewissermaßen von hinten ausgezäumt wird. Der Anfänger schafft es aber gerade erst das Pferd von vorn aufzuzäumen. Die zweite wichtige Fähigkeit ist das Refactoring, das ist auch ein spezieller Skill. Agile Entwickler sind Testautomatisierungs- und Refactoring-Experten.

    3. Er hat ein überdurchschnittlich hohes Abstraktionsvermögen: agil bedeutet für mich anpassbar entwickeln. Man macht sich ja vorher nicht unednlich viel Gedanken, sondern versucht möglichst schnell ein lauffähiges Produkt zu deployen. Das wiederum erfordert eher flexible, generische Lösungen, damit viele ehemals strategische (irreversible) Design-Entscheidungen entfallen.

    4. Hohes Design-Verständnis: Während der Entwickler in der „Backstube“ ein fertiges Design serviert bekommt, muss der agile Entwickler den gesamten Designprozess selber (natürlich auch in Teilen in Zusammenareit mit anderen) bestreiten. Das alleine erfordert schon eine gewisse Erfahrung. Viele „Anfänger“ haben nicht den Blick für gute oder schlechte Lösungen, was ein guter und was ein schlechter Programmierstil ist.

    5. Er ein starken Charakter haben: Formalismen entstehen in meinen Augen aus einem gekränkten Ego. „So, dann schreiben wir halt ab jetzt alles auf.“ Oder sie entstehen aus dem Kontrollzwang von Managern. „Wir wollen es messbar machen, wir wollen verstehen …“. Und kontrolliert wird dann auf Basis von Dokumenten, anstatt auf Basis implementierter Features. Und noch was: der agile Entwickler steht im Mittelpunkt des Projektes. Er bringt die Lösungen. Er trägt viel mehr Verantwortung und tut „mehr“ als in herrkömmlichen Projekten. Wird das honoriert? Will das jeder Entwickler? Angst vor Veränderung darf der agile Entwickler auch nicht haben, ein Gewohnheitstier darf er nicht sein. Veränderung bedeutet stress, oder?

    Fazit: Hat der normale Entwickler in einem konservativen Prozess nicht ein ruhigeres Leben als der agile Entwickler? 🙂 Hier tragen andere die Verantwortung und die Entscheidungskompetenz. Leider haben „die anderen“ aber auch oft viel zu wenig Plan, wie man Software baut … upps 😉 … und da war der agile Gedanke/Entwickler geboren 🙂

  • Uwe Friedrichsen

    Hallo Niklas,

    ja, absolut d’accord! Da gibt es kaum etwas hinzuzufügen.

    Ich denke auch, dass Agilität wesentlich höhere Anforderungen an einen Entwickler stellt als Prozess- und Artefakt-getriebene Vorgehensmodelle, dass ein Entwickler in agilen Umfeldern eben nicht mehr nur „Entwickler“ ist, sondern deutlich mehr.

    Bezeichnenderweise ist der agile Gedanken ja auch im Dunstkreis einiger sehr erfahrener, hochqualifizierter Entwickler-Teams entstanden. Das waren alles Leute, die dieses „mehr“ mitbrachten und es auch einsetzen wollten.

    Interessant finde ich Deinen Gedanken mit dem gekränkten Ego. Ich habe das Einfordern von Formalismen bislang eigentlich primär auf Unsicherheit und Angst (vor was auch immer) zurückgeführt; die „beleidigte Leberwurst“ habe ich da bislang noch nicht gesehen, stimme Dir aber zu, dass das in der Tat auch ein Treiber sein kann … sehr interessanter Gedanken … muss ich mal sacken lassen.

    Danke noch einmal für den klasse Kommentar!

    Gruß, Uwe

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.