In my recent articles I’ve been discussing why building trust is more important than building software. This is never more evident than when I’m brought in for a Project Rescue. Each ailing project is unique, but the one thing they have in common is that trust has been lost. You can see it in the actions of everyone involved.
Building trust is more important than building software.
Jacobism
Every one is under a microscope and team members start acting out of fear. No one on the team wants to be blamed for failures so they try to reduce their risk of being the scapegoat. I’m not losing my job other this!
Stakeholders are hesitant to make decisions so they won’t be held accountable. Developers only want the easy tasks they can complete so they can show they’re not to blame. Management starts holding regular status meetings so they can figure out who’s not performing. Trust has completely deteriorated and everyone is feeling the pressure.
Getting a Team Back on Track
My first priority is always getting a quick win for the team. Regardless of project circumstances, I’ve found the following suggestions will lead a team back to the promised land. Be prepared to wear multiple hats or learn how to find the right people to wear those hats.
#1 – Understand the Product Vision
Understand the Product Vision and see what progress the team has made toward solving the problem. Sometimes the answer is none, but other times the team has just lost their way. It’s important to know where the team is at so you can identify where things got off track.
Making sure the team has a clear Product Vision is the foundation of any successful software project. Along the same vein, spending time with the Product Owner and Stakeholders helps build rapport with these key team members. This starts the trust building process.
#2 – Assess the quality of the Product Backlog
Next, assess the quality of the Product Backlog. Now that some rapport has been built with the Product Owner, work with them to determine whether the Backlog Items are well-defined and appropriately prioritized. Help them to identify based on the current project status, what the “best bang for your buck” backlog items would be. These should be features that are very important to the product, but can be implemented quickly.
#3 – Assess the Team’s Delivery
Work with the development team to assess their speed of Delivery. If they haven’t delivered anything, why? Are technology choices hindering them? Do they need additional automation to speed delivery? Are they struggling under the weight of excessive technical debt? Are the requirements well-defined prior to the Sprint? Try to understand them. Understand what’s been holding them back.
These conversations help build rapport with the development team. It allows them to speak their mind on what’s happened up until this point. They feel heard. This helps build rapport with the developers and avoid the feeling that you’re just there to tell them everything they’re doing wrong. You’re figuring out what’s going wrong together and determining how they can solve these problems.
#4 – Prioritize the “Best Bang for your Buck” Backlog Items
Prioritize the “best bang for your buck” backlog items to the next Sprint, or couple of Sprints. Work with the development team to ensure that these items can be completed. If you need to address items you discovered while assessing the team’s speed of Delivery, prioritize these items to the top of the Backlog and tackle them as part of the Sprint.
I can’t emphasize enough that the prioritized backlog items should be completed in the upcoming Sprint. If this means reducing Sprint Velocity and taking in less work than the team has up until this point, so be it. The key is, proving the team can do what they said they were going to do.
#5 – Get your Hands Dirty
Get in the trenches through the next Sprint(s)… deep in the trenches. Developers are extremely skeptical of “Ivory Tower Architects.” If developers feel you are suggesting an approach that you’ve never used before and you couldn’t do it yourself, you’ll lose them. As soon as they run into challenges with an approach or a technology, they will start losing any trust you may have built. Guiding them through the solution with modeling and helping them along the way through Pair Programming will not only increase their trust and respect for you, it will help you ensure their success.
#6 – Deliver
Delivering is like winning in sports. Even if your team has lost 10 games in a row, a win feels like progress. The team is turning things around, it’s a sign of life, a sign of things to come. Nothing builds trust quicker than delivering actual, useful software. When a stakeholder, manager, director, even the CEO can see a working solution in front of them, the impact is undeniable. The team is proud of what they’ve delivered and those watching feel the team is turning around.
Notice that nowhere in these steps did I mention evaluating staff or replacing team members. Is it possible that a team member isn’t suited for the role they’ve been playing? Sure, but every team I’ve worked with, the team members have fallen into roles that they are good at. People want to succeed and feel like they’re contributing. Especially if they’re on a winning team.
Rome wasn’t built in a day, and building back trust won’t happen overnight. Even a single successful Sprint can have an undeniable impact on organizational trust. The team is afforded more space to breath. Given more leeway when things may not go quite as planned. It’s never easy building back trust, but getting a team delivering useful software is a surefire way to do it.
Is your software development team performing at its peak? We can help! Schedule a free consultation to find out more.