I BROUGHT YOU IN, AND I WILL KILL YOU

— Misha, could it be that you are simply a bad manager, that you failed to get your team used to some good agile or scrum, to bring in those best practices?

It was minute 25 of the Q&A after the talk Dzimka and I gave on "Why everyone hates daily stand-ups".

The first questions were either complimentary or incomprehensible. And here came the first attack.

"What did we ever do to you, Vitalik? No more beers with you," I thought.

And no, I got upset not because I was being criticised. Criticism is good. Even this kind.

I got upset because I now had to explain to a man who believes in best practices that ...

Best practices do not exist

Saying that is cruel. It is like telling a child there is no Santa. And that the bearded guy in the shopping centre is just a failed stand-up comedian. And that he smelled of Jägermeister, not of pine.

Someone could fairly point out: where did the phrase "best practices" even come from, if they do not exist? My answer: they do exist, but only in one particular context. The one the Cynefin framework calls Simple.

Cynefin splits "decision-making contexts" into 4 categories: Simple, Complicated, Complex, Chaotic. They differ in predictability: how precisely we can explain the cause by looking at the effect.

You are in a Simple context if pressing a button gets you the expected result, guaranteed. Your keyboard comes with a simple manual listing which key to press in which situation. Anyone with three years of village schooling can make good decisions here. Example: operating a TV remote.

Your context is Complicated if you have to think hard about which exact button to press. There are no manuals. There are collections of advice from people who have been around. Situations differ in small details, and those details decide what you end up pressing. Over the years you get better at it, you become an expert and you make fewer wrong presses that eject you from the vehicle when all you wanted was to recline the seat. Example: driving a car.

Your context is Complex if, to get a result resembling what you need, you have to press keys at random and watch what comes out. As a rule, what comes out is not it. And if you do manage to hit something suitable, you will not be able to get the same thing next time. Or you will, but only if you sneeze times first. And only if you turn 15 today.

However much former developers turned team leads would like it, management is not like operating a microwave. The decision-making context here is at least one level above Simple. If you could feed a compiler some code that manipulates human behaviour and get the same outcome every time, I would suggest you pinch yourself: Erzhan Neo, wake up, time for work.

Advice: study everything, try every practice, idea and trick you find attractive. But do not count on running into a silver bullet. And do not count on never having to change anything again, because ...

Nothing lasts forever

A couple of years ago we started writing code in pairs.

For the first six months everything went like clockwork. The practice did its job, gave us a pile of positive side effects, and we did not notice any negatives.

Over time the guys started missing the days when you could work alone. Some avoided working in pairs altogether. And our boss started treating the practice as playtime and waste.

It looked like we had changed nothing. The practice stayed exactly as it had been introduced. So why did it stop working?

Because the environment changed. The team grew in headcount, the work got harder. But the main thing is that the practice itself changed everyone around it.

A group of people who have never heard of pair programming and a group who have already tried it, loved it or come to hate it, behave differently. Indifference disappears, people start reacting. Some attack it, some criticise it, some defend it, some avoid it.

A practice can only survive if it is able to adapt to changed circumstances. But adaptation leads to a new round of feedback, and the practice has to change again and again. Fans of the stability of best practices are not going to enjoy this news.

Advice: after bringing a new practice into the team, be ready for constant change. Tune the rules to people's tastes. Try not to fall in love with the practice, and remember that ...

Every practice deserves to be killed

According to TRIZ, an ideal system is one that performs its function and does not exist. Yes, TRIZ was built to solve engineering problems, looking at mechanisms and technical systems, but I think managers can take some ideas from there too.

Any practice we use to organise work can be seen as a system. If we accept that an ideal system is one that performs a function but does not exist, then any existing real-world practice cannot be ideal. And if you push it, any practice is a crutch by definition.

Introducing a practice is an answer to some problem. The function of the practice is to fix that problem. Any overhead spent on performing that function pushes the practice further from the point of ideality.

The point of ideality arrives when efficiency reaches 100%. When running the practice takes 0 seconds, costs 0 €, and has no side effects at all.

As you understand, reaching the ideal is impossible. But at the very least we can try.

Advice: you made the mess, you clean it up. Review the practices your team has settled into. Look for ways to squeeze them, shake the nonsense off them, make them as weightless as your skill allows.

If all else fails, use the Taras Bulba principle: "I gave you life, and I will take it."