3 ms·

I used to work at an R&D company. While that cadence is possible in a website mill, it’s a laughable blanket statement.

diggs 5y ago
Agreed - I’ve spent months working on a deep tech problem before I could even show a functional core, let alone putting it into production. Some problems take time, experience and foresight to solve and the solution only dovetails at the end.
gffrd 5y ago
Just wanted to say thank you for "website mill" … I'm reminded of this stark difference when talking with a friend who builds ultrasonic hardware.
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.
nitrogen 5y ago
Keeping a daily log of progress helps prove your research is original.

Agreed - I’ve spent months working on a deep tech problem before I could even show a functional core, let alone putting it into production. Some problems take time, experience and foresight to solve and the solution only dovetails at the end.

gffrd 5y ago

Just wanted to say thank you for "website mill" … I'm reminded of this stark difference when talking with a friend who builds ultrasonic hardware.

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.

nitrogen 5y ago

Keeping a daily log of progress helps prove your research is original.