Featured in Architecture & Design

On the podcast today, the two discuss what today’s reality is for AI. Grady answers questions like what does an AI mean to the practice of writing software and around how he seems it impact delivering software. In addition, Grady talks about AI surges (and winters) of over the years, the importance of ethics in software, and host of other related questions.

Featured in AI, ML & Data Engineering

Joy Gao talks about how database streaming is essential to WePay's infrastructure and the many functions that database streaming serves. She provides information on how the database streaming infrastructure was created & managed so that others can leverage their work to develop their own database streaming solutions. She goes over challenges faced with streaming peer-to-peer distributed databases.

Handling Your Team's "Rotten Apple"

Over the past few days there has been a very active discussion in the Scrum Development Yahoo Group about what to do when one person on your team is "under-performing". In the 130+ response thread, Rotten apple in Scrum team, discussion ranged from advice for the primary question, to talk of team morale and who manages it, to the classic debate of measuring individuals, to distinguishing whether a team is really a "team", and more.

Marko Majkic initiated the discussion by describing a member of his team who he perceives as being a relative "under-performer" and asking for advice on how to approach (quote derived from the original post and a later response):

Average contribution per developer is 38 usp (user story points). One of the members makes only 19 usp - twice less than the others
...
I don't think that this guy is lazy or malicious. It looks to me like he's mind absent on work and/or has lack of concentration
...
Should I bring this to Scrum review meeting or I should talk with this guy in private? What would you do?

From this statement many topics were launched, one of which being a discussion around Marko's primary question about how to handle the underperforming individual. Many of these responses lead back to a basic suggestion that the most crucial action is to do an fresh, objective evaluation of what is really going on. Paul Hudson summarizes:

As others have said, you may need to step back here. It seems to me based on what you have said that you may have assumed the individual should be blamed for the low productivity, rather than supported in addressing any underlying issues.
...
I think I (and several others) are encouraging you do use other points of view. There’s no magic bullet. You need to find out what issues the person concerned may have and discuss them with him.
...So the [concrete] suggestions have been:
a) Check the problem really is a problem, and is what you have assumed it to be
b) Get more information about the issues the guy may be facing
c) Raise and discuss the problem at the team or individual level

Further advice on how to act on Paul's high-level listed suggestions included things like:

Be careful with the words you choose to describe this individual; namely, "Rotten Apple" is probably a terrible way to refer to this situation, let alone this person! (note that Marko clearly agreed wholeheartedly with this sentiment)

Interestingly, further discussion revealed that Marko's concern wasn't so much about the actual output of the individual per se, but rather a fear that the rest of the team might soon react negatively to the individual, perhaps by bringing this up at a retrospective. As might be expected, many responses were quick to stress that this is a desired outcome, not one to be afraid of. As stated by Ilja Pruess:

I would actually worry much more about what *not* speaking up would do to team atmosphere.
...
So if I felt that there were bad feelings about this "underperformer" in the team, I'd see it as my responsibility as a facilitator to *encourage* team members to speak up, end to help them resolve it gracefully.

Also prompted from Marko's initial statement was a revival of the discussion around measuring individual performance (re: Marko's use of "points per person"), highlighted by Ron Jeffries' reminder that there should really be no such thing as "points completed per individual" if the team is really operating as a "team". Related discussion posed the idea that measuring people's performance (objectively) may not necessarily be wrong, but should be used only as one input of many to your subjective evaluation of an individual (eg. Eric Deslauriers' entry).

Finally, remember, as of this writing there were 130 responses in Scrum Development Yahoo Group discussion, so understand this InfoQ post is merely a light overview of some of the key items. Check out the thread yourself to get the full picture of all that was summarized here, and of course be sure to add your thoughts either there and/or here.

Missing info

Your message is awaiting moderation. Thank you for participating in the discussion.

There's two possible reasons:1 -under performer2 -constant underestimation of the areas this person works on.

Very often, what looks like lower productivity is a function of not understanding the system you are working in. I've run into issues in the past where strange ideas get created from statements people make...example "we average 4 hours to fix a bug" gets understood by some people to me "we shouldn't ever put down more than 4 hours for the time to complete a bug".

Short of it... make sure you understand the person's REAL productivity before you start worrying about what's coming up on reports.

Re: "Individuals and interactions", remember?

Your message is awaiting moderation. Thank you for participating in the discussion.

Agile isn't about turning people into coding machines. We must always be aware that we are talking about human beings....

:)

An excellent point! It is unfortunate that people have started measuring everything in terms of lines of code. What happens when the whole project is scrapped because the "design" had not been captured correctly? The worst part of Agile practice is "Design == Code".