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.
Was this post helpful?
More articles
fromUwe Friedrichsen
16.10.2018 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
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 author
Uwe Friedrichsen
CTO
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.