Why “Agile” and especially Scrum are terrible • Hacker News Board

Re: Why “Agile” and especially Scrum are terrible

#21

Post by wirrbel » Sun, Jun 07, 2015, 8:35 PM UTC

beckler wrote: post #19

wirrbel wrote: post #18

Earlier quoted context omitted.

I think there are a few red flags here with the way you are doing scrum: I have never heard of individual velocity measurements, they are wrong and should not be measured. I also think that burndown charts and velocity are for the team, not the stakeholders. This is because story point estimation is volatile and turning it into a feedback loop would turn this estimation into a meaningless thing. Thus, there is room f…

Yes, I absolutely agree entirely. The reason we had individual velocity measured, is because our management wanted to use it as a metric to determine our performance (Which I think is an awful method for measuring performance). I work in a digital agency, and our management tries to be very hands off, but then they do something like look at individual velocity and our amount of git commits to make sure we're working.

more red flags.

Taking commit counts as a measure (and line counts for the same reasons) is like evaluating a writer by the number of words they write without looking at the content. A writer could copy a phone book to get good reviews.

Individual velocities are bad for several reasons. (1) they discourage team work (2) they are inexact (story point estimates only work because we look at the sum of them for sprint planning, they work on average, not for individual stories). (3) there are better metrics available.

If your management wants you to do agile develoment, they should be there in the sprint review and look at last sprint's work.

Re: Why “Agile” and especially Scrum are terrible

#22

Post by vannevar » Mon, Jun 08, 2015, 3:52 AM UTC

beckler wrote: post #20

vannevar wrote: post #16

Earlier quoted context omitted.

These are really good observations. If there's a common thread, I would say it's the intolerance for failure exhibited by managers who don't understand software development. I'm not sure that intolerance would be lessened by another system, whether it be waterfall or kanban, or ad hoc. Prior to agile, when failure happened, it tended to happen in a big way near the end of the project. But if a project were two or thr…

So kanban and scrum are fairly similar, but the difference is that with kanban, you don't have to estimate a point value to it, as time isn't the priority. I view this as an advantage for two reasons: - 1. Most non-technical clients view point estimates as absolute expectations. They can't comprehend an estimation in any other way. So if I can do 5 points a day, and I give a story 13 points, it's expected to be accom…

Thanks, interesting perspective. The advantage of sprints is that you're demoing progress on a regular basis. I can see the possibility of people focusing more on the demo than the ultimate purpose of the code, in which case as you say you'd accumulate technical debt in the form of hacks. But if you don't demo regularly, you run the risk of hidden problems where everyone assumes something works when in fact it doesn't. Either way, competent management is needed to avoid the pitfall.

Re: Why “Agile” and especially Scrum are terrible

#23

Post by spronkey » Mon, Jun 08, 2015, 7:09 AM UTC

vannevar wrote: post #22

beckler wrote: post #20

Earlier quoted context omitted.

So kanban and scrum are fairly similar, but the difference is that with kanban, you don't have to estimate a point value to it, as time isn't the priority. I view this as an advantage for two reasons: - 1. Most non-technical clients view point estimates as absolute expectations. They can't comprehend an estimation in any other way. So if I can do 5 points a day, and I give a story 13 points, it's expected to be accom…

Thanks, interesting perspective. The advantage of sprints is that you're demoing progress on a regular basis. I can see the possibility of people focusing more on the demo than the ultimate purpose of the code, in which case as you say you'd accumulate technical debt in the form of hacks. But if you don't demo regularly, you run the risk of hidden problems where everyone assumes something works when in fact it doesn'…

The 'hack a demo' problem highlights one of the rationales behind having a Definition of Done in Scrum. Unfortunately Scrum doesn't put hard and fast rules behind what should be in it, but most good Scrum teams take principles from XP such as all code should be tested. This helps reduce the 'hack' factor at the expense of getting it out the door faster.