Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile Scrum: Delivering Broken Software Since 1991

writemoretests.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Agile Scrum: Delivering Broken Software Since 1991

#41

Post by MostAwesomeDude »

wccrawford wrote: post #4
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…

It sounds like you're in a 'bugfix' position, and we found it hard to integrate that into Scrum, so I'm not surprised it's confusing for you. In the end, we ended up just saying that bugfixes were more important and slicing off some time for how much we expected, and using the rest of the time for Scrum. Once you get into Scrum, it isn't hard to remember the terms. A 'story' is just a feature to implement. It's calle…

I am in what might be accurately called a "student" position. I work not more than 4h/day, vary wildly in capabilities, and occasionally need training on the spot.

We don't have customers. We have the sysadmins, who want features, and ourselves, who want our names to be associated with quality software. Maybe it helps that we're an open-source-only shop.

Stories seem like they might not work well with what we do. For example, a bug I was given in January was "implement WebSockets in this proxy so that we can have WebSockets in the backend." Estimated time: 2 months. It's now September and we are just now considering the relevant code battle-ready and getting it out the door. Turns out that the bug didn't really address any of the design decisions, so those have all been slowly reevaluated over the spring, and I ended up rewriting an entire library in July.

This sounds interesting, though. Thanks for the story.

Re: Agile Scrum: Delivering Broken Software Since 1991

#42

Post by MartinCron »

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.

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.

Re: Agile Scrum: Delivering Broken Software Since 1991

#44

Post by mrgoldenbrown »

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…

I don't have a textbook in front of me, but I doubt textbook Scrum says "be inflexible"

Re: Agile Scrum: Delivering Broken Software Since 1991

#45

Post by kstenerud »

alexkearns wrote: post #39
kstenerud wrote: post #34

Earlier quoted context omitted.

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

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

Re: Agile Scrum: Delivering Broken Software Since 1991

#46

Post by buff-a »

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.

Well, either people are doing Scrum right, and it isn't working, or they are trying to do Scrum but failing. Which is it?

Is it the case that no matter what situation is presented, a Scrum zealot can always find a reason to say "Ah, you're not doing it right". That is to say that Scrum is so wishy-washy that there's always a get-out clause.

Or is it that in nearly all cases presented, there are key things which Scrum says to do that are not being done? That is to say, Scrum is pretty concrete about what needs to happen, and yet most cases presented are not doing these basic things.

The article presented in this discussion starts out by immediately saying that his ignores one of the basic rules of scrum (that a sprint's stories cannot be changed once started). The author appears to have decided that "this is Ok" because he then goes on to criticize Scrum.

So, in the example presented, I feel absolutely happy saying "You're doing it wrong".

Would you return a car because it doesn't start, even though you fail to exercise step 1 in the manual stating "Insert Key"?

What is really fucking tiring is that for some reason, a whole ream of programmers feel that they can decide for themselves that putting the key in the ignition is a waste of fucking time, and then loudly blame the car for not working, and further, anyone who has the temerity to say "put the fucking key in the ignition" is just some fucking whiner making excuses and saying "You're doing it wrong".

Yes, you are fucking doing it wrong. Feel free to not do it right. Just don't fucking complain that the car isn't getting you to where you need to be.

Re: Agile Scrum: Delivering Broken Software Since 1991

#47

Post by buff-a »

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…

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.

Re: Agile Scrum: Delivering Broken Software Since 1991

#48

Post by lucisferre »

rickmb wrote: post #38
bad_user wrote: post #33

Earlier quoted context omitted.

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, whi…

I disagree, Scrum's whole design and methodology (simple though it may be) contains serious flaws. Things like iterations (are we releasing iterations or features here?), as well as the poorly defined responsibilities of positions like the product owner and scrum master. Also it fails to adequately define how teams should confront the problems found in retrospective. Overall it often leads to a stuck process for the many, many teams that struggle with Scrum, and blaming everyone else for "doing it wrong" seems like a defensive cop out.

Scrum is to the product management process as management games like "colors" are to office team building and group psychology. Overly simplistic to the point of being nearly meaningless. By itself I find it provides very little real-world guidance for how teams should improve themselves and their process at all.

Thoughtful Edit: Don't get me wrong, I think Scrum has an initial value, but it is "meatless" for want of a better term. Anyone who really wants to improve a process for a dysfunctional team dynamic is going to need more than just some iterations and stories. Scrum is a starting point, but more often than not I think it is little more than that. Blame the team if you want, but I'll put at least some of the blame with the methodology not providing enough long term guidance.

Re: Agile Scrum: Delivering Broken Software Since 1991

#49

Post by buff-a »

narag wrote: post #20
fauigerzigerk wrote: post #16

What on earth does that have to do with Scrum? Pressure to make compromises on code quality is about as universal an issue as you will ever find one.

It seems a case of "bait and switch". You've been attracted to a methodology as defined by experts, but get an aproximation by some random PHB. The result is similar to Mr. Bean trying to apply ninja techniques as seen on a Steven Seagal movie. Sadly, for many of us, it's the only Scrum that we've seen, so expect more hate. Maybe it is a problem with Scrum, after all. What good is a methodology that gets so often mis…

What good is a methodology that gets so often misimplemented?

Scrum is simple. Its not misimplemented because its complicated. Its misimplemented because organizations are fundamentally not good at developing software. Scrum just puts it in your face. You don't even need to actually write any software to know how and why you are failing. Just attempt to do Scrum, and see what excuses you make to do not do any given part of it.

Re: Agile Scrum: Delivering Broken Software Since 1991

#50

Post by buff-a »

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…

There are number of classic failure modes for Scrum. One of them is to not have a Product Backlog at all, or to only plan it out a few weeks.

Since you claim that in your experience, Scrum de-emphasizes forward thought and big-picture thinking, I can only conclude that you don't do this, and have decided to blame Scrum for this fact.

I suggest that you identify whatever it is that is preventing your team from creating a full product backlog.

Also, my YAGNI detector is going off big time.

Post reply on HN