5 ms·

Exactly .... Agile works pretty well in the "execution" phase when all of the requirements are known upfront. For any kind of R&D agile is not a good fit at all

by ngc248 5y ago

Exactly .... Agile works pretty well in the "execution" phase when all of the requirements are known upfront. For any kind of R&D agile is not a good fit at all. R&D fits the waterfall model better. Ideally it should be like you do your R&D with waterfall and the agile for execution.

deleted 5y ago
[deleted]
TameAntelope 5y ago
"Waterfall works best in well-understood domains without a lot of uncertainty."[0] Agile is, by far, a more effective way to run an R&D shop. By far. "Agile teams show progress with working software, not documents. Right from the beginning. And that's huge." [1] [0] The Art of Agile Development, pp. 35 [1] The Art of Agile Development, pp. 8
- trelane 5y ago
  This presumes that software is the entirety of the problem being researched, which is not always the case. Especially as you get more physical. That said, I don't think waterfall works any better there either. Sometimes there's no way past the "muck about and find things out" work.
- dogleash 5y ago
  In my aforementioned example, the set of development practices most often called "agile" was neither the right approach nor what we did. Agile as defined as the ideas in the agile manifesto might have been what we did. It would depend on who you asked and whatever their particular axe to grind was. So I don't know, and quite frankly we didn't really care if we were "agile." All we found was that "agile" is simply too lossy of a descriptor for meaningful conversations about development process. People writing books and blogs about what they mean when they say "agile" hasn't caused the industry to coalesce on a concise definition. That horse is out of the barn, and I don't expect we're getting it back.
  - TameAntelope 5y ago
    You can be as cynical as you like, the general idea of (very) quickly iterating to stay focused on what your customer wants is a proven and effective way of build software. It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.
    - dogleash 5y ago
      I didn't know I was coming across as cynical? Just saying that I have no idea if we were "agile" because the term is so damn malleable. I do know we weren't a cookie-cutter copy of the popular SCRUM inspired workflow that's commonly just called "agile" regardless of whether the team is being "Agile."
      - TameAntelope 5y ago
        Ah okay. SCRUM is the square to Agile's rectangle. You're "lowercase a" agile if you operate under the prioritization outlined in the Agile Manifesto. I think most of the people who've found consistent success with agile would say that's what matters is more about that than about XP or SCRUM or Kanban or whatever. Those systems can help, but to be agile is to focus more on individuals, working software, customer collaboration, and responsiveness and less on processes, documentation, contracts, and plans. I hesitate even to reword the items in the manifesto, just because I know it took a lot of very smart people a good while to agree to the specific wording, and it's seemingly stood the test of time.
    - rtikulit 5y ago
      This may be true if you have no aspirations for your software beyond what your customer can imagine in the present. Almost seems like a methodology that has internalized learned helplessness.
      - TameAntelope 5y ago
        If you think the process I'm describing here is, "Ask customer what they want, do exactly what they say." then I'm not being very clear. "Don't assume that your team should build what it's told to build. Instead assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team's job is to take those ideas, test them, and learn what you should really build." [0] That's your team's job. Not to make guesses by assuming you know what's best, not to do what they're told by customers, but to run tests and use results to inform next steps. That's the entire purpose of a development team, and you simply cannot do this without a quick iterative cycle. [0] The Art of Agile Development, pp. 453

by ngc248 5y ago

deleted 5y ago

[deleted]

TameAntelope 5y ago

"Waterfall works best in well-understood domains without a lot of uncertainty."[0] Agile is, by far, a more effective way to run an R&D shop. By far. "Agile teams show progress with working software, not documents. Right from the beginning. And that's huge." [1] [0] The Art of Agile Development, pp. 35 [1] The Art of Agile Development, pp. 8

trelane 5y ago
This presumes that software is the entirety of the problem being researched, which is not always the case. Especially as you get more physical. That said, I don't think waterfall works any better there either. Sometimes there's no way past the "muck about and find things out" work.
dogleash 5y ago
In my aforementioned example, the set of development practices most often called "agile" was neither the right approach nor what we did. Agile as defined as the ideas in the agile manifesto might have been what we did. It would depend on who you asked and whatever their particular axe to grind was. So I don't know, and quite frankly we didn't really care if we were "agile." All we found was that "agile" is simply too lossy of a descriptor for meaningful conversations about development process. People writing books and blogs about what they mean when they say "agile" hasn't caused the industry to coalesce on a concise definition. That horse is out of the barn, and I don't expect we're getting it back.
- TameAntelope 5y ago
  You can be as cynical as you like, the general idea of (very) quickly iterating to stay focused on what your customer wants is a proven and effective way of build software. It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.
  - dogleash 5y ago
    I didn't know I was coming across as cynical? Just saying that I have no idea if we were "agile" because the term is so damn malleable. I do know we weren't a cookie-cutter copy of the popular SCRUM inspired workflow that's commonly just called "agile" regardless of whether the team is being "Agile."
    - TameAntelope 5y ago
      Ah okay. SCRUM is the square to Agile's rectangle. You're "lowercase a" agile if you operate under the prioritization outlined in the Agile Manifesto. I think most of the people who've found consistent success with agile would say that's what matters is more about that than about XP or SCRUM or Kanban or whatever. Those systems can help, but to be agile is to focus more on individuals, working software, customer collaboration, and responsiveness and less on processes, documentation, contracts, and plans. I hesitate even to reword the items in the manifesto, just because I know it took a lot of very smart people a good while to agree to the specific wording, and it's seemingly stood the test of time.
  - rtikulit 5y ago
    This may be true if you have no aspirations for your software beyond what your customer can imagine in the present. Almost seems like a methodology that has internalized learned helplessness.
    - TameAntelope 5y ago
      If you think the process I'm describing here is, "Ask customer what they want, do exactly what they say." then I'm not being very clear. "Don't assume that your team should build what it's told to build. Instead assume the opposite: nobody really knows what you should build, not even the people asking for it. Your team's job is to take those ideas, test them, and learn what you should really build." [0] That's your team's job. Not to make guesses by assuming you know what's best, not to do what they're told by customers, but to run tests and use results to inform next steps. That's the entire purpose of a development team, and you simply cannot do this without a quick iterative cycle. [0] The Art of Agile Development, pp. 453