Trust issues in software development
We all know that to make a good development team, we need to trust in each other that we deliver the best we could. That we can rely on each other.
That’s seems good on paper. But why in the real-world, there are only few teams success implementing this idea of trust?
It is not like this cannot be achieved at all. I always hear good and productive developer or agile evangelist said that they don’t encourage deadline and they will achieved even better result and productive team.
And personally, here in Taskworld, we also don’t use deadline. And we are getting lot more productive ever since we drop deadline. We rely on trust that everyone including designer, developer and stakeholder are trying their best. We have a milestone, but not a hard deadline.
Back to the question, why is it so hard to implement these kind of trust into other organisation?
I would said that it not hard at a start. Any consult can come to any organisation and tell them to just simply don’t do deadlines. It is not even hard to start. But it is hard to maintain.
Why?
From my experience, because usually, when people lose trust with each other, they don’t bother to repair the trust, they try to workaround by putting process or middle-man in-between.
Let’s say a developer in team take very long time for simple feature. What I mostly see repeat again and again is:
- Stakeholder / Team leads will ask about why is this take so long?
- They were given some answer from developer, which seems nonsense in stakeholder / lead perspective. Trust between them is lost at this point.
- Both parties try to come up with some process, let it be sprint planning, planning poker estimation, some rules they can think of. So they will be able to work together without annoying each other.
- Those processes fuel even more conflict between each party.
Don’t get me wrong. Process is require if you manage large group of people. Process can be a good thing. Process can make work easier. Sometimes we cannot move without a nice boundaries and rigid processes.
But what I saw is people usually try to use processes as a substitute for the trust that have been missing, and this never end well.
Don’t establish any process as a workaround for trust issues. Process is a tool that help people to achieve more, not a tool enable people to work with each other without proper level of communication and trust.
You cannot workaround trust issues.
Of course you may try, but I just have to say that I never found that succeeded.
And when people don’t bother repair trust, but try to workaround it. That’s when everything go down the slope. Meeting room become war room with a lot of politics. Every process is just a painful meeting which take too long than it should be.
Now, people try to workaround by try adjusting the processes or put even more processes into the equation. At this point, productivity is greatly decreased.
Because, in the end, process is not workaround for trust issues.
Me personally, as lead developer, I would go so far to fix trust between me and my teammate. We can sit together talking without doing any work for a day to clear any misunderstanding.
Because I knew that in the long run, it make us as a team more productive. I already realised from my past experienced that trust issues cannot be workaround.
I also have established some processes, but not as a workaround to be able to work with people I don’t trust. Every process I come up with is just a helper to make us more productive.
(Actually, some processes can help us regain trust between each party, but both party also need to realise that trust also need to be regained. Process can act as a tool, but not the end-goal.)
Resolving broken trust can be really really hard. I know, and I perfectly understand why people would rather put some processes instead of actually try to resolve the broken trust.
But I try to tell myself every time that I simply cannot runaway from it, since I’ve learned that trust issues cannot be workaround, in a really really hard way.
