Agile Scrum: Delivering Broken Software Since 1991 • Hacker News Board

Re: Agile Scrum: Delivering Broken Software Since 1991

#31

Post by alexkearns » Wed, Sep 28, 2011, 3:45 PM UTC

bobbles wrote: post #29

alexkearns wrote: post #26

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…

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 shou…

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.

Re: Agile Scrum: Delivering Broken Software Since 1991

#32

Post by cube13 » Wed, Sep 28, 2011, 4:18 PM UTC

alexkearns wrote: post #31

bobbles wrote: post #29

Earlier quoted context omitted.

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 shou…

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 stuf…

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

Re: Agile Scrum: Delivering Broken Software Since 1991

#33

Post by bad_user » Wed, Sep 28, 2011, 4:31 PM UTC

Aloisius wrote: post #23

api wrote: post #14

My experience with Scrum is that it has a tendency, especially if implemented "textbook" with absolutely no flexibility, to completely de-emphasize any kind of architecture, forward thought, elegance, or big-picture thinking about the code. The result tends to be a giant snotball of hacks. In my personal experience the biggest casualty is efficiency, followed by maintainability and scalability. The fact is that good…

The textbook way of running Scrum is to have a retrospective at the end of every sprint where you find faults with the process and tunes it for your specific environment. If you skip over that part or worse, refuse to adjust the Scrum process because it breaks some rules, then You're Doing It Wrong.

Ah, the standard excuse for failed Scrum implementations -- you're doing it wrong.

Re: Agile Scrum: Delivering Broken Software Since 1991

#34

Post by kstenerud » Wed, Sep 28, 2011, 4:33 PM UTC

alexkearns wrote: post #31

bobbles wrote: post #29

Earlier quoted context omitted.

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 shou…

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 stuf…

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.

Re: Agile Scrum: Delivering Broken Software Since 1991

#35

Post by unobfuscate » Wed, Sep 28, 2011, 4:37 PM UTC

alexkearns wrote: post #26

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

Re: Agile Scrum: Delivering Broken Software Since 1991

#36

Post by rickmb » Wed, Sep 28, 2011, 4:37 PM UTC

api wrote: post #14

My experience with Scrum is that it has a tendency, especially if implemented "textbook" with absolutely no flexibility, to completely de-emphasize any kind of architecture, forward thought, elegance, or big-picture thinking about the code. The result tends to be a giant snotball of hacks. In my personal experience the biggest casualty is efficiency, followed by maintainability and scalability. The fact is that good…

Scrum doesn't de-emphasize those things, bad programmers do.

I'm just following your logic here, which I agree with up to the point where Scrum has a negative influence.

I don't see how Scrum can encourage good programmers to write bad code, since it gives them all the room they need to write good code, and lets them decide how much time and effort they put into architecture etcetera.

Bad programmers however tend to get exposed by Scrum, since without anybody telling them they have to consider architecture, they will produce said giant snotball of hacks.

Re: Agile Scrum: Delivering Broken Software Since 1991

#37

Post by unobfuscate » Wed, Sep 28, 2011, 4:48 PM UTC

kstenerud wrote: post #34

alexkearns wrote: post #31

Earlier quoted context omitted.

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 stuf…

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 e…

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

Re: Agile Scrum: Delivering Broken Software Since 1991

#38

Post by rickmb » Wed, Sep 28, 2011, 4:48 PM UTC

bad_user wrote: post #33

Aloisius wrote: post #23

Earlier quoted context omitted.

The textbook way of running Scrum is to have a retrospective at the end of every sprint where you find faults with the process and tunes it for your specific environment. If you skip over that part or worse, refuse to adjust the Scrum process because it breaks some rules, then You're Doing It Wrong.

Ah, the standard excuse for failed Scrum implementations -- you're doing it wrong.

If a methodology is so simple that it only requires you to do a few things and you're not doing those, than "you're doing it wrong" is not an excuse, it's an objective fact.

Besides that, given that Scrum is such a lightweight methodology, it's pretty hard to fail for competent programmers to fail using Scrum. Worst that can happen is that they find Scrum isn't an improvement over whatever they were doing before, which is cool. There's no one size fits all.

But failure is usually caused by other factors. The standard excuse for failing projects is of course blaming the methodology... Ever notice that in places where Scrum "fails" that is usually not exactly the first failure?

Re: Agile Scrum: Delivering Broken Software Since 1991

#39

Post by alexkearns » Wed, Sep 28, 2011, 5:11 PM UTC

kstenerud wrote: post #34

alexkearns wrote: post #31

Earlier quoted context omitted.

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 stuf…

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 e…

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.

Re: Agile Scrum: Delivering Broken Software Since 1991

#40

Post by MostAwesomeDude » Wed, Sep 28, 2011, 5:21 PM UTC

peteretep wrote: post #3

MostAwesomeDude wrote: post #2

This just makes me feel like scrum isn't worthwhile. Here's how my work flow goes, as a developer: There's an issue tracker. A handful of issues are assigned to me. I know, by memory, which issue's important, because it's always the one people are yelling about the most. I write the code for the issue, test, commit, get feedback, close the issue. Done. I could not remember all of this terminology. Stories? Sprints? C…

Author here... I once started a contract at a company where I was working with a permie on this hugely popular site running off the God-awful blogging software. Everything was a fire that had to be put out RIGHT NOW. And there were two of us. Coworker had earned himself a reputation for being unhelpful and unproductive. This was partly because he had sociopathically bad communication skills and hated people, but he a…

Cool story! This is interesting.