Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile Is a Tainted Term

pcloadletter.dev

Post reply on HN
Print view View original

71–80 of 108 posts

Re: Agile Is a Tainted Term

#71

Post by hkt »

praptak wrote: post #27
hkt wrote: post #16

Earlier quoted context omitted.

Exactly the same thing here. Once some interloper with paper qualifications and no tech background rocks up and says "this is how agile works!" you're doomed. The only time I've ever seen this not happen was when we had a 55 year old delivery manager who viewed his job as facilitating team meetings in a way that meant everyone got the chance to speak and that consensus formed. Didn't try to dictate process or anythin…

Organisations make it very hard to be that manager. On top of the human tendency to overmanage there's often push from top for "more visibility and accountability" which results in forcing stuff rather than facilitating.

Blame Mckinsey and their ilk: "what can be measured can be managed".

(I refuse to utter the above phrase without accompanying it with tjis: "not everything that counts can be counted")

Re: Agile Is a Tainted Term

#72

Post by EchoChamberMan »

DrNosferatu wrote: post #59
thimp wrote: post #12

Earlier quoted context omitted.

I’ve seen agile done well once. Yes it does happen. The process was not described, spoken of or even considered. It just existed between a few like minded decent engineers. Their manager got an “agile PM” forced on them and it broke. The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.

Quality engineering has to be *repeatable*. If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX. I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.

I once had to explain to a manager of hundreds of people why reproducibility in engineering (and science) is important. Not good.

Re: Agile Is a Tainted Term

#73

Post by EchoChamberMan »

bruce343434 wrote: post #65
DrNosferatu wrote: post #59

Earlier quoted context omitted.

Quality engineering has to be *repeatable*. If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX. I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.

What has been, in your experience, a repeatable process for quality engineering? How much does it depend on the kind of software one is engineering, or is it applicable to any kind of software with any kind of constraints?

Repeatable processes require long term strategy.

[edit] Too many of these people want tomatos, so they plant a tomato, when really they want seasonal tomatos, and need to consider a farm, and take into account growth cycles. The term I like is "sustainable development."

Re: Agile Is a Tainted Term

#74

Post by whstl »

phkahler wrote: post #37
midasz wrote: post #17

Earlier quoted context omitted.

How does that work? So you've already went through the steps of figuring out a process, or do you just pick one and stick with it - accepting shitty parts? What's the process?

1) Come to work. 2) Look at the current state. 3) Decide what the product needs from you. 4) Do that. 5) Use git. Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates). This is how my current job works and we are unbelievably productive.

I would argue that 3 and 4 already imply 5! :)

And IMO it also implies things like CI/CD.

Re: Agile Is a Tainted Term

#75

Post by Kim_Bruning »

Tabular-Iceberg wrote: post #67
pydry wrote: post #47

Earlier quoted context omitted.

>Is it really vaguely defined? https://agilemanifesto.org/ does this look like a clear and precise proscription for a good way to engineer software? Or does it look more like a bunch of "inspiring quotes" from a discount southern baptist church website from the 1990s? I learned this the hard way when I was younger when I tried to write some tests for some bugs and my boss told me that we needed to deal with it with m…

They couldn't be more precise than that because each team and project has their own set of constraints and capabilities that determines how they achieve the Agile goals. I think the only problem is that the authors took for granted that everyone understands that it takes an actual empirical process and not just a bunch of magic incantations to do that, like the enterprise world seems to think.

The way you word it, it sounds very much like a cargo cult phenomenon.

Copying the external trappings (Towers, runways, procedures.) , not the underlying goals or process (shipping cargo across the pacific).

I only do a small number of projects myself, but my understanding is that in a lot of places, people might follow "the agile process", rather than that they are aiming at actual Capital-A-Agility (where any and all process is merely a means to that end, and is rapidly tuned and adjusted as required) .

Re: Agile Is a Tainted Term

#76

Post by whstl »

pydry wrote: post #68
photonerd wrote: post #57

Earlier quoted context omitted.

Scrum is supposed to be training wheels for agile, not the end point. I think a lot of ppl forget that.

I quickly searched for evidence that it was supposed to be that and found nothing except one essay on medium refuting the idea. One of the nice things about scrum is that it has an official source who defines it and you can look at it to see what it is and what it is not intended to be.

And Scrum is not even as strict as people paint it, honestly. It retains a lot of the good parts of Agile. It is a basic framework for a self-managing team.

The retrospective is where you can tweak the process, but you can honestly change things anywhere. Bad managers will resist change at any cost and will use Scrum as an excuse to resisting change, but that's true for any methodology.

The problem is it doesn't work when there's micromanagement, it doesn't work when there are waterfall-ish parts (eg: PMs not splitting tickets, QAs hogging releases). Scrum also doesn't work when the development team isn't empowered, or has no domain experts. But most methodologies also don't.

Re: Agile Is a Tainted Term

#77

Post by Kim_Bruning »

pydry wrote: post #51
SideburnsOfDoom wrote: post #23

Earlier quoted context omitted.

> That can be fixed by defining something new, more precisely. I do not think that we're going to find a single precisely-defined process that will work well for everyone. The strength of the OG Agile thinking was the iterative, "inspect and adapt", "shorten the feedback cycle" thinking. Which is somewhat in opposition to your desire for a precisely defined process. The Agile manifesto specifically stated that "proce…

I absolutely don't think we need a single precisely defined process that will work for everyone. That's scrum and it's shit. I think we just need some criteria which can provide clear answers to whether you're doing agile or bullshitting around or doing cargo cult agile. The manifesto/principles aren't that but they should have been. Instead they were some sort of vague inspiring motivational bullshit. "Build project…

"Cargo Cult Agility" should be a term!

It turns out that iteration (and recursion) are pretty mind blowing concepts to have to explain to people. Like for instance just explaining why is it important to iterate faster?

I've gotten lucky explaining it once or twice, [1][2]; but mostly I think it needs to be something someone experiences somehow. Either by programming or engineering or some other way.

[1] Some engineers understand what a control loop is, and you can explain why iterating (faster) actually leads to better precision than trying to measure things precisely in one go inside the loop. ( https://en.wikipedia.org/wiki/Closed-loop_controller )

[2] You might be lucky to find a manager who really understands PDCA or OODA. https://en.wikipedia.org/wiki/PDCA , https://en.wikipedia.org/wiki/OODA_loop . Unfortunately these are also somewhat prone to cargo-culting. On the "upside", OODA cargo-culting may be subject to natural selection.

Re: Agile Is a Tainted Term

#78

Post by Kim_Bruning »

JackSlateur wrote: post #58
midasz wrote: post #17

Earlier quoted context omitted.

How does that work? So you've already went through the steps of figuring out a process, or do you just pick one and stick with it - accepting shitty parts? What's the process?

You failed as soon as you think "process" A process is a hardcoded way of do thing, which is deficient because it cannot react to an ever-changing world A better way to handle things is by defining "what" should be done, not "how" it should be done

I have the opposite view.

Everything you do -up to and including taking a leak- is a sort of process. Perhaps you don't think that particular example should be a corporate process, but that's not my problem :-P .

You can compose processes to get things done.

Processes can be made mutable or flexible by eg. incorporating decisions or iteration. Especially iterated processes can be very powerful (you can get a lot done with them).

Thinking of things in terms of processes instead of in terms of component steps each time frees your mind to worry about other stuff.

Compare it with dividing a program into functions. Once you've wrapped a task in a function, you can then design using the function, rather than worry about how to write the code from scratch each time. Same with process thinking: you don't have to get bogged down in particulars all the time.

That said, maybe you're thinking of the "Befehlstaktik" vs "Auftragstaktik" [1] approach to doing things. In which case we're arguing definitions instead (which can be easily resolved).

[1] https://en.wikipedia.org/wiki/Mission-type_tactics

Re: Agile Is a Tainted Term

#79

Post by SideburnsOfDoom »

Kim_Bruning wrote: post #77
pydry wrote: post #51

Earlier quoted context omitted.

I absolutely don't think we need a single precisely defined process that will work for everyone. That's scrum and it's shit. I think we just need some criteria which can provide clear answers to whether you're doing agile or bullshitting around or doing cargo cult agile. The manifesto/principles aren't that but they should have been. Instead they were some sort of vague inspiring motivational bullshit. "Build project…

"Cargo Cult Agility" should be a term! It turns out that iteration (and recursion) are pretty mind blowing concepts to have to explain to people. Like for instance just explaining why is it important to iterate faster ? I've gotten lucky explaining it once or twice, [1][2]; but mostly I think it needs to be something someone experiences somehow. Either by programming or engineering or some other way. [1] Some enginee…

> for instance just explaining why is it important to iterate faster. I've gotten lucky explaining it once or twice; but mostly I think it needs to be something someone experiences somehow.

Agreed, your "once or twice" is once or twice more often than my success rate at that. You're better off finding an employer who already gets it, and hoping that they don't forget.

Re: Agile Is a Tainted Term

#80

Post by Kim_Bruning »

oneshtein wrote: post #40
Tabular-Iceberg wrote: post #34

Earlier quoted context omitted.

Is it really vaguely defined? I find it perfectly precise in what it tells you what you need to optimize for. It just doesn't tell you how because it couldn't possibly know. But finding out is hard work. What the fraudsters are telling you is that you don't need to do any of the things in the manifesto because they know everything already. A general lack of industriousness on the part of software companies is really…

A customer of the software product need to know that after spending of $X dollars for Y days he will receive Z. In a working Agile project, PM must calculate team velocity and then use it to predict arrival time and expenses, then add/remove developers or features to meet budget and/or dead line. Agile manifesto says nothing about that.

Perhaps the customer does want to spend $X to receive Z, this is fine. Probably they should consider buying something off-the-shelf.

Alternately, a different thing the customer might want is to Solve Their Problem; which is a fundamentally different thing, and requires a fundamentally different process.

Post reply on HN