As an agile coach, one of my favorite expressions in response to nearly any situation I encounter in an agile team is—“trust the team” or “trust the process”. So here are a few examples of what I mean:

If you think the team has underestimated their work and are leaving velocity on the table, “trust the team”…

- If they have underestimated they can always pull in more work. And you know, you could be wrong, so allow the team to sort through how they understand, size, and execute their work. They’ll appreciate the trust you’ve given them and will invest in doing good work.

- If you do see poor estimation or poor execution & adjustment, then bring this to the attention of the team within their retrospective. Give them examples, but allow them to explore the most effective way(s) to improve.

If you feel that the team isn’t working hard enough or are committed enough to their work, “trust the team”…

- Unless you’re a direct member of the team, it’s fairly presumptuous of you to assume they’re sand-bagging and not working hard. Or thinking that they lack commitment. Rather observe how hard they do work, handle their challenges, and deliver on their sprint commitments. Assume that the wonderful professionals you’ve hired are just that—hardworking, honest, and professional.

- And remember, just because people are putting in hours, that doesn’t mean they’re doing good work or working hard. It just means you have their butt in their seat…not their brain in the game.

If you feel that quality is poor and it isn’t improving sufficiently or you feel that the team isn’t taking product quality seriously, “trust the team”

- Ensure that your concerns are visible to the team and that they’re looking into root cause within their retrospectives.  However, let them tailor their activities to improve deliverables each and every sprint. Explore objective data on their defect & quality deliverable trending with them. Give them clear and complete done-ness criteria. BUT, allow them to discover how to do a good job as a team.

- Agile is not a magic formula. It cannot take a crappy product and, simply because you’re ‘agile’, remove all technical debt and bugs overnight. Improvement takes serious effort, commitment, and time. No silver bullets allowed!

If you’ve got a fixed date software delivery to make and you wonder if the team is going to get there, “trust the team” and “trust the process”

- First of all, solid agile teams make everything transparent. Secondly, they approach delivery in iterative chunks. Put these two together and you’ll actually get a heartbeat of how well the team is meeting your projections & needs. If they aren’t, then you get the chance to negotiate scope trade-offs with them.

- Agile projects can ALWAYS hit fixed date targets with fixed cost & quality goals. And they can ALWAYS deliver a set of your highest priority features. The variable in these situations though is scope—so you must be prepared to pare back scope via dropping low priority features and making micro-adjustments to other features—generally delivering Must-Haves over Nice to Haves.

If you feel that the Product Owner isn’t making good decisions surrounding feature priority, “trust the process”

- The Product Owner will get plenty of feedback in the Sprint Reviews as to whether they’re focusing the team on the ‘right’ features, at the ‘right’ time within the flow of the project. The key is to get stakeholders regularly attending and to encourage positive and constructive feedback.

- Quite often the Product Owner is a surrogate without real decision-making authority. That is NOT setting them up for success. Ensure your Product Owners are empowered to make decisions and have the seasoning and domain experience—to make the ‘right’ decisions.

These are only a few of the many real-world situations where we have a choice in how we actively demonstrate our understanding of agile principles and exhibit trust to our teams. You see, it’s not about saying you trust the team—it’s about truly trusting them and demonstrating that in in your words and actions. Next I want to explore a few, how shall I say it, trust anti-patterns or excuses that I commonly see.

 

There’s trust, and then there’s TRUST

Here are a few anti-patterns I frequently hear that indicate to me that the organization, leadership, project, management and other stakeholders don’t fully trust the team. I’m sharing them to broaden your thinking around trust and the ways we can frame it organizationally. By no means is this an exhaustive list, but more so a list that illustrates how our words don’t always necessarily align with truly trusting.

And of course this doesn’t apply to anyone reading this blog. So please just read it for future reference—in case you run into some of these anti-patterns…

Trust, but Verify

Of course I trust you, but I’m just simply verifying that what you’re telling me is true—as a simply checkpoint. Don’t worry about it, I’m just verifying…

Don’t be fooled, this anti-pattern isn’t about verification. It’s about distrust and the use of micro-management techniques to get into the heads of the team and control how they’re attacking the project. Yes, verification is important, but not daily. The Sprint Review is the ultimate verifier. Attend them.

The process is making me do it

Of course I trust you, but I need to get this information into the CMMI Level 3 artifact repository so that we pass our audits. Did you know that an audit was coming next month? Very serious stuff…

Another common anti-pattern is blaming distrust on the methods or process patterns that you’ve adopted as an organization. We’re CMMi Level 4, so I must have you fill out a detailed test results plan and sign at the bottom to confirm that you’ve tested everything you’ve said you’ve tested.  

Sure, processes carry some weight and responsibility. But this anti-pattern extends that as an excuse to hover over the team and control approaches & outcomes.

I’ve been doing this a long time and I know this path will lead to a disaster

Of course I trust you, but in my 25 years of experience, I’ve never seen a team deliver on a large scale refactoring effort. I simply don’t think it can be done…

While your experience is certainly valuable, times have changed and contexts are different now. Your team is exploring their own experience and finding their way. They’re establishing their experiences, and need to do that largely on their own…as you probably did.

I’m paid to prevent us from making mistakes

Of course I trust you, but my job is to prevent us from making mistakes and to develop the best products possible. It’s actually in my job description that I lead the team by the sheer force of my will and experience.

That I’m responsible and accountable for all of the results my teams produce. That leadership is about leading—showing team the way forward in practices and approaches. Trust does come into play, and of course I trust you, but only so far. Only when I have a belief that the outcomes will align with our organizational goals and my bonus plans.

 

True Trust

I have a favorite story I use for describing effective delegation. It goes like this—

Delegating is easy when you know how someone will approach the problem you’re delegating. Or when they’ve been asked to do the task many times before? There is no outcome risk.

But what if they would approach the solution differently than you? Or what if they might try a novel, but risky approach? Or, what if you’ve seen them fail at this sort of problem many times before? You ‘get’ the idea…but you still delegate to them. To me, this delegation, regardless of outcome risk, or approach, is true & pure delegation.

It means you trust the individual enough to encourage them to try something new. You’re enabling their creativity and you’ll be there if they ask for your help or advice. But they ‘own’ the task you’ve delegated to them and ultimately the results.

Now THAT’S delegation!

Adapt this definition and re-focus it towards trust. Then accordingly, start trusting your teams more. For example, here are a few transitional trust adjustments you might need to make—

  • Trust that they are estimating work based on the best information they have—and that the estimates are accurate given their context
  • Trust that when they run into trouble, they’ll let you know; otherwise they are making progress and don’t need your ‘help’
  • Trust that transparency and Sprint Demo’s will give you sufficient progress information—both on velocity and quality of their efforts
  • Trust that the team knows best in how to solve product development challenges related to architecture, design, and implementation
  • Trust that your Product Owner is effectively driving customer value—and are making the best decisions balancing business needs against team capacity
  • Trust that your Scrum Master is emphasizing done-ness, quality, and working collaboratively as a team. That if something needs attention, they’ll raise it as an impediment
  • Trust that when the team recommends refactoring a component of your system—that it’s truly broken and needs attention
  • Trust them to trust your own judgment and skills; that they look to you for high level guidance, goal-setting, support, and impediment resolution.

 

Wrapping Up

True trust, like delegation, can be really hard. As leaders, many of us have engineering backgrounds and are natural problem solvers—so our efforts to engage the team with our ‘advice’ emerges from our own backgrounds, skills, and interests.

We’ve also been programmed not to trust our teams. The inherent dynamics of Taylorism and Scientific Management influences our behaviors when it comes to telling our teams what to do and hovering over them until they do it.

But trust is what a truly empowered and self-directed team needs from you. Of course you can inquire measure, establish vision and set goals, measure results, and provide feedback. Surely you’ve earned that right with your experience and role. However, try and give true trust as often as you can. You’ll see a huge difference in your teams’ performance and the results.

I trust that you were listening,

Bob.