[jt2190]

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 very clear, basic instructions as a starting point, and hence Scrum steps in to fill the gap. What's unfortunate is that scrum isn't a program for developing software managers from rigid, by-the-book managers into experienced, agile managers: Instead it encourages newbie practices for everyone, forever.

[mistermann]

> 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 if I am the only one that feels this way.

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

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

[mangodrunk]

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.

[tootie]

Exactly. I look at it as following the Dreyfus Model. If you don't know what agile delivery looks like or how to approach it, you start with Scrum and follow it religiously. Once you get the feel and the team is accustomed, you can modify it to suit your needs or just wing it and keep the goals in mind.

[lowbloodsugar]

Unfortunately, what teams do religiously is the process, contrary to the manifesto. So they put a Scrum Master pin on someone, they do Sprints and burndowns. They cargo cult.

I did my first CSM course with Ken Schwaber. I did another recently with someone else. The recent course was all process. Ken's course was mostly "why".

Jeff Sutherland said there are three things that must be true for a team to be a Scrum team:

1. It must be self-governing.

2. The team members must be on the team 100%

3. The team members must stay for the duration.

With the exception of start-ups, I've seen maybe one team which met these criteria. But they all had sprints. And of course, they were all held to their commitment. Scrum is now a tool for management to death march people.

Think of all these metrics that management measures scrum teams on. Can you imagine any of these teams turning around and saying, "We're going to measure how many of your bullshit wishlist items meet the definition of an actionable story when presented in sprint planning, and how many hours are wasted?" Of course not. Management can't abide a team that meets rule 1. "I'm a manager! I must manage! What is my job if my teams are self managing?!"

Scrum, as Ken Schwaber describes it, is a fantastic way to develop product. Unfortunately, if you are in an organization that would truly let you do Scrum, then you probably don't need it. You are already qualified, experienced and empowered. If its a hundred twenty-year-olds being told to "do scrum", it probably ain't Scrum.

[watwut]

I worked on self governing teams without manager, twice. Never again. Relationships were hell with constant power struggle between wanna be micromanagers over who is going to be non existent leader and get to have his vision.

Clear responsibilities, accountability and personal autonomy are so much, so much, better arrangement then self governing team.

[stephenhuey]

Hear hear! Scrum predates Agile. It welcomes mixing in other tools as needed, e.g. XP, Agile, etc. After 15 years of professional software development, I just picked up a scrum master certificate a couple days ago after my employer paid for the class. I'd rather see teams using scrum than just winging it unless they are provably experienced or extraordinarily competent. Individuals can be good at their work but it's often difficult to get everything in sync on a team, or even if the team is super amazing the complexity of getting things done in a corporate environment with lots of moving parts and dependencies is usually aided by using tools such as scrum. Even when a complex corporate environment commits to trying to follow it, it's still a struggle to get the basic elements of scrum adhered to (enough time with product owner, enough time figuring out dependencies, any time at all spent identifying ways the team could do better in the future and reduce friction, impediments, or needless work). Take a look at the Scrum Guide - I'd be satisfied if just the few events in the minimal scrum framework could be fit in, but often not even that happens.

* edit: provably