Today I'd like to follow up on a few thoughts that reached me as feedback: Why should we be agile now and not continue as before?
A model - inaccurate but useful
In one of my first agile projects in the early 2000s, I asked myself the question very often: Why? Why overturn all processes, change responsibilities, dissolve hierarchies, new tools here and fancy methods there? Just because it's hip and everyone is doing it?
Yes, of course you can argue with faster, higher, further, more flexible...but for me a completely different reason has emerged over the years: Working agile - thinking agile - helps us deal with knowing that we know nothing - that is, with uncertainty.
And how did that come about? An inaccurate but useful model helps here: complicated became complex.
That was a turning point and is already over. Complicated used to be. Now it's complex.
The "good" old days
Everything was far from better in the past. But it was simpler. At least we understood it. A development project was manageable. Even large projects could be based on relatively stable framework conditions. An MS Project plan still had a useful half-life. The link between cause and effect was traceable. If something was changed at one end, it was possible to estimate what it would affect.
This was the great time of the optimizers. Making the process more and more efficient. Cutting away what could be cut away. Fine-tuning the set screws and coordinating them with each other so that the entire project structure runs like clockwork. This worked quite well, at least until the costs of further optimization exceeded the benefits. But that was only one problem.
I know that I know nothing and I do not know what I do not know
Let's blame it on the Internet. Maybe not the first generation, not even the second, but at some point our software and our projects started to develop a life of their own. Creeping, hardly recognizable. Only accompanied by the uneasy feeling that it becomes confusing. A few systems were coupled here, a data exchange there, a few microservices added. And today we are faced with applications and system landscapes whose algorithms cannot be explained by individuals (but they do work), where the connection between cause and effect is no longer clear. And if you turn a cog, you can't be sure what the effect will be (beautiful examples of this can be found, for example, in the current Netflix documentary: The Social Dilemma).
But that's not all. The general conditions are also no longer as stable: rapid update cycles of the environment, security gaps, a physical virus that - snap - turns the entire world upside down, Safe Habour here, DSGVO there, employees and their needs, shareholders and theirs. And all this in a rush. Now we have three options:
- further optimizing and sticking to the usual: this then ends in frustration or burnout - but the goal can no longer be achieved.
- Sit it out. Theoretically possible if you have staying power and bet on things going back to the way they were. I don't believe in it.
- Accepting uncertainty and shaping it yourself. Sounds exhausting, tedious and unsatisfying. But in my opinion it is the only sensible option.
What's so hard about that?
In my experience, the biggest hurdle to overcome is the fear of not having control. Not having anything to fill MS Project and any PowerPoint report traffic lights with. Not being able to cover all eventualities. Not being able to hedge your bets. Not being able to name someone to blame if something goes wrong.
I'm going to spin around optimistically: I think that's what all the agile paraphernalia of methods and tools want to educate us to: Trust, courage and responsibility. Big words and so far away from planning, control and software development. But it is - sorry for that - without alternative. Sitting out is not. Holding your hands in front of your eyes won't make the problem go away. So please: take the first step courageously!