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

21–30 of 112 posts

Re: Cargo Cult Agile (2008)

#21

Post by PJDK »

flukus wrote: post #3

I'd argue stand up meetings are the opposite of agile, the insistence on them is literally breaking the first rule of the agile manifesto: > Individuals and interactions over processes and tools Probably breaking the fourth too: > Responding to change over following a plan How many companies have done a retrospective on whether the daily recitation of Kanban board movements​ is providing any value?

We've talked about the stand up a few times in retros. We've mixed it up a few times (we now do a task based stand up rather than a person based one) but always felt it was more valuable than not having it.

Re: Cargo Cult Agile (2008)

#22

Post by Nursie »

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 the meeting for "management announcements". I've seen it go wrong when one team member cannot shut up and regularly took over the whole meeting (yes, the scrum master was ineffectual). But in general I've found the daily rapid-fire catchup a thing of beauty.

The rest I can take or leave. One of the worst projects I've ever observed had a highly paid SCRUM Master/Consultant/Trainer and that team seemed to spend several hours each day on process. They failed to deliver anything, ever, the product was scrapped and everyone was laid off, including the development manager.

Re: Cargo Cult Agile (2008)

#23

Post by flukus »

isoos wrote: post #11
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…

This matches my experience, although I was lucky that I stopped doing "Agile transitions" gigs early enough. My question is: how do you discuss this with a customer? At one point I had a talk with a director of a smaller bank, and he was enthusiastic to bring me on board, even wanted to pay me just to spend my workday in the office doing nothing specifically. I declined, because it was a lost cause: their team was to…

> their estimate for a very minor change added up to several months...

It sounds like they had an issue with technical debt (and that had led to a lack of trust from the rest of the company) and thought they could fix it with a process, correct? I don't think you can help someone that won't recognise the root cause.

Re: Cargo Cult Agile (2008)

#24

Post by adrianmsmith »

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).

So if you had a requirements sprint, a software architecture sprint, a development sprint, then that gets tested on the next sprint, what process does that remind you of? :)

Re: Cargo Cult Agile (2008)

#25

Post by flukus »

Swizec wrote: post #9
flukus wrote: post #3

I'd argue stand up meetings are the opposite of agile, the insistence on them is literally breaking the first rule of the agile manifesto: > Individuals and interactions over processes and tools Probably breaking the fourth too: > Responding to change over following a plan How many companies have done a retrospective on whether the daily recitation of Kanban board movements​ is providing any value?

> I'd argue stand up meetings are the opposite of agile Those 15min when the team gets together and talks about what they're doing and where they need help ... that's the most useful meeting I've ever been a part of. 80% of all other interactions could be removed with a kanban board and some patience. Like, shit man, sometimes it takes me more than 3 minutes to reply on Slack because I'm doing shit. Go do some stretc…

> Those 15min when the team gets together and talks about what they're doing and where they need help ... that's the most useful meeting I've ever been a part of. 80% of all other interactions could be removed with a kanban board and some patience.

For me it's almost always a waste of 15 minutes. I get to hear 8 people mention what they're up to even though only 1 or 2 (on a good day) will be having any impact on what I'm working on. Of those 2 it's generally more effective to send an email or update the issue so I don't forget about it 5 minutes later.

Re: Cargo Cult Agile (2008)

#26

Post by _betty_ »

danpalmer wrote: post #12

Agile is the only word I know that inverts its meaning when you capitalise it. The team I work in is fairly agile, in that we communicate well, react to changing priorities very quickly, and ship things regularly. We're not perfect by any means, but whenever we consider adding more of the typical "Agile" process we always realise it would slow us down, and we see other companies with more set "Agile" processes being…

I typically find the same about Software Architect vs software architect - eg the Job Title vs the activity that decent developers do.

Re: Cargo Cult Agile (2008)

#27

Post by jaggederest »

tomelders wrote: post #16

I could wax lyrical about Agile all day long. If you google 'Agile Bullshit', a comment I wrote on HN a few years ago is usually in the top three results, and because of that I get an email once a month from someone driven to despair by said 'Agile Bullshit' who feels compelled to get in touch with me and vent a little. I enjoy the emails, and I think they've given me a much broader perspective on agile than my own e…

> Agile can never work in an agency, where the client has control over budgets, deadlines, and features. There is simply no incentive for the client to compromise when your agency has made some pretty ridiculous promises and put themselves on the hook to deliver.

There's an interesting triad that I've been talking to people about a lot recently.

1. Authority (the ability to make decisions of importance)

2. Accountability (a way of telling if you are doing better or worse)

3. Responsibility (pride and reward proportional to the results you deliver)

Essentially when you lack any of those three, you cannot operate effectively.

Without accountability, you have no way of knowing what success is. Without authority, you have no power to recruit help or make the necessary changes to be successful, and without responsibility, no amount of accountability or authority matters.

This is especially true in asymmetrical relationships like customer-vendor and employee-employer.

Re: Cargo Cult Agile (2008)

#28

Post by flukus »

tomelders wrote: post #16

I could wax lyrical about Agile all day long. If you google 'Agile Bullshit', a comment I wrote on HN a few years ago is usually in the top three results, and because of that I get an email once a month from someone driven to despair by said 'Agile Bullshit' who feels compelled to get in touch with me and vent a little. I enjoy the emails, and I think they've given me a much broader perspective on agile than my own e…

I'd go a step further and say that agencies can never work, at least past the small project or website level. The customer is oblivious to the maintenance required for a software project (even if it's just maintaining developer familiarity with the code base) and the agency can only ever get them to pay for features.

Re: Cargo Cult Agile (2008)

#29

Post by flukus »

mikekchar wrote: post #19
jwdunne wrote: post #8

Earlier quoted context omitted.

To me, a lot of Agile breaks the first rule. A Certified SCRUM Master comes in and overhauls your processes. That is, in effect, processes and tools straight up, from the minute that scrum master goes on a course. It wouldn't be much of a course if it didn't teach some process for implementing SCRUM. It wouldn't be much of a consultation if the consultant tells you to go speak to your customers and find out what is r…

I think you have the same misconception about the first rule that many people do (forgive me if I'm wrong). > Individuals and interactions over processes and tools This does not mean that you minimise process and tools. This means that individuals and interactions trump processes and tools. So if you have a process that doesn't fit the people on your team, then you change the process, not the team. Similarly, you try…

> But it's a mistake to think that you want to remove process.

It's also a mistake to keep a process that isn't delivering any benefit though. I've seen very few stand-ups that provided a benefit and zero where there was no other way to get the same benefit.

Re: Cargo Cult Agile (2008)

#30

Post by flukus »

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…

> 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.

Don't you have a kanban board or equivalent where you can see what everyone's been up to and what their upcoming tasks are? Do you need to know what's holding them up if it's not you?

For those of us complaining, it's not that we don't see the value, we just see other, arguably better ways to get the same value.

Post reply on HN