> But if you’re designing and developing something fairly well understood…
There in lies the problem; building software is not like building a house.
I've seen many projects at Big Co fail to deliver on time, budget or quality because senior managers believed that everything is "fairly well understood" up front when just wasn't true.
That mistake leads to treating estimates as concrete delivery times, scaling the development team before it's ready and a refusal to fix things that hurt productivity because they're not on the unchangeable timeline.
The author is correct Scrum is usually sabotaged by outside influences trying to turn it into waterfall.
If IBM couldn't make waterfall work in the 1970s it's very unlikely that will work anyone's big project today either.
There in lies the problem; building software is not like building a house.
I've seen many projects at Big Co fail to deliver on time, budget or quality because senior managers believed that everything is "fairly well understood" up front when just wasn't true.
That mistake leads to treating estimates as concrete delivery times, scaling the development team before it's ready and a refusal to fix things that hurt productivity because they're not on the unchangeable timeline.
The author is correct Scrum is usually sabotaged by outside influences trying to turn it into waterfall.
If IBM couldn't make waterfall work in the 1970s it's very unlikely that will work anyone's big project today either.