4 ms·

The thing I don't understand about agile is that many projects require a year+ investment before anyone will use it. e.g. say you're building a competitor to Go

The thing I don't understand about agile is that many projects require a year+ investment before anyone will use it. e.g. say you're building a competitor to Google Docs. How do you get any real user feedback after < a year of work by a substantial team of engineers? No one is going to want to use your prototype that barely does anything. Or worse yet, your backend that doesn't even have a UI yet, and also barely does anything.

Jtsummers 5y ago
In that case you don't have a customer, you have to dog-food it. Most of the time when agile references a customer, customer feedback, and customer interaction it's actually the customer contracting the work. That is a different context than a startup or video game developer or others because there is a clear customer stakeholder who can provide feedback and validation from the start. This gets to part of the problem in all these discussions. The context that the Agile Manifesto was written in was not in creating Facebook or Google, but in creating software for a defined customer who held a stake in the outcome (had invested capital, along with wanting/needing the results). Once written, something like your Google Docs replacement can get a customer stakeholder, but they won't have it at the start unless you line up early users (and even then, they probably aren't invested).
- allturtles 5y ago
  In that case, I have never worked in the context for which Agile was intended, and neither, I suspect, have a significant proportion of all working software developers. That may explain many of the disconnects in these conversations.
  - Jtsummers 5y ago
    Well, that's not the only case it was intended for. But the language around customers is colored by that context.
- geodel 5y ago
  Indeed. They way I understand Agile/Scrum in enterprises is basically a dogmatic process around implementing a bog standard CRUD app Nth time. Minor details keep changing from customer to customer. It should be clear to folks that complex technology products in past were not developed by caricature of Waterfall method that Agile peddlers show on slides. Neither today interesting engineering products are developed following some "methodology industry".
LadyCailin 5y ago
In this case, you do user research with mock-ups and other extremely low effort prototypes. But the work done in that regard is the same for agile and waterfall. If you truly do have a project where the MVP will take a year, and the prototypes would be useless until that year is up, then it probably doesn’t matter which methodology you use in that first year.

Jtsummers 5y ago

In that case you don't have a customer, you have to dog-food it. Most of the time when agile references a customer, customer feedback, and customer interaction it's actually the customer contracting the work. That is a different context than a startup or video game developer or others because there is a clear customer stakeholder who can provide feedback and validation from the start. This gets to part of the problem in all these discussions. The context that the Agile Manifesto was written in was not in creating Facebook or Google, but in creating software for a defined customer who held a stake in the outcome (had invested capital, along with wanting/needing the results). Once written, something like your Google Docs replacement can get a customer stakeholder, but they won't have it at the start unless you line up early users (and even then, they probably aren't invested).

allturtles 5y ago
In that case, I have never worked in the context for which Agile was intended, and neither, I suspect, have a significant proportion of all working software developers. That may explain many of the disconnects in these conversations.
- Jtsummers 5y ago
  Well, that's not the only case it was intended for. But the language around customers is colored by that context.
geodel 5y ago
Indeed. They way I understand Agile/Scrum in enterprises is basically a dogmatic process around implementing a bog standard CRUD app Nth time. Minor details keep changing from customer to customer. It should be clear to folks that complex technology products in past were not developed by caricature of Waterfall method that Agile peddlers show on slides. Neither today interesting engineering products are developed following some "methodology industry".

LadyCailin 5y ago

In this case, you do user research with mock-ups and other extremely low effort prototypes. But the work done in that regard is the same for agile and waterfall. If you truly do have a project where the MVP will take a year, and the prototypes would be useless until that year is up, then it probably doesn’t matter which methodology you use in that first year.