1   Work for Outcome

“The first and most important step in addressing a problem is to determine who caused it. Find that moron! Once you’ve established fault, then you can make sure the problem doesn’t happen again. Ever.”

Sometimes that old devil sounds so plausible. Certainly you want to make finding the culprit your top priority, don’t you? The bold answer is no. Fixing the problem is the top priority.

You may not believe this, but not everyone always has the outcome of the project as their top priority. Not even you. Consider your first, “default” reaction when a problem arises.

You might inadvertently fuel the problem by saying things that will complicate things further, by casting blame, or by making people feel defensive. Instead, take the high road, and ask, “What can I do to solve this or make it better?” In an agile team, the focus is on outcomes. You want to focus on fixing the problem, instead of affixing the blame.

The worst kind of job you can have (other than cleaning up after the elephants at the circus) is to work with a bunch of highly reactive people. They don’t seem interested in solving problems; instead, they take pleasure in talking about each other behind their backs. They spend all their energy pointing fingers and discussing who they can blame. Productivity tends to be pretty low in such teams. If you find yourself on such a team, don’t walk away from it—run. At a minimum, redirect the conversation away from the negative blame game toward something more neutral, like sports or the weather (“So, how about those Yankees?”).

On an agile team, the situation is different. If you go to an agile team member with a complaint, you’ll hear, “OK, what can I do to help you with this?” Instead of brooding over the problem, they’ll direct their efforts toward solving it. Their motive is clear; it’s the outcome that’s important, not the credit, the blame, or the ongoing intellectual superiority contest.

You can start this yourself. When a developer comes to you with a complaint or a problem, ask about the specifics and how you can help. Just that simple act makes it clear that you intend to be part of the solution, not the problem; this takes the wind out of negativism. You’re here to help. People will then start to realize that when they approach you, you’ll genuinely try to help solve problems. They can come to you to get things fixed and go elsewhere if they’re still interested in whining.

If you approach someone for help and get a less than professional response, you can try to salvage the conversation. Explain exactly what you want, and make it clear that your goal is the solution, not the blame/credit contest.

Blame doesn’t fix bugs. Instead of pointing fingers, point to possible solutions. It’s the positive outcome that counts.

What It Feels Like

It feels safe to admit that you don’t have the answer. A big mistake feels like a learning opportunity, not a witch hunt. It feels like the team is working together, not blaming each other.

Keeping Your Balance

• “It’s not my fault” is rarely true. “It’s all your fault” is usually equally incorrect.

• If you aren’t making any mistakes, you’re probably not trying hard enough.

• It’s not helpful to have QA argue with developers whether a problem is a defect or an enhancement. It’s often quicker to fix it than to argue about it.

• If one team member misunderstood a requirement, an API call, or the decisions reached in the last meeting, then it’s very likely other team members may have misunderstood as well. Make sure the whole team is up to speed on the issue.

• If a team member is repeatedly harming the team by their actions, then they are not acting in a professional manner. They aren’t helping move the team toward a solution. In that case, they need to be removed from this team.^[2]

• If the majority of the team (and especially the lead developers) don’t act in a professional manner and aren’t interested in moving in that direction, then you should remove yourself from the team and seek success elsewhere (which is a far better idea than being dragged into a “Death March” project Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects [You99]).