[jryan49]

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.

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

> 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

[weego]

I worked at a large consultancy in the UK where the platform team were 'agile' in that they had 2 week sprints, but those 2 week sprint goals were fixed for months ahead. If you needed a small API addition or specific bug fix in one of your apps (elearning courses) to launch a product on the platform and you hadn't foreseen this 2 months+ in advance then you were out of luck (unless you had leverage on one of the platform team higher ups of course).

That was my first introduction to uppercase A for Agile.

Ultimately the wider business never changes in terms of it wants predictable delivery and deadline forecasts, but internally they have to then wedge some version of lowercase a for agile into that because the benefits day to day are there so you have this clunky enterprise friendly version that poorly tries to get best of both.

[sorokod]

In my experience this kind of Agile inevitably emerges when the desire to be agile is limited to a (small) subset of the organisation.

[philbarr]

Absolutely - some people hear, "people before process", think it sounds great, then immediately go looking for a process to implement it and find Scrum.

[crdoconnor]

I think that's largely the fault of the manifesto. It is entirely unclear about what putting "individuals before process" actually means.

One way I've seen it used was as a way to justify organizing meetings as a means to solve an increase in defect regressions rather than allocating extra work on automated tests.

The former was "individuals and interactions" and the latter was tools and processes. I thought it was a reasonable interpretation and also wrong.

[chris11]

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.

[mangodrunk]

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.

[dlezama]

Well, nobody makes money by pointing at the manifesto. But a whole business can be built around "certification" and all that.

[ionforce]

Maybe people are ultimately imperfect and others are looking to process to smooth over those imperfections.

[rileymat2]

> That is, while there is value in the items on the right, we value the items on the left more.

[wnevets]

Trying to explain this to people who are "certified" is exhausting.