Questions and Conflict

#1

I have a team and organization that I learned is very conflict adverse to the point that asking questions or having a dialog is considered as adversarial or judgement. Does anyone have any tips, coach experience, training material group dynamics and even conflict coaching classes that I can take to improve questions and to get the team to realize that it is ok to question. I think the team is also thinking the retrospectives are judging verse a chance for the team to find some way to improve. Sometimes it is difficult for teams to be self examining. Some of the personalities take offense to questions on pointing stories and such. The good thing is that is not just with me but others. However I could use some new coaching techniques and ideas to help the people. One very interesting personality is the PO who thinks he or she is being told that they are wrong because the team changes a point estimate or if we go around the room to do the point estimation. It is like why are you pointing when I already did it.

One other area is that there are too many 1 pointer when the stories should really be a bit larger as the numbers and dev work clearly show the stories are more like a couple of points. Anyone have anything have a techniques for adjusting the current habits by the team?

Lastly, bugs which is a term that I now know is offensive to my developers. Which caused all kinds of conflicts. Anyone have anything on the dreaded bug conversation?

Thanks,

Greg

#2

Trust. I believe that’s your problem here, and before you can work toward a high performing team, trust must be established. Here’s a few suggestions:

  • Pick up the book Five Dysfunctions and give it a read through. I believe that link also has some exercises you can review.
  • More than once in your post, you mention story points so I’m curious why your focus is there. I’d suggest stepping back and evaluating why your teams estimate and who the estimates are for. Are they for your teams? Or for someone outside your teams and why? This article might help you think through that conversation.
  • Why would a conversation about bugs be dreaded? Making mistakes is part of being human. We humans all know and accept this so are mistakes punished in your environment? Without mistakes, we miss out on important learnings. The fact that you dread a conversation about bugs is a symptom of some deeper cause. Find that cause and address it.
#3

I’ll check out the book.

  • As for the story points they are only used by the team to judge how much work to take into the Sprint. Nothing more. Part of it is the classic PO vs team battle of wanting more work into the Sprint.
  • Bugs yeah I think there is a deeper concern of being graded on the the number of bugs someone creates. Not sure where that comes from other than previous experiences.
#4

Tanner is spot on with his responses…trust!
I would add on to the story point conversation to make sure you stress comparing previously sized stories to the new ones. “You are sizing this a 1, but the last time you sized a 1 it was this story. Is this story the same complexity?”

There is a lot of “debate” among coaches if the PO should size or not. My 2 cents would be that if the PO has practical hands on experience (within the past year) with the team product he/she can help the team size (notice I said help). Estimations in an agile team are supposed to be purely for the team to build a consistent flow in order to make a commitment of work they can accomplish. If anything is being estimated that is smaller than a sprint (story, task) that isn’t a team member, it’s micromanagement and removes trust.

The team needs to clearly define the definition of a bug and own it if it happens to meet that criteria. Ambiguity around is it a missed requirement, working as designed, or code fault is never a good start. One way to approach this is to have the team come up with their working definition of bugs.
1- Any issuesfound within the sprint that are from the sprint backlog are fixed immediately and are not classified as a "bug"
2- Bugs should have an expected and actual outcome with steps to reproduce
3- etc. etc.

At the end of the day, bugs are bugs. Sometimes the team created them, and sometimes they inhereted them. Bugs should be seen as more of a way to show opportunity and technical excellence changes rather than a method to punish a team. I would also challenge the team to not only fix bugs, but make it part of the acceptance criteria to show how it can be prevented in the future with an automated test or manual regression step.

#5

Agree with everything that’s been said so far.[quote=“Gemphilly, post:1, topic:784”]
I think the team is also thinking the retrospectives are judging verse a chance for the team to find some way to improve
[/quote] Seems like maybe there’s also an opportunity to remind the team about the core values and principles of the Agile mindset and revisit why we do the things we do in Scrum - e.g. the purpose of a retrospective is to help us on our path of continuous improvement (Agile Principle #12), to help us continue to get better with our technical approach (Agile Principle #9), to make sure we’re working at a sustainable pace (Agile Principle #8), etc. -> you can’t improve what you don’t see/acknowledge. It’s also an opportunity for us to celebrate what went well, which is important too, because if we don’t know why the things that are working are going well, we’ll struggle to recreate that success later if/when those things stop working.

If trust is a challenge, and it sounds like it might be, in addition to the advice above, perhaps you could also try a game like circles and soup to facilitate a discussion about what steps the team can take to address their challenges with a focus on what’s in our control and what’s outside our control. Also, in the past, I’ve seen trust get eroded when the team and the organization adopt a stance of “us versus them,” and the longer that mindset hangs around, the more contentious things get. If you think that may be the case and can help bring that information to light so it can be addressed, that should help make these difficult conversations more productive.