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

61–70 of 112 posts

Re: Cargo Cult Agile (2008)

#61

Post by Underqualified »

dasmoth wrote: post #48
Underqualified wrote: post #17

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…

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

Re: Cargo Cult Agile (2008)

#62

Post by Nursie »

dasmoth wrote: post #58
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…

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. Two things that bother me: 1) You either have to hold them at the start of the working day (in which case they become a synchronization point and everyone has to turn up at the same time -- which will inevitable be a bad time for some people) or a bit later (in which case you end up…

Does the timing matter? We hokd ours in the middle of the day at the moment. Still seems to work (though the discipline is lacking and they often overrun, which I hate)

Re: Cargo Cult Agile (2008)

#63

Post by humanrebar »

taneq wrote: post #55
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…

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

To be fair, many "low level" technical decisions also cost orders of magnitude more than was originally intended.

Not coincidentally, there is rarely strong strategic technical direction at the organization level. Rarely is there accountability (especially for middle management) in making sure that cobol is actually deprecated, those Windows XP boxes are actually powered down, and that gnarly business logic is cleaned up and well-tested.

It's worth noting that typically there's collusion from all levels to create one of those problems. That being said, there's not much an individual contributor can do about massive strategic mistakes other than move to another org. A magical org with great engineers and no major technical debt.

Re: Cargo Cult Agile (2008)

#64

Post by codingmyway »

Microservices seems to be the latest cargo cult technique being pushing without really considering whether the benefits outweigh the costs. Some consultants always need another thing to push that a particular company's problems for them so therefore it must be applied everywhere.

Re: Cargo Cult Agile (2008)

#65

Post by ryanmarsh »

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…

Agile coach here. You nailed it.

One way of looking at these companies is that they're organisms adapted to their environment. If there are weak selection pressures around agility and software delivery in their market "environment" then you can expect that they're well adapted to other pressures (i.e. credit risk, or buying labor at one price and selling it at another).

Often times these businesses might see reasons for agility, opportunities they could take advantage of, still they really aren't feeling selection pressures so there's no real need to change. How they deliver software with really bad agile is "good enough". Well it will be until it isn't and then it might be too late.

So you have all the structures and processes that make one organism good at being a bottom feeder and it's like pushing water up a hill to make them change when they REALLY DONT HAVE TOO.

Every once in a while I have a client where this stuff actually matters to them and we have a lot of fun and make amazing stuff.

Re: Cargo Cult Agile (2008)

#66

Post by dasmoth »

Nursie wrote: post #62
dasmoth wrote: post #58

Earlier quoted context omitted.

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. Two things that bother me: 1) You either have to hold them at the start of the working day (in which case they become a synchronization point and everyone has to turn up at the same time -- which will inevitable be a bad time for some people) or a bit later (in which case you end up…

Does the timing matter? We hokd ours in the middle of the day at the moment. Still seems to work (though the discipline is lacking and they often overrun, which I hate)

It matters if you're trying to preserve some decent chunks of time for focussed work.

And if matters if the standup is scheduled for 9am and you can't drop the kids of and be sure of getting in before 9.10

If everyone goes for lunch at the same time, holding it 10 minutes before lunchtime could be a smart move. But only if you've already got that "everyone eats together" culture.

Re: Cargo Cult Agile (2008)

#67

Post by ryanmarsh »

struppi wrote: post #15
isoos wrote: post #11

Earlier quoted context omitted.

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…

Well, this is very hard. It is more frustrating with bigger companies. In one occasion, where they officially brought me in as an agile coach, I tried to at least achieve some local optimum with the team, because some big improvements were plain impossible. I occasionally talked to managers about all the walls we were constantly hitting, but the answer was always "we can never change that in this company". This did n…

> establish a culture of continuous improvement

This is the thing in agile/technical coaching. Too many people focus on the process and dogma when what's really missing is an organizational habit around continuous improvement.

Re: Cargo Cult Agile (2008)

#68

Post by Nursie »

dasmoth wrote: post #66
Nursie wrote: post #62

Earlier quoted context omitted.

Does the timing matter? We hokd ours in the middle of the day at the moment. Still seems to work (though the discipline is lacking and they often overrun, which I hate)

It matters if you're trying to preserve some decent chunks of time for focussed work. And if matters if the standup is scheduled for 9am and you can't drop the kids of and be sure of getting in before 9.10 If everyone goes for lunch at the same time, holding it 10 minutes before lunchtime could be a smart move. But only if you've already got that "everyone eats together" culture.

We hold ours after lunch. No "everyone eats together culture", unfortunately, but there is now an "everyone finishes lunch by 13.30" culture.

Re: Cargo Cult Agile (2008)

#69

Post by joncampbelldev »

_pmf_ wrote: post #40

Also nice: the joke by Rich Hickey that Agile solving software development via sprints is like someone revolutionizing the marathon by firing a starter pistol every 100 meters.

Thats a good one, from his "Simple made easy" talk[0]

[0] https://www.youtube.com/watch?v=zPT-DuG0UjU

Re: Cargo Cult Agile (2008)

#70

Post by BaronSamedi »

cvs268 wrote: post #33

Based on my personal experience, most projects are doomed from the start due to these 2 MAJOR problems: 1. Not prioritizing the task of gathering, decomposing and documenting use-cases at the project kick-off. 2. Chronically under-estimating effort required. [1] http://thecodeartist.blogspot.com/2015/04/use-case-is-everyt... [2] http://thecodeartist.blogspot.com/2017/04/effort-estimation....

I often see these as well. I would even go so far as to say these problems are the rule rather than the exception. Why is software development still so high risk?

I don't know the answer but it seems to me that software development is much too bespoke. Take a relatively simple case of web store front development. What if the development company said, OK, for your store you can have option A or option B. Period. The developer doesn't gather requirements at all, and all the tools and libraries are known and have been used before. The customer gets to pick a few options like when you buy a car (e.g., say some look&feel options). This is a low risk, predictable, "there's only one way to do it" approach.

I'd like to see software development become vastly more predictable and stable. This will bore some developers who always want to try the latest framework and technology, but novelty adds risk.

Post reply on HN