Welcome to Incremental Social! Learn more about this project here!
Check out lemmyverse to find more communities to join from here!

jj4211 , (edited )

I'm all for and good eye rolling at institutional Agile (basically checkered with bad management who doesn't know what to do, but abuses buzz words and asserts Agile instead), but this article has a lot of issues.

For one, it's a plug for someone's consultancy, banking on recognition that, like always, crappy teams deliver crappy results and "Agile" didn't fix it, but I promise I have a methodology to make your bad team good.

For another, it seems to gauge success based on how developers felt if they succeeded. Developers will always gripe about evolving requirements, so if they think requirements were set in stone early, they will proclaim greatness (even if the users/customers hate it and it's a commercial failure).

BurningnnTree ,

This article doesn't make any sense. A project's "success" can't really be measured in any objective way like the article is implying. Even saying that a project is "on time" is a vague statement depending on the situation, and it's not a good way to measure the quality of the end result or the efficiency of the development team.

snek ,
@snek@lemmy.world avatar

No to all cults in general, as a rule of thumb

hellothere , (edited )

If you know exactly what you need, then specs are great. Proven solutions for known problems are awesome. Agile is pointless in that circumstance.

But I can count on one hand the number of times stakeholders, or clients, actually know what they want ahead of time and accept what was built to spec with no amends.

When there is any uncertainty, changing a spec under waterfall is significantly worse. Contract negotiation in fixed price is a fucking nightmare of the client insisting the sky is red when the signed off spec states it's to be green.

grrgyle ,
@grrgyle@slrpnk.net avatar

If you know exactly what you need, then specs are great.

If you know exactly what you need and the specs are great, then you barely need project management framework at all.

Maybe I just work at shit companies, but it feels unrealistic to expect this this level of maturity from assigned work.

hellothere ,

Well, exactly.

RagnarokOnline ,

what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.

I haven’t read the book they’re advertising here, but I’ve found these challenges to be socially created, not caused by agile.

dustyData ,

Oh, so Agile is only done by autonomous AI?

RagnarokOnline ,

In the article, they’re proposing a solution to agile (“Impact Development” or something). The quote I listed above is talking about how Impact Development is supposed to provide those things. That said, I don’t blame agile for projects not having those things, it’s the people’s fault. So changing methodologies likely won’t help.

In short: yes, make AI do all project management :P

chakan2 ,
@chakan2@lemmy.world avatar

Pbpbpbp...agile fails fast by design.

The counter from the article is you need a specification first, and if you reveal the system wasn't going to work during requirements gathering and architecture, then it didn't count as a failure.

However, in my experience, architects are vastly over priced resources and specifications cost you almost as much as the rest of the project due to it.

TLDR...it's a shit article that confuses fail fast with failure.

bionicjoey ,

Fail fast is the whole point and the beauty of agile. Better to meet with clients early and understand if a project is even workable rather than dedicating a bunch of resources to it up front and then finding out six months in (once the sunk cost fallacy has become too powerful)

MechanicalJester ,

Thanks for pointing that out so I didn't have to.

What's the alternative? Waterfail?

Yeah because business requirements and technology is changing at an ever slower rate...

whyNotSquirrel ,
@whyNotSquirrel@sh.itjust.works avatar

That's because they forgot the meaning of the word agility and want to apply the rules what ever the cost

ture ,

And also because it's a comfortable cover up for any kind of money saving stupidity. We don't need proper requirements engineering, we're agile. We don't need an operations team we're doing an agile DevOps approach. We don't need frontend Devs, we're an agile team you all need to be full stack. I have often seen agility as an excuse to push more works towards the devs who aren't trained to do any of those tasks.

Also common problem is that still tons of people believe agile means unplanned. This definitely also contributes to projects failing that are just agile by name.

mynamesnotrick ,
@mynamesnotrick@lemmy.zip avatar

100% my experience.

RamblingPanda ,

Especially the last part. Writing a single word into a jira ticket doesn't make it a story, epic or sub task. You're too lazy to specify, that's not what agile is meant to be.

magic_lobster_party ,

I don’t know how many times I have been waiting for the product manager to get out of their meeting so they can help me clarify what they really mean with their "high priority" ticket only consisting a vague title.

RamblingPanda ,

"Looks like I'm home early, bye"

wewbull ,

A lot of places seem to view it as "we just work from the backlog" with no requirements on when features are delivered, or their impacts on other parts of the project.

You still need a plan, goals and a timeline. Not just a bucket of stuff to get done.

Prox ,

Or, even worse, they want to apply some of the rules, cherry-picking bits and pieces of a framework without truly understanding it.

Vanth , (edited )
@Vanth@reddthat.com avatar

[Thread, post or comment was deleted by the author]

    •
    grrgyle ,
    @grrgyle@slrpnk.net avatar

    I haven't read the article yet, but surely they can't be juxtaposing waterfall as the alternative to agile. The modern alternative, especially in small to medium businesses, would be kanban.

    CameronDev ,

    Kanban is Agile. They are pushing Impact Engineering.

    drphungky ,

    Ehhhh...Kanban is much older than Agile even if they tried to subsume it and say it's an agile technique, so that's sort of right. But kanban vs "scrum" - which virtually everyone means when they say "agile" - is fair.

    CameronDev ,

    Within my company there is a mix of Scrum and Kanban, so Agile != Scrum.

    I don't think it makes much sense to say "We are switching from Agile to Kanban", but "We are switching from Scrum to Kanban" does make sense (at least to me)

    grrgyle ,
    @grrgyle@slrpnk.net avatar

    Well that's news to me

    henfredemars ,

    The few times I’ve been on an agile project it amounted to start writing without understanding what product we’re building.

    grrgyle ,
    @grrgyle@slrpnk.net avatar

    Yeah. Which actually doesn't have to be bad as long as leadership accepts that this exploratory work (sometimes called a "spike") might have to be thrown away, if findings reveal better paths.

    The trouble begins when you start shipping your proof-of-concepts (without immediately paying back that tech debt).

    It very quickly becomes an unmaintainable mess.

    homesweethomeMrL ,

    An Agile Project eh. Like an Agile Waterfall process? cool. Cool cool cool.

    I know PMI has an Agile thing but by and large Agile can't be "projects" and vice versa.

    Treczoks ,

    Does that surprise me? Not at all. "Agile" was never about making programming better. It was a management buzzword from the start.

    We once had a manager who came to me with the serious idea "to make the development process agile". He had heard of this in a discussion with managers from other companies. The problem? I'm the only person in this department. I program everything alone. How the F should I turn my processes "agile"?

    Vanth , (edited )
    @Vanth@reddthat.com avatar

    [Thread, post or comment was deleted by the author]

    •
    Treczoks ,

    I think he wanted it more like Product Owner, Scrum Master, Architect, Stakeholder, New product development, Tester, Integrator, Team member, Agile architect, Agile Coach, Developer, Team lead, Technical expert, Product Designer, Business Analyst, Programmer, and Specialist for at least eight hours a day in each role...

    BrianTheeBiscuiteer ,

    As someone who practices agile software development I find this baffling. I've never started a new project without at least 3 weeks worth of research and requirements gathering (and obviously more as the project rolls on). There are seriously companies out there who are like, "Mmm, I feel like this is gonna be an Electron project. Let's just lay the groundwork and we'll flesh out the nitty gritty in a week or so." 😱

    ChowJeeBai ,

    Cries in waterfall.

    autotldr Bot ,

    This is the best summary I could come up with:

    Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be.

    One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.

    "Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout."

    A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.

    One Agile developer criticized the daily stand-up element, describing it to The Register as "a feast of regurgitation."

    In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.

    The original article contains 502 words, the summary contains 175 words. Saved 65%. I'm a bot and I'm open source!

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • technology@lemmy.world
  • random
  • incremental_games
  • meta
  • All magazines
    •