4 ms·

It's certainly preferable to team of analysts spending 6 months writing specs, then engineers spending 12 months writing code, then 2 years spent testing and fi

It's certainly preferable to team of analysts spending 6 months writing specs, then engineers spending 12 months writing code, then 2 years spent testing and fixing things only to find out that while that's all been happening the internets been invented and the original product has no purpose.

ssmoot 11y ago
Anecdotal, but I've never been witness to a project where requirements changed so drastically it led to failure. I've seen MANY "Agile" projects where effectively no analysis was done however. Which then reliably leads to failure. EDIT: To add: If the success metric you're using is: From the client's perspective, do they get what they asked for, when they were promised, for the price they agreed to? Then I've seen a majority of "Waterfall" like projects succeed. And the ones that don't typically "fail fast" in the analysis phase. I've never seen an Agile project meet that bar. By the time they're canned they're usually already way over budget and while a team might imagine they've "delivered value" the projects are (IME) canned specifically because it became evident they would most likely be handed over to another vendor and the delivered version scrapped entirely at some point. I also find it frustratingly comical that projects are routinely compared to assembly line work (Toyota assembly line philosophies) when they have a lot more in common with the design and development phases of car production. Agile in the small perhaps, but overall an incredibly structured process with a lot of planning and analysis. Unless you want a car launch 3 years late that costs 50% more than you promised. Nobody wants an "Agile" car (unless you've already set aside your deposit for a Tesla Model 3 I suppose ;-) ). If I were a client, there's no way I'd ever give a anything bigger than a low six figure project to an Agile shop. For a process intended to lower risk, I've only seen it do the opposite.
saiya-jin 11y ago
i've seen exactly 0 of this type of projects you describe in corporate multinational environemnt (or any other for that matter). in any non-agile corp i've been, projects are usually a mix, where analysis doesn't finish when dev starts, testing is ongoing with dev, just shifted a bit. and when these projects go fubar, it's usually caused my forces far away from delivery team. rarely, it's really fault of team not delivering, but agian, situation is so complex and uncontrollable, that putting everything and everybody (including all stakeholders) into agile wouldn't probably make a big difference in go/nogo call. agile approach brings quite a few aspects that developers like and they just feel right (or at least better), but frankly, it's overhyped. just another tool/approach to certain set of situations, in certain conditions
- jacques_chester 11y ago
  > i've seen exactly 0 of this type of projects you describe in corporate multinational environemnt I work in Pivotal Labs. I happen to be working on such a project with one of the world's largest financial firms. Across the hall from me is another team working with that company. Behind me are three teams working for a retail giant, in front two teams working for a large insurer. In the same office I've seen everything from iphone scroller games, to startup apps, to microservice migrations, to entire product categories, being created this way. Collectively, Pivotal Labs has helped develop thousands of products for hundreds of clients with a collective business value in the billions. I invite you to visit any of our offices to see it for yourself. Email me: jchester@pivotal.io and I'll set it up.

ssmoot 11y ago

Anecdotal, but I've never been witness to a project where requirements changed so drastically it led to failure. I've seen MANY "Agile" projects where effectively no analysis was done however. Which then reliably leads to failure. EDIT: To add: If the success metric you're using is: From the client's perspective, do they get what they asked for, when they were promised, for the price they agreed to? Then I've seen a majority of "Waterfall" like projects succeed. And the ones that don't typically "fail fast" in the analysis phase. I've never seen an Agile project meet that bar. By the time they're canned they're usually already way over budget and while a team might imagine they've "delivered value" the projects are (IME) canned specifically because it became evident they would most likely be handed over to another vendor and the delivered version scrapped entirely at some point. I also find it frustratingly comical that projects are routinely compared to assembly line work (Toyota assembly line philosophies) when they have a lot more in common with the design and development phases of car production. Agile in the small perhaps, but overall an incredibly structured process with a lot of planning and analysis. Unless you want a car launch 3 years late that costs 50% more than you promised. Nobody wants an "Agile" car (unless you've already set aside your deposit for a Tesla Model 3 I suppose ;-) ). If I were a client, there's no way I'd ever give a anything bigger than a low six figure project to an Agile shop. For a process intended to lower risk, I've only seen it do the opposite.

saiya-jin 11y ago

i've seen exactly 0 of this type of projects you describe in corporate multinational environemnt (or any other for that matter). in any non-agile corp i've been, projects are usually a mix, where analysis doesn't finish when dev starts, testing is ongoing with dev, just shifted a bit. and when these projects go fubar, it's usually caused my forces far away from delivery team. rarely, it's really fault of team not delivering, but agian, situation is so complex and uncontrollable, that putting everything and everybody (including all stakeholders) into agile wouldn't probably make a big difference in go/nogo call. agile approach brings quite a few aspects that developers like and they just feel right (or at least better), but frankly, it's overhyped. just another tool/approach to certain set of situations, in certain conditions

jacques_chester 11y ago
> i've seen exactly 0 of this type of projects you describe in corporate multinational environemnt I work in Pivotal Labs. I happen to be working on such a project with one of the world's largest financial firms. Across the hall from me is another team working with that company. Behind me are three teams working for a retail giant, in front two teams working for a large insurer. In the same office I've seen everything from iphone scroller games, to startup apps, to microservice migrations, to entire product categories, being created this way. Collectively, Pivotal Labs has helped develop thousands of products for hundreds of clients with a collective business value in the billions. I invite you to visit any of our offices to see it for yourself. Email me: jchester@pivotal.io and I'll set it up.