In my organization Scrum teams almost never finish all of their stories 100%. I suggested that we commit to fewer stories each Sprint, but the R&D manager says if we do that people will still not complete the work, but will just do less of it thus slowing down development. He says there is a Student Syndrome at work here.
What is your take on that?
Your manager needs to understand that Student Syndrome / Parkinson's Law becomes a significantly larger problem when there is zero hope of hitting targets. Suddenly the time available for a task's completion is infinite. As an old colleague of mine used to put it, "Deadlines are just things that pass by here. We miss them, they get moved back, we miss them again."
And that was entirely a result of unreasonable deadlines in the first place. These people weren't naturally lazy, they just saw no hope of hitting a target and no consequence of not hitting it, so why worry about it?
My point being that your manager might well be right. But he needs to understand that he's creating the problem.
When a team does sprint planning well, they start working as a team to hit their deadlines. Any one person doesn't pull their weight, they fail as a team. If that happens continually, the team deals with that person.
There is a possibility that you will cut the velocity too much and achieve less than you might have. But you will have succeeded. Feelings in the team will be positive. Someone is likely to say "Honestly, I think we can achieve a couple more points next sprint."
Eventually, you'll find your balance point and start predicting correctly the amount of work you can actually achieve in an iteration.
Who cares? Shouldn't the produce owner be asking where's the rest of my features?
You may need to limit the length of your sprints. This way more progress has to be shown along with way. Use the feedback on what is getting done to determine how much can be accomplished in subsequent sprints.
You can't have a fixed timeframe for a project and a fixed list of stores/features without allocating enough resources. If there is a fixed due date, you may not get all the stories finished. You want to cut out some stories? Which ones? Can you really determine that at the beginning? Hopefully, if you prioritize right, the product owner gets what's most important. It's their priority after-all.
The manager is playing mind games. If you're a kid who wants a dog, ask for a pony.
In my organization Scrum teams almost never finish all of their stories 100%. I suggested that we commit to fewer stories each Sprint, but the R&D manager says if we do that people will still not complete the work, but will just do less of it thus slowing down development. He says there is a Student Syndrome at work here.
From my limited experience with [what poses for] Agile, I'm not surprised. Everything I've read about Agile suggests that everybody needs far more organised than in other development technique but, like you, I'm seeing little, if any, evidence of it.
Estimating Story Points is not an exact science, especially in "cutting-edge" areas like R&D. It could easily be that your Developers are mis-estimating their Story Points (IME, usually over-estimating their own abilities) or it might be that there's some "target" number of Points that they're supposed to produce in each Sprint (IMHO, an utterly flawed way to manage, which brings me to ...).
Your manager needs to be investigating this and finding out what's not working. It's their responsibility to get stuff delivered to the clients (or it ought to be), and so their "neck on the block" when the users start complaining.
[cynicism]Of course it won't be, because they have all the necessary training/ skills to make sure none of the blame sticks to them. [/cynicism]
And insulting their workers, branding them with any kind of "syndrome", is never acceptable behaviour - it just shows management's lack of commitment to the Team and their desire to "distance" themselves from it.
Development is being slowed down either way, but doing the job slowly and more conscientiously (i.e. actually making stuff work) is far, far better than simply not delivering anything at all.
