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

Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

scrum.org

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#81

Post by mangodrunk »

mistermann wrote: post #68
jt2190 wrote: post #45

Earlier quoted context omitted.

The Agile Manifesto suffers from "the curse of knowledge": The signatories are all very experienced, and deeply understand all of the differences between projects and people and when to be flexible and when to be rigid, and they know that it's important to not specify a method for every situation. But there are many, many people entering the software industry who don't have their years of experience, and who need ver…

> Instead it encourages newbie practices for everyone, forever. I feel like YAGNI is similarly abused, I don't know how many times I've said "You know what, while we're at it we should...." only to be overridden with "YAGNI!", only to be proven right 3 months later, only now the cost of refactoring > value of the feature, and saying I told you so isn't being a "team player", so no one ever learns. I very often wonder…

Be wary of confirmation bias. I think YAGNI is typically a good idea. There's a balance between YAGNI and planning (as the extreme in either case is obviously wrong). You probably understand the system fairly well and have good judgement, but YAGNI definitely saves more than I think it hurts in my experience.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#82

Post by mangodrunk »

chris11 wrote: post #73
jryan49 wrote: post #25

I still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ (which is short and uncomplicated), that the first line is "Individuals and interactions over processes and tools" and these days practicing agile, at least in a big-house corporate environment feels like anything but.

On another note, what metrics could be commonly used to judge individual dev productivity, and should they be used? I'm wondering because I have had places bring up metrics like average story points completed per sprint in performance reviews. Which kind of confused me when numbers for our team seemed to be doing fine, and it seemed like my work was going well based off of previous conversations with management.

In my experience, using story points to judge performance is typically not useful. It is a very simplistic view. It doesn't include the quality of the code. And who knows if the estimation was accurate. And then you can have story point inflation. Also, someone may figure out an easier less complicated solution for a problem, and so that would have a smaller story point, which is better.

I would be curious in hearing how people judge dev productivity as well, it's something that I don't like to just use a number, though there may be some benefit in having that being a small part of the judgement.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#83

Post by Nomentatus »

beat wrote: post #74
0x445442 wrote: post #69

Earlier quoted context omitted.

> I very often wonder if I am the only one that feels this way. You're not. One of the bigger issues I've seen with Scrum is not being able to shoe horn in work that needs to be done because business didn't identify it as a "story". I believe development is there to serve business and any processes used to facilitate this serving should be defined by development. I don't dictate how a general contractor satisfies my…

There's an analogy I like to use... you're baking bread. Bread is just flour, water, yeast, and salt, plus maybe decoration ingredients. You mix things in the correct proportions, let it rise, bake at the right temp/time, and you get bread. Easy, right? Then someone wants you to put in raisins. "It should be easy! It's just a handful of raisins, I don't see why you're telling me it can't be done!", they shout, five m…

Yes, I have seen businesses die, both ways. The problem is that YAGNI cashes out to "make the right decisions" - it's logically a tautology, but an emotional encouragement to drop features. Dropping is usually the correct decision - but too often catastrophic when it's not. If you invoke YAGNI you have to be careful you aren't "picking up nickles in front of steamrollers" - a great idea until suddenly it's not. Fortunately, frequent iteration gives people a more realistic view of the cost of raisins.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#84

Post by gaius »

joejerryronnie wrote: post #79
gaius wrote: post #48

Earlier quoted context omitted.

People get necks and backs broken in real scrums too. A real scrum is a violent fight for control between opposing teams. A lot of these analogies were not well thought through. I will wager the methodology merchants behind scrum were neither runners nor rugby players ever.

Ah yes, the shenanigans that occur in a real scrum are no joke. Some of our forwards would wrap tape around their entire head (including ears) to prevent their ears from being torn off.

We used to play rugby when I was at school, it was banned when a kid in the next town ended up in a wheelchair, then my school switched to tennis or something. Nowadays I only watch, the atmosphere at Twickenham is incredible

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#85

Post by rapala »

theptip wrote: post #51
neltnerb wrote: post #36

Earlier quoted context omitted.

Is that actually what scrum suggests sprints are? Thanks, I missed that, that's silly if so. I assumed by the name that this was like a one week a month kind of thing.

I think there's quite a lot of getting hung up on the word itself here... According to the Scrum guide, a sprint is just: > a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. ( http://www.scrumguides.org/sc…

Exactly. The point of time boxing is that you have to stop and reflect on the time spent. It gives you the chance to switch tasks if priorities have changed or to split the current task.

Or to go on to the next sprint with the same task. But here lies the problem in many cases. The sprint is taken not as a time box but as a deadline. A sprint should meen: "You can work 2 weeks, 5 days a week, 8 hours a day on this. Then you stop to think."

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#86

Post by rapala »

bamboo_7 wrote: post #31

Yes yes yes. It never made sense to me that our ticket sizing was supposed to be an estimate and yet the planning that used those estimates was considered a commitment. Totally insane.

I have always thought commitment in this context as "we commit this much time for this task, then we stop and reevaluate" instead of a deadline.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#88

Post by beat »

Nomentatus wrote: post #83
beat wrote: post #74

Earlier quoted context omitted.

There's an analogy I like to use... you're baking bread. Bread is just flour, water, yeast, and salt, plus maybe decoration ingredients. You mix things in the correct proportions, let it rise, bake at the right temp/time, and you get bread. Easy, right? Then someone wants you to put in raisins. "It should be easy! It's just a handful of raisins, I don't see why you're telling me it can't be done!", they shout, five m…

Yes, I have seen businesses die, both ways. The problem is that YAGNI cashes out to "make the right decisions" - it's logically a tautology, but an emotional encouragement to drop features. Dropping is usually the correct decision - but too often catastrophic when it's not. If you invoke YAGNI you have to be careful you aren't "picking up nickles in front of steamrollers" - a great idea until suddenly it's not. Fortu…

I haven't seen businesses die because they can't wait two weeks for a new feature, and had to have it right now. I have seen businesses die because a development team was so paralyzed by constant interruptions that they were dysfunctional and couldn't get any real work done.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#89

Post by Nomentatus »

beat wrote: post #88
Nomentatus wrote: post #83

Earlier quoted context omitted.

Yes, I have seen businesses die, both ways. The problem is that YAGNI cashes out to "make the right decisions" - it's logically a tautology, but an emotional encouragement to drop features. Dropping is usually the correct decision - but too often catastrophic when it's not. If you invoke YAGNI you have to be careful you aren't "picking up nickles in front of steamrollers" - a great idea until suddenly it's not. Fortu…

I haven't seen businesses die because they can't wait two weeks for a new feature, and had to have it right now . I have seen businesses die because a development team was so paralyzed by constant interruptions that they were dysfunctional and couldn't get any real work done.

If it's a better data structure, then two weeks might set the course, alas. It's happened to me. Fact is, one can't get away from judgement calls, slogans might nudge in one direction or another, but it all remains a judgement call what's just a raisin and what isn't. The fatal problem is bosses up the chain who want to demonstrate they matter and are worth their expense by throwing in superfluous raisins; having a crude slogan (misleading or not) to deter them is fine by me.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#90

Post by brightball »

daanlo wrote: post #67

I am a big fan of scrum precisely because of the word commitment (I hand't realized it was removed). Forecast means we need to use a larger estimate next time. Commitment means: "how can we still get this live". In a good culture the answer to this should rarely be work extra hours or reduce code quality - it should be reduce scope of functionality. Without the commitment you often get micro feature creep, where a bu…

Depending on the size or the organization, that word commitment can create numerous issues.

It can keep teams from collaborating because of a need to finish their commitments first, effectively blocking the other teams and delaying actual delivery of the product. You can see the same issues in customer support requests. The second that somebody decides to measure completed sprint commitments, you are in deeeeeep trouble because it forces people to low ball to hit that number. It removes your ability to pivot.

The entire concept of sprint commitments in a moderately sized team is borderline destructive.

This change is the best news about software development I’ve read in YEARS.

Post reply on HN