4 ms·

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 weig

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
  >If as a developer you're opposed to the company and its direction, why are you even working there? It's so true, and I feel it works both ways. You can be a developer who's surrounded by complete idiocy, and tries to infuse change with little success. You can also be the problem, and be causing everyone else more headache with your unrealistic expectations. If choices are being made to drive customer value which impact your enjoyment of the job (work sucks, they threw out stuff you did before, your suggestion was ignored, etc), then it's time to make a decision about if you belong on that team or at that company. Do you believe in what your company is trying to accomplish? If not, it can severe impact your desire to go to work in the morning. Just please don't check out, quit instead! Having someone on a team who's just phoning it in hurts everyone.(this is not targeted at anyone, more a blanket statement)
- alexkearns 15y ago
  My point is not over whether Scrum delivers better software than other methods (in my experience, it delivers average software consistently, which may be a good or bad thing depending on your point of view). My interest is in how the role of the developer has changed over the years, and how developers have been increasingly stripped of power over what they do. I believe Scrum is simply the latest step in this direction. Now, it may be that stripping developers of power is the best way to create good software (we've all seen the god awful usability of some developer-created software). But let's not pretend that this is empowering for the developer, as the author suggests Scrum is. "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." But isn't Agile (of which scrum is part) partly about putting a product out there and seeing how users or customers respond. There is a built in acceptance that some new features are not going to work but you never know until they have been tested out by the end users. "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." That is kind of my point. Developers don't get the chance to write software for other people. They don't have any say how the software actually works, by which I mean the user journeys, the feature set etc because they have been reduced to simply turning the fickle ideas of product owners into a reality. I now work on my own products because that is the only way I can turn my own ideas for user-centric software into a reality.
MartinCron 15y ago
And therefore the sweat a developer has put into creating this feature is not valued. If the feature doesn't actually add value, you just have to be an adult and move on. I've developed lots of things that haven't seen the light of day. That's part of life.
buff-a 15y ago
Scrum is designed to empower the business, not the developer What do you mean by "empower the business"? I assume you don't believe that a non sentient legal entity can be empowered. In which case can I assume you are talking about empowering the humans within the business? And what I deduce from this statement is that you feel that in your business, there are programmers, and there is everyone else, and further that Scrum empowers only everyone else. From your other posts, I deduce that They are not qualified, in your opinion, to determine what should be worked on to deliver value to the customer. Scrum isn't going to magically fix this situation. This is a people problem. This is an organizational problem.

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
>If as a developer you're opposed to the company and its direction, why are you even working there? It's so true, and I feel it works both ways. You can be a developer who's surrounded by complete idiocy, and tries to infuse change with little success. You can also be the problem, and be causing everyone else more headache with your unrealistic expectations. If choices are being made to drive customer value which impact your enjoyment of the job (work sucks, they threw out stuff you did before, your suggestion was ignored, etc), then it's time to make a decision about if you belong on that team or at that company. Do you believe in what your company is trying to accomplish? If not, it can severe impact your desire to go to work in the morning. Just please don't check out, quit instead! Having someone on a team who's just phoning it in hurts everyone.(this is not targeted at anyone, more a blanket statement)
alexkearns 15y ago
My point is not over whether Scrum delivers better software than other methods (in my experience, it delivers average software consistently, which may be a good or bad thing depending on your point of view). My interest is in how the role of the developer has changed over the years, and how developers have been increasingly stripped of power over what they do. I believe Scrum is simply the latest step in this direction. Now, it may be that stripping developers of power is the best way to create good software (we've all seen the god awful usability of some developer-created software). But let's not pretend that this is empowering for the developer, as the author suggests Scrum is. "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." But isn't Agile (of which scrum is part) partly about putting a product out there and seeing how users or customers respond. There is a built in acceptance that some new features are not going to work but you never know until they have been tested out by the end users. "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." That is kind of my point. Developers don't get the chance to write software for other people. They don't have any say how the software actually works, by which I mean the user journeys, the feature set etc because they have been reduced to simply turning the fickle ideas of product owners into a reality. I now work on my own products because that is the only way I can turn my own ideas for user-centric software into a reality.

MartinCron 15y ago

And therefore the sweat a developer has put into creating this feature is not valued. If the feature doesn't actually add value, you just have to be an adult and move on. I've developed lots of things that haven't seen the light of day. That's part of life.

buff-a 15y ago

Scrum is designed to empower the business, not the developer What do you mean by "empower the business"? I assume you don't believe that a non sentient legal entity can be empowered. In which case can I assume you are talking about empowering the humans within the business? And what I deduce from this statement is that you feel that in your business, there are programmers, and there is everyone else, and further that Scrum empowers only everyone else. From your other posts, I deduce that They are not qualified, in your opinion, to determine what should be worked on to deliver value to the customer. Scrum isn't going to magically fix this situation. This is a people problem. This is an organizational problem.