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

71–80 of 112 posts

Re: Cargo Cult Agile (2008)

#71

Post by humanrebar »

fiftyacorn wrote: post #38
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 dont think its "under-estimating" as much as to get buy-in in a corporate environment means promising to over-deliver Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack

> Architects/Developers can also be their own worst enemy - chosing a new stack over the existing stack

Or doubling down on existing tech (and technical debt) instead of keeping their options open.

One of the problems with agile development processes is that they're not paired with agile design principles.

Re: Cargo Cult Agile (2008)

#72

Post by humanrebar »

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…

> asynchronous stand ups in a chat client

I've been thinking this is actually the perfect standup. People don't tend to write novels in chat clients anyway (and to the extent they do, you can move the text to a README or wiki and just link it).

Does anyone have any experience with this? Any pros and cons worth mentioning?

Re: Cargo Cult Agile (2008)

#73

Post by eru »

struppi wrote: post #34
solatic wrote: post #31

Earlier quoted context omitted.

> Never give up mentioning problems I've tried this strategy, but it just comes off as whining. People's reactions tend to be "we all know that's a problem, but what's the fix? None of us have any power to apply any fixes." The essential strategy to make a company more agile is to a) spend some time at the bottom, to understand how daily processes aren't agile and are broken up by the organization's silos, b) explain…

Thanks for your insightful reply! b) works only when you are even allowed to talk to the exectuives ;) That's why I said it's more frustrating in larger companies...

I always talk to everybody. But then, I've only ever been an employee, not a consultant, and I picked my employers accordingly.

Re: Cargo Cult Agile (2008)

#74

Post by struppi »

ryanmarsh wrote: post #65
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…

Awesome explanation! I have to think about this organism / selection idea a bit more.

It's amazing how much I have learned and how many different perspectives people have told me since I first gave that talk...

Re: Cargo Cult Agile (2008)

#75

Post by humanrebar »

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 outside the scope of Agile (and standups).

The bulk of the info in the yesterday-today-blockers standup is to let the manager get a quick rundown of what the employees are up to. It's a management tool, basically. And that info is all duplicated (if you're doing it correctly) in the agile board, the burndown chart, and in the version control system. So management could just create better queries and dashboards on top of existing data and get the same information.

Re: Cargo Cult Agile (2008)

#76

Post by eru »

solatic wrote: post #31
struppi wrote: post #15

Earlier quoted context omitted.

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…

> Never give up mentioning problems I've tried this strategy, but it just comes off as whining. People's reactions tend to be "we all know that's a problem, but what's the fix? None of us have any power to apply any fixes." The essential strategy to make a company more agile is to a) spend some time at the bottom, to understand how daily processes aren't agile and are broken up by the organization's silos, b) explain…

> I've tried this strategy, but it just comes off as whining.

It helps to deliver some good results first. People take you and your opinions more seriously after.

Re: Cargo Cult Agile (2008)

#77

Post by stiva »

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…

> I'd argue that having a 'war chest' is actually detrimental to agility [...]

I believe that's what the parent is saying as well. I read it as saying that larger companies with a 'war chest' are able to weather the problems caused by reacting more slowly, and so agility is not as highly prioritized, while smaller, newer companies have to react quickly or die.

Re: Cargo Cult Agile (2008)

#78

Post by eru »

UK-AL wrote: post #51
flukus wrote: post #23

Earlier quoted context omitted.

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

The reason for technical debt is the process. If you have a very waterfall like process like at a lot of large companies, everything has to go through change control. Every change has to have business case, and becomes very bureaucratic. As a result no one proposes any changes to fix technical debt. You can do it under the radar by attaching it to existing tasks, but these companies tend to be so project manager driv…

Add to that putting projects into 'maintenance' mode once they are 'delivered'. Ie no manpower to do any improvements, and even barely an bugfixes---even though lots of new downstream projects depend on it.

Re: Cargo Cult Agile (2008)

#79

Post by dasmoth »

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

> asynchronous stand ups in a chat client I've been thinking this is actually the perfect standup. People don't tend to write novels in chat clients anyway (and to the extent they do, you can move the text to a README or wiki and just link it). Does anyone have any experience with this? Any pros and cons worth mentioning?

I pushed http://geekbot.io/ as an alternative for physical standups at my current place -- it's been generally well received, and when I've used it on short projects (that were set up a way that needed daily sync-ups) I found it pretty helpful, and much less intrusive than a physical standup.

Still prefer to have things structured in a more coarse-grained manner, though.

Re: Cargo Cult Agile (2008)

#80

Post by maxxxxx »

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…

That's what turned me away from Scrum. When you do something really difficult you end up reporting the same thing for weeks. Or you feel you shouldn't even try something difficult because you can't break down into little daily chunks.

I prefer my people solve difficult problems and not just little bite-sized tasks that only touch the surface of the system.

Post reply on HN