3 ms·

> 7. Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less mana

> 7. Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more. > 8. Scrum is typically implemented with HORRIBLE task management tools (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste huge amounts of developer time. Additionally, they effectively lock you into one mode of operation, no matter how ineffective. Scrum is not just management heavy. It's micromanagement heavy. If someone asked me for an account of what I did for a whole six (assumed to be productive) hours yesterday and how many story points have been burned, and wanted this every single day, I can only imagine that the person has no experience with software development whatsoever. There are productive days when a lot of stuff gets done and there are unproductive days when almost nothing gets done because it's hard to focus or because of distractions. But the daily standup meeting that's enforced would make any unproductive days as something to get publicly shamed about. On the tools, yes, whatever I've seen in Scrum dictates a lot of time spent updating the tools with estimated hours, hours spent, remaining hours, everyday. That data is rarely useful for any further estimations or to figure out what's going on. Lastly, the "story points not related to effort but related to effort" conundrum confuses developers (especially the ones who are considered to follow instructions and code whatever the user story's tasks say). Add to this a really weird concept called velocity, which is not just a measure of how many story points are completed in a sprint, but is used as a range — too low and you're not working hard enough; too high and your estimates are wrong. The only way to satisfy the Scrum master in many cases is to lie and make the velocity conform to expectations. I have no idea who was tying to prove what to whom when they came up with Scrum and Scrum certifications. The certified Scrum masters I've seen don't even know how to write a good user story or to break it into tasks. Give me low process overhead iterative waterfall any day over these schemes. Repeatedly trying to turn software developers into predictable manufacturing style widget makers is not a good idea.

mmcnl 9y ago
The daily stand-up is simply about "what did I do yesterday, what will I do today and do I have any impediments". It has nothing do with productivity evaluation.
- newscracker 9y ago
  Would anyone ever say something like “I just couldnt get into writing code yesterday, and I’ll try to do yesterday’s plan today.”?
matthewmacleod 9y ago
You have given an example of a shitty company using a shitty process. It's unfortunate that it's nominally 'Scrum', but that's kind of irrelevant. If someone asked me for an account of what I did for a whole six (assumed to be productive) hours yesterday and how many story points have been burned, and wanted this every single day, I can only imagine that the person has no experience with software development whatsoever. This is wrong. If this is happening, you are following a broken process. On the tools, yes, whatever I've seen in Scrum dictates a lot of time spent updating the tools with estimated hours, hours spent, remaining hours, everyday. No it doesn't. This is wrong and broken. Lastly, the "story points not related to effort but related to effort" conundrum confuses developers If a software engineer can't immediately grasp this abstraction then they are not good software developers. too low and you're not working hard enough; too high and your estimates are wrong Velocity should not be used as a stick. It's a measure of the amount of work being done which can be used for planning. If it fluctuates, that can indicate problems that need to be dealt with. Give me low process overhead iterative waterfall any day over these schemes. Repeatedly trying to turn software developers into predictable manufacturing style widget makers is not a good idea. "Low process iterative waterfall" is basically Scrum. I work two-week sprints. There are a total of four hours of meetings for those two weeks. 5% overhead seems pretty reasonable.
- newscracker 9y ago
  The problem, as I see it, is having Scrum certifications and certified Scrum Masters who follow a rigid process with many conditions (which is antithetical to the agile mindset). I know “low process overhead iterative waterfall” sounds agile, but somehow the word “Scrum” seems to make people want a certified Scrum Master (these people usually frown on waterfall-like processes even if those are better suited for delivery).

mmcnl 9y ago

The daily stand-up is simply about "what did I do yesterday, what will I do today and do I have any impediments". It has nothing do with productivity evaluation.

newscracker 9y ago
Would anyone ever say something like “I just couldnt get into writing code yesterday, and I’ll try to do yesterday’s plan today.”?

matthewmacleod 9y ago

You have given an example of a shitty company using a shitty process. It's unfortunate that it's nominally 'Scrum', but that's kind of irrelevant. If someone asked me for an account of what I did for a whole six (assumed to be productive) hours yesterday and how many story points have been burned, and wanted this every single day, I can only imagine that the person has no experience with software development whatsoever. This is wrong. If this is happening, you are following a broken process. On the tools, yes, whatever I've seen in Scrum dictates a lot of time spent updating the tools with estimated hours, hours spent, remaining hours, everyday. No it doesn't. This is wrong and broken. Lastly, the "story points not related to effort but related to effort" conundrum confuses developers If a software engineer can't immediately grasp this abstraction then they are not good software developers. too low and you're not working hard enough; too high and your estimates are wrong Velocity should not be used as a stick. It's a measure of the amount of work being done which can be used for planning. If it fluctuates, that can indicate problems that need to be dealt with. Give me low process overhead iterative waterfall any day over these schemes. Repeatedly trying to turn software developers into predictable manufacturing style widget makers is not a good idea. "Low process iterative waterfall" is basically Scrum. I work two-week sprints. There are a total of four hours of meetings for those two weeks. 5% overhead seems pretty reasonable.

newscracker 9y ago
The problem, as I see it, is having Scrum certifications and certified Scrum Masters who follow a rigid process with many conditions (which is antithetical to the agile mindset). I know “low process overhead iterative waterfall” sounds agile, but somehow the word “Scrum” seems to make people want a certified Scrum Master (these people usually frown on waterfall-like processes even if those are better suited for delivery).