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.
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.
> 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.
That depends on what you mean by "empowering". Do you mean it in the sense that the developer has the final say on what a program does (i.e. feature set)? Do you mean that the developer has the final say on how it is implemented (i.e. architecture)? I would argue that the developer should NOT have the final say on what a product does, but SHOULD have the final say in how it does it. Product designers decide WHAT it does and how it should look to the customer. The developer's job is to turn that product design into a reality using intimate knowledge of technologies and architectures, and alerting designers to the reality of what developing according to their design involves (time + effort), and coming to a compromise if it's too heavy.
> 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.
Absolutely. If you build something and it doesn't work for your customers, throw it out. If you can't handle that, you're ego focused, not customer focused.
> 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.
It seems to me that you want to be the product designer AND engineer. That's fine since you have the abilities of both, but that's not the common case. The ability to write code does not magically confer the ability to design good products.
And even then, scrum will help you because you can track the morphing of your designs into concrete products, do the estimation, prioritization, feature cutting, tracking, and do all the throwing out and redesigning of your own stuff as customers respond positively or negatively to your product refinements. And then at the end of it all you can decide how well the process is working in a retrospective, and refine it to work better for you. Scrum is a meta-process; It helps you BUILD a process that works for you, and provides a convenient starting point that works fairly well in general.
>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)
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.