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

Why I'm not a big fan of Scrum

okigiveup.net

Post reply on HN
Print view View original

151–160 of 387 posts

Re: Why I'm not a big fan of Scrum

#151

Post by lmm »

camtarn wrote: post #33

Quoting a nice idea from the article: "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resem…

> Quoting a nice idea from the article: "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resemble a network of equations, instead of a list of items, where solving one equation would simplify the others by replacing unknowns with more precise values."

Does this even mean anything? How would it work in practice?

Re: Why I'm not a big fan of Scrum

#152

Post by TeMPOraL »

lmm wrote: post #118
humanrebar wrote: post #105

Earlier quoted context omitted.

> You may end up never porting that subsystem, in which case refactoring the currently-stable implementation is wasted effort. I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and r…

> I understand this approach, and it works many times. But when the porting is delayed until the last possible minute, it's more likely that hacks are put in because the requirement turned into a hard deadline. Instead of defining a sensible OS abstraction layer, the developers might find and replace "Windows XP" with "Windows 7". Which may well be the right choice for the business at that point. More generally, it's…

> Which may well be the right choice for the business at that point.

I think it may be imporant to raise a few points for consideration here:

- what may be a good choice for the business short-term can also be a very bad choice for the business long-term

- many - personally, I believe most - businesses don't care about products they make or services they give, they care about the money they can make via those products/services; ergo, the quality doesn't matter beyond the point the customer already paid what they were expected to pay

I don't bring it up as criticism, but only to point out that there are two completely different worldviews here competing. One, shared by many developers, is that the product is what that matters. The other, shared by the "business types", is that the profit generated by product matters.

I also feel that part of one becoming a professional developer is a shift from thinking about quality of work to thinking about its money-making potential. Which I personally consider a poison to the mind, and it makes me hate working in companies. But those are just my personal feelings.

Re: Why I'm not a big fan of Scrum

#153

Post by clifanatic »

I got my first programming job, while still in college (as part of a co-op/internship program) in 1992, for the U.S. department of defense. As you can imagine, everything was BDUF there. It was very frustrating and the most annoying part was the massive disconnect between what the users expected, which was that they could suggest a change and see it on their desktop an hour later, and the reality of change and release management, regression testing, unexpected side effects, code entropy, etc. etc. Some time around 1999, I started to hear about "extreme programming" (XP), and when I looked into it, I breathed a huge sigh of relief, because here were people whose opinions people seemed to be paying attention to making the same observations that I was, but far more eloquently than I ever could, in a way that seemed to be resonating with users and project managers. I guess I'm too much of a "glass is half full" type, though, because it didn't take too long before XP gave way to "agile methodologies" which became "scrum" which is really BDUF with micromanaging daily standups.

Re: Why I'm not a big fan of Scrum

#154

Post by TeMPOraL »

ozmbie wrote: post #148
thackerhacker wrote: post #52

Earlier quoted context omitted.

It's a long time since I've had to deal with "strict" Scrummers. But I do remember being utterly baffled as to the insistence on user features being ready by the end of a sprint, even for quite complex, technical components. Why can't we make some sub-component this sprint then the UI bit the next? I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.

Because that two weeks you spent writing excellent code is mostly useless unless you have a way to get feedback on it. As a customer, you've given me no value. What if you finally hook up UI to the sub-component and the customer/stakeholder decides they don't like any of it? You could have known about it earlier.

That's why I sometimes say at my workplace that we should make our projects in Flash. Faster to make an interactive UI this way and get the approval of the management/customer, no time wasted on useless things like having the program actually work in an efficient, useful and secure way.

Re: Why I'm not a big fan of Scrum

#155

Post by afroisalreadyin »

discreteevent wrote: post #112
afroisalreadyin wrote: post #70

Earlier quoted context omitted.

Author of the post here, thanks for your comment. As you said, the fact that you have to stick out your neck and fight for code quality is very annoying, and after some time, one just stops doing it, and starts flowing with the "add the one more line of crap to get things working and collect the points".

"Lean" is supposed to address quality and habitability more. 2 of the 7 tenets of lean focus on it: Build Quality In Optimize the Whole I've never practiced it and my only exposure has been reading some of the book "Lean Architecture". But it certainly seems like an improvement over Scrum which seems blind to some of the most critical things in developing complex innovative systems. In fact I'm convinced that Scrum w…

That book appears to be very interesting, I'll definitely have a look. Thanks for the tip.

Re: Why I'm not a big fan of Scrum

#156

Post by Udik »

lmm wrote: post #129
fsloth wrote: post #116

Earlier quoted context omitted.

"The user-facing design needs to drive the API interface, not the other way around." I don't see how this need would nullify the ability to modularize code.

Modularize by functionality, not by layer. Start with a simple end-to-end path and grow outwards, rather than trying to go top-down or bottom-up, and don't split into distinct layers until you're actually deriving value from doing so. Writing code when you don't have the use case yet is always a bad idea.

Yep. And then at the third sprint into this path you realize that the way the backend has been built during the first two sprints makes it impossible to deliver some essential or just very desirable feature that nobody took in consideration because it was outside the scope of the first two sprints. Seen it happen multiple times.

Re: Why I'm not a big fan of Scrum

#157

Post by je_bailey »

The aha moment for my team which changed us from a mindset of dealing with scrum to enjoying it was when we moved from aiming towards a number of story points to complete towards committing to the stories that we could individually complete in a sprint, without a concern for the associated story points.

All of a sudden story points disassociated with time. They just became a number. a combination of complexity and understanding.

A lesser, but still important shift, came with our changes to backlog grooming. When part of that grooming included poker planning to estimate points. This Spread that chore out, and our Sprint planning is now approximately half an hour as the team goes down the prioritized list and commits to stories.

Re: Why I'm not a big fan of Scrum

#158

Post by vpeters25 »

cheriot wrote: post #115

Keep in mind that Scrum was designed by consultants working for organizations that don't understand software development. So they designed a process that can make sense to people outside our industry. In order for it to go well, though, the person running the Scrum process needs to know how shit really works. This is rarely the case.

> Keep in mind that Scrum was designed by consultants working for organizations that don't understand software development.

Scrum was "designed" by Ken Schwaber, a software project manager at the time looking for a better way to control software development processes.

Schwaber discovered he could use an empirical process, rather than a defined one, to control software projects. He created Scrum following this principles.

Re: Why I'm not a big fan of Scrum

#160

Post by bhaak »

blub wrote: post #65
bhaak wrote: post #23

Earlier quoted context omitted.

I've seen the "you're doing it wrong" argument so many times (I applied it myself a few times). Scrum is complex and not always possible to follow exactly, so this is to be expected but it makes me wonder, how many successful projects are out there that are following the true Scrum methodology? My guess is that it's a few more than the classic waterfall but I still seem to see far more failure than success stories.

The very idea of a one-size-fits-all process is unrealistic IMO. Something will always be customised in practice. Regarding success stories, it might be that process doesn't play such a critical role as long as solid engineering techniques are used and the team is competent.

If your team is competent and solid engineering techniques are being used, you already have a well working process. Forcing any methodology on this will likely result in a deterioration.

All those methodologies are for the less stellar programming teams, to get consistent results from those (also to a lesser degree to make good and bad programmers work well along each other). Because you can't always get the best programmers.

If Scrum would only work well with good programmers, it would be next to useless.

Post reply on HN