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.
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.