Skip to main content

Confronting the problem with the entire dev team? Even individual's problems?

Last post 08:34 pm February 4, 2019 by Juliano Kessler
6 replies
07:38 pm January 18, 2019

I remember having read in "The Art of Doing Twice The Work in Half The Time" by Jeff and JJ Sutherland that you are supposed to discuss sprint performance problems with the entire dev team, instead of discussing the problem with one developer alone.

However how about this situation:

There was a team and one dev was underperforming.

Some developers reported, in private, that the likely causes had to do with commitment, discipline and maturity issues. The other developers were irritated with the underperforming individual.

The underperforming individual had threatened to resign a few days earlier and was frequently late for work. He had a challenging and aggressive way to relate to his immediate leadership. 

Knowing this, would you still address the issue with the team (naturally, not disclosing the suspected causes heard from his teammates) or would you address it with the individual, directly?

 

Think about what is your answer, and then keep reading.

In that direct situation, a private conversation was held with the individual. The issue was that he received growth promises from his last superior, and they were not fulfilled. The promises were inflated and would never have been fulfilled, which means, he was tricked by his previous superior. He was given a choice: start over, with more realistic career growth expectations, or walk away. He chose to walk away, he could not accept and adapt to this new, far less exciting career growth opportunities. 

Having now known what had happened in the end, do you change or stick to the answer you just gave above?


11:55 am January 23, 2019

There was a team and one dev was underperforming.

Some developers reported, in private, that the likely causes had to do with commitment, discipline and maturity issues. The other developers were irritated with the underperforming individual.

To whom did those developers report this? Did they talk to the "underperforming" developer first? These are questions I would have liked to have cleared up first before deciding on how to proceed.

 


05:56 pm January 23, 2019

In addition to @Julian's questions it would be useful to know if the previous superior is still employed at the company.  Also, is the current superior part of the Scrum Team or are those roles maintained outside of the Scrum Team?

If you could give us a little more insight like @Julian and I suggest, I do believe you will get much better responses.  We could all give you "Scrum by the book" type answers but if you want some meaningful real life advice, more info would be nice.


04:19 pm January 31, 2019

OK. Here goes more information.

Today I understand that scrum was poorly implemented in that organization. One thing that exemplifies this is that individuals were accounted for their individual sprint performance, as opposed to the entire dev team being accounted for the entire sprint performance. It was more like a traditional organization with the colors of the scrum events.

There was the dev team, the scrum master, and the manager of the dev team, that was purely a manager.

Today I also understand the scrum master was not a servant leader. He was very much a traditional carrot-or-stick leader. An aggressive person that was, in a way, feared.  Someone that pushed for results.

And what I saw back in that day was: 

The developers and the scrum master reported the issue with the underperforming individual to the manager of the team. 

I don't think the devs confronted themselves the underperforming dev.

The preceding manager of that individual was no longer in the organization when this event happened.

Being it seen as a behavior/committment issue, it was escalated to management, as is done in traditional organizations.

So, a lot more of information is given. Suppose you were the scrum master (a decent one), or the manager who received the escalation, what would you do? It may be easier to find out a response now, after all this background was explained, and all of us study scrum. But also try to think in that particular scenario, when it started and little was known. One dev is lagging behind, and it looks like a committment issue, rather than a technical issue. How do you address? How long to the values of openness and courage apply here? 


11:01 pm January 31, 2019

This is my opinion and only my opinion. 

Many companies still have hierarchical structures and can be successful with Scrum.  Given the information you provided, it actually sounds like the company handled it in the way it knows....brute force and intimidation.  Since that sounds like an established practice, I really can't say it was wrong. I may not agree with it but for your company it sounds correct. As you said, they are not doing Scrum. They may be using a few of the prescribed practices but in no way is that Scrum. 

Now since you asked how this kind of thing could be handled in Scrum fashion if I was the experience Scrum Master involved, I'll give you my opinion on that also.  In a Scrum team that truly appreciates the Scrum values this would have been handled openly.  The Scrum values of commitment, courage, focus, openness and respect would allow the developers to discuss the behavior with the" under performing" development team member in a non-confrontational way.  As Scrum Master I would facilitate the team to have the discussions, prevent them from becoming heated and preserve the peace of the group. The open and honest discussion would most likely have lead to a better understanding across the team of what was demotivating the individual.  As a team they could work together to help that individual become more engaged. The team could support the individual in his frustration and encourage him to be open and honest with current management on what had happened, how the individual felt and ask how management and the individual could work together to rectify the situation. Having the support of others can often be the key to turning demotivated individuals around.  If they feel that everyone is against them, including their peers, it just makes matters worse.  But if they feel that others understand and can support their efforts to rectify the issues, they are much more likely to come back to their motivated, contributing self. 


08:44 am February 1, 2019

1. Don't wait for anything, make completely transparent (as a team task):

(from your scenario) performance, communication, commitment, discipline, maturity, threads, aggression, leadership, management, your questions, scrum.

(and make sure to address) the scrum values and last but not least trust

2. A good clash, specially if it's performance related, is also an opportunity for a group of people to become a real team.

3. Be a scrum ambassador in the wider organisation

 


08:34 pm February 4, 2019

I think I'm with you Daniel. The dev team members should have had a team discusstion about it. And if they failed, they should have requested the help of the scrum master. And still, it should have been a group discussion. Even if in the end it turns out to be an individual problem, the group having discussed it together helps them practice the values of scrum. 

Thanks.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.