We all knew it

  • @[email protected]
    link
    fedilink
    English
    05 months 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”.

    • @[email protected]
      link
      fedilink
      English
      25 months 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.

      • @[email protected]
        link
        fedilink
        English
        15 months 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.