5 ms·

> "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 pro

• Aurornis 2y ago
  Every agile coach always tells me that agile is whatever works for the team. Conveniently, if something isn’t working they dismiss it as not true agile. Of course, all of the processes and meetings they push on to the team don’t actually work out, but they’re long gone by then.
  • boxed 2y ago
    I mean.. "science" is what works too. If something turns out to be false, we throw it out and say it's not science. This is good. I don't see a problem with this at all. But pushing useless stuff that doesn't work and then leaving, yea that's not agile :P
    • giantg2 2y ago
      Science has proven methodologies to it and those are explicitly taught, followed, and reviewed. Agile coaches offer no real guidance if the bulk of the advice is "do what works". No shit...
      • boxed 2y ago
        The methodologies were discovered after the fact though. The only real scientific method is "if you are a winner you are with us". In fact, plenty of scientific methodologies are NOT tested and probably super bad, like the modern peer review system, or grant writing/proposal/reviews.
        • giantg2 2y ago
          Neither of those are methodologies for actual science, but rather publication and funding issues. The methodology most closely related to peer reviews would be idea of reproducibility. There are plenty of peer reviewed things that fail reproducibility.
          • boxed 2y ago
            Many people think it's not science if it's not peer reviewed.
  • pseudalopex 2y ago
    > Every agile coach always tells me that agile is whatever works for the team. Most so called agile coaches are scrum prescriptivists in my experience.
• oriel 2y ago
  Probably the originally intended Agile [1] These days its been devolved into micromanagement musical chairs of pain. The kind that promotes what it professes to prevent and provide. [1] https://agilemanifesto.org/ https://agilemanifesto.org/
  • boxed 2y ago
    Yea, like when people say they are Christians but are against helping the poor. Pretty clearly not Christians in any reasonable definition...
    • falcor84 2y ago
      Isn't "Christian" one of those predicates where identifying as such (public profession of faith) is what makes you one? I mean unless you're going for a denomination that requires baptism.
      • boxed 2y ago
        Yea, that's what it has devolved into. At least Catholicism can protect its brand against crazy stuff like that. The agile guys should have done something like that from the start... if they had known what was coming.
  • jvanderbot 2y ago
    Before someone says "No true scottsman", consider that "Agile" is supposed to mean: > People over processes and > Responding to change over plans And capital-A-agile is literally a textbook process.
• fook-dang 2y ago
  "prevent developer burnout." ...Frankly I think all the standups & the pressure from constantly asking me if I am contributing (every single day?!) instead of trusting that I am... burns me out. I don't mind 2-3 standups per week, 15 mins max. But 5x 30 minute standups... Is exhausting. It feels like a lack of trust from product managers. Oh yeah... and unqualified, zero engineering experience, diversity-hire product managers. That's super annoying-- being managed by people who did not obtain their role via the route expected of an engineer (having demonstrable engineering skills)
  • sroussey 2y ago
    It’s a synchronization primitive, not the only kind available but most popular. It should not be 30min. Maybe 10. And it’s not a test of your contribution. It’s part of being a team.
    • projektfu 2y ago
      "Why is it called a stand-up meeting?" "So we are incentivized to get it done quickly and go back to our desks." "Ah, so if we sit down we can make the meeting longer...."
  • adastra22 2y ago
    The equation of "agile = standups" has done more harm to agile (and projects using it) than anything else. I run a company and we use a lot of agile project planning methods, but threw out the standup. Especially in the era of remote work and varying timezones, it makes no sense at all.
  • thaanpaa 2y ago
    That's all kinds of wrong. A stand-up is supposed to take 15 minutes max, and if no one is stuck with anything, it shouldn't take more than just a couple of minutes. It's not supposed to be a "status meeting" at all.
    • thayne 2y ago
      Unfortunately, in practice,that doesn't seem to happen very often.
• giantg2 2y ago
  "robust requirements engineering process" I worked on one team that had this and it was amazing. It implicitly helped with burnout too. It was an "Agile" team, but we followed more of a scrumifall model that worked well for that project. I've been on a bunch of Agile teams (some more than others) since then, but the requirements processes are all garbage. Then the leaders wonder why things take so long, there's so many bugs, burnout is high, etc. It's really not surprising.
  • farresito 2y ago
    Could you expand a little bit on what the "robust requirements engineering process" was like on that one team?
    • giantg2 2y ago
      It was an app that was heavily focused on business processes, like routing items between different groups. We had spreadsheets and process maps for each business process. This means the business actually had to think about the possible routes it could take and the data required on each step. So the spreadsheet would tell us all the possible data exposed on the step including how it was treated (R, RW, required, formats/types, etc). It was magical. Once a process was created the business would have to sell any process changes to the product owner by either showing it was a regulatory/legal issue, or using a cost study to show it would save money. So not back and forth or superfluous changes.
      • kohbo 2y ago
        This is the type of engineering method that I try to instill in my teams. It's very dependant on good practices at every level of requirements management.