Live data from Hacker News

Cargo Cult Agile (2008)

jamesshore.com

41–50 of 112 posts

Re: Cargo Cult Agile (2008)

#41

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 have definitely lived through #1. I started out at a "web agency for marketing agencies". Most of the time the actual client never knew we existed. Budget and features were set up front and the deadline was immovable as other forms of media would be directing to our apps/webpages starting on a specific date.

Despite all of that we called ourselves agile. This amounted to pretending to be agile for 90% of the project and then as the deadline approached just staying up late/working weekends to make sure it was complete and out the door. Naturally it was worse when we had competing deadlines between different projects. And when do different clients ever have deadlines that fit nicely in between other clients?

Being at a "product company", it is much easier to be agile about stuff where features and/or deadlines can be shifted

Re: Cargo Cult Agile (2008)

#42
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?

[deleted]

Re: Cargo Cult Agile (2008)

#43
post #29

Earlier quoted context omitted.

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.

especially as the team and code grow there's little reason for standups, nobody cares about what most of the other people tells anyway unless they're effected in their goals.

much better to have a team leader who knows the tasks for everyone and warn people when they are operating an area where they can step on each other toes, so that they know they need to coordinate.

the Nx(N-1) rigid reporting structure of stand up makes very little sense

Re: Cargo Cult Agile (2008)

#44
I don't see value in stand ups most of the time and usually they just get in the way of your work e.g. "I'll start this feature in 30 mins because we've got a standup in 10 mins". I already know what most people are doing from either group chat or the planning board, and a lot of details won't have much relevance to everyone so you end up zoning out just like you would in typical bad meetings.

The "what did you do yesterday?" part can also encourage people to scramble to justify they worked hard enough yesterday when it's tricky to condense why a task isn't as trivial as it sounds.

What did you do yesterday? What are you doing today? What is getting in your way? That's exactly what planning boards are for! Create a Slack bot which automatically summarises and posts this for each team member every day if you really must.

Planning boards are great though. They give you an overview of what everyone is up to, what progress is being made and they're little effort to keep up-to-date compared to having to reply to lots of emails about "what's going on?".

Re: Cargo Cult Agile (2008)

#45
I think the article is correct. Agile has valid motivations and solves concrete problems.

But in practice, you will eventually see confirmation bias and cargo cult.

The motto of delivering customer value has been used as an excuse to emphasize the surfaces exposed to the customer (e.g: features) and neglect non-features (non-functional requirements, e.g: maintainability, security, performance, scalability, configuration, testing).

Re: Cargo Cult Agile (2008)

#46

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

I'd change the labels a little, since I think those terms are overloaded:

I think 'authority' is 'agency', or 'self-determination',

'accountability' is 'direction'/'awareness'/'sensitivity'/'comprehension',

'Responsibility' is actually 'motivation': It also might matter if this is 'pride', or 'avoiding blame', and to what degree it is 'reactive' and 'proactive'. Obviously, knowing what you are responsible for, and having every are have a point of responsibility is important too; 'accountability' seems similar to this to me.

Re: Cargo Cult Agile (2008)

#47
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

That too.

However most of us tend to be overtly optimistic about the possibility that something will work as expected. Also we tend to forget the secondary tasks involved[3].

Also the fact that there is usually an expected schedule/due-date that are presented before being asked for estimates, people tend to invariably try to fit the effort-estimate into the pre-determined schedule subconsciously neglecting the secondary tasks.

Its like when asked if i can cook a turkey-dinner in 2hours, i say - "looks do-able, i can try...". Completely forgetting the fact that i am being expected to raise it from an egg, and take care of it for a few months first.

[3] Slide 8 - https://www.slideshare.net/cvs26/effort-estimation-73647698/...

Re: Cargo Cult Agile (2008)

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

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-flavoured setups being anything other than intrusive.

[1] https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...

Re: Cargo Cult Agile (2008)

#49

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…

For #1, I'd say a dedication to Agile requires significant business commitment on the contractual side to ensuring there basically ARE no commitments beyond the backlog/stories. Needless to say, some clients can't handle this and you need to to turn business away.

There are agencies that act this way like Tribalscale or Pivotal Labs, both of which are pretty dedicated XP shops but also with significant design and product capabilities.

Re: Cargo Cult Agile (2008)

#50

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…

Yes. The funny thing is that at a company I worked for in the 90ies, we were very agile, before that became a thing, and it was GREAT. Empowering, fun, engineering-driven, effective, efficient. The things we did with our tiny team were amazing. When I read about XP, what I read very much resonated with what we were doing, without ever having a name for it other than "what we do and like that works well". However, whe…

The issue is that "agile" was a descriptive word, used relatively loosely. Then some people tried to capture its essence and artificially engineer it into their process, and it became prescriptive.

Some things are better left to occur organically. If you want to be "agile," then reevaluate your corporate culture and create an environment where it might occur. It needs to be you, you can't fake it, much to the chagrin of some of the more uncharismatic business types.

Post reply on HN