Live data from Hacker News

Agile Is a Glass Cannon

tomdalling.com

51–60 of 86 posts

Re: Agile Is a Glass Cannon

#51
post #50

Earlier quoted context omitted.

I'm not sure we feel the same but I kinda experienced high anger after seeing my team babble for hours on epics while no information of value was put out clearly and no actual design/planning was produced. Just a bunch of paragraphs in jira. Smells like rot already.

We feel the same. I’m ready to lose my mind.

What I got out of this is that my next job interview I will be harassing every person to know every detail about their workflow and views on how to organize.

ps: have you ever searched about high speed / high perf teams ?

Re: Agile Is a Glass Cannon

#52
post #4

Anyone else notice Agile creeping in where it has no place being? I’m suffering on an infrastructure transformation project — migrating complex apps to Azure — which insists on being Agile. It’s preposterous. I just started and already I’ve counted up 40 person-hours of time in ‘planning’ sessions. I spent two hours in a room with an architect and a whiteboard and then one single day myself on Thursday building a sch…

Yes and no. Yes, the principles of Agile sound nice, but no, I've never seen them done properly. At every company where I've worked, when Agile got adopted, things went downhill

Re: Agile Is a Glass Cannon

#53
“It works when engineers and management are both highly skilled” is hardly a glowing recommendation for a management process. Only a management system so bad that it is tantamount to sabotage would not work when everyone involved is highly skilled. The most productive management system I ever operated under was “the founder DMs ‘how’s it going’ whenever he remembers to” and that worked great because we were all skilled too.

One can imagine a 2x2 grid like so:

        good mgmt    bad mgmt

  good   anything     eng is 
   eng     works        sad

   bad    mgmt is     nothing
   eng      sad        works

Particular management styles don’t really matter in the top left or bottom right square. The most salient criticism of Agile from this perspective is that in the top right square it multiplies bad management’s capacity to make good engineering sad.

Re: Agile Is a Glass Cannon

#54
post #50

Earlier quoted context omitted.

We feel the same. I’m ready to lose my mind.

What I got out of this is that my next job interview I will be harassing every person to know every detail about their workflow and views on how to organize. ps: have you ever searched about high speed / high perf teams ?

Funny, I was just cleaning up dinner thinking how if I was a program manager hiring a bunch of PMs my interview question — which I would advertise ahead of time to weed out the chaff — would be simple.

“Here’s an engineer/architect, a scope statement, and a whiteboard. Show me how you’d create your initial high-level migration plan.”

For organisation, Johnny.Decimal. :-)

Re: Agile Is a Glass Cannon

#55
post #8

> success largely depends on the skill and experience of the individuals involved. Yes. Well sort of. The key insight here is that in software at least, this is a pre-requisite anyhow. If you don't have skilled and/or experienced people, nothing will save you. So you might as well tailor your process around the expectation of a certain amount of skill, because although you can't use process to save you, you can use p…

Young individual without enough skill/experience joins a team and fails miserably. Same individual joins another team and succeeds. Skills and/or experience are _not_ prerequisite for every single individual. You need enough skillful/experienced people to create a process/culture that allows less experienced engineers to join and flourish.

If young individual later flourishes, same individual obviously has some skill (and/or talent).

> for every single individual.

I didn't write "every single individual", and for good reason. Note the story in the second part of my comment...

Re: Agile Is a Glass Cannon

#56
post #54

Earlier quoted context omitted.

What I got out of this is that my next job interview I will be harassing every person to know every detail about their workflow and views on how to organize. ps: have you ever searched about high speed / high perf teams ?

Funny, I was just cleaning up dinner thinking how if I was a program manager hiring a bunch of PMs my interview question — which I would advertise ahead of time to weed out the chaff — would be simple. “Here’s an engineer/architect, a scope statement, and a whiteboard. Show me how you’d create your initial high-level migration plan.” For organisation, Johnny.Decimal. :-)

Interesting question. Migration are key problems.

btw, our messages crossed, so asking here:

have you ever searched about high speed / high perf teams ?

How to metaprogram your team workflow to optimize processes on multiple layers so everything is soft and fluid.

Re: Agile Is a Glass Cannon

#57
post #42

Earlier quoted context omitted.

The problem I have with your question is "agile" seems to mean anything except a pure waterfall development model. Even modified waterfall seems to be described as agile. As a sole developer of a software product, I haven't figured out how the agile principles even apply to me. "Individuals and interactions over processes and tools" doesn't work when there's only one person. "Working software over comprehensive docum…

You, the developer, have one customer: you, the software vendor. The software vendor sells a software product, not the developer.

Next, tell me how many angels can dance on the head of a pin.

Assuming your definition makes sense, what are the "interactions ... processes and tools" between me-the-vendor and me-the-developer?

What is the comprehensive documentation that I'm supposed to avoid?

What is the contract negotiation?

Re: Agile Is a Glass Cannon

#58
post #20

I think it is crazy we are debating Agile more than 20 years after it was coined. After such long time, a successful idea should not need constant debate about its advantages and disadvantages. We should be on the next thing now, post-Agile, whatever that would be.

I think you have that exactly backwards. ONLY successful ideas are being debated more than 20 years after they are proposed. Only successful ideas spawn reaction and counter-reaction, which lead to its evolution - which you say is not happening, but certainly is, as evidenced by the tree of methodologies that branched from it.

In that respect (which might not be the one the coiners hoped for), capital A agile has been extremely successful.

Re: Agile Is a Glass Cannon

#59
post #3

Good article. I think the issue is the often 'higher ups' want 'Agile' as they've heard it is faster and/or cheaper - missing the part that it is faster and cheaper to fail with agile. If you know exactly what you want and are happy to wait, then an agile methodology probably isn't for you. If you need to test something out or scratch an itch now , then agile might be a good fit (depending on the skills/buy in/experi…

You can build a house with agile methodology. And I think many have been...

You might be able to live in one, but surely you don't want to buy one. As these are probably not legal in this day and age and mostly done by do-it-yourself self-builders. That is they are not code compliant. Like electricity might or might not burn down the house, there might or might not be leaks all over the place. And mold and so on is probably common... Also I doubt every door closes or is straight and so on...

Actually that really describes most of software we use.

Re: Agile Is a Glass Cannon

#60
post #22
post #13

Kinda misses the entire point of 'agile' which is a way to adjust to and gather changing requirements in an iterative process. It's a risk _mitigation_ strategy. I'm not sure I agree that anything is a glass cannon because it could work but you could also do it wrong so it could fail. If a team can't pull off agile what do they think would have been a safer strategy?

> gather changing requirements in an iterative process. But you can't have processes, after all its "individuals and interactions over processes and tools".

The process is iterated on by the people. The people tweak the process so it works for them instead of adhering to some dogma.
Post reply on HN