[0x445442]

> 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 requirements for my home build, I leave that to them. I just expect my requirements to be met at or near budget.

A lot of these software process issues boil down to managements never ending quest to commoditize developers.

[beat]

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 minutes before the oven timer goes off.

Scrum is, at heart, designed precisely to stop the behavior you're demanding - that is, the endless stream of "small" interruptions and constantly shifting priorities. The raisins.

Why are you trying to "shoe horn in work" for this iteration that you weren't aware was even an issue when the iteration planning happened? Is production down? Is it a hair-on-fire emergency that threatens the business? Or is it just "important". FUCK important. If it's so important, put it in the story backlog and have it done in the next iteration.

If it's important enough to disrupt the iteration, it's important enough to cancel the iteration, toss all that iteration's unfinished work onto the backlog, and start over. That's how Scrum is supposed to work, but never does, because someone wants raisins at the last minute and thinks it's not a big deal.

[Nomentatus]

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.

[beat]

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.

[mistermann]

I've seen products fail because of a refusal to support flexibility in core functionality because the extra work couldn't be justified due to YAGNI, and then get totally outclassed by competitive products where they were more agile.

Want to know the correct answer to this agreement? Sometimes YAGNI is good, sometimes it's bad. Anyone who doesn't realize this is not qualified to decide which case a team finds itself in.

[Nomentatus]

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.

[beat]

A "better data structure" is almost never an emergency. And being unable to adapt or extend a data structure in the future is not agile, and it's not the simplest thing that can possibly work.

Back when I first started building a startup, I thought "Thank Dog I no longer have to deal with stupid compromised software, and can start writing everything right!" By the time I was getting anywhere, I was well into toss-over-wall methodology. I did things that I knew full well were compromised and would hurt me later, because the work needed done, and needed to "be done". It was a real education.

I actually have a lightning talk in mind on this subject, called "Why software sucks", that argues that suckage is the nature of software development, and that "barely works" is the best we can realistically ask for - or even should ask for.

[mistermann]

> If it's important enough to disrupt the iteration

Do you realize your argument is based on an assumption that is not necessarily true? If Scrum is as good as advertised, it shouldn't require untruths to justify it.