[quanticle]

Like committing to a sprint target. And literally doing everything to fulfill it. Like not waiting for a manager to step in and ask for overtime and weekend shifts. Remember? Scrum teams take all the necessary steps themselves. Always!

Isn't the entire point of scrum to enforce a sustainable pace of development? One that doesn't require heroics like having programmers come in on nights and weekends to finish? The entire point of tracking time and making burndown charts is so that you can avoid taking on too much work. If your team doesn't have the ability to push back on the requirements and say, "Hey, this is too much, we need to push features X, Y, and Z into the next sprint," you're not really doing scrum. You're doing kabuki-scrum, which is usually just waterfall with all the meetings relabeled.

[dreamfactory2]

Much as I dislike scrum and find it anti-agile, the author seems unaware that official scrum docs removed the word 'commitment' years ago because it was misunderstood as more than a target and misapplied just about everywhere.

[ryan-allen]

Can you recommend any good books on kabuki-scrum?

[RalfR]

Well, as far as I understood, Scrum's fundamental principle dictates that the team delivers working software at the end of every Sprint.

This has partially to do with not over committing at the beginning, but if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises.

Unfortunately, this clear obligation gets forgotten to often – as I pointed out in the original post.

You seem to second my point.

[marcus_holmes]

I don't care what methodology you're using, if it includes crunch then it's broken.

Proper, grown-up coding on a business application is incredibly wearying on the mind, and results have shown time and time again through research studies and professional management that past 8 hours coding in a day the average programmer's code quality starts to deteriorate. Past 10 hours it goes negative - at this point the code base is actually being damaged.

"doing what needs to be done to fulfil the promise" is actually alerting the team that you've made a poor estimate of the effort required for this feature and need to recalibrate. It is absolutely not sticking with your poor estimate and delivering shoddy code to the project.

[pacala]

The next time I hear "crunch" from a PM type, I'll publicly invite him/her to lead by example and deliver a bunch of features over his weekend.

[GFischer]

Be careful what you wish for... I know several PM types that can match you insane hour per insane hour - some had skin in the game (part ownership), others were just overzealous and I know at least one burned out.

[artjumble]

"I don't care what methodology you're using, if it includes crunch then it's broken."

Rather than saying it is broken, it needs to be said that the team needs to improve. Continuous Improvement, it's where it's at.

[quanticle]

>it has to do what needs to be done to fulfil its promises.

No. Scrum is explicitly open to renegotiation. This is where burn-down charts come in to play. This is where having the product-owner be part of the team comes into play. If a feature is costing a lot more hours than anticipated due to unforeseen problems, it is expected that the team gets the product owner involved early so that a decision can be made: do we drop other work to deliver this feature, or do we drop other features to deliver this?

The core premise of scrum and other agile methodologies is that given the uncertainties inherent in software development, it is impossible to fix both the featureset and the schedule. Scrum fixes the schedule and explicitly allows for flexibility in the featureset. Other methodologies (like spiral, for example) fix the featureset and allow for flexibility in the schedule. Waterfall attempts to fix both, and fails as a methodology.

[flurdy]

Once a team starts to work overtime and weekends to finish stories (on its own accord or by instruction) then the value of your velocity measurement is shot to pieces. Predicting and committing to future sprints is then a complete guesswork (or rather even more of a guesswork..) when bad committal is masqueraded with pulling a rabbit out of hat.

[cmdkeen]

It also masks the problem in the retrospective - in my view the most important part of scrum. Developers put down positives for going above and beyond rather than being forced to admit, and therefore analyse, that the team failed.

I've found, though perhaps it is a British cultural thing, that there are plenty of things people sit on and don't mention out of politeness - they only come out after a particularly bad failure.

[lmm]

> Well, as far as I understood, Scrum's fundamental principle dictates that the team delivers working software at the end of every Sprint.

Working software yes. If you break the build the minute before the end of Sprint then yeah you better fix it. Sensible teams resolve this by not committing at the last minute, and by having the Sprint end at, say, midday Thursday, not 9AM on Monday.

> if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises.

Nope. There are no promises, no "clear obligation". Half the point of the daily standups is that if a feature is not going to be deliverable in its original form within the sprint, you catch this early, and then you talk about it, you have contact with the product owner, and you decide something sensible.

[UK-AL]

Working software =! All the features committed. It means it should be useable, even if only half the features were complete.

Also next time you plan a sprint, you reduce the commitment.

[Morst]

But another point often forgotten is that the main goal is to deliver a working increment. Even if not the whole sprint gets delivered for some reason.

[dreamfactory2]

There is an obligation to deliver working software but there is no commitment to deliver specific features, just a target.