I've been doing regression testing for over 20 years, split about 50/50 between waterfall and Agile implementations. Regression testing has several characteristics, few of which are attractive no matter what framework you're in. It's a long, tedious, unpleasant process that no one really wants to do. And, as with all such processes, it is by definition prone to error (when was the last time you really put your best effort into something long, tedious, and unpleasant? When was the last time you realistically expected anyone else to?)

“If it ain’t broke, don’t fix it”; It’s a phrase that I’ve heard as long as I can remember. This was always a peculiar saying to me, because every time I heard it, I couldn’t help but ask myself the question, “but how can we make it better?”

We all want to be productive, right? But when does our desire to be productive, and our mental model of what "being productive" looks like, get in the way?

Many of us work in environments where the question "when will you be done with X?" matters. Some of the examples I have seen recently are:

• The business team wants a certain set of functional enhancements as well as performance & scalability improvements. Can we get both done? Will one need to take a back seat to the other?
• A customer has a "deployment window" that we want to hit with a certain set of functionality. Do we look like we will make it? If not, what adjustments might we make?
• A customer wants an early warning if the cost of a project is likely to go over a certain amount.