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

31–40 of 112 posts

Re: Cargo Cult Agile (2008)

#31

Post by solatic »

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…

> 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 how the organization isn't agile to executives, until finally c) you and the executives talk to middle management together and start to take on the middle-management fiefdoms.

The very good reason why Agile requires C-level support is because it often involves reorganization or firings at the middle-management level. You're never going to get anywhere complaining to people on lower levels, or to middle management, which is typically against changes to organizational structure. If the executives aren't on board ("we can never change that in this company"), leave and find another company.

Re: Cargo Cult Agile (2008)

#32

Post by mpweiher »

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…

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, whenever I've seen Agile applied at other companies, it was horrible. And yet they refer to the same words. Someone recently told me "Agile/XP/etc. sound like slaves trying to figure out better ways to please their masters". And when I take that frame of reference, yep, that is exactly what it sounds like.

So something weird is going on with those words.

Re: Cargo Cult Agile (2008)

#33

Post by cvs268 »

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

Re: Cargo Cult Agile (2008)

#34

Post by struppi »

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…

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

Re: Cargo Cult Agile (2008)

#35

Post by liamt »

zer0tonin wrote: post #2

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

I've been there. Now we do scrum and do standup meetings but it's a lot less strict. Most of the team talks constantly anyway as we're all in the same room.

Our old boss is long gone.

Re: Cargo Cult Agile (2008)

#36

Post by seanwilson »

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…

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

Yes, I've worked at places where they'd accept fixed budget and short timescale projects while also preaching about the benefits of agile to the client. This meant there was minimal upfront design and the customer was given a chance to change their mind often. This lead to crunch time and having to make changes that could have easily been predicted if planning had been done from the start. If you suggested the latter advice though, you'd be accused of being a "waterfall" practitioner and ignored so it felt very cargo cult.

My view is that projects with short time scales where it's predictable early on what all the functionality should be, you should plan out as much as you can from the start and get the client to OK as much as you can early on (e.g. with mockups, interactive prototypes). Agile is more suitable for larger projects with flexible budgets where there are so many unknowns that planning ahead isn't productive.

Re: Cargo Cult Agile (2008)

#37

Post by LoSboccacc »

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…

I used to work at a megacorp that pretended having stand up meeting seated was working agile.

I just nodded, cashed the paycheck and still did great work. some battles I won, like moving a whole team to continuous integration or removing most of the manual busywork in testing, sometimes I just let bad stuff go because you can't always win and instead aimed for the second best option: dodge.

Re: Cargo Cult Agile (2008)

#38

Post by fiftyacorn »

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

Re: Cargo Cult Agile (2008)

#39

Post by jwdunne »

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…

I think process is important. If there isn't some kind of method or process, it isn't really engineering. You can't build modern bridge or building just by going at it.

My comment wasn't clear: scrum is sold the majority of the time as a whole new process and it's seen that way by most, from the minute they do the training.

I've read the scrum book and to me it seems like a process that helps develop your own process. I think that's a fantastic idea.

The problem I'm talking about is that 90% of scrum masters and companies moving to scrum, well, are moving to scrum, as though it's a whole new process as opposed to organically developing new effective processes that fit the company like a glove.

On a smoke break, I heard about a company "doing agile" that's now moving "back to waterfall" after laying off 2/3rds of their team. Another big blue chip I work with also got shafted in a big way by a consulting company that tried "moving them to agile".

What you do is a world apart from what most people attempt and it's the latter that devastates.

Re: Cargo Cult Agile (2008)

#40

Post by _pmf_ »

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.
Post reply on HN