News

I am an agile guy now so I believe in things like psychological safety, “safe to fail” and trusting people.

Just like all agile coaches, I am a nice guy and I believe everyone else is too. So I let people try new things, they make mistakes and we are pretty happy about it all since we know mistakes are a great source of learning.

Of course, there is a small blast radius where the mistakes led to some human suffering but that is cool because we all learned from the experience.

But in the old days, I did a lot of work looking at processes and work practices and I was not so enthusiastic about making mistakes. In fact, I spent a lot of my time predicting and identifying mistakes so I could design them out of what I was building.

Not only that – when building processes, I would try to design them to stop naughty people causing harm to nice people. Essentially, if a naughty person wants to steal money and they work in a bank, I thought that we should try to stop them.

So what happened when I became agile, did I become more naive, or did I suddenly discover that people are nice and amend my behaviour to account for this new discovery?

We know I have always been a pretty trusting person.

"My father taught me that the cost of not trusting people is usually higher than the cost of trusting them."

- James King – Son of Barry

My father had a saying – “whether you trust people or not, you will generally prove yourself right.” What he meant by that is that the way you treat people changes the way they behave.

Now that I am older I can think of several times where trusting someone led to me being hurt or let down. But for the most part, I think my father was right. Treating other people the way I want them to treat me has almost always worked out for me.

This seemed true in process design too – if you put in too many checks and balances then they distract people, who then stop thinking and miss things. At the same time, naughty people spend time gaming the system – learning how to circumvent all the controls and barriers to being naughty.

So a complex system or approach generally leads to more errors than a simple one that relies on people’s accountability.

"Telling someone that you trust them and letting them know you are relying on them is usually more effective than trying to control their actions to prevent them from being dumb or naughty."

- Agile researcher – 2016 (Written on a post-it note, since lost to the world because he failed to document his thinking properly.)

So where does that leave us – should we trust our customers and our teams and just assume the benefit of learning will always outweigh the cost of failure?

My wife has a saying in project management – I trust but I will check. She will trust people to deliver, but there will be agreed on points in where that trust will be validated by reality. There will be milestones, walk-throughs and audits.

In an agile team, we build this in too. Every sprint has a plan at the start, trust in between but a checkpoint at the end of the sprint. Every day has trust and collaboration supported by a stand-up where we check in on things. Every story has a definition of done and an agreed acceptance test. It all sounds like a lot more validation than trusting. 

In fact, these approaches are designed to minimise the “blast radius” of mistakes. We can create a culture of safety because people know that when they make a mistake, it will be found and corrected quickly without them being yelled at and without great suffering for others.

This is especially true where we have retrospectives, peer reviews and constant collaboration which increase the speed and depth of learning.

"Agile approaches aim to decrease the cost of mistakes and increase the speed of learning so the value of learning exceeds the cost of learning from mistakes."

- James King and possibly many agile coaches before him.

That is lovely and empowering. But, mistakes still have a cost and some of them just suck, with no learning to be gained.

So we should still try to analyse our mistakes, so we are making “learning mistakes” and not stupid ones. Interestingly, there is a long history of designing mistakes for learning and in designing processes and even collaboration to avoid them.

I have previously written about designing systems to protect users from making predictable, yet annoying mistakes in an ancient article called “International standards for being stupid.”

What I would like to do in my next article is to explore one specific type of error – bad decisions. These might be decisions where naughty people intend to be lazy or where good people may be prone to make a mistake or exercise poor judgement.

I hope that by looking at these areas, good teams can adopt some simple practices to build good decisions without slowing the team down or harassing people to make them justify everything they do.

Posted by James King
Copyright © James King