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

81–90 of 163 posts

Re: Why I'm done with Scrum

#81

Post by vannevar »

pherk wrote: post #58
vannevar wrote: post #3

FTA: Scrum forces iterations, forces feedback, forces smaller iterations. These are all good things, which I loved about Scrum. And yet the author spends most of the article denying that these aspects of scrum are useful at all. Planning sessions are "highly inefficient," a "quick meeting between the architect and the developer" is better. What if someone else has an important piece of information that the dev and th…

> What if someone else has an important piece of information that the dev and the architect don't? That isn't good enough justification. You are too much erring on the side of caution.

But it's not costing me much. My devs still need to be in on planning their own work, and if they're all on the same scrum there should be a lot of overlap. Listening in on the planning for work entirely unrelated to their own should be pretty rare.

Re: Why I'm done with Scrum

#83

Post by efuquen »

brazzy wrote: post #48
debacle wrote: post #30

Earlier quoted context omitted.

I completely disagree [1]. There's a difference between a cowboy programmer and a programmer that can go more than a day or two without checking in with his superior. In my personal opinion, based on the level of intelligence required to do good programming, the best programmers are self-managing. As a corollary to that, it's too expensive to hire development managers (in the traditional "management" sense) that can…

Actually, you completely agree with me. A Scrum Team very explicitly is self-managing. Agile processes ARE frameworks for coordinating self-management at the team level, and which have been found to work repeatably. That doesn't mean a given one will work everywhere. Specifically, Scrum is probably not ideal for startups doing something truly new, since it assumes there is someone who can prioritize features by their…

"Actually, you completely agree with me"

I'm sure if you keep that condescending and conceited attitude everyone will come around ...

Re: Why I'm done with Scrum

#84

Post by eevilspock »

zwieback wrote: post #73
InclinedPlane wrote: post #69

Earlier quoted context omitted.

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…

Good developers+zero formal process only works to a certain scale, though. I think that's where scrum might have a place, just enough process to keep things from going off the rails when the team is too big to self-organize over a long period of time. Agree about the danger of zealotry though. Also, the vocabulary is just so ridiculous - I have to mentally think "black dog grooming" when I say "backlog grooming" just…

It also depends on the nature of the work. Is it more mechanical, a more-or-less straightforward implementation of a spec? Or does it require real creativity, invention, non-linear thinking? Anyone who truly understands the creative process knows you have to give it freedom.

Scrum might have valuable in big hierarchical companies or when there are many average-talent programmers, but there's no way I'd foist it on a team of smart developers much less and early stage startup.

Re: Why I'm done with Scrum

#85

Post by CodeMage »

brazzy wrote: post #27
debacle wrote: post #16

Earlier quoted context omitted.

I think your last point is key. You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one.

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.

You're yelling at the wrong guy. What @debacle said was "You can't use process to turn a bad programmer into a mediocre one - any process that does will also turn a great programmer into just a mediocre one." That's decidedly not "cowboy programmer bullshit". If your response was directed at @fingerprinter's statement that "having nothing and good developers you trust is always going to be more productive", then maybe you should have been rude to him instead of @debacle.

I think @debacle nailed it. One of the major problems with all the processes I've ever seen is that people (large corporations, mostly) expect them to solve the problem of having teams made of bad or mediocre programmers. It's quite similar to the idea that you can solve just about any problem with technology.

Re: Why I'm done with Scrum

#86

Post by tosh »

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

If you are doing routine work you might as well use waterfall or "jfdi" as your approach. Burn-down charts, velocity and sprint planning doesn't help if you just don't know where the next problem will be or when your team variation changes constantly (people move to other teams, new people join, people get sick, …).

I've found that changing/being able to change the 'system' (scrum) to something else that works better (agile/lean to its roots, kanban, different stand-up meeting format, evidence based time-tracking, value-flow …) is way more effective than changing the people to become 'better' at Scrum and doing it less 'wrong'.

YMMV

Re: Why I'm done with Scrum

#87

Post by debacle »

sethg wrote: post #34
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…

In my experience (six months at a job that does Scrum and, I think, does it very well), the thing that slows down iteration planning meetings is when the product manager hands down a one-sentence feature description, the engineers say “we can’t size that, it’s too vague”, and then you need a five-to-fifteen-minute discussion in order to expand that one sentence into something resembling a spec.

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.

Re: Why I'm done with Scrum

#88

Post by sjtgraham »

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…

This is a really interesting insight. I have seen so many instances of prescriptive Scrum with no explanation as to why that it's appropriate, i.e. Cargo Culting.

Re: Why I'm done with Scrum

#89

Post by Domenic_S »

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…

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

Of course there is. There is no burn-down, no 'time', without tasks. So while in a pedantic sense you're right that you commit to 'time', time is measured in stories.

Re: Why I'm done with Scrum

#90

Post by mizhi »

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…

After a bit of experience with scrum, one of the things I"ve come to appreciate is that it's not a one-size-fits-all methodology. I think the spirit of scrum (break work into chunks, have working code at each stake in the ground, define a project in terms of user stories, etc) is more important than the letter of the law, and being able to tailor the process to your current reality is more valuable than dogmatic adherence to some prescription.
Post reply on HN