Live data from Hacker News

Cargo Cult Agile (2008)

jamesshore.com

91–100 of 112 posts

Re: Cargo Cult Agile (2008)

#91

This is anecdotal, but I've found that the more "agile" a place is, the more underworked I am. In most non-agile places, if im out of work its up to me to find a way to make myself useful (agency!), but in agile environments I usually am told not to take something on because "it wont fit in the sprint". I generally think agiles main benefit is bringing the low performers up to average, but at the cost of handcuffing…

When I worked with a bigger agile group one of the things I liked was having a task list put together and then divided up among everyone but also having an 'on-deck' group for stuff we didn't think we'd have time for. Anyone who got things done faster would have their pick of the on deck work and was some extra freedom and recognition for doing so.

Re: Cargo Cult Agile (2008)

#92
post #48

Earlier quoted context omitted.

One of the reasons SCRUM wasn't very popular in our team was that we realized it meant having a lot more meetings than we were having before. I think if you go by the numbers, standard scrum has you spending nearly 20% in your time in developer meetings. Stand ups didn't really work for us either as we are doing our own thing most of the time, so there is little to coordinate, and when there is a need, we usually jus…

Capital-A-Agile puts a lot of emphasis on very fine-grained collaboration and reducing the amount of time people are "doing their own thing". Some advocates are pretty open about this being a form of micromanagement[1]. Some people thrive in high-visibility, fine-grained-collaboration environments. On the other hand, if you've got people who are already doing good work without many meetings, it's hard to see Scrum-fl…

That blog post is really odd. It's like "sure you're being micromanaged, but its by a mob instead of a tyrant", as though thats a comforting thing. How is that better?! You cant just throw the word "team" in there and pretend it makes things ok.

Re: Cargo Cult Agile (2008)

#93

I think the most critical factor in the success or failure of a software development project is the skill and dedication of the developers. Yet I never seem to hear or "Agile Coaches" mention that. I guess clients would not be receptive if someone were to tell them that their best course of action was to replace half of their team.

I think this is why agile is, frankly, so insulting. I went to a good university for four years to learn computer science, a field that is legitimately hard. I produce real business value daily. And yet this methodology places about as much trust in me as a mcdonalds worker.

Re: Cargo Cult Agile (2008)

#94
post #59

I have yet to see an implementation of "Agile" that's not a cargo cult pretext for micromanagement.

Some advocates are pretty open about this: https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-all-about-micromanaging Interesting question is -- why is micromanagement by "the team" more palatable to some (many?) people?

It is an interesting question. I suspect its palatable because it evens the playing field. The game changes from skills based to politics based, and that suits some people better.

Re: Cargo Cult Agile (2008)

#95

This is anecdotal, but I've found that the more "agile" a place is, the more underworked I am. In most non-agile places, if im out of work its up to me to find a way to make myself useful (agency!), but in agile environments I usually am told not to take something on because "it wont fit in the sprint". I generally think agiles main benefit is bringing the low performers up to average, but at the cost of handcuffing…

Ugh, I deal with this, too. "It won't fit in to the current sprint." Who cares? Nothing bad is going to happen! I just take them anyway and take people to task to explain why this is a worse situation than my salary burning up while I do nothing instead.

Re: Cargo Cult Agile (2008)

#96
post #82

Earlier quoted context omitted.

Great stuff. I asked one Agile coach about how and when one should do software architecture decisions for a larger project, he said you can take an extra sprint/spike at the start to do software architecture if necessary. At another place, the testing members of the team always tested the previous sprint's work (otherwise they'd be doing nothing for the first 80% of the sprint, if they tested that sprint's software).…

That is still iteration. Agile doesn't say you can't do things in phases, it just says those phases need to be short enough that you can iterate on them.

Yea but how done is your sprint if your work isn't tested?

It's the old, "done" vs. "done done" debates we had end of every sprint. I wrote the code, it mostly works, it has bugs. Am I done? Should I move on?

Technical debt creeping higher and higher.

Re: Cargo Cult Agile (2008)

#97
post #22

To echo another comment on here - Daily standups have been the most useful development I've seen in my 17 year career so far, I'm not sure why there's the hate for them. It's a small time allotment where everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up. I've seen them go wrong, when managers decide that they need to attend and use part of…

I had a standup at a 24 person company where every single person (except the CEO of course) had to attend standup and report. That's a long standup, esp. when someones report spirals into a discussion.

Wasn't very agile.

Re: Cargo Cult Agile (2008)

#98
post #55
post #4

I have been thinking about this a lot, ever since I first read this article, some years ago. Most of my freelance projects and technical coaching gigs in the last few years where at companies that were in or after their "Agile transition". And most got "Agile" horribly wrong. I think cargo cult is an issue, but the problem goes deeper. I wrote a conference talk titled "Your Company Will Never Be Agile" around that to…

> Many C-level executives want "true business agility" for their company: They want to be able to react quickly when circumstances change. True, and this isn't a bad goal in and of itself, but what they don't realise is that these 'quick reactions' (aka fundamental low level changes in the product) may require orders of magnitude more work than said executives expect (and in fact, probably the work required is at lea…

"War chest" kind of implies liquid assets of some kind. Code is a highly illiquid asset and even a liability if you have to maintain its existing functionality.

Most of the small companies that are able to pivot easily do have reasonably large war chests in the form of VC funding. If they don't have that kind of funding they won't be able to pivot as easily because they need to worry about maintaining cash flow just to keep the lights on.

Re: Cargo Cult Agile (2008)

#99
post #82

Earlier quoted context omitted.

Great stuff. I asked one Agile coach about how and when one should do software architecture decisions for a larger project, he said you can take an extra sprint/spike at the start to do software architecture if necessary. At another place, the testing members of the team always tested the previous sprint's work (otherwise they'd be doing nothing for the first 80% of the sprint, if they tested that sprint's software).…

That is still iteration. Agile doesn't say you can't do things in phases, it just says those phases need to be short enough that you can iterate on them.

Agile does say the results of sprints should be something the customer can understand and use: a software architecture document, or untested code from the development sprint, isn't that.

Re: Cargo Cult Agile (2008)

#100
post #22

To echo another comment on here - Daily standups have been the most useful development I've seen in my 17 year career so far, I'm not sure why there's the hate for them. It's a small time allotment where everyone gets just a couple of minutes to sum up where they were yesterday, where they're going today and what's holding them up. I've seen them go wrong, when managers decide that they need to attend and use part of…

I had a standup at a 24 person company where every single person (except the CEO of course) had to attend standup and report. That's a long standup, esp. when someones report spirals into a discussion. Wasn't very agile.

Yeah, that sucks, you don't want more than 5 or 6 people in one really.
Post reply on HN