My thought on this is that both sides can be right in some respects. I’m not a big fan of Fowler and Sadalage’s idea of multiple columns (old value and new value) and slowly weaning people off of the old value. That’s a recipe for disaster unless everybody involved has a complete understanding of what the columns mean and the business rules behind them. Most likely, you’ll end up with people misinterpreting them or different systems pulling different values and leading to different numbers.
On the other hand, Fowler and Sadalage talk about change scripts and versioning. This is an excellent practice. Reverting the actual data is a complex problem and so not all of these scripts are easy to pull off—especially if you drop columns—but putting some extra work into archival tables and backwards-compatibility views does pay off.
Also, in LaRock’s comments section, a couple of people bring up coding against stored procedures (and views, though I’m somewhat ambivalent about that). This is a good practice and can help with version changes.
So, now that I’ve said something good, I have to go back to saying something bad about the “agile” world. With good people, you tend to get good results; with bad people, you tend to get bad results. You can argue about whether certain practices shift the margins of value somewhat (and even that good people will ipso facto perform certain activities), but certain methods will not make bad developers write good code, especially when lazy developers interpret “flexibility” as “We don’t need no steenkin’ requirements.”