Hacker News Reader

Comment by snorkel | Hacker News Reader

Unfortunately I was one of those bosses. I was not trained in the art of managing a team with asymmetric talents, so this paper read exactly how my team and I were acting. Eventually I figured out that each person on the team can shine if they're given independent projects that they themselves had spec'd out rather than having everyone tugging on the same rope and fighting over who is pulling the most. This is one of the unfortunate fallacies of the scrum teams that everyone is equally capable to take any story and the point size will be the for everyone, that just sets up the false expectation of everyone can do every story just as fast. I essentially dropped the everyone is a talented clone aspect of scrum and just let some people drive hard on their own project, and they delivered good stuff.

The manager also has to stop and applaud each accomplishment, make sure everyone's effort is recognized, it's easy to forget that in a busy environment.

View on HN

You're absolutely right about the fungible teams / Scrum fallacy, and it's one of reasons I always ask the person who's doing the story to re-point it if they feel the point allocation was wrong. This also corrects for the peer-pressure people feel in planning to give stories fewer points [1].

This way at the end of the sprint you get a better idea for how much work was really done. There's an opportunity for abuse - if someone wants to slack off, they can make a 2 point story into an 8 pointer, but that's going to get noticed by everyone, and it hasn't been an issue in practice.

[1] "That's not 4 points, it's definitely 2, it's really not that much work ...", etc.

EDIT: Fixed typo

"Scrum" is often an attempt to take micromanagement, or the low-status programmer culture, and institutionalize it in a way that seems impersonal and policy-based. Hence, the haggling over story points (a low-status behavior, because it refuses to recognize the meaninglessness of the involved currency and the way the team has been pitted against itself). But high-status programmers just ignore that sort of process and work the way they want to.

If it's a choice between democratised micromanagement, and highly political feudal lords and their serfs, which would you pick?

OK, having the right people manage might be better. Can you point me to an institution that's managed to consistently pull that one off?

> Can you point me to an institution that's managed to consistently pull that one off?

Sure, hoards of shops founded and run by developers with PM's who have actually done the grunt (coding) work in the past.

I've noticed that this problem usually pops up when the PMP certified suits end up managing technical staff.

Can you define high and low status programmers / programmer culture? Because the most competent and productive engineer in my office is also the biggest sticker for the planning / pointing process.

Ultimately I think Scrum needs to be for the team, and the process should be defined by the team. If pointing stories isn't working then the team can stop doing it (we pay it lip service, but that's about it). But you do need some way to agree on what's to be done and who's going to do it.

The planning/pointing process can only benefit people with high status. Rules don't really impact high status employees.

If somebody with high status doesn't meet expectations we tend to think the problem is with the expectations; if they are low status we tend to think the problem is with the person.

In the same way the high status employee has a lot more say over the way story points are allocated and how the work is allocated.

I've been low-status before despite being just as good as everyone else in the team and I've also been high-status despite being one of the worst in the team.

When you are low status people focus on your mistakes. When you are high status people look at your successes and overall contribution.

Recognizing people's successes and what they are doing well is a 1000% more effective than harping on what people have messed up. It's very easy find yourself in or create a toxic culture that is overly focuses on the negative, but it instantly kills motivation.

People who feel like they are doing great work and motivated to do great work.

>Recognizing people's successes and what they are doing well is a 1000% more effective than harping on what people have messed up

Yes, this is (verifiably) true. One must be aware, however, that positive feedback is usually going to be ineffective, thanks to natural "regression to the mean" effects, elucidated wonderfully in this Veritasium video[1].

(The point, in the end though, is that performance is going to statistically improve if people do worse than average, and do worse if they do really well, regardless of the feedback you give them", which is called "regression to the mean". The net effect is that you might get a false positive for negative feedback, and a false negative for positive feedback if you don't account for the natural tension that brings everything back to average.)

[1] https://www.youtube.com/watch?v=1tSqSMOyNFE

It is extremely important to celebrate successes (of the team and individuals), but a good manager needs to know when and how to correct behavior as well.

One of the best ways I've ever seen is simply asking the right questions (What did they think of the <recent event>? How could it have been handled better? How could it have been prevented?) People get very defensive and find excuses if you tell them they fucked up, but if they can admit it themselves they tend to correct their own behavior.

"each person on the team can shine if they're given independent projects that they themselves had spec'd out"

Be careful about that. It can fail disastrously if they end up flailing around without making progress; you need to keep an eye on (a) what they're trying to do, and (b) what kind of progress they're making.

I'm working with a group fond of independent projects and the failure mode seems fairly popular.

Reply on news.ycombinator.com