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

Why I'm done with Scrum

lostechies.com

Post reply on HN
Print view View original

141–150 of 163 posts

Re: Why I'm done with Scrum

#141

Post by vannevar »

erichocean wrote: post #95
vpeters25 wrote: post #75

Every time I come across "why scrum sucks" articles like these I can quickly point the problem: the ScrumMaster. #1 - Iterations are less efficient than pull-based approaches: A good ScrumMaster keeps an eye on the burndown chart and negotiates with the stakeholders and team to either add or remove tasks from a sprint. My first sprint ever as ScrumMaster, we estimated a 3 months project, we did everything in 2 sprint…

So scrum has a single-point-of-failure that organizations, more often than not, see high failure rates with? And we're still recommending companies adopt this, when the failure rates are both known to be high, and catastrophic when they occur?

Companies still do project management, and the project manager is a single point of failure. The reason the failure rate is high is that scrum is relatively new and companies still think they can get away without having a scrum master, while they know from long experience that they need good project managers.

Re: Why I'm done with Scrum

#142

Post by josephlord »

adrianhoward wrote: post #125
ajross wrote: post #71

Earlier quoted context omitted.

Isn't that just a No True Scotsman argument? You're saying that Agile is good because it's isomorphic to any successful, minimal ad hoc process that fits the project . Well, OK, if that's your defintion of "Agile". But the "Agile" (rather "Scrum") described in books and web videos and blog posts isn't like that at all. It has become a decidedly "heavy" process with all sorts of jargon behind it. My guess is that this…

I know - it does come across as the one-true-scotsman argument at times. Disclaimer: I'm a fan of agile. I even seem to be turning into one of those evil consultant people in my old age (but only just recently - and I still code :-) I'd urge agile sceptics to put aside some of the crap they see in the real world. Go take a look at the original sources (e.g. both of Beck's books on XP are fun reads - and short :-). Ta…

16 pages is plenty to define a onerous heavy process. I could define an onerous process in one page if I wanted.

I don't feel sufficiently informed to judge wether it is onerous in theory or practice but weighing the description is the wrong test.

Re: Why I'm done with Scrum

#143

Post by slurgfest »

gaius wrote: post #118
martincmartin wrote: post #63

I've done a bunch of reading about Scrum. If you read between the lines, you realize that Scrum was created and popularized by consultants who go into dysfunctional teams/organizations, and tries to fix the worse problems. For example, the idea of a sprint is for a team to be able to work for at least a couple weeks on a single thing, without people being asked to work on other "small" projects, or without the entire…

Scrum is by and for management, not developers. Want your devs in at 9am? No problem, hold the standup then. Want to easily replace your dev team with an outsourced one? No problem, a Scrum team is a black box as far as the rest of the organization is concerned, one with a well-documented interface. Etc, etc. Ir's insidious because it tricks devs into thinking it's for them.

It is a compromise. Like any long-term compromise, it is gradually bent into a shape mostly determined by whoever has the better bargaining position.

Re: Why I'm done with Scrum

#144

Post by alphadogg »

tosh wrote: post #86
debacle wrote: post #13

> With Scrum, there is an explicit commitment ... on what stories are going to be delivered within the sprint, No, there isn't. You adhere to your burn-down, not to your feature set. Scrum is time driven, not task driven. The whole idea is to become better at estimation so that Scrum appears task driven, when really it's just because your team is that good at estimating. > Iteration planning meetings are seriously ex…

“A bad system, will defeat a good person, every time.” -- Deming I can no longer count how often I heard "you're doing it wrong" when people explain why scrum didn't work for them or when they feel there needs to be something that works 'better'. Getting Scrum right is hard. Managing huge backlogs is hard. Doing time-based sprint plannings is hard, especially if you are working on stuff that is either new or new to y…

I'm curious about "different stand-up meeting format". What format(s) do you use?

Re: Why I'm done with Scrum

#145

Post by igouy »

anthonyb wrote: post #102
igouy wrote: post #100

Earlier quoted context omitted.

>> work from intuition a lot of the time But work better when they follow a checklist! "The Checklist Manifesto: How to Get Things Right" http://www.npr.org/templates/story/story.php?storyId=1222261...

Sure, but a checklist is an aid to memory, not a set of prescriptive rules.

In what way is a pre-flight checklist not prescriptive?

Re: Why I'm done with Scrum

#146

Post by javajosh »

gaius wrote: post #118
martincmartin wrote: post #63

I've done a bunch of reading about Scrum. If you read between the lines, you realize that Scrum was created and popularized by consultants who go into dysfunctional teams/organizations, and tries to fix the worse problems. For example, the idea of a sprint is for a team to be able to work for at least a couple weeks on a single thing, without people being asked to work on other "small" projects, or without the entire…

Scrum is by and for management, not developers. Want your devs in at 9am? No problem, hold the standup then. Want to easily replace your dev team with an outsourced one? No problem, a Scrum team is a black box as far as the rest of the organization is concerned, one with a well-documented interface. Etc, etc. Ir's insidious because it tricks devs into thinking it's for them.

What does management want anyway? Do they want a black box with a well defined interface? What other options do they get?

It seems to me that this question depends very much on the kinds of commitments management is making. Which in turn depends on whom they are making them to. If it's to a customer that has some hard requirements, enumerated in a contract, and providing those is the source of money, then management's focus is (and should be) executing those requirements. Which would seem to imply that a black box is just fine.

The problem is not the desire for a black box approach, but that boxes fail. Management is risk averse (and their risk aversion is what keeps your paycheck coming, in theory).

(Actually, black boxes are creeping into software development all of the time. For example, there's no reason to not have fast PSD-to-HTML turn-around anymore. That process has been black-boxed. Not shrink-wrapped, but black-boxed. Yes, there are still quality variations, questionable use of excessive markup, etc, but its not bad.)

Anyway, I just question your tacit assumption that management wanting a black box with a well defined interface is a bad thing. It seems like a reasonable goal.

Re: Why I'm done with Scrum

#147

Post by YZF »

adrianhoward wrote: post #135
YZF wrote: post #121

Earlier quoted context omitted.

I've heard this before. I think the most simple reasoning there is that the Agile manifesto says: Individuals and interactions over processes and tools. In Scrum it is process over individuals. The process is what is important, not the individuals.

That's certainly not the intent behind Scrum though. The intent behind Scrum is to let the team within the sprint be pretty much completely free to implement whatever process they like to deliver the sprint goal. It's whole focus is to remove management interference from the main body of work the team does. PO figures out what needs doing. Team figures out the best way of doing it. Scrum provides a framework for acco…

I know that. The historical motivator is the 1986 paper, "The new new product development game". I think the difference in what happens in Scrum is that the team gets further isolated from an organization through the ScrumMaster and Product Owner and therefore has less ability to influence and more process imposed (the various invariable rituals of Scrum and more). The teams are now viewed as units of production, stick story in, get implementation out. Almost never will the Product Owner be really a product owner within the intention of Scrum and the ScrumMaster will drift towards a semi-team-lead role and his incentives are not aligned with those of the company or the team.

Re: Why I'm done with Scrum

#148

Post by gaius »

javajosh wrote: post #146
gaius wrote: post #118

Earlier quoted context omitted.

Scrum is by and for management, not developers. Want your devs in at 9am? No problem, hold the standup then. Want to easily replace your dev team with an outsourced one? No problem, a Scrum team is a black box as far as the rest of the organization is concerned, one with a well-documented interface. Etc, etc. Ir's insidious because it tricks devs into thinking it's for them.

What does management want anyway? Do they want a black box with a well defined interface? What other options do they get? It seems to me that this question depends very much on the kinds of commitments management is making. Which in turn depends on whom they are making them to. If it's to a customer that has some hard requirements, enumerated in a contract, and providing those is the source of money, then management'…

It's not healthy for the organization as a whole if the only point of contact between "the business" and the developers is enshrined in the Product Owner. It is however very amenable to empire building and short-term cost savings, both of which are examples of a manager favouring their own interests over that of the organization. In short, Scrum is most useful for those for whom a dysfunctional organization is their goal. That the turkeys (devs) are voting for Christmas themselves is the icing on the cake.

Re: Why I'm done with Scrum

#149

Post by alphadogg »

InclinedPlane wrote: post #69
brazzy wrote: post #27

Earlier quoted context omitted.

That's cowboy programmer bullshit., the kind of thing mediocre but cocky programmers tell themselves to justify primadonna behaviour "having nothing and good developers you trust" is either a recipe for disaster, or a short prelude to those good developers coming up with a minimal ad hoc process that fits the project and most likely is remarkably similar to one established Agile methodology or another.

Here is another perfect examplee of what's wrong with SCRUM, it creates zealots. When someone starts talking about a need to give good, self-disciplined devs a little freedom instead of micromanaging them to death the scrum zombies start shouting about "cowboy programmers". When someone starts talking about long-term or strategic planning they start screaming about "waterfall". The truth is that there is a lot of evi…

Ironically, SCRUM creates a sort of anti-zealot too. The kind that compares no SCRUM as giving "good, self-disciplined devs a little freedom" and having SCRUM as equivalent to "micromanaging them to death the scrum zombies".

SCRUM has basic principles that I don't think are egregious to any dev. Mind you, there's a million and one ways to mis-apply them, like patterns, frameworks and other things devs take for granted.

Re: Why I'm done with Scrum

#150

Post by tetha »

anthonyb wrote: post #94
debacle wrote: post #87

Earlier quoted context omitted.

If the project manager throws out a feature description like that, just say "Yes" and throw it to the bottom of the backlog - it'll be revisited when it's well defined.

No - because you're not the business owner and don't decide what order things go in the backlog. A better way is to just give a sufficiently large estimate: "That's 100 points* due to risk and uncertainty." If they want a more detailed estimate, then they have to give a more detailed story. * - whatever will give you 6 +/- 3 months

This is one of the best things an older programmer has taught me. If people want estimations on vague things, give them 8 month full team full time. Minimum. Doesn't matter what it is. Implement a new, small feature? 8 month. Move the office furniture around? 8 month. People talking to you learn quickly to give out more precise specifications.
Post reply on HN