"I'd rather have a hole in my team, than an @$$hole in my team"

Tuesday, 2 November, 2010

Its a great quote and I love it. I heard it second hand, but I believe Dan Jacobs (Apple) I have to credit for it. Scrum puts teams under pressure to build production ready software in every sprint. Fact.

During my travels as a coach I have seen this effect different individuals in different ways. Firstly, let's not assume that every scrum team member I meet is a stereotypical software geek with long greasy hair tied in a pony tail, wearing a faded Skid Row t-shirt who thinks in binary. I meet a wide range of team members who are about to be thrust into the 'do-or-die' scrum adoption that his or her boss has been threatening for months.

The large proportion of these people (about 80%) have the intellect, capacity and patience to try something new called Scrum. Most of them will like it. Some will love it. Most of them will need some help and guidance. Some will do it instinctively.

But there is a small percentage of people I have coached who actively oppose Scrum. Their personality or behaviour has a negative effect on both the Scrum team and success of the Scrum adoption. John Kotter was quite clear on these types of "no-no's" by saying that there is no place for them in the transformation. I have to agree. I can look back now myself and think about people I should have moved out of team pretty quick.

These people have a damaging effect on the remainder of the team. I have seen one particular Scrum's team velocity increase when the "problem child" was on holiday for the majority of the sprint. The communication and collaboration of the team improved when that person was not in the office.

I have also seen another example of a team member cheerfully smiling at the end of a sprint review which the team failed miserably. When the ScrumMaster queried his cheerful expression the reply was "I'm glad I wasn't involved in anything these guys were doing!". This lack of accountability divides teams and needs addressing as a priority.

In coaching a team to play planning poker, I have seen one individual bring the meeting to it's knees by refusing to move on until an estimate was lowered. When you can hear the rest of the team noticeably sighing when an individual talks or responds, those are the warning signs ScrumMasters need to look for.

But how do you tackle these people? What does Scrum we should do? It doesn't. The ScrumMaster needs to improve the productivity of the team in any way possible. Well, you could fire them. Some companies will (and have) taken that stance. Scrum is what we are doing now, if you don't like it - fine, move on and we'll find someone else that does.

If that is too radical you may have to look at different ways. Certainly it needs direct feedback from the ScrumMaster. Some people I have worked with responded to that as they were unconsciously destructive. A quiet word was enough to remedy the problem with minimal impact.

For the more consciously destructive, try 360 feedback. Peer feedback (in multiple doses) can be more disheartening for employees than ScrumMaster feedback. If that fails, expose the problem in a retrospective. Hearing the feedback is more brutal than reading it.

But what happens when the @$$hole is the team's hero? Imagine the situation where everyone hates this guy, but he writes twice as much code as everyone else. I would argue that the team's productivity will decrease or stagnate the longer this person remains in the team. Other team members will consciously take on less out of spite. Removing this team member may seem like suicide to the Product Owner, but the team will benefit in the longer term by stepping up more and getting more done as a united Scrum team.