4 ms·

Trying to 'kill the old ways' without understanding them is how we get junk such as Scrum. Agile is just fast Waterfall with iteration. Waterfall is naturally

by aa-jv 4y ago

Trying to 'kill the old ways' without understanding them is how we get junk such as Scrum. Agile is just fast Waterfall with iteration. Waterfall is naturally inherent in the process of going from idea -> working software that a user can use - Agile takes those inherent factors and makes the developer more responsible for them, in smaller, tighter, more Jira-friendly chunks. If you can do Waterfall properly, you are ready to do Agile properly. If you can't do Waterfall properly, do not pass go, do not collect $200 Agile Dollars: learn Waterfall first. Agile fails because Waterfall is not understood well by newbies and grey-beards, alike. You will see Waterfall in every Agile cycle - Waterfall describes the natural condition of software. Agile provides tools to rapidly manifest those conditions. Disclaimer: 40 years of software development. I've seen some shit. Waterfall is real. Be agile about it if you must.

deleted 4y ago
[deleted]
p0nce 4y ago
Hot-take: Agile is for service work, where the customer can't explain the problem very well yet, and you can take the reputation damage of showing half-work. Product work should have some amount of discovery, but derisked by user research (and thus is more waterfall) and thus will be released polished.
- thunderbong 4y ago
  If the customer can't explain the problem very well, then how will they verify the software is doing what they're expecting?
  - p0nce 4y ago
    Can't explain entirely before having something in front of them.
  - alwaysbeconsing 4y ago
    Many if not most people are better at describing "what should be different" given a concrete thing than they are at describing "what should be" given a blank sheet. The idea is to build that fact into the work plan.
  - thunderbong 4y ago
    I agree with both the sibling comments. However, in my opinion, in a scenario where the customer is not clear about what they want without something in front of them, it is better to create a high fidelity click through design prototype, rather than actual code. Finally, I'm personally very averse to finalise requirements where the customer is suggesting or dictating UI. Many times, there's a better way to fulfill their requirements by identifying what they want, in textual format, rather than asking them from the UI perspective.
- cratermoon 4y ago
  It's been well-demonstrated that users can't articulate what they really want. I don't recall the source, but I read one observation, "users will ask for a toaster in their car's dashboard when their real problem is that they don't have time to make make breakfast in the morning". You can do all the research you want on in-car toasters to get the optimal product, but you still aren't really solving the right problem.
cratermoon 4y ago
> Trying to 'kill the old ways' without understanding them is how we get junk such as Scrum. You can hardly do better in understanding the "old ways" than reading Royce's paper. And the difference between Waterfall and Agile is not just iteration, it's rapid feedback. As noted in Royce's paper, Waterfall is inherently one way, hence the name. You don't see water flowing uphill, at least not without a lot of external force. Agility means feedback comes at every step of the way, not just at the end, when testing. This is also the difference between what's been called "the Toyota way" vs prior automobile manufacturing. In the traditional automobile factory, the car was put together and completed, then a team of engineers would exercise it to find and fix defects. The Toyota was was to find and fix defects along the assembly line, and perhaps more importantly, learn from defects found during assembly to prevent or reduce defects before they appear. The same applies to Waterfall vs. Agile. Instead of completing the entire system and then testing it and fixing defects, as waterfall would have, even when done iteratively, agility works out the defects in every aspect and uses what's found to reduce the rate of defect creation.

by aa-jv 4y ago

deleted 4y ago

[deleted]

p0nce 4y ago

Hot-take: Agile is for service work, where the customer can't explain the problem very well yet, and you can take the reputation damage of showing half-work. Product work should have some amount of discovery, but derisked by user research (and thus is more waterfall) and thus will be released polished.

thunderbong 4y ago
If the customer can't explain the problem very well, then how will they verify the software is doing what they're expecting?
- p0nce 4y ago
  Can't explain entirely before having something in front of them.
- alwaysbeconsing 4y ago
  Many if not most people are better at describing "what should be different" given a concrete thing than they are at describing "what should be" given a blank sheet. The idea is to build that fact into the work plan.
- thunderbong 4y ago
  I agree with both the sibling comments. However, in my opinion, in a scenario where the customer is not clear about what they want without something in front of them, it is better to create a high fidelity click through design prototype, rather than actual code. Finally, I'm personally very averse to finalise requirements where the customer is suggesting or dictating UI. Many times, there's a better way to fulfill their requirements by identifying what they want, in textual format, rather than asking them from the UI perspective.
cratermoon 4y ago
It's been well-demonstrated that users can't articulate what they really want. I don't recall the source, but I read one observation, "users will ask for a toaster in their car's dashboard when their real problem is that they don't have time to make make breakfast in the morning". You can do all the research you want on in-car toasters to get the optimal product, but you still aren't really solving the right problem.

cratermoon 4y ago

> Trying to 'kill the old ways' without understanding them is how we get junk such as Scrum. You can hardly do better in understanding the "old ways" than reading Royce's paper. And the difference between Waterfall and Agile is not just iteration, it's rapid feedback. As noted in Royce's paper, Waterfall is inherently one way, hence the name. You don't see water flowing uphill, at least not without a lot of external force. Agility means feedback comes at every step of the way, not just at the end, when testing. This is also the difference between what's been called "the Toyota way" vs prior automobile manufacturing. In the traditional automobile factory, the car was put together and completed, then a team of engineers would exercise it to find and fix defects. The Toyota was was to find and fix defects along the assembly line, and perhaps more importantly, learn from defects found during assembly to prevent or reduce defects before they appear. The same applies to Waterfall vs. Agile. Instead of completing the entire system and then testing it and fixing defects, as waterfall would have, even when done iteratively, agility works out the defects in every aspect and uses what's found to reduce the rate of defect creation.