Bias

The other night I found a credit card receipt from The Pampered Chef. This is one of those Tupperware party kind of things that women go to and overpay for stuff because they feel guilty for insulting the party giver if they don't buy something. I told Laura before she went to that party to not buy anything. I had just started my own business and had made it clear in a Family Meeting that we're going to restrict our spending until I see what kind of cash flow we're going to have. We were to buy nothing unless we could eat it.

So, as Laura was heading off to this Pampered Chef party the other day and I told her not to buy anything, she told me she was getting a free meal out of it so I should relax. I can't remember if she explicitly agreed to not buy anything but I know she heard and understood my request to not-buy-anything.

What was she thinking? I stewed over this all night. Laura was already asleep when I found the receipt. I didn't think I should wake her up to discuss this. I knew that wouldn't go over well. So I stayed up thinking about how I'd approach this in the morning.

I avoided my wife for a while the next morning. When I could avoid her no longer I told her I thought we agreed that she wasn't going to buy anything at that party. Laura calmly told me she bought me a birthday present. A $22.26 birthday present. She bought something inexpensive which is exactly what I would have wanted her to do. And I bet it's an incredibly thoughtful gift.

Man did I feel like a heel.

I've been reading lately about biases. In The Principles of Product Development Flow, Donald G. Reinertsen says that psychologists know that "…[humans] have a general bias to interpret the behavior of other people negatively."

There is a nice list of cognitive biases on wikipedia. Some that are particularly relevant to this topic are:

• Actor–observer bias – the tendency for explanations of other individuals' behaviors to overemphasize the influence of their personality and underemphasize the influence of their situation (see also Fundamental attribution error), and for explanations of one's own behaviors to do the opposite (that is, to overemphasize the influence of our situation and underemphasize the influence of our own personality).
• Fundamental attribution error – the tendency for people to over-emphasize personality-based explanations for behaviors observed in others while under-emphasizing the role and power of situational influences on the same behavior (see also actor-observer bias, group attribution error, positivity effect, and negativity effect).

These are amplified by an additional set of biases:

• Bias blind spot – the tendency to see oneself as less biased than other people.
• Negativity bias – the tendency to pay more attention and give more weight to negative than positive experiences or other kinds of information.
• Availability cascade – a self-reinforcing process in which a collective belief gains more and more plausibility through its increasing repetition in public discourse (or "repeat something long enough and it will become true").
• Halo effect – the tendency for a person's positive or negative traits to "spill over" from one area of their personality to another in others' perceptions of them (see also physical attractiveness stereotype).
• Illusion of asymmetric insight – people perceive their knowledge of their peers to surpass their peers' knowledge of them.
• Illusion of transparency – people overestimate others' ability to know them, and they also overestimate their ability to know others.
• Illusory superiority – overestimating one's desirable qualities, and underestimating undesirable qualities, relative to other people. (Also known as "Lake Wobegon effect," "better-than-average effect," or "superiority bias").
• Ingroup bias – the tendency for people to give preferential treatment to others they perceive to be members of their own groups.
• Projection bias – the tendency to unconsciously assume that others (or one's future selves) share one's current emotional states, thoughts and values.

But why would I assume the worst of my spouse? That's ridiculous. Of all the people in the world, I should not have these biases towards her. If this can happen within my family, how much more so can it happen in the workplace?

What I learned from this experience is how real these biases are and how on-guard we as humans need to be. Poor communication skills (or just a simple mismatch in communication styles), fear of reprisal and fear of confrontation can make matters worse. The problem with poor communication is we always assume it's the other person who can't communicate.

Kerth's Retrospective Prime Directive hints at a solution:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

How do you encourage that other than posting it and reviewing it before retrospectives?

And in Coaching Agile Teams, Lyssa Adkins says to "...create a positive regard for them. Do this by changing your view of them. Regard the person as a human being with hopes, dreams and desires (like your own) so that you can approach them with love and compassion..."

How do you foster this in an organization?

Reinersten offers this advice:

This tendency [toward bias] is reduced when we get to know others as complex hum beings, much like ourselves. Task related (job related) communications by itself is not enough to create an appreciation of this complexity. Non-task-related interpersonal communication that comes from colocation is key to developing cohesive teams.

Chats around the water cooler, going out to lunch together, after-work drinks, post iteration and post release celebrations and kick offs beforehand are good things to try. Fantasy football and office baby birth date/weight pools and the like can help. Team working agreements (norms) posted on a big visible chart can help. Praying daily for your co-workers by name helps remarkably well. Other ideas?

We can bring up the elephant in the room in our retrospectives, but other than just hashing it out, what techniques or exercises have you found useful?

Most of us don't enjoy a tense and confrontational workplace. Likewise, most of us don't recognize how much we ourselves contribute to that situation.

What additional advice do you have to combat bias, increase non-task-related interpersonal communication and improve interpersonal relationships?

Sizing with Incomplete Information

Some teams that I work with that are new to agile struggle to size their first big agile release. The team is often still trying to gel, assimilate new members, and increase their velocity while spending lots of time creating, understanding and refining the product backlog. One of the challenges they face is learning to estimate with imperfect and incomplete information. How quickly they adapt seems to depend on what they are presented with during their 1st agile/relative estimating session.

Some teams new to agile start with a new project and need to estimate the whole thing with little info, perhaps during a "sprint 0". Those teams are forced to deal with ambiguity right from the start. From then on they accept that they'll have to estimate fuzzy stories. This helps them accept that stories will change, both the details of individual stories as well as what stories make up the backlog. Sometimes revealed detail changes an estimate (up or down). Sometimes it doesn't. But that's life and we can deal with that quite well on an agile project. More on that in a moment.

Other teams I work with already have a project well underway. They have a product in maintenance when they go agile. They've got lots of small and well understood stories. Or if they aren't well understood, they can get that way quickly. The 1st stories they estimate are detailed and certain. But a day will come when the team is forced to estimate some new release or some new product with less than full information. That can be frightening. As these estimates are recorded, we can note that the estimates were made with less info and certainty, but that seldom provides much comfort to this type of team.

However, what you'll find (on a healthy team) is that:

• Large estimates on the larger stories tend to drive the Product Owner to decompose those behemoths and then ask for new estimates.
• The team is allowed and even encouraged to revise the estimates (up or down) as more information is revealed.
• Many of the estimates will not need to be revised. Any additional detail or certainty often doesn't affect the estimate after all.
• Consistency is good, but accuracy and precision are not necessary. Wrong estimates have an offsetting impact on velocity. That's the beauty of using relative estimates and the empirically measured velocity to compute a release end-date -- an incorrect increase in one gives an offsetting decrease in the other.
• There will be details that are overlooked. Developers tend to be optimistic with estimates. But that too will soon be taken into account in the velocity (unless you implement all the well understood stories 1st and always save the others for later). (Do note, however, that the shorter your release is the shorter your iterations need to be in order for a change in velocity to be noticed in time.)
• And management will heed the warning signs when presented with the estimates and velocity and not pressure the team into short-cutting craftsmanship, quality or sustainable pace. (Remember that I said /healthy/ team.)

Seeing is believing

On the second type of team this learning happens slowly. You can have a conversation around these things to try to speed up the learning or to provide some comfort. It's certainly worth trying. But don't be surprised if your convincing arguments are met with disbelief.