Is Agile supposed to be so cultish?

In My Humble Opinion
1

So we’re moving to Agile development methodologies here at work, and to me, the amount of evangelism and cheerleading and what-not seem to verge on the cultish. Like, if I get into an “Agile mindset” and start following Agile practices, everything will be awesome, my farts will smell like lilacs, food will always taste good, projects will always be on time, bosses will always be reasonable, etc…

And it pretty much immediately makes me very skeptical and resistant. Not because of what they’re saying, but how they’re going about it. I mean, the Agile stuff makes good sense, but the whole “Drink the Kool-Aid- it’s good!” approach is seriously turning me off by pushing every “this is a cult… stay away!” button, even though I know it’s not even a religious thing.

Is it just me? Am I misinterpreting this, or is this something anyone else has noticed?

2

No. It’s a tool for accomplishing a job. And like a lot of tools, credulous managers sometimes think that bashing every problem over the head with it will somehow make things work.

3

Similar to ITIL, I’d wager. Somebody piled up a bunch of the improvements to running IT shops that have come up in the past 30 years, slapped a name and/or acronym on it, and copyrighted it. Kind of like Taco Bell reassembling their seven ingredients in a new, exciting way.

4

I hear you, bump. Like so many good ideas it has been over-hyped to get people to switch. I find some of the mixed metaphors smirk-worthy (story points, epics, etc.) but it really is a better process for getting things done, at least with software development. However, it won’t make your coffee taste any better.

5

Agile is a reaction to what came before it – project plans devised well in advance based on barely-understood requirements that, faithfully executed, will produce software that meets no one’s needs. If you consider it as simply being “not that”, it’s an entirely reasonable thing. Accepting the reality that clients are not going to be able to deliver complete and unchanging requirements in advance, and not having expensive developers sitting on their hands until they do, is entirely sensible.

Of course, it is also a project management buzzword, and is treated as such.

6

Yes, most management “philosophies” or techniques take a small dose of common sense, attach fancy titles and words, and use it as a hammer as if everything was a nail.

As one management consultant once told us, this results in front line workers reacting to each new management push in turn as “BOHICA”
(BOHICA = Bend Over Here It Comes Again)

7

My current boss keeps saying how our team needs to be “Agile!” None of us, including the boss, really have any idea what the Agile process is all about. It’s just some magic word management likes to invoke.

It’s the same with a lot of business fads, diet fads, self-help fads, whatever. Instead of saying, “there are some good ideas here; let’s do some hard thinking and implement these concepts in a way that works for us”, it’s so much easier to say, “do what this book says!” And some celebrity CEO like Jack Welch says how great the newest fad is, and all the suits nod and decide they can be like Jack if they follow these easy steps. Maybe there are a lot of good ideas in the Agile methodology. I have no idea. And by the time my team has figured it out and built it into our work, we’ll be on to some other thing. Maybe the Gift of the Goose will make a comeback. Those posters were pretty.

8

Since the OP is asking for opinions, let’s move this to IMHO.

Colibri
General Questions Moderator

9

I agree with that. My company went agile about a year and a half ago, and, like the OP, we had a lot of culty rah-rah stuff. I think it was mostly to get us all stoked about the move, but we also had plenty of people who’d worked in Agile shops before who were telling is “it really is better” in a calm and non-cultish way, so it worked out.

Having successfully worked through an Agile transition, I can tell you - it’s a SHITLOAD of work, and you need support and training from the CEO on down to the lowest person on the totem pole. I, too, have heard stories of places that tout agile but don’t really do it. It’s more than just meeting every day and saying you’re in a sprint; our entire organizational structure changed, work methodologies changed, releases changed, communication up and down the hierarchy changed. If everyone is not 100% on board with that, don’t even try.

10

The thing about Agile, is that you get three kinds of people that implement it.

You get the kind of people that say “Hey, Agile! Yea, we’re going to do that, except we’re not going to maintain a backlog or do sprint reviews or have standups. You know, adapt it to our needs!” These kind of people will ignore any process and it shows.

Then you have the people that go “Agile means you WILL have a sprint exactly this long, you WILL accomplish this many points per sprint, you WILL fill out every tedious bit of documentation however worthless, and you WILL fit with the project schedule that was planned out before you ever heard of the project”. These kind of people have one process, they just call it different things.

Then you have the people that really implement Agile appropriately for their organization and their needs. If you are lucky enough to have this, it’s glorious. Just the right amount of process to keep you from going off track, but not so much that it interferes with your workday.

Unfortunately, the success of group 3 makes groups 1 and 2 try all the harder to do things “their way”. If you’re having a consultant come in to teach you agile, you’re stuck in group 2. Sorry :frowning:

11

How the hell do organizations transition to Agile without someone coming in to train people in the methodology? It’s not like we jumped out of the womb knowing Agile.

My place had a couple Agile consultants. I mean “coaches”. Whatever. But basically they assisted in the transition, taught us all what the basics of Agile are, and were around to answer questions. We still have one “coach” around, but I rarely see/hear of him.

We’re not at all groups 1 or 2. I wouldn’t say Agile is perfect, but it’s a hell of a lot better than any other methodology I’ve tried.

12

Agile: do the same stupid shit you’ve been doing but in smaller, quicker increments.

13

Read the manifesto? It’s not like it’s some 1000 word tome that is only written in Sanskrit.

The places I know that implemented agile the best did not use consultants. We figured it out for ourselves. The places where it was shitastic had high-priced consultants in to do multi-day training. YMMV.

14

Agile has it’s place but waterfall does as well.
Telecom uses a lot of waterfall because the demands the FCC puts on telecom providers means that downtime is more or less verboten and therefor there are only a handful of carefully planned out releases a year if for systems that impact the operation of the network.
Systems like ordering and billing are far more adaptable to an agile methodology because frankly if the billing system goes down for 3 hours it’s not the end of the world - if the phones go off for 3 hours the FCC tends to get grumpy.

15

How big were those places?

My company was close to 100 people in the development department (devs/QA/Product managers/etc) and they transitioned the entire place to Agile at the same time. Ended up with something like 10 teams. I have no idea how we would have done it without someone training/coaching/coordinating.

10 or 20 people? Yeah, I can see “read the manifesto and figure it out”. Not with 100 people, though.

16

The total number of people doesn’t make a difference. Each team should be doing things somewhat differently anyway (unless your teams are extraordinarily homogeneous).

17

All the teams do the Agile thing things differently. I think the total number of people does make a difference. We couldn’t afford to have the entire organization come to a halt while everybody was trying to figure out the whole Agile thing, even if it were just for a week or two.

18

Actually, no.

The same stupid shit we had all been doing was waterfall. Develop the code, test it, send it to the test group, and then, after many months of development, the test group decides they don’t like the way part of it works, and months of work is wasted as we redesign and re-implement that part.

The one thing agile does well is it gets buy-in from everyone at every step along the way. So now the testers have to say whether they like the way it works or not during the sprint when the user interface is hammered out. They can’t just kick it back at the end and say they don’t like it now.

It may not work for everyone, but it really fixed a lot of things that our company was doing very poorly.

I was extremely skeptical of agile at first. I thought it was just another buzz-word bullshit thing but once I really got into it I found out that there are some good ideas in it. You do have to apply it properly to what you are doing, though.

We had a couple of consultants come in. They trained us for a few days, then came back about a month later to help us fix the kinks in how we implemented it. The outside consultants were essential for us because they prevented some folks from doing their own interpretation of what agile was and screwing things up, and also forced buy-in for the new methodology from everyone. If we had just done it in-house then other groups could have just said they didn’t like what we were doing and we were doing it wrong etc. and could have chosen not to implement it properly.

The consultants we hired were pretty good. There is a bit of a different mindset that you have to get into for agile to work, but they weren’t at all cultish or cheerleaderish about it.

You can’t just go “Agile! Woo hoo!” either. You have to recognize how it helps and when it won’t. I, for example, do mostly embedded design and programming, and while agile has done wonders for the rest of our product, it doesn’t really work well for embedded code where each step of the development takes significantly longer than a typical agile sprint.

ETA: Our division has about a hundred people in it. About 30 of those are involved in coding.

19

Agile isn’t supposed to be cultish, but some of the methods and frameworks used for it certainly can be. Scrum, for example, originally had roles based on a fable about chickens and pigs, and there’s the whole standing-up-meeting thing where everyone answers the Three Questions.

20

The problem is that you can’t really understand agile until you’ve built a tower out of spaghetti and marshmallows.