Bye bye Complicated - Hello Complex

Today I would like to follow up on a few thoughts that have reached me as feedback: Why should we be agile now and not carry on as before?

A model - imprecise, 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, you can of course 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 to deal with knowing that we don’t know anything - in other words, with uncertainty.
And how did this come about? An imprecise but useful model helps here: complicated became complex.
That was a turning point and is now a thing of the past. Complicated used to be complicated. Now it’s complex.

The “good” old days

Not everything was better in the past. But 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 connection between cause and effect was comprehensible. If something was changed at one end, it was possible to estimate what effect it would have.
That was the great age of the optimizer. Making the process more and more efficient. Cutting out what could be cut out. Fine-tuning and coordinating the set screws so that the entire project structure ran like clockwork. That worked quite well, at least until the costs of further optimization exceeded the benefits. But that was just one problem.

I know that I don’t know anything and I don’t know what I don’t 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. Gradually, barely recognizable. Accompanied only by the uneasy feeling that things were getting confusing. A few systems 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 work), where the connection between cause and effect is no longer clear. And if you turn a cog, you can’t be sure what effect it will have (great examples of this can be found in the current Netflix documentary: The Social Dilemma).

But that’s not all. The framework conditions are no longer so stable either: rapid update cycles of the environment, security gaps, a physical virus that - snap - turns the entire world upside down, safe haven here, GDPR there, employees and their needs, shareholders and theirs. And all at a rapid pace. Now we have three options:

1. continue optimizing and sticking to the familiar: this ends in frustration or burnout - but the goal can no longer be achieved.
2. sit it out. Theoretically possible if you have staying power and bet that everything will go back to the way it was. I don’t believe in it.
3. accept uncertainty and shape it yourself. Sounds exhausting, tedious and unsatisfactory. But in my opinion, it’s the only sensible option

What’s so difficult about it?

In my experience, the biggest hurdle to overcome is the fear of having no 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 protect yourself. Not being able to blame anyone if something goes wrong.

Let me be optimistic: I think that’s what all the agile bits and pieces of methods and tools want to teach us: Trust, courage and responsibility. Big words and so far removed from planning, control and software development. But - sorry about that - there is no alternative. Sitting out is not an option. Holding your hands in front of your eyes won’t make the problem go away. So please: take the first step with courage!