6 ms·

Even if scrum works perfectly, it does not empower developers. In fact, from what I can see, the whole purpose of scrum is to disempower developers while giving

Even if scrum works perfectly, it does not empower developers. In fact, from what I can see, the whole purpose of scrum is to disempower developers while giving them the illusion they are empowered. As the author reveals, under scrum, it is not the developers who decide what new features to add to the software. It is the product owners. Who decides the priority of the new features under scrum? Not the developers but the product owners. At least under waterfall, developers could get their teeth into a good chunk of interesting work. They could come up with some fancy architecture or something. But under scrum, all work is broken up into bite-sized chunks of work that are rarely challenging and often highly repetitive. Under scrum, the developer's time and ingenuity are not valued. If a product owner out of the blue decides to ditch a new feature or radically change one, wasting the work a developer has done creating it, he does so without a moment's concern about the developer's wasted time and effort. In short all that scrum offers developers is a small amount of control over their workload. Compare that with developers of the past, who would conceive software and build it themselves the way they wanted, and you can see that, far from empowering developers, scrum has reduced them to little more than assembly line robots, at the beck and call of their masters. I am not saying that we should go back to the past when developers were in charge or everything but to say that scrum empowers developers when it clearly does not needs to be challenged.

bobbles 15y ago
This is the exact opposite of what SCRUM hopes to achieve. If a product owner decides to bin a feature, it's because it has been weighed against the options available and decided that this feature is no longer valuable to the company. 'Wasting' the developer time as you have stated it is a misnomer, as I would say developing a product you know wont be used by a customer is wasting time. Within SCRUM, a developer should have full control of how software is developed, if a product owner is trying to dictate the way in which a product is developed, they are stepping too far and the ScrumMaster needs to get them to back off. The way for a product owner to determine how a product is developed is to have a clear set of requirements in place that are testable and achieveable.
- alexkearns 15y ago
  Everything you say seems to back up my point about scrum not empowering developers. "If a product owner decides to bin a feature, it's because it has been weighed against the options available and decided that this feature is no longer valuable to the company." And therefore the sweat a developer has put into creating this feature is not valued. Scrum pretty much ensures that developers will at some point create stuff that will never see the light of day. Hardly empowering. "'Wasting' the developer time as you have stated it is a misnomer, as I would say developing a product you know wont be used by a customer is wasting time." I would not necessarily disagree with you but it is hardly empowering for a developer. Scrum is designed to empower the business, not the developer.
  - cube13 15y ago
    >And therefore the sweat a developer has put into creating this feature is not valued. Scrum pretty much ensures that developers will at some point create stuff that will never see the light of day. Hardly empowering. That's software development, period. Miscommunication and incorrect assumptions are a major contributor to it happening. Aggressive deadlines are another cause, because there often isn't enough time to complete everything the dev wants to do on the project, so they need to settle for what they can do. There's also the possibility that the feature just isn't needed, or won't ever work well. Agile isn't unique in this, too. Every SE pattern in existence has issues with these. It's simply what happens when you are developing a new product.
  - kstenerud 15y ago
    That is definitely a possibility, but not the common practice. Most often, a feature is binned BEFORE any development occurs. In fact, I've only ever seen a feature binned after development started once. It was a feature that we decided was being introduced too early, required too much re-architecting, and wouldn't offer any compelling benefits to our customers. And it saved a LOT of effort and pain to cut the rope early. Binning work in progress is not a good thing, of course. It's actually a failure on the part of the manager. But just as you expect to be forgiven your failures, so too must you forgive others. > Scrum is designed to empower the business, not the developer. Scrum is designed to help you as a COMPANY develop a better process for getting things done with minimal headaches. If as a developer you're opposed to the company and its direction, why are you even working there? It's a question of priorities. Are you working to make a good customer experience or are you working to stroke your own ego? If you're not customer focused, you shouldn't be writing software for other people.
unobfuscate 15y ago
The key here is to separate how we things done from how objectives are defined. Using Waterfall instead of Scrum does not inherently change who gets final say on what will be accomplished. If the project manager or project owner want to have complete control of what gets done, will little to no input, your process won't change this. Scrum is about visibility, accountability, and continuous product evolution. It's about controlling what gets done, and when we do it, not who defines the goals. It's your companies loss if they don't take the input of both the developers and customers when deciding what to do next.

bobbles 15y ago

This is the exact opposite of what SCRUM hopes to achieve. If a product owner decides to bin a feature, it's because it has been weighed against the options available and decided that this feature is no longer valuable to the company. 'Wasting' the developer time as you have stated it is a misnomer, as I would say developing a product you know wont be used by a customer is wasting time. Within SCRUM, a developer should have full control of how software is developed, if a product owner is trying to dictate the way in which a product is developed, they are stepping too far and the ScrumMaster needs to get them to back off. The way for a product owner to determine how a product is developed is to have a clear set of requirements in place that are testable and achieveable.

alexkearns 15y ago
Everything you say seems to back up my point about scrum not empowering developers. "If a product owner decides to bin a feature, it's because it has been weighed against the options available and decided that this feature is no longer valuable to the company." And therefore the sweat a developer has put into creating this feature is not valued. Scrum pretty much ensures that developers will at some point create stuff that will never see the light of day. Hardly empowering. "'Wasting' the developer time as you have stated it is a misnomer, as I would say developing a product you know wont be used by a customer is wasting time." I would not necessarily disagree with you but it is hardly empowering for a developer. Scrum is designed to empower the business, not the developer.
- cube13 15y ago
  >And therefore the sweat a developer has put into creating this feature is not valued. Scrum pretty much ensures that developers will at some point create stuff that will never see the light of day. Hardly empowering. That's software development, period. Miscommunication and incorrect assumptions are a major contributor to it happening. Aggressive deadlines are another cause, because there often isn't enough time to complete everything the dev wants to do on the project, so they need to settle for what they can do. There's also the possibility that the feature just isn't needed, or won't ever work well. Agile isn't unique in this, too. Every SE pattern in existence has issues with these. It's simply what happens when you are developing a new product.
- kstenerud 15y ago
  That is definitely a possibility, but not the common practice. Most often, a feature is binned BEFORE any development occurs. In fact, I've only ever seen a feature binned after development started once. It was a feature that we decided was being introduced too early, required too much re-architecting, and wouldn't offer any compelling benefits to our customers. And it saved a LOT of effort and pain to cut the rope early. Binning work in progress is not a good thing, of course. It's actually a failure on the part of the manager. But just as you expect to be forgiven your failures, so too must you forgive others. > Scrum is designed to empower the business, not the developer. Scrum is designed to help you as a COMPANY develop a better process for getting things done with minimal headaches. If as a developer you're opposed to the company and its direction, why are you even working there? It's a question of priorities. Are you working to make a good customer experience or are you working to stroke your own ego? If you're not customer focused, you shouldn't be writing software for other people.

unobfuscate 15y ago

The key here is to separate how we things done from how objectives are defined. Using Waterfall instead of Scrum does not inherently change who gets final say on what will be accomplished. If the project manager or project owner want to have complete control of what gets done, will little to no input, your process won't change this. Scrum is about visibility, accountability, and continuous product evolution. It's about controlling what gets done, and when we do it, not who defines the goals. It's your companies loss if they don't take the input of both the developers and customers when deciding what to do next.