Project Management Blogs

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.

Thanks for listening,

Bob.

Don't forget to leave your comments below.

What is one of the root causes of project failure?

Last month we explored how much project management was enough.  It is generally accepted that just the right amount is needed based on the situation.  It is usually when the project is over or under managed that we have failures.  Common project management causes of failure are:

• “Wishful” Planning – Planning that is based on the desire to have something done by a deadline and within a budget limit without regard to the reality of the situation.
• Lack of portfolio management – initiating projects without regard to whether they are justified based on sound business reasons
• Poor project control communication – Hiding the reality of project trouble until it is too late to do anything but bemoan a horrible outcome
• Lack of accountability – Allowing project stakeholders to fail to deliver what is expected of them without accountability.
• Absentee sponsors – Sponsors failing to perform their functions to provide direction and leverage.

Each of these causes is worthy of an article if not a book.  But, in this article, let’s look for a common root cause. 

In a recent webinar, Joseph Grenny hypothesized that the root cause underlying these and other problems in projects is failure to effectively hold crucial conversations.  It is the Abilene Paradox in action, where silence or avoiding difficult confrontations robs the project team and its organization of the ability to either avoid the causes of failures or to catch the causes early in their life to turn the project around or end it when that is appropriate.

What is the Abilene Paradox, you might be wondering?  It is the phenomena where a group of people collectively decide to do something that is counter to the preferences of everyone in the group and counter to the benefits of the organization or group as a whole.  It involves a breakdown in communications.  Each member of the group avoids saying what they think because they think it would be counter to what the group or its leadership prefers.  As a result valuable information is withheld and the group is not able to make effective decisions.

For example, an individual feels that a project plan is overly aggressive but fails to speak up because he or she is afraid that saying anything about it would have negative consequences.  As a result the “wishful” plan becomes the baseline plan and sets expectations for the project.  This leads to the inevitable overruns and the rushing, corner cutting and such that, in turn, causes poor quality product to be delivered late and over budget.

If, fact, this failure to speak up and hold the crucial conversation in a respectful and candid way is a root cause of these causes of project failure, what can we do about it?

If we are in a position of influence we can create a safe environment in which people do not feel threatened for saying what they think, even if it is not what everyone wants to hear.   If we are a less influential (everyone has some influence, usually more than they think they have) player, we can muster up the courage to “tell it as we see it” and learn the skills of how to confront directly and firmly with appropriate diplomacy.

Don't forget to leave your comments below.

We as Project Managers are often faced with difficult situations and have to resolve any and all conflicts that arise with our stakeholders.  We are very adept at our hard skills but often our soft skills go lacking.  One of the skills most often called upon, but in most cases the one we are the least comfortable with, is conflict resolution.  Most of us are conflict averse and unsure how to manage or resolve conflict.  We know that according to the PMBOK the preferred method of conflict resolution is “confrontation.”

Perfection of means and confusion of goals seem -- in my opinion -- to characterize our age.

Albert Einstein

This blog entry is Part 3 of a 5-part series laying out the elements of an Agile framework. It presents 4 techniques generally included in Agile methodologies, and discusses which of the 8 principles presented in Part 2 are usually implemented through them. I will try to explain why some of those techniques do not work sometimes, as well as why it is paramount to apply all of the 8 principles of Agile for Agile techniques to really succeed.

Lessons learned must be one of the biggest time wasters in the discipline of project management. Most organizations do them to some extent. Most of the time nobody looks at them after the project is done. But still we keep trying to persuade people to do them. What do we expect? That they will learn from history? A wise man said (Churchill? Not sure), “The only thing we ever learned from history is that we never learn from history”.