4 ms·

I personally think that it is all matter of risk. The risk of contract work (which is what the agile manifesto writers were facing most of their careers [they a

I personally think that it is all matter of risk. The risk of contract work (which is what the agile manifesto writers were facing most of their careers [they are all consultants), is building something that the customer do not want or did not intend do. The actual tech risk is very low (e.g. ruby on rails on postgres) since most of them use mature technology. In this case the agile manifesto make sense - I.e. we can build something really fast and literally ask the customer if this is what he wants every two weeks. When you building hard tech products (e.g. borg or tensorflow), the actual risk is technology and competition, and since this is new technology, there are not that many customers. In this case the risk is in the architecture (i.e. it would be hard to change the core architecture) and in the technology, since you do not know what kind of application will be build on top of this new technology. In addition, you face general competition risk, since the market can usually absorb only one dominant architecture. So in this case, you invest much more time in design and careful construction.

hinkley 7y ago
Even without mature technology, you want to shake down the new tech early to find out if it’s going to crumble around your shoulders at the worst possible moment. While Agile is not perfect for this kind of work, it does have a lot of facility in this area. Now if you could just get any two people to agree on what constitutes the last responsible moment... And with new tech you often have to do it first or do it better. Oddly I find Agile seems to work better for “do it better” because if it’s easier for you to add features than your competitor, they will probably get burned out before you do. If you can survive that long you start to pull ahead.
- streetcat1 7y ago
  So, just from observation, when developing new tech, there is always LAST to market advantage. MS was LAST to market. Google was LAST to market. Kubernetes was LAST to market. Apple was LAST to market (After MS and Palm). I think that Agile is good after the market is captured. But when developing the core tech (usually with no customers beside product managers and based on research), it might be too constraining.
  - hinkley 7y ago
    I’ve observed the same thing. I’ve also observed that the dogma in the startup world is exactly opposite. Everything is about version 1 and there is nothing left in the tank for version 2. The whole MVP thing is more about selling demoware to investors. It just sounds like it’s being supportive and it gets them what they want. They don’t give one shit about what happens 18 months from now. That’s somebody else’s problem. There’s always someone with a higher pain tolerance they can hire (note: pain tolerance is negatively correlated with capacity to anticipate problems before they become emergencies). And there’s always advertising or mergers to mask the real problems.
  - agency 7y ago
    There's a last to market advantage in the same way that "you always find things in the last place you look"
  - Nomentatus 7y ago
    Gates made this argument strongly, in public, before getting nailed a couple of times - the latest big smackdown being Android, as he's confessed recently. "Last to market" is often "first to market with the truly appropriate technology."
andrewmutz 7y ago
I agree 100%. You should be continuously delivering in a way that allows you to learn about the area of greatest risk. For much of what Agile development is applied to, the greatest risk is market risk. You want to get something out to users as quickly as possible to see if your assumptions about your users and their needs are right. For google style projects, there is primarily technology risk rather than market risk. If you are trying to build something that is obviously useful but is perhaps impossible, it makes sense to focus on delivering working systems that allow you to see if your assumptions about technological limitations are correct.
jammygit 7y ago
Suppose you are a Series <X> startup with a very large amount of technology to build before you surpass your competitors. In order to do a better job, you have to adjust things constantly in response to customer feedback. Presupposing that there are years of feature work to be done, do you go with Agile, or waterfall?

hinkley 7y ago

Even without mature technology, you want to shake down the new tech early to find out if it’s going to crumble around your shoulders at the worst possible moment. While Agile is not perfect for this kind of work, it does have a lot of facility in this area. Now if you could just get any two people to agree on what constitutes the last responsible moment... And with new tech you often have to do it first or do it better. Oddly I find Agile seems to work better for “do it better” because if it’s easier for you to add features than your competitor, they will probably get burned out before you do. If you can survive that long you start to pull ahead.

streetcat1 7y ago
So, just from observation, when developing new tech, there is always LAST to market advantage. MS was LAST to market. Google was LAST to market. Kubernetes was LAST to market. Apple was LAST to market (After MS and Palm). I think that Agile is good after the market is captured. But when developing the core tech (usually with no customers beside product managers and based on research), it might be too constraining.
- hinkley 7y ago
  I’ve observed the same thing. I’ve also observed that the dogma in the startup world is exactly opposite. Everything is about version 1 and there is nothing left in the tank for version 2. The whole MVP thing is more about selling demoware to investors. It just sounds like it’s being supportive and it gets them what they want. They don’t give one shit about what happens 18 months from now. That’s somebody else’s problem. There’s always someone with a higher pain tolerance they can hire (note: pain tolerance is negatively correlated with capacity to anticipate problems before they become emergencies). And there’s always advertising or mergers to mask the real problems.
- agency 7y ago
  There's a last to market advantage in the same way that "you always find things in the last place you look"
- Nomentatus 7y ago
  Gates made this argument strongly, in public, before getting nailed a couple of times - the latest big smackdown being Android, as he's confessed recently. "Last to market" is often "first to market with the truly appropriate technology."

andrewmutz 7y ago

I agree 100%. You should be continuously delivering in a way that allows you to learn about the area of greatest risk. For much of what Agile development is applied to, the greatest risk is market risk. You want to get something out to users as quickly as possible to see if your assumptions about your users and their needs are right. For google style projects, there is primarily technology risk rather than market risk. If you are trying to build something that is obviously useful but is perhaps impossible, it makes sense to focus on delivering working systems that allow you to see if your assumptions about technological limitations are correct.

jammygit 7y ago

Suppose you are a Series <X> startup with a very large amount of technology to build before you surpass your competitors. In order to do a better job, you have to adjust things constantly in response to customer feedback. Presupposing that there are years of feature work to be done, do you go with Agile, or waterfall?