Agile Teams - The Weakest Link

I was talking to a fellow coach the other day and she was venting a bit about one of her teams and their Product Owner.

Bob, she said, I have an outstanding agile team. We’ve been working within our product organization for nearly two years. In that time, we’ve delivered an application upgrade that everyone has viewed as simply fantastic. Now we’re onto a building a critical piece of new system functionality for them—so we’ve earned everyone’s confidence in our abilities.

We work hard, we work well together, we deliver high-quality working code, and we have fun doing it.

Ok, I asked. That sounds like a fantastic situation. To be honest, I’m a bit jealous.

We’ve gotten into the habit of being able to work around him and still deliver sufficient customer value at each sprint review…but it’s incredibly challenging. The team has to “bend over backwards” to help develop a view to our backlog.

And he constantly changes his mind, which is the cherry on top – increasing our rework and driving the entire team crazy.

Wow. I guess everything isn’t so great. Then I asked, have you made him aware of the behavior and your (and the teams’) concerns?

Of course, she said. This comes up in virtually every retrospective. He listens, agrees, and then promises to improve. There might be a slight change for a sprint or two, but he always falls back into the same old patterns.

I’ve even tried to escalate it (carefully) to his supervisor. And even she agrees that it’s a problem, but again, nothing seems to change.

I’m at a loss. What do you think I should do?

Taking a step back

On the surface, this is sort of an intractable situation. It reminds me that every team, agile teams included, is only as good as their “weakest link”. Sure, teams can collaborate and work around internal challenges such as this. And in some cases that’s the right thing to do. But when the behavior is affecting the entire team's morale and performance, and when there is no consistent improvement; then I say something needs to be done.

What do you think? And what are the options here?

It seems clear to me that the Product Owner's manager is dropping the ball. There is a performance issue and (apparently) they’re ignoring it. One obvious and immediate action would be for his manager to begin taking it seriously and start actively coaching the PO, with a possible performance improvement plan as an outcome.

Could the team “vote the Product Owner” off the island (team)? I’ve seen this happen in extreme cases with team members. It’s a very messy situation and somewhat of a last resort. However, if the team really is being negatively affected, then it might be the most congruent thing to do.

Under the banner of “good team play”, should they just persevere along and keep dealing with it? That’s what this team has been doing. Sure, they’re talking about it. But it’s been happening for nearly TWO YEARS. What makes anyone think it will improve without a major intervention?

Overreact or Underreact

I normally see two reactions to similar situations in my agile coaching travels. Either the team grows impatient too quickly and overreacts to remove someone from the team, many times without having a conversation with the person. It’s just easier for them to complain behind their back and then look to eject them.

Or

Like the team in this example, tolerate the underperforming behavior in perpetuity, working around it within the team. Sure, they bring it up occasionally, but the team essentially accepts it.

Is there somewhere in “the middle”?

I sure hope so!

You might be asking yourself, what counsel did I provide to my coaching colleague? Well, I’ll share it with you. But I’m still thinking about the situation and whether my advice was sound.

I told her that the team was “working around” an issue and that they weren’t transparent enough with the effects of the under performance. You see, they were working overtime to cover for the Product Owner and from a results perspective; the team was perceived to be high performing.

I basically said to stop doing that.

My advice was to allow the Product Owner to fail more often and to make those failures more transparent.

For example, the Product Owner was essentially bringing empty stories to the team for execution. The team would then meet with stakeholders and analysts across the organization to fill in the blanks. This would take tremendous time that wasn’t theirs to offer. In the end, they got very good at writing stories FOR the Product Owner.

I told her to stop that, to put in place Readiness Criteria for stories that would enter the teams’ sprints and to not accept “under-cooked” stories. If the Product Backlog became empty as a result of this, then so be it. Raise that as an impediment and wait until the Product Owner did their job and worked with the team to deliver a proper backlog.

I was careful not imply that the team sabotage or not help the Product Owner as a healthy team would. But I was firm in that they needed to stop doing the PO’s job for them AND allow the dysfunction, under performance and honest results to become transparent to all.

I suggested that IF they did this well, then the organization would reach out to the entire team to discover “what was wrong” and to help them “fix it”.

Wrapping Up

Now at this point, we broke the conversation off and went on our way. But I could tell that my colleague was very uncomfortable with my advice. To be honest, so was I.

But I keep thinking that it was a congruent suggestion for handling a “weak link” that is affecting team health AND not improving. That if teams have the option of helping / masking the problem vs. making it transparent, they might want to reflect whether their masking it IS part of the problem.

That’s what I intended here, but I do agree that it’s a fine line to walk. My biggest fear is that teams read this and start throwing struggling team members under the bus. That’s certainly not my intention.

I wonder what you think of my story and my advice? And if you’ve had a similar situation, what have you done?

Robert 'Bob' Galen is the President and Principal Consultant of RGCG, L.L.C. a Cary, NC based agile methods coaching & training consultancy. He is a deeply experienced agile coach who is active in the agile community and regularly writes & teaches on all topics related to the agile methods. Bob wrote the book Scrum Product Ownership, which is focused on that role and driving value in team delivery. Bob can be reached at bob@rgalen.com and networked with via his LinkedIn profile.