Are Only 1 in 4 Developers Trusted?

Following on from my previous post about Trust & Agility, I ran a straw poll on the @codemanship Twitter account as a sort of litmus test of how much trust organisations put in their developers.

A new monitor is a decision of the same order of magnitude of risk of the proverbial “$100 decision” that I’ve used for many years now when assessing the capacity for trust – and therefore for decentralised decision-making – that agility requires.

If I wanted a new monitor for my home office, that would be entirely my decision. There was, of course, a time when it would not have been. That was when I was a child. If 13-year-old me wanted a new monitor, I would have had to refer that decision up to my parents.

When I got jobs, I made my own money and bought my own monitors. That’s called “being a grown-up”.

I’ve worked in organisations where even junior developers were handed corporate credit cards – with monthly limits – so they could “just go get it”, and not bother management with insignificant details. Smaller decisions get made when they need to be made, and they don’t get caught in a bottleneck. It really works.

So why are 3 out of 4 developers still not trusted to be grown-ups?

UPDATE:

A few people have got in touch giving me the impression that they took this to be literally about buying monitors or about company credit cards. These are just simple examples. They indicate a wider problem often. Developers who I’ve seen wait weeks for a monitor, or a laptop, or a software license, have tended to be the ones who “wanted to do TDD but weren’t allowed”, or who “wanted 20% but the boss said ‘no’ “, or who wanted to go to a conference but it was denied. These tend to be the teams that can’t self-organise to get things done. In my 20 years’ experience of Agile Software Development, the correlation has been very close between teams of developers who have to ask permission for a new monitor – just as an example (IT’S NOT ABOUT BUYING MONITORS!) – and teams who have to ask for permission to automate deployments or to talk to the end users directly.

Trust & Agility

I find it useful to revisit the Manifesto for Agile Software Development when I think I need a reminder of what it was originally all about. One of the 12 principles of Agile software is:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done

Now, it’s just one little word, buried in that text, but in my experience it makes all the difference: trust.

In two decades of kind of sort of doing Agile Software Development, I’ve found one simple metric that has tended to be the best predictor of whether an organisation is capable of agility: how much does it cost here to make a $100 decision?

Let me give you an example. I worked on a contract once where the team needed a couple of whiteboards in the room. I’ve bought those kinds of whiteboards. I know what they cost (a few hundred pounds), and I know they can be acquired within 24 hours very easily.

If I want a whiteboard for my home office, I go online to one of the thousands of retailers who sell them, whip out my credit card, and that whiteboard will be in my office and covered with boxes and arrows the next morning.

In this particular client organisation it took multiple meetings and hours of everyone’s time. It got escalated to the IT director, who – presumably – had nothing more important to think about. We spent thousands of pounds deciding to buy a few hundred pounds-worth of whiteboards, and for several weeks we struggled with design discussions at a critically early stage of the work for the want of a few square metres of something cheap we could draw on. And in the end, the IT director didn’t buy us two basic boards. He bought us a £4,000 electronic whiteboard that we never used. Eventually, real whiteboards did appear, but not before a heap more discussions.

Now, it shouldn’t have come as a surprise, because the organisation in question was in the business of selling shrink-wrapped bureaucracy. But the whiteboard debacle turned out to be an omen of what was to come. I’ve seen that many, many times in my career.

These days, I test for that metric when I get the chance. As a small, niche supplier of training and coaching services, it’s in my interest to try and avoid overly bureaucratic clients. The cost of doing business with them often outweighs the benefits. And, let’s face it, their developers are unlikely to be given the time and support they need to learn code craft. Agility is not for you.

What has this got to do with trust? And what does trust have to do with agility?

It’s simple: the reason we couldn’t just go out and buy whiteboards is because the managers didn’t trust us to make that decision. So we had to wait. And wait. And wait.

Agility demands that the people doing the work, whenever possible, make the decisions about how the work is done. Management have to support them in that, and remove any obstacle getting in the team’s way. Lack of whiteboard space in the early iterations of a design process was an obstacle, created by lack of trust, that cost us time and money and stopped us getting stuff done.

Want stuff to get done? Then you need to trust the people doing it to just get on with it. Escalating what are relatively trivial decisions costs time. A whiteboard. A monitor. More memory.  A WebStorm license. These are all small, low-risk decisions that hold teams back when they’re delayed.

Making small, low-risk decisions quickly is foundational to agility. Fail fast. If an organisation can’t make a $100 decision quickly and easily, then the more it costs them to decide and to act, the further agility will be out of reach.

Sure, if the team wants to move to Sweden, or buy a minibus, that size of decision will need to be discussed at a higher level of budgetary authority. But a whiteboard? Or a laptop? Or – goddamit – stationary?! The sad fact is that far too many teams have absolutely no budgetary discretion at all (unless they want to have a meeting, in which case – bizarrely – the sky’s the limit).

Of course, some will say “Trust has to be earned”, but for teams this is a Catch 22. They have to deliver to earn the trust to make their own decisions, but they’re less likely to deliver if they can’t make those decisions. It’s a self-fulfilling prophecy. Teams who aren’t trusted will struggle to earn trust.

My solution has always been to trust myself and make the decision anyway. This has not gone down well with some managers, who demand compliance from their teams. This is why I and the corporate world have tended to be incompatible, and why I now run my own business and buy my own whiteboards.

Lack of trust is usually a symptom of fear of failure. It’s a learned behaviour built on historical failures – usually by completely different teams of completely different people. When we refuse to give Team A autonomy because Teams B, C, and D failed in the past, then we’re punishing the children for the sins of their ancestors.

It takes courage – one of the four core Agile values – to press the reset button and say “Okay I’m going to let Team A do their thing and I won’t interfere unless they screw up”. It takes even more courage – and honesty – to recognise that a team that’s not delivering might actually be being held back by our lack of trust, and to relinquish some control.

This is why so many organisations fail to achieve agility. Managers are afraid to take their hands off the wheel and let the team drive. So many “Agile transformations” – especially at scale – push in the exact opposite direction, attempting to impose processes and standards that constrain teams while giving managers nothing more than a greater illusion of control. This is the antithesis of agility.

I’ve only seen it work when managers genuinely empower their teams. As terrifying as it may sound to hand a company credit card to people who cover their laptops in Marvin The Martian stickers and come to work on tiny scooters, the alternative is that you accept the inevitable bureaucracy that will result if you won’t trust your teams.

 

Extreme Programming Is Dead. Long Live Extreme Programming.

So, hey. Back in them olden times when architects ruled the world, and methodology was an actual thing – despite nobody having any idea what that meant, and I can tell you that from first-hand experience  – there was a way of delivering working software that end users could actually use.

It went un-articulated for decades, until some folk actually articulated it. They gave it a name, and that name was  – disappointingly – “Extreme Programming”. To quote from The Hitchhiker’s Guide To The Galaxy when Deep Thought named the computer to solve the meaning of life, the universe and everything that would come after it: “Oh”.

But don’t be fooled by the name. XP is how computer programmers writing software for customers had been winning at writing software for customers for decades. There’s literally nothing new in it. Its brilliance is in how it named the thing those programmers were doing. It gave them form. It gave them voice.

There’s nothing extreme about it. Unless you think that delivering software customers need is extreme.

But since the rise of “Agile”, those software development truisms have been lost in a fog of the same illusion of control that gave rise to the Big Methods of the 1990s. SAFe is just SSADM with agile tinsel draped around it. LeSS is even less than that. Scrum has become a monster, spewing out an exponentially growing army of consultants 70% of whom have never delivered a working software product in their lives.

Cut through all that crap and what’s left is those decades-old insights into what delivers reliable, maintainable working software that customers can change their minds about. And those Big Agile ideas may now dominate the world of Big IT, but teams who dare to deliver working software still cleave to those original insights. There are no shortcuts.