luckylefty

If you hate working on Agile projects that means "they're doing it wrong". I wouldn't be surprised if that's the case. There's Agile, and there's what management thinks Agile should be.

I'm working at a place that's "trying to be agile", but they have a command and control mentality which pretty much makes that impossible. In our scheme, agile is probably costing us a lot of productivity. But that's because we have stand-ups with one engineer, one team lead and five "chickens" who spent most of the time talking.

It is what you make of it. Just as you can write bad code in any language, you can be a bad manager in any management structure.

From:

"If you hate working on Agile projects that means 'they're doing it wrong'" seems pretty clearly to me to be an example of the No True Scotsman (http://en.wikipedia.org/wiki/No_true_Scotsman)fallacy. Are you so certain that Agile is the One True Perfect management style that works perfectly for everyone that it's completely impossible that there are some people who hate Agile, even if it's done correctly?

I've been a professional software engineer for 25 years. I've thought pretty hard about it, and I can't remember a time when I've either learned something useful, or communicated something useful, in a "go around the room and everyone say what they're working on" meeting. Any methodology that mandates mandatory meetings of this sort is a bad one for me.

From:

"Are you so certain that Agile is the One True Perfect management style that works perfectly for everyone that it's completely impossible that there are some people who hate Agile, even if it's done correctly?"

More or less.

From the agile manifesto: http://www.agilemanifesto.org/principles.html

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

In practice, that means that agile methodologies are a starting point, not a destination. If such and such isn't working for you, then do what works for you. You might argue that Agile isn't the optimal path to the best way to work. I couldn't argue with that.

"I can't remember a time when I've either learned something useful, or communicated something useful, in a "go around the room and everyone say what they're working on" meeting. Any methodology that mandates mandatory meetings of this sort is a bad one for me."

Assuming you're talking about stand-ups, these things are supposed to be very short (under 15 mins), and done only with team members who doing the work. Here team has a very specific meaning in that anyone on the team should be able to the work of anyone else on the team. But if daily stand-ups aren't working for the team, that's ok. Agile methodology allows and encourages you to discard what doesn't work. If you're not allowed to discard what isn't working, then you're not actually working on an Agile project.

From:

It's certainly possible to fall into the No True Scotsman trap, but I think equally it has to be recognized that sometimes there are generic frameworks that you can hang things off of and sometimes the problem is what/how you do that hanging and not with the framework itself.

I am not claiming Agile is or isn't the greatest thing since sliced bread; I'm currently in my first significant experience with it :-) There are things I like about it.

I've thought pretty hard about it, and I can't remember a time when I've either learned something useful, or communicated something useful, in a "go around the room and everyone say what they're working on" meeting.

This surprises me. Sure, these can become tedious, especially if there is too much wandering off and/or not properly scoping things and drilling down into implementation details etc. that really don't belong in a standup meeting. The whole point of standup is it's a short recap of what you've been working on.

Is it directly relevant to you to know what everyone's up to? Of course not. Is it often useful? It can be. Depends on the rest of your group dynamic. We do pair programming and switch up every few days. It's useful to be at least vaguely in the loop on what the rest of the team is doing because (a) you might end up working on it soonish and/or (b) even if you aren't you might have a good idea about something they're stuck on, etc.

I do think there is a maximum group size above which the time/benefit ratio isn't worth it. Of course, above that point you really should probably be splitting up into multiple teams each holding their own standup etc.and inter-group sharing on a less frequent basis and maybe only involving the leads or managers etc.

From:

nonelvis

Speaking as a designer, not a coder, Agile seems poorly optimized to include design in the process, and particularly to allow for the kind of high-level view you need to create visual designs that are applied consistently through an application and properly enhance all the functionality. Taking code in bits and pieces and then throwing stuff away later means that you're designing a visual language on the fly, which is frankly a crap way to do visual design (and in some cases, user interface design, too).

I agree with you that like any methodology, Agile is probably what you make of it, and that some organizations handle it better than others. But I've yet to work on a project that gave visual design the time it needs to work from the top-down rather than piece by piece.

From:

There are bad metaphors and bad management structures. The relationship between the two is correlational, not causal. I suppose the real danger comes from people only understanding the metaphoric language, not what that language is actually describing.

See also: "Your love is like bad medicine."

From:

Yes, there are good and bad metaphors used by good and bad managers. But I find it interesting that one of the central metaphors in the current flavor-of-the-month software development silver bullet uses some really terrible metaphors, and no-one has pointed that out before as far as I know.

I'm not a rugby player, but from what I've seen, "when everyone puts their heads down, most lose sight of the ball completely, everyone pushes in opposite directions, and mostly they just cancel each other out and no forward progress occurs" is a reasonable description of a scrum.

And metaphors do matter. If I was interviewing somewhere, and was told "we don't call them a manager's 'direct reports'; we call them his 'slaves'", I would think twice about working there. "Sprint" rings the same sort of warning bells (though not as strongly).

From:

The term "sprint" is not an agile term, it's a scrum term. Scrum is one flavor of agile management, but it is not the only flavor. I'm not entirely clear about the genesis of scrum, but I think it caught on because XP was viewed as a bit goofy. Over time scrum has morphed into something closer to XP, but it still uses it's separate jargon.

Fun fact: Angry Birds is *exactly* a metaphor for scrum. The bad news; we're the pigs.

http://robsnetblog.blogspot.com/2011/12/scrum-is-like-angry-birds.html

From:

"... and no-one has pointed that out before as far as I know."

http://www.infoq.com/news/2008/11/sprint-misnomer

From:

dougo.livejournal.com

"In rugby football, a scrum refers to the manner of restarting the game after a minor infraction." I think that's the sense they were trying to get at, i.e. a way to get everyone in the same place to kick off the day, make sure no one's stuck or going down the wrong path or duplicating work or whatever. ("Huddle" would be a better word for Americans, I think.) It shouldn't be mandatory, e.g. if people work from home some days or need to come in late or whatever, but I think in general it does help the team work more smoothly as a team. Just keep it very brief! (We call ours "standup", and if you get tired of standing, then you know it's going too long.)

I'm still confused about the word "sprint" though. I don't think the idea is to work at a unmaintainable pace, but to work without interruptions and changing requirements. Maybe the idea is that while you're "on the track" you can't be interfered with, but that you should periodically end the sprint and regroup off-track rather than just stay on the track for a whole marathon.

For what it's worth, Scrum is a specific instance of an Agile methodology; the Agile Manifesto doesn't have any of these hardcoded procedures (or metaphors), and in fact explicitly makes adherence to process secondary to people and communication. Which doesn't take away from your criticism, just pointing out that what you're criticizing is Scrum rather than Agile.

From:

Also we call them iterations and not sprints (though occasionally people who've called them sprints elsewhere call them that too).

So does this seriously just reduce to, you dismiss/condemn an entire philosophy because its early proponents/promulgators were bad at choosing names?

From:

I don't see what I say above that can be construed as dismissing or condemning an entire philosophy. I think agile has a lot of good points and a lot of bad points. I think that names matter, and that "sprint" (which I've been informed is scrum terminology, while the Agile terminology is "iteration") is a really bad name.

My view of standups is certainly colored by the fact that in my current job, we have a standup with 15 people, and the fact that half of them are in Nepal means that I can't hear what half of them are saying, and that time zones force us to have the meeting at a really inconvenient time.

Because Agile is the current buzzword, everyone wants to claim to be Agile. So my perception is that there is as much difference between management styles within groups claiming to use an Agile methodology as there is between groups that do and don't pay lip service to Agile.

It seems to me that people today take (whatever their misconception of) Agile is as gospel, and say "Agile is the Right Thing; is this thing we might do Agile?" rather than just asking "Is this the Right Thing to do for this group to accomplish its goals"?

From:

I'll separate the meta-linguistic discussion and the process discussion into separate replies...

I don't see what I say above that can be construed as dismissing or condemning an entire philosophy.

"I would discount not only their advice on sprinting, but all their advice on how to go about running a marathon."

"I would think twice about working there. "Sprint" rings the same sort of warning bells (though not as strongly)."

Now, my "dismiss/condemn" is an overbid, but it does seem like you are overly hung up on the terminology.

I'm not saying the terms don't matter, I'm saying they don't matter that much.

You explicitly did NOT say: "I don't like the chickens/pigs metaphor; I would think twice about working at a place that disrespects its human employees by calling them barnyard animals."

but my reaction to your post was vaguely as if you had. Feel free to say this says more about me than about what you actually said if you want :-)

From:

People find it very difficult to change their management styles. So it's much more likely that people will adopt the buzzwords and tools of a new approach than that they will actually adopt a new approach. So even though the terminology is only a small and relatively unimportant part of an approach, it may well be the part that is most influential. So it's important to choose good metaphors.

I'm probably also influenced in the strength of my reaction by having worked at multiple places where management felt, consciously or unconsciously, that cultivating an attitude of perpetual crisis would increase developer productivity.

From:

My view of standups is certainly colored by the fact that in my current job, we have a standup with 15 people, and the fact that half of them are in Nepal means that I can't hear what half of them are saying, and that time zones force us to have the meeting at a really inconvenient time.

Well, to me, that's an example of doing it wrong. As mentioned above I think it scales only up to a certain group size, and 15 is definitely too many, and mixed remote standups are problematic (we have one full time remote employee, although he's not in the group I directly work with; they do their standups in a conference room via video conference. I don't know how well it works but no one seems to complain.)

We have offshore teams in both Beijing and Bangalore. Mostly we communicate with them via email, but they have weekly sync-ups that consist of 1-2 people in the US and (usually) the entire offshore team (6-8 people) to discuss stuff they'll handle in the upcoming week, things they're blocked on and/or need help with, etc. This seems to work pretty well for us. I would never try to do it on a daily basis.

Because Agile is the current buzzword, everyone wants to claim to be Agile

Strongly agree.

So my perception is that there is as much difference between management styles within groups claiming to use an Agile methodology as there is between groups that do and don't pay lip service to Agile.

Quite possibly. My only real experience with it is my current job so I can't undertake any comparative analysis. (We tried to implement it at my last job but did a poor job of it.)

It certainly isn't a one-size-fits-all thing, so I don't mean to suggest it is a good thing for all projects in all organizations.

From: