Bye bye complicated - Hello complex 

 18 December 2020

Like it?

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

A model - false, but useful

In one of my first agile projects in the early 2000s, I asked myself the question a lot: Why? Why change all processes, responsibilities, 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 - thinking - agile helps us deal with knowing we know nothing - that is, with uncertainty. And how did that come about? Here, an inaccurate but useful model helps: complicated became complex. That was a turning point. But it's already over. Complicated used to be. 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 frameworks. 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. These were the great days of the optimizers. Making the process more and more efficient. Cutting away what could be cut away. Fine-tuning the set screws and aligning them with each other so that the whole project structure ran like clockwork. That worked pretty well, at least until the cost of further optimization outweighed 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 noticeable. 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 work), where the connection between cause and effect is no longer clear. And if you turn a cog, you can't be sure what it will affect (nice examples of this can be found, for example, in the current Netflix documentary: The Social Dilemma). But that's not all. The framework 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:

  1. further optimizing and sticking to the usual: this then 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 on things going back to the way they were. I don't believe in it.
  3. 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!

Do you like this post? Share it: