We all knew it

  • @[email protected]
    link
    fedilink
    English
    1972 months ago

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

    I’d like to work in that company.

    • @[email protected]
      link
      fedilink
      English
      832 months ago

      Try medical software and devices. The requirements and specs are mandatory before doing anything. It’s actually very fun and I have less burnout thanks to this.

      • @[email protected]
        link
        fedilink
        English
        632 months ago

        I couldn’t disagree more.

        In medical I would end up being apart of endless retirement gathering meetings, then draft up the SOW doc only to have stakeholders change requirements when they were reviewing the doc. Then months later once the doc was finally finished and I could do the development, when UAT time finally came, they’d say the build wasn’t what they wanted (though it matched the written requirements).

        Most of the projects I saw executed in the last 4 years either got scrapped altogether or got bogged down in political bs for months trying to get the requirements “just right”.

        It was a nightmare. You could blame me, or the company, or bad processes all you want, but I’ve never had fun on a waterfall project, especially not in medical. (Though, in my opinion, we are severely understaffed and need like 4 more BAs.)

        • @Serinus
          link
          English
          352 months ago

          It’s almost like the methodology is less important than the people.

        • @francisfordpoopola
          link
          English
          202 months ago

          Do you think the problem is that the person driving the requirements doesn’t know what they actually want?

          I think a good BA is critical to the process because lots of end users have no idea how to put their ideas onto paper.

          I also think an MVP helps a lot because people can see and touch it which helps focus their needs.

          • @[email protected]
            link
            fedilink
            English
            162 months ago

            I would say yes, the problem is stakeholders not having thought critically about what they really wanted from the project.

            The motivation for projects were usually “regulatory told us we need to have this new metric for federal reporting”, or “so-and-so’s company can do this, why can’t ours” rather than, “we’d like to increase retention by 6% and here’s the approach we’ve researched to make that happen”.

            I ended up experiencing that people in the highest positions weren’t experts in their field, but just people who had a strong intuition. This meant they would zero-in on what they wanted by trial and error rather than logic. Likewise, it meant they were socially adept enough so their higher-ups would never get mad at them when we finished “late and over budget”. People lower on the totem received that blame.

            I think humans are just really bad at estimating and keeping their commitments, which is why I enjoy working with agile more. It’s a forgiving framework (imo).

    • @[email protected]
      link
      fedilink
      English
      31 month ago

      No thanks. It’s way more fun to be part of the decision process. If a manager can anticipate all of the requirements and quirks of the project before it even starts, it’s probably going to be a really boring, vanilla project at which point it’s probably just better to but the software.ä somewhere else.

      Creating something new is an art in itself. Why would you not want to be a part of that?

      Also: Isn’t it cheating to compare the two approaches when one of them is defined as having all the planning “outside” of the project scope? I would bet that the statistics in this report disregard ll those projects that died in the planning phase, leaving only the almost completed, easy project to succeed at a high rate.

      It would be interesting to also compare the time/resources spent before each project died. My hunch is that for failed agile project, less total investment has been made before killing it off, as compared to front loading all of that project planning before the decision is made not to continue.

      Complementary to this, I also think that Agile can have a tendency to keep alive projects that should have failed on the planning stage. “We do things not because they are easy, but we thought they would be easy”. Underestimating happens for all project but for Agile, there should be a higher tendency to keep going because “we’re almost done”, forever.

    • gradyp
      link
      fedilink
      English
      11 month ago

      no shit, I feel most people can function in just about any framework, so long as everyone knows what they are building. I’ve seen agile (and other frameworks to be fair) as the ‘solution’ to missing requirements too often. Sure we can get to work without them, but to what end?

    • @[email protected]
      link
      fedilink
      English
      -132 months ago

      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.

        • drphungky
          link
          English
          11
          edit-2
          2 months ago

          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.

          • @[email protected]
            link
            fedilink
            English
            102 months ago

            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)

  • @[email protected]
    link
    fedilink
    English
    752 months ago

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

    • @[email protected]
      link
      fedilink
      English
      712 months ago

      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.

        • @[email protected]
          link
          fedilink
          English
          122 months ago

          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
            link
            fedilink
            92 months ago

            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.

    • @[email protected]
      link
      fedilink
      English
      132 months ago

      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
      link
      English
      62 months ago

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

  • @[email protected]
    link
    fedilink
    English
    651 month ago

    Today, new research conducted for a new book, Impact Engineering, has shown that 65% software projects adopting Agile requirements engineering practices fail to be delivered on time and within budget, to a high standard of quality. By contrast, projects adopting a new Impact Engineering approach detailed in a new book released today only failed 10% of the time.

    All you need to know about this study.

    • @Simplicity
      link
      English
      61 month ago

      It almost sounds like a project team that is actually and actively looking to solve known and recurring problems instead of “just do whatever everyone else is kind of doing” might be why they are successful.

      It’s the difference between “how should we go about this” vs “see how we go” regardless of what you label those approaches as.

      • @jj4211
        link
        English
        151 month ago

        I think the take away should be:

        new research conducted for a new book, Impact Engineering,

        By contrast, projects adopting a new Impact Engineering approach detailed in a new book released today only failed 10% of the time.

        So the people who want to sell you ‘Impact Engineering’ say ‘Impact Engineering’ is better than Agile… Hardly an objective source.

        Even if they have success with their ‘Impact Engineering’ methodology, the second it becomes an Agile-level buzzword is the second it also becomes crap.

        The short of the real problem is that the typical software development project is subject to piss poor management, business planning, and/or developers and that piss poor management is always looking for some ‘quick fix’ in methodology to wave a wand and get business success without across the board competency.

        • @Simplicity
          link
          English
          11 month ago

          Oh yeah. I totally agree that the source has its own objective. I wasn’t supporting their specific approach at all.

          You are right that the key take away is somene saying “I think my own idea, which I happen to be selling a book about, is great, here are some stats that I have crafted to support my own agenda”

          The point I was making was simply that people who care enough to try something, anything, with thought (like looking for a new methodology to try out) are likely to be more successful.

          Like a diet. The specific one doesn’t matter so much. It’s the fact that you are actually paying attention and making a specific effort.

  • magic_lobster_party
    link
    fedilink
    53
    edit-2
    2 months ago

    A more proper title would be “study finds 268% higher failure rates for poorly planned software projects”.

    “Agile” as a word is mostly an excuse of poor planners for their poor planning skills.

    • @kescusay
      link
      English
      29
      edit-2
      2 months ago

      Yeah, Agile isn’t really at fault here. If done right - if you’ve got a scrum master, a proper product owner, proper planning and backlog grooming, etc. - it works really well. The problem is some companies think Agile is just “give the devs some pie-in-the-sky hopes and dreams, let 'em loose, and if they don’t give half a dozen execs exactly what they want (despite their massively conflicting ideas on what they want), cancel the project.”

      • magic_lobster_party
        link
        fedilink
        11
        edit-2
        2 months ago

        In one the worst “poor planning” projects I’ve been in the product owner just kept sneaking in new “high priority” issues to the top of the backlog throughout the sprint. I don’t think we had a single sprint where we ended up with fewer open issues in the backlog than when we started.

        Needless to say, he was the main reason why I quit.

      • @[email protected]
        link
        fedilink
        English
        82 months ago

        In my experience it’s just kanban, but make the devs feels guilty between sprints for not meeting their goals.

        • beefalo
          link
          fedilink
          21 month ago

          Absolutely It’s so management can say “your velocity was down 15% this sprint” and not feel bad about it instead of saying “work more” It’s plausible deniability for demanding unpaid overtime

      • @jj4211
        link
        English
        01 month ago

        Yeah, Agile isn’t really at fault here. If done right

        This is what ticks me off about the “Agile” brand, it’s chock full of no true Scotsman fallacy (if a team failed while doing “Agile”, it means they weren’t being “Agile”).

        I can appreciate sympathizing with some tenets as Agile might be presented, but the popularity and consultancy around it has pretty much ruined Agile as a brand.

        Broadly speaking, any attempt to capture nuance of “best practices” into a brand word/phrase will be ruined the second it becomes “popular”.

        • @kescusay
          link
          English
          21 month ago

          This isn’t a case of No True Scotsman. There really is a right way and a whole lot of wrong ways to do Agile development. Any team that calls itself an Agile team that doesn’t actually follow the processes properly is doing it wrong and will fail.

          That doesn’t mean any team that’s doing it right will succeed, but it’s like riding a horse: If you only climb halfway up the horse and try to hold on while at a 90-degree angle, it’s not going to work, and it would be stupid to declare that the concept of horse-riding is broken. No, it’s not broken, you’re just an idiot who thought you could ride a horse while only halfway up, clinging desperately to its side.

          • @jj4211
            link
            English
            11 month ago

            Any team that calls itself an Agile team that doesn’t actually follow the processes properly is doing it wrong and will fail.

            I mean, this statement is also weird, to imply that not following Agile implies failure. I’d say it’s quite possible for a team to “falsely” execute on Agile and still pull off success. However, if that story is prominent and successful, no one is going to make a peep about it not being “true Agile”, they’ll only do that when it’s a failure.

            But really this detail is beside the point, that people want to use ‘Agile’ as shorthand for good methodology, but it’s the way of the world that any shorthand that is popular will get co-opted and corrupted to the point of uselessness. You end up with various “interpretations” and so the meaning is diluted.

            Now at a glance, this may seem an innocuous scenario, ok, Agile doesn’t “mean” anything specific in practice because of people abusing it to their objectives, but it still carries the weight of “authority”. So if you have a criticism like “there’s way too many stupid pointless required fields in our Jira implementation, and there’s a super convoluted workflow involving too many stakeholders to walk a simple ticket to completion”, then you get chastised because “our workflow is anchored in Agile, and you can easily see online that Agile makes success, so you obviously don’t understand success”. You can try to declare “Individuals and interactions over processes and tools”, but then they’ll say “oh, but the stuff on the right is valuable, and it’s used to facilitate the interactions between people”. Thanks to Atlassian marketing, for a lot of the corporate world if you implement it in Jira, then it is, by definition, “Agile” and your peons can shut up because you are right.

            Basically, things get ruined by trying to abbreviate. You may be able to cite the Agile manifesto as something specific enough yet still short, though it’s still wishy washy enough to not be able to really “win” an argument with someone when deciding how you are going to move forward.

    • @[email protected]
      link
      fedilink
      English
      132 months ago

      Agreed. The problem is people mistake “zero planning and structure” to mean “agile”. Of course it fails.

      Agile to me was always mini waterfall. You always know who’s doing what, why, and what success looks like on a 2 week sprint horizon. When you see people on a sprint without a clear understanding of what they are doing over the next couple of weeks - then you know your project is in trouble for sure.

    • @[email protected]
      link
      fedilink
      English
      112 months ago

      I don’t have much direct experience working in agile since I tend to work on the business side but I can tell you that the term agile is WAY overused. So many projects are described as agile when they are just waterfall with more steps. Leaders love to say they are working in agile because it sounds ‘techy’ and cool, but I don’t think they fully appreciate what it is vs other methods. I wonder if a lot of the failed projects described in the article are some of those agile in name only kind of things.

    • drphungky
      link
      English
      62 months ago

      An even better title would be “‘Study’ by firm pushing new technique finds old technique is bad.”

  • @chakan2
    link
    English
    40
    edit-2
    2 months ago

    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.

    • @[email protected]
      link
      fedilink
      English
      92 months ago

      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…

    • @[email protected]
      link
      fedilink
      English
      82 months ago

      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)

  • HelloThere
    link
    fedilink
    English
    35
    edit-2
    2 months ago

    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.

    • @[email protected]
      link
      fedilink
      English
      62 months ago

      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.

  • @ShittyBeatlesFCPres
    link
    English
    332 months ago

    Personally, I was never great with agile projects. I get that it’s good for most and sort of used it when I was a CTO but as a solo developer, there are days when I’d rather eat a bowl of hair than write code and then some days, I’ll work all night because I got inspired to finish a whole feature.

    I realize I’m probably an exception that maybe proves the rule but I loathed daily stand-ups. Most people probably need the structure. I was more of a “Give me a goal and a deadline and leave me alone, especially at 9am.” person. (Relatedly, I was also a terrible high school student and amazing at college. Give me a book and a paper to write and you’ll have your paper. If you have daily bullshit and participation points, I’ll do enough to pass but no more.)

    • @douglasg14b
      link
      English
      252 months ago

      It’s very likely that as a sole developer you are actually practicing agile as it’s intended and not corporate “agile”.

      There isn’t a problem with agile there’s a problem with it being mislabeled and misused as a corporate & marketing tool for things that have nothing to do with agile.

    • tinyVoltron
      link
      English
      162 months ago

      Stand-ups can become so proforma. What did you do yesterday? I coded. What are you doing today? I am going to code. Do you have any blockers? No. It gets a little repetitive after a while.

      • @ShittyBeatlesFCPres
        link
        English
        52 months ago

        I did twice a week when I was management: once at the start of a sprint, once on the first Friday where we only identified blockers, and once the following Wednesday where we talked about what can ship and be ready for QA.

        The goal was to have a release fully ready on Thursday so Friday could be for emergency bug fixes but most releases are fine. If everything is perfect, great! Everyone go have a three day weekend. If QA catches a bug or two, we fix it and then ship.

        If a deadline is gonna slip, just tell me when you know. It’s not usually a big deal.

      • المنطقة عكف عفريت
        link
        English
        42 months ago

        I found them to be useful because I usee to be in an erratic team where people either get a lot done or drag projects on for years. At least the project draggers had no place to hide when needing to report their project daily.

        In my current job we only have these stand-up type meetings once weekly which made a big difference because many people had more interesting things to report and it wasn’t some kind of lip service, instead people were genuinely haring progress.

      • @Knock_Knock_Lemmy_In
        link
        English
        01 month ago

        I think you are missing the part where you help others with their blockers.

        • @jj4211
          link
          English
          31 month ago

          In my workplace, that happens in the moment of the blocker being incurred. When people are continually in communication, the daily standup is redundant and frequently for the sake of some manager/project manager who “technically” shouldn’t be part of the standup.

        • tinyVoltron
          link
          English
          11 month ago

          If someone is blocked I’d be pretty cranky if they waited until the next day to mention it. Blockers are to be dealt with swiftly and with extreme prejudice.

          • @Knock_Knock_Lemmy_In
            link
            English
            11 month ago

            Yeah. I can see in your case a stand up could be replaced with a status update message.

  • @neclimdul
    link
    English
    281 month ago

    Feels like the old php metric. PHP had a ton of great code and successful projects but it also attracted very bad devs as well as very inexperienced devs leading to a real quality problem.

    Honestly kinda see thing in a lot of JavaScript applications these days. Brilliant code but also a ton of bad code to the point I get nervous opening a new project.

    My point? It may be a tough pill but it’s not the project framework that makes projects fail, it’s how the project is run.

    • @ChickenLadyLovesLife
      link
      English
      191 month ago

      I witnessed a huge number of failed projects in my 25-year career. The cause was almost always the same: inexperienced developers trying to create a reusable product that could be applied to imagined future scenarios, leading to a vastly overcomplicated mess that couldn’t even satisfy the needs of the original client. Made no difference what the language or framework was or what development methodology was utilized.

      • Ephera
        link
        fedilink
        English
        61 month ago

        I feel like that’s the same underlying issue: The requirements are not understood upfront.

        If a customer cannot give you any specific information, you cannot cut any corners. You’re pretty much forced to build a general framework, so that as the requirements become clearer, you’re still equipped to handle them.

        I guess, the alternative is building a prototype, which you’re allowed to throw away afterwards. I’ve never been able to do that, because our management does not understand that concept.

        • @ChickenLadyLovesLife
          link
          English
          31 month ago

          I feel like that’s the same underlying issue: The requirements are not understood upfront.

          Actually on most of these failed projects the requirements of the original customer were pretty clear. But the developers tried to go far beyond those original requirements. It is fair to say that the future requirements were not well understood.

          the alternative is building a prototype, which you’re allowed to throw away afterwards

          Lol I’ve done many prototypes. The problem is that management sees them and says “oh, so we’re finished with the project already? Yay!”

      • @neclimdul
        link
        English
        41 month ago

        I’ve seen a lot of contractors over promising timelines too. “No matter how hard you push and no matter what the priority, you can’t increase the speed of light.”

        But yeah exactly.

      • @jas0n
        link
        English
        11 month ago

        Preach brother!

      • @neclimdul
        link
        English
        61 month ago

        No it’s a set of tools you can use to run a project.

        My point is that a lot of people use “agile” to mean not planning or don’t put guard rails on scope and they fail. That’s not agile, it’s just bad PM

        • @Knock_Knock_Lemmy_In
          link
          English
          21 month ago

          Agreed.

          Being Agile is being flexible. To do that you need to plan for multiple contingencies. Resulting in more planning, not none.

          • @jj4211
            link
            English
            31 month ago

            “agile” is being flexible. Being “Agile” more often than not means your company’s incompetent management paid some hack consultants to come in and bless your flavor of stupid bureaucracy as “Agile”.

    • @jj4211
      link
      English
      21 month ago

      Yeah, look at the most prolific language at a given time. There’s your crappy projects or your soon-to-be-crappy projects. What are the universities and ‘coding academies teaching’? That’s going to be the crappiest stuff in the world when those students come out.

      So too it goes with ‘management’, the popular ‘self-help’ style crap of the moment is what crappy teams will adopt, and no matter what methodology it is, that crap team is still crap, and it will reflect on that methodology.

  • Echo Dot
    link
    fedilink
    English
    25
    edit-2
    1 month ago

    Isn’t it more that people tend to use agile as an excuse for not having any kind of project plan.

    It’d be interesting to know how many of those agile projects actually had an expert project lead versus just some random person who was picked who isn’t actually experienced in project management.

    • @[email protected]
      link
      fedilink
      English
      61 month ago

      In my experience It’s not about a project plan for features, but actually doings things correctly instead of doing the minimum to finish what you need to do on the current sprint.

    • @jj4211
      link
      English
      41 month ago

      I’d say it’s that people tend to use Agile because consultants tell them they can be piss poor managers dealing with the crappiest developers and stupid business ideas and still make awesome stuff if they just make everything buzzword compatible.

      I’d say projects without much of an upfront project plan can still be very successful, but it’s all about having a quality team, which isn’t something a two week ‘training and consultancy’ session isn’t going to get you, so there’s no big marketing behind that sort of message.

    • @[email protected]
      link
      fedilink
      English
      11 month ago

      Agreed. We follow agile, and we have a team of product owners who know where the project is likely headed in the next 3 years. Our sprint to sprint is usually pretty predictable, but we can and do make adjustments when new requirements come in. The product team decides how and when to adjust priorities, and they do a good job minimizing surprises.

      It works pretty well imo, and it hinges on the product team knowing what they’re doing.

    • @masquenox
      link
      English
      01 month ago

      Isn’t it more that people tend to use agile as an excuse for not having any kind of project plan.

      I’d say it’s more about continuously milking customers on projects that never seem to end. I’ve never done software project management, but I have seen it’s “tenets” applied to other types of projects. The results were arduous - to say the least.

      • Echo Dot
        link
        fedilink
        English
        2
        edit-2
        1 month ago

        I’ve seen it being done even on internal projects though. Things within an organization.

        It tends to be that they start developing a feature and then someone comes along and says, ooh wouldn’t it be nice if it did x, so they modify it to have x feature. Then someone decides it should be able to sync with Azure (there’s always someone that wants that), so Azure sync is added, but now that interferes with x, so that has to be modified so that it can sync as well. Then we get back to original product development which is now 3 weeks behind schedule.

        Repeat that enough times and you can see why a lot of this stuff fails.

        • @jj4211
          link
          English
          21 month ago

          Even internal projects have a facet of ‘milking customers’ even those customers are internal. There’s a rather large internal team that has managed to last years by milking the fact their stuff always sucks but any moment when they are challenged about their projects they always have a plan to fix all that’s wrong within ‘3 months’.

        • @masquenox
          link
          English
          11 month ago

          During my project management days one of the things I learned the hard way is to nail down exactly what something has to deliver and getting everybody involved to sign onto it in black and white - if you don’t, disaster follows.

          Agile seems literally designed to make this impossible.

  • @Treczoks
    link
    English
    252 months ago

    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”?

      • @Treczoks
        link
        English
        42 months ago

        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…

  • @jj4211
    link
    English
    22
    edit-2
    1 month ago

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

  • @[email protected]
    link
    fedilink
    English
    201 month ago

    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.

  • @cybersandwich
    link
    English
    171 month ago

    The article even states this is a thinly veiled ad for some other “method”.

    The agile manifesto is fantastic. Scrum can work wonders as a means for providing a framework to hang “agile principles” onto.

    Most organizations don’t do “scrum” well or quickly lose sight of the “why” behind it.

    Companies are gonna company at the end of the day. Process + bureaucracy + buzzwords + ill-informed management + vendors promises + shit customers/product owners = late projects.

    Agile done right, works. The benefit agile has over waterfall(the process it replaced in a lot of places), imo, is that it’s predicated on working software, responding to change and working collaboratively/iteratively.

    • @kaffiene
      link
      English
      11 month ago

      Imo waterfall is an imagined beast for most software devs today. I worked on many successful waterfall projects. It was nowhere as bad as the caricature that people imagine.