Trust isn’t just an Agile essential, it’s an essential whatever you’re doing, but I think it is a good indicator of how successful your Agile practices are. You can’t force people to trust you but you can do some things that will prevent them from trusting you. This post is about why it’s important and how Agile helps.
Making customers trust you
I once joined a team at the start of a new project, working with internal business users. We talked to some users in an attempt to prioritise their requirements. Everything was a must, and I mean everything. They wouldn’t accept a single one of their requirements as anything other than a cast iron essential. Worse than that, we couldn’t stop the requirements from coming. It turned out that they had already expended a lot of effort working out every last detail of what they wanted, solutioneering all the way.
This, it turned out, was because they felt they’d been burned by tech so many times. Too often in the past they had given basic requirements and seen nothing until the end of the project, when it was too late to do anything about it. They had complained about the results and been told that their complaints had no basis because the software conformed to the requirements. So this time they came to the project armed with a cast iron contract. If you’ve been around enough software projects this will be familiar to you. It’s depressing.
If you’re doing a lot of Agile things on your project, your users will trust you because they will be seeing things all the time and helping to guide the project. They will feel part of decision making and understand the reasons behind project decisions as you make them. If they are really close to the project they may even feel like part of the project team – responsible for successes and as proud of the software as you are. That’s what happened to us, and it came in handy when we had to have some conversations at the end of the project about a few genuinely non-essential items nobody wanted to pay for. In short, they’ll respond to the fact you’re collaborating with them towards a good outcome.
Making your team trust you
Trust is also a huge part of your team working environment. I’ve been fortunate enough not to work in any truly toxic teams, but I’ve certainly been in environments where development teams were not entirely honest with senior management, or where developers were nervous about breaking the build or keeping the lead developer happy. In the short term, this sort of thing raises stress levels for development teams. In the longer term, it results in nasty surprises for managers and tech leads.
Mostly, in my experience, this happens because of people reacting poorly to bad news. It’s just a personal opinion, but I don’t think shouting at people or assigning blame is the best way to deal with challenges. That doesn’t mean you don’t analyse processes when something goes wrong but there is a distinction to be drawn between “finding out who screwed up” and “finding out how we screwed up and how to prevent it in future”.
A good way to keep tempers in check inside development teams is by changing how you think about problems. If we’re all one team and we all share collective responsibility then it’s tough to blame one individual for a screw up.
Better than this, and just as effective for senior management, is the short timeframes. If a developer is talking about what they’re working on to the rest of the team every day, it’s impossible for them to go too far astray or become too delayed before everyone else can see it. If the team’s progress is slower than expected then they will see it and should be in a position to report it up the chain a lot faster than they would in a waterfall-style project.
Trusting your team
A less unpleasant symptom of a lack of trust, but just as destructive, is micromanagement. Many people will have seen this too: a manager gets some bad news about a mistake or a delay and they parachute into the project to make sure things are “run properly”. Maybe they attend some meetings or change the project structure without consulting the people on the project. Even if the intervention is a wise one, it is unlikely to improve relationships if you don’t seek the consent of the governed, so to speak 🙂
There isn’t much advice I can think of for trusting teams except to do it. Maybe in the early days you can do it a long way from a hard deadline – give someone on the team a task you would normally do yourself and let them get on with it. They may fail, but they’ll learn when they do and if you really leave them to it, they’ll try again and eventually succeed.
In conclusion, trust is important. Ask yourself if you trust all of the people involved with your project and if they seem to trust everyone else. If they don’t, that is an indicator that your processes can be improved. If everyone trusts everyone, that may not be an indicator that your processes are perfect but it is certainly an environment where they are free to evolve in the right direction.