[HN Gopher] Agile Cult
___________________________________________________________________
Agile Cult
Author : thunderbong
Score : 22 points
Date : 2024-02-26 11:58 UTC (11 hours ago)
(HTM) web link (milestones.dothub.cloud)
(TXT) w3m dump (milestones.dothub.cloud)
| bitwize wrote:
| Agile was and is only ever adopted by organizations because of
| what it promises organizational _management_ , to wit: _fine
| grained_ observability and control of the software development
| process. That 's it. Take that away and the advantages to Agile
| crumble, and your boss will be back to breathing down your neck
| asking for estimates that are really signed-in-blood commitments.
|
| Nobody making the decisions really gives a shit about what's on
| the manifesto.
| AnimalMuppet wrote:
| False. It was adopted at an organization where I worked because
| of what it promised management, which was greater productivity.
| It died because management wanted greater observability (and, I
| presume, control). There was an impedance mismatch (so to
| speak) between the agile team and upper management - management
| wasn't getting their GANTT and PERT charts, and couldn't figure
| out how to manage the agile team. "Trust us, bro, we're
| delivering" didn't cut it, though the agile team had a track
| record of delivering.
|
| > Nobody making the decisions really gives a shit about what's
| on the manifesto.
|
| That's probably true. But if agile is any good, shouldn't it be
| good for the organization, not just the programmers? Shouldn't
| it deliver actual value faster than other approaches? (And in
| fact, we did. But management just _had_ to have their charts to
| be sure we were going to...)
| psunavy03 wrote:
| And here we go with an entire thread of cynical comments where
| people assume that the jacked-up Agile implementations they've
| seen at their own organizations are the only way it ever can be
| implemented . . .
|
| Unfortunately, doing it well requires managers willing to give up
| power and developers willing to take the headphones off, go talk
| to other human beings, and be more proactive than just "I did
| what I was told." Some companies/teams struggle with these
| things.
| harimau777 wrote:
| Isn't that the entire problem though? Agile fails to take into
| account the realities of corporate politics and human (i.e.
| manager) psychology?
| psunavy03 wrote:
| Agile, or the "Agile Cult" the author mentions? Agile merely
| recommends biasing in four directions:
|
| - Individuals and interactions over processes and tools
|
| - Working software over comprehensive documentation
|
| - Customer collaboration over contract negotiation
|
| - Responding to change over following a plan
|
| And also to comply with 12 principles listed here in all
| their 2001 internet glory:
| https://agilemanifesto.org/principles.html
|
| There's nothing wrong with any of that, and a lot that's
| quite good. Failing to take into account the realities of
| corporate politics and human psychology when you implement it
| doesn't make the idea bad. There's no cause so noble that it
| won't have a few incompetents following it.
|
| What's more, there's a difference between expecting someone
| to change at a healthy pace as opposed to RIGHT NOW, and
| saying that they don't need to change at all. Implementing
| whatever flavor of Agile requires growing pains in the same
| way that getting physically fit or learning a new skill does.
| That's healthy. A lot healthier than just sitting on the
| metaphorical couch with a bowl of Cheetos. Just because a bad
| personal trainer pushes someone to the point of injury is not
| evidence that exercise itself is bad.
| OldGuyInTheClub wrote:
| Your bullet points may (or may not) be fine for commercial
| software. If you're working on anything governed by the US
| Federal Acquisition Regulations (FAR), they are a
| minefield.
|
| - Process compliance is usually baked into the contract. If
| the contractor stipulates to complying with a process,
| especially a government process, then it had better be
| followed and documented
|
| - Documentation is not optional. People move on, get fired,
| and/or die. Because the s/w works today, it may not
| tomorrow when MS, Redhat, or whomever push patches
|
| - "Customer collaboration over contract negotiation": Once
| the contract is in place, it is in place. Customers will
| _always_ try to add scope and eventually try to direct the
| individual performers. If you're Firm Fixed Price, you are
| dead in the water. If you are Cost Plus Fixed Fee (CPFF),
| you will dilute your profit when you inevitably overrun.
|
| -- Aside: CPFF means the fee is fixed at contract start. If
| you overrun you may get your costs but the fee stays the
| same.
|
| And so on.
|
| An even bigger problem is when Lean/Agile gets glommed on
| to hardware efforts where you can't simply issue a patch
| every 30 minutes and where you can't have the customer in
| your day-to-day shorts.
| psunavy03 wrote:
| And yet the government is starting to realize that the
| FARs need a major overhaul if the DOD is to have a prayer
| of staying competitive in the 21st Century.
|
| You're not describing a critique of Agile so much as
| you're describing why the government sucks out loud at
| software.
| OldGuyInTheClub wrote:
| I'll let you fly the plane whose software is written
| without requirements, updated on the fly, and released
| without regression testing.
| kelseyfrog wrote:
| The complexities of human interaction implies that _every_
| system will fail to take into account realities. It 's a
| sociological version of Godel's incompleteness theorems -
| either the system is comprehensive and inconsistent, or it's
| consistent but not comprehensive.
|
| Even so, if every model will fail, which one minimizes the
| quantity and quality of failure? The solution still seems to
| be, "let's be aware of our system, whether formal, informal,
| or somewhere in between, and be conscious designers of our
| interactions with others in the social organization of
| software development."
|
| It requires system-level thinking, which at face value,
| appears to be something that engineering folks would love to
| sink their teeth into.
|
| At the very least, Agile recognizes that time, features, and
| effort exist in relation to each other, and that if
| one[effort] is held constant, social interactions are
| constrained in a number of important ways.
| psunavy03 wrote:
| Which is why Scrum in particular is express about being
| "purposely incomplete." It's intended to leave wiggle room
| for people to adapt it to their context.
|
| Unfortunately mediocre people and mediocre organizations
| take this as a license to fill the gaps with inane bullshit
| and call it "Scrum" or "Agile," instead of mindfully
| determining what makes sense in their context.
| randomdata wrote:
| _> Agile fails to take into account the realities of
| corporate politics and human (i.e. manager) psychology?_
|
| No, it does. Each of the 12 principles calls attention to
| what developers need to be thinking about when there are _no_
| managers. Agile is, in effect, a framework to help you
| operate without managers. If you already have managers, and
| they aren 't willing to let go, agile was never on the table.
| wallaBBB wrote:
| Seems a bit like blame shifting. Almost any approach will work
| if perfectly executed by a team with a perfectly matching skill
| sets, but yeah we have to account for the imperfections (to put
| it lightly).
| rightbyte wrote:
| > Unfortunately, doing it well requires managers willing to
| give up power
|
| Agile is the best micromanagement process there is. Nothing
| even comes close. I guess there is a fitting LoTR quote here
| about tempting weak mortals with power.
|
| These levels of micromanagement did not exist before agile.
| Sure the bosses could try earlier, but there were no tooling or
| developer self-imposed mindset for the modern worst practice
| nightmare. And the process is so stiff I wanna cry, but you are
| gaslighted into being blamed for it, as you "can change it" --
| maybe after the next retro though. Just need to align your
| agile with the other teams agile first.
|
| We are way past agile being nothing but a farce.
| datadrivenangel wrote:
| "And no, this is not a post where I will say "corporate" agile
| bad or "scrum-but" bad or any other truth worn thin. On the
| contrary, I'm talking about the "good" Agile that the cheerful
| but barely experienced in software development coaches will share
| with you in a two-day training session. I'm talking about one of
| the huge pillars of modern agile - Scrum itself.
|
| My biggest problem with Agile is that it has become a cult, full
| of fanatics, dogmas, sermons, its own mythology, and of course
| the holy inquisition that fiercely fights heretics. I'm a heretic
| now. In this post I will say a few anti-Agile things, so you may
| think I have completely embraced the Dark Side, where all the
| Evil Managers in their suits sit, and where the looming shade of
| the Great and Terrible Waterfall instills fear into the hearts of
| the bravest developers."
| nivenhuh wrote:
| I think most stressful development environments happen because a
| manager either isn't familiar with how software development is
| done (resulting in unreasonable expectations), or the manager
| isn't communicating expectations upwards effectively.
|
| It's important to understand when the business needs a certain
| capability, and that should be communicated to the development
| team (so that the correct scope tradeoffs can be made). Bonus
| points if the business can communicate the challenge they're
| trying to solve as opposed to the desired output. (Sometimes, you
| can start with a simple shell script that relieves the pressures
| of the business while iterating towards a more feature-rich
| solution.)
|
| It's also important for the business to understand that the goal
| is a minimum functional implementation for the capability, and
| that there are development quality standards that must not be
| sacrificed to hit a date (bad code is a liability). Also, they
| have to understand that the date they are communicating to the
| development team is a "I would like it by this date", not a
| deadline / guarantee that they'll have that software capability
| on that date. (As a consumer, I do not set deadlines on a
| provider in many industries.)
|
| Finally, a manager needs to understand the project health on a
| regular interval and communicate progress and confidence levels
| as the project continues. This is usually where expectation
| management goes wrong -- because the conversation about the work
| becomes metrics driven (instead of talking about the true story
| of what is actually happening with the work).
|
| Everyone involved needs to understand the flexibility required to
| develop a useful, trustworthy product -- and that the time
| required will vary depending on a number of factors (some
| knowable / mostly unknowable).
|
| As long as there is trust and expectation management between all
| stakeholders, a program will usually go positively (and
| relatively stress free).
|
| (Lessons learned from shipping enterprise software applications &
| running a development consultancy.)
| nusl wrote:
| I've worked at a lot of places that said they do Agile but they
| all really do waterfall with Kanban and call it Agile. Sometimes
| they do retros too.
|
| If you're someone that studied Agile and knows how it really
| works I think you're in the vast minority.
|
| Admittedly I am not one of those people and haven't a clue of
| what "real" Agile looks like. I can't say that I feel like I'm
| missing out either.
|
| Where did the word Spike come from? How does it mean "research"
| (kinda)? Dunno, I'll google that now I guess. But the word itself
| feels out of place if you're not in the Agile mindset.
|
| Seems like it's from track running terminology for a short, quick
| sprint. Okay. Why not just call it what it is, just research
| and/or planning?
| psunavy03 wrote:
| Because a spike was supposed to originally represent a short,
| quick, narrow trip through all levels of the stack from UI to
| DB to figure out how to approach a given gnarly problem. Narrow
| and deep . . . looks like a spike.
___________________________________________________________________
(page generated 2024-02-26 23:01 UTC)