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

Re: Agile Scrum: Delivering Broken Software Since 1991

#51

Post by Zimahl » Wed, Sep 28, 2011, 8:36 PM UTC

I've done a fair amount of Scrum and have seen it succeed and fail. Scrum works and is great, but like most tools it works only for specific types of jobs.

I wouldn't use Scrum in a situation where the final product is somewhat defined and is expected at a certain date. Any situation where you ask yourself 'why aren't we using waterfall here?' is one where Scrum will inevitably fail.

Scrum is typically great for startups (and sometimes established companies) that are building something that is more of an idea than a product and time is irrelevant due to being able to push new features out later if they aren't done. It helps if your customer doesn't expect polish and is fine with incremental improvements.

To use the Minecraft analogy, Scrum would be a great process for Mojang. The target is moving, the features the developers thought were significant yesterday have found to be of no concern to the users, and thus they can drop something and focus a new feature. The next version has what's done, not necessarily what was expected. Waterfall wouldn't work in this situation at all.

Re: Agile Scrum: Delivering Broken Software Since 1991

#52

Post by romaniv » Wed, Sep 28, 2011, 9:02 PM UTC

rickmb wrote: post #36

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…

Scrum favors incremental/additive changes, which leads to inconsistencies. Often inconsistencies are too large to simply fit with some other task, and a separate task just for reconciling everything never gets prioritized. Viola.

Re: Agile Scrum: Delivering Broken Software Since 1991

#53

Post by thematt » Wed, Sep 28, 2011, 9:26 PM UTC

lucisferre wrote: post #48

rickmb wrote: post #38

Earlier quoted context omitted.

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…

I don't think it's reasonable to expect the process to define how a team should confront the problems found in a retrospective. Those project and team specific problems are likely to be unique and giving the team the framework to choose the best course of action is likely to more effective than some prescriptive process that says "If A then do B".

It also wasn't meant to provide guidance on how teams should improve themselves, that's up to the team to choose the best route to get there. It excels at enabling the team to make those decisions for themselves.

Re: Agile Scrum: Delivering Broken Software Since 1991

#54

Post by grncdr » Thu, Sep 29, 2011, 2:14 AM 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…

I think this previous comment by michaelfeathers supports what you're saying:

"The fact of the matter is that too many people think that projects can be run through the interface of stories and feature lists without paying attention to the quality of the software underneath. And, when you don't pay attention to it, it suffers. This, really, is _Joel's Law of Leaky Abstractions_ applied to process. Business wants to see features, and if that abstraction is their only view of the project, they will be blindsided by creeping quality issues. It's nearly inevitable."

Quality issues aren't always architectural issues, but architectural issues (especially lack of any planned architecture) always cause major quality issues.

http://news.ycombinator.com/item?id=2978806

Re: Agile Scrum: Delivering Broken Software Since 1991

#55

Post by daemin » Thu, Sep 29, 2011, 6:05 AM UTC

neilk wrote: post #22

At least in my understanding of Agile/Scrum, there shouldn't be any cards representing code quality. There are only features that make sense to both the customer and the developer. The time to write tests and so on should be built into cost estimation of the feature. However, as 'api' says, this tends to result in a mucilaginous mess. There really is a certain amount of work that you have to do on a project which is…

I don't think there should ever be a scheduling item for 'code quality' (and related activities) in any software development planning/management cycle. If software developers want to be treated as proper engineers at some point in time, we should start implementing quality as a default, not as an afterthought.

Therefore it stands to reason that 'code quality' should always be baked in when estimating software tasks, same goes for any other related and required development activity.

Re: Agile Scrum: Delivering Broken Software Since 1991

#56

Post by daemin » Thu, Sep 29, 2011, 6:09 AM 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…

In this case it seems to be a tool forthe developers to manage the expectations of the 'other' non-development side of the business.