Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cargo Cult Agile (2008)

jamesshore.com

Post reply on HN
Print view View original

81–90 of 112 posts

Re: Cargo Cult Agile (2008)

#81

Post by Nursie »

humanrebar wrote: post #75
Nursie wrote: 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…

> ...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. Peer-to-peer, listing blockers is more or less the only thing that matters, followed distantly by making sure we're not stepping on each other (deploying the same thing, refactoring the same class). It's also important to sync up that designs are good and work together, but that's out…

We've run the standups like that with no management involvement at all in some places. I still find them useful as they allow people to resolve dependencies a schedule work appropriately.

Those other tools have a tendency to get ignored, get out of sync, out of date and add overhead.

Re: Cargo Cult Agile (2008)

#82

Post by Sharlin »

adrianmsmith wrote: post #24
zer0tonin wrote: post #2

I should explain that to my boss, we're literally doing waterfall but with standup meetings...

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.

Re: Cargo Cult Agile (2008)

#83

Post by jwdunne »

Underqualified wrote: post #61
dasmoth wrote: post #48

Earlier quoted context omitted.

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…

Micromanagement is indeed what it looked like to me with all the daily stand ups (what did you do yesterday), review meetings (what did you do last week ?), scoring (what do you mean it would take you longer than that other developer to finish something ?) and sprints (we HAVE to do this THIS WEEK).

That's certainly what it can be used for and probably is on a large scale.

The most important one that a lot seem to miss is the "did you face any road blocks?", with a culture where the whole team thinks and removes the roadblock such that it is removed for everybody for good.

Morphine is a pretty damn good painkiller. Unfortunately, it is extremely easy to abuse to the point where there are more people abuse it than people who genuinely benefit from it.

On a larger scale, communism as it was originally conceived sounds like a utopia. Unfortunately, the only thing that's actually happened is an abuse that takes anything from democracy to authoritarian regimes well towards totalitarianism, the anti-thesis of communism.

Scrum and agile is the same in that respect. Sounds great. Works well on paper but very rarely used correctly or with the original intention.

Re: Cargo Cult Agile (2008)

#84

Post by humanrebar »

Nursie wrote: post #81
humanrebar wrote: post #75

Earlier quoted context omitted.

> ...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. Peer-to-peer, listing blockers is more or less the only thing that matters, followed distantly by making sure we're not stepping on each other (deploying the same thing, refactoring the same class). It's also important to sync up that designs are good and work together, but that's out…

We've run the standups like that with no management involvement at all in some places. I still find them useful as they allow people to resolve dependencies a schedule work appropriately. Those other tools have a tendency to get ignored, get out of sync, out of date and add overhead.

> Those other tools have a tendency to get ignored...

That's basically my point. Managers should home their craft and improve their tools instead of molding the people around them to meet the needs of middle management.

Re: Cargo Cult Agile (2008)

#85

Post by rhapsodic »

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.

Re: Cargo Cult Agile (2008)

#86

Post by Nursie »

humanrebar wrote: post #84
Nursie wrote: post #81

Earlier quoted context omitted.

We've run the standups like that with no management involvement at all in some places. I still find them useful as they allow people to resolve dependencies a schedule work appropriately. Those other tools have a tendency to get ignored, get out of sync, out of date and add overhead.

> Those other tools have a tendency to get ignored... That's basically my point. Managers should home their craft and improve their tools instead of molding the people around them to meet the needs of middle management.

Well, I'm not sure that the daily standups have always been about that, and as a developer I've found them useful.

Re: Cargo Cult Agile (2008)

#87

Post by overgard »

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 your top performers.

Re: Cargo Cult Agile (2008)

#88

Post by exelius »

struppi wrote: 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…

Actually (and I do this for a living as a management consultant) we are pushing all of our clients to an Agile operating model. There are many reasons for this, but the primary one being that consumers now expect to interact with all companies like CPGs.

Agile lends itself very well to a top-down brands-and-products hierarchy. You build the core of the products in a shared engineering group (again, just like most CPGs) then apply localized branding and product focus as needed.

And here's the thing: adopting Agile in the corporate world is less about "reacting quickly" (though that is one of the benefits, at least in comparison to the legacy methods) but really more about cost control. Agile is simply cheaper because you're not building shit that nobody wants. If you can build an Agile culture of "if it's not in the backlog that was approved by product and reviewed every couple weeks, you don't build it" you cut down on a lot of pet projects, deprecated features and duplication of effort.

Is there still duplication? Sure; but often times companies will have 5 groups build the same thing and they just choose the one that gets the most internal traction. That's actually a viable strategy when you don't know the product you need to build, but you need it to work. It also tends to help find the right "home" within the organization politically (i.e. the people who really need said functionality will build it, use it, make it popular, and then get the money to maintain it while fringe users lose funding and migrate to the shared platform).

The key thing is that the engineers aren't in control. And with good reason; engineers are paid to build products, product managers are paid to design products and brand managers are paid to build portfolios of interrelated products. You cannot run a large company without this kind of P&L discipline.

Re: Cargo Cult Agile (2008)

#89

Post by huherto »

rhapsodic wrote: post #85

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 the most critical factor in the success or failure of a software development project is the skill and dedication of the developers.

And yet. It is part of the agile principles.

#9 Continuous attention to technical excellence and good design enhances agility.

I am shocked to see how the agile principles are ignored by "Agile Coaches".

https://www.agilealliance.org/agile101/12-principles-behind-...

Re: Cargo Cult Agile (2008)

#90

Post by shanemhansen »

overgard wrote: post #87

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…

> bringing the low performers up to average, but at the cost of handcuffing your top performers.

Sounds about right. If you view humans as interchangeable resources then predictable performance is good. Most businesses don't need or benefit from a Linus Torvalds to build their CRUD app.

Post reply on HN