The fairy tale of the agile developer

What is the common story that you usually hear about agility? Yes, most of the times it is something like this: Agility was invented by a bunch of frustrated developers who had enough of big, big processes that did not work out and dozens of artefacts that did not deliver to the final product at all. They fought all those evil V-models, RUPs and however those cumbersome process monsters were named by inventing some nice, lean and agile principles they called Scrum, XP and so on. And since then they kept on with their heroic fight to free the developers from their 800 pound process burden and to carry agility into those centres of backwardness, i.e. the management and the business departments to make the developers lives worth living again. That’s sort of the story you know, isn’t it?

Now, here at codecentric we know a quite different story. Practicing agility for quite a while we had the opportunity to be part of the first agile projects that some of our customers implemented. Most of the times those customers had a tough deadline to meet or something similar that would not work with their standard processes and they had heard about the speed of agility. And, to make a long story short: At some point in time we were there to implement the project in an agile fashion. But throughout the implementation of those projects our observations were often quite different than you would expect it from the “common story”:

The business departments simply *loved* agility! They were happy that they had fast feedback cycles and somebody who was going to have a real communication with them, not just urging them to write another formal document whenever they had a problem or a requirement. They loved to see their vision growing in short iterations and having the opportunity to fine-tune their own ideas. They even loved to figure out where they were wrong with their initial ideas because they had the opportunity to change it easily and to improve the final product a lot that way. They were simply happy and they never wanted to do a non-agile project again if they had the choice.

The management also was quite fond of agility. The business management liked it because their departments loved it and the IT management liked it because the business management stopped complaining, about delivering too slow, putting too much workload on their folks, and so on. Okay, with the IT management it wasn’t always love on first sight. They often were quite suspicious about that agile stuff because they had no idea what it would mean for them if that would really become a big success. Sometimes those managers secret hope was that this agile project would fail. Then they would have shown to the business folks that all this agile stuff does not work out either and that they can stick to the way they did it before. On the other hand, when the agile project turned out to be successful they liked the part that the business people were quite happy.

And then there were the developers, those guys from the customers IT department who should be lucky that finally they are allowed to work agile, after all those years, shouldn’t they? Surprisingly, most of them weren’t lucky at all! They liked their processes and artefacts very much and most of the time they were pushing towards “more formalism”. They felt save in the world that they built up throughout the last years. Whenever something went wrong in the former years they added another piece of formalism, another process step, another artefact. They had built their own comfortable world within the bounds of their processes. Everything had its place and its order. Everything was defined in their processes and things that were not described in their processes simply were not allowed. And the best part of it: No one had to take over real responsibility for any failure. As long as you comply with the processes you have done everything right and if something goes wrong it must be the fault of someone else. So, simply do whatever the process tells you and you are safe! Whew, what a relief!

You can imagine that agility with its focus on the product instead of the process, with self empowered teams who take over responsibility for the result, with its enforcement to communicate with business people to clarify things instead of simply rejecting specifications, this whole strange agile thing wasn’t exactly the thing those developers were looking for. It actually scared the shit out of them! It made them feel really uncomfortable. They did not know how to deal with this and they always had that creepy feeling that they could be responsible if something would go wrong. No, they weren’t lucky at all!

Yes, I exaggerated it a bit to make the point plain, but: That is not a problem of some particular customers of ours. That is something that you can find throughout the whole industry and we had a lot of talk and discussions with many other agile protagonists who approved that observation we made. And it is not that those developers don’t like agility because they are “evil” or “backward” or whatever. They are simply insecure. They built their well organised comfort zone for many years or they were forced into that comfort zone and they simply haven’t learned yet how to deal with this agile way.

And what is the moral of the story? Yes, it takes a lot of change management efforts to introduce agility successfully into a company, but … *but* quite often it is not the business departments that we have to prepare for agility; it is the IT departments that we have to prepare for agility. Strange, isn’t it? … ;-)

A short “disclaimer”: I am not talking about *all* developers. I know many of you have an agile mindset and really love to work the agile way. But on the other hand there is still that huge mass of developers around who do not want to become agile or at least do not know how to change, and I think it is those people we have to focus our change efforts on, not on the business folks.

  • Facebook
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Blogger
  • LinkedIn
Uwe Friedrichsen

2 Responses to The fairy tale of the agile developer

  1. Niklas Schlimm says:

    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 :-)

  2. 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

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>