Discussion about this post

User's avatar
Jeff Grigg's avatar

In traditional pre-agile software development, the cost of change does indeed rise substantially, maybe even exponentially, over time. The cost of testing goes up. The risks of regressing functionality when making changes goes up.

But the big change in perspective, which you led, was to realize that things did not have to be this way: Instead of making decisions based on fixed cost-benefit curves and calculations, we could instead dramatically reduce those future costs with changes in the process of building the software.

Likewise, the "I have to ask for everything up-front or I won't get it." is an inevitable result of the way we fund and make decisions on improvement initiatives -- "projects." As an industry, we usually structure it that way. But we don't have to. With build and delivery approaches that enable iterative delivery with substantial change over time, without excessively increasing costs, one can sensibly do iterative requirements specification too.

It's not just a different view of fixed cost-benefit curves. It's a fundamental changing of the curves themselves.

Expand full comment
Gizem Saruhan's avatar

Your draws triggered me (because of ocd) but it worthed! Thank you.

Expand full comment
8 more comments...

No posts