There is no Agility without timely Acceptance

There is no agility without timely acceptance of features or changes. Need I say more?

If you answered no then don't waste your precious time reading any further.

For the rest of you I will continue.

Lack of timely acceptance of features/changes requires detailed requirements, which in turn leads to traditional waterfall development. "What?" you say. "Yes!" I say, "Big Up Front Requirements gathering which necessitates flow charts, prototypes, etc..., and other such activities will become necessary."

When a feature/change is completed and the users of the product run the features on real data and on real hardware and finds issues the developer will still remember the changes needed for the implementation. Therefore the developer is more likely to correct the issues in the right places.

When a feature/change is completed and the users do not exercise the new code for days, weeks, or months the developer may have difficulty correcting any issues found. Why? The most common cause of difficulty is that the developer doesn't remember the ramifications of the changes. The developer will have to find the changes in the revision control system and review the check-in comments and maybe even walk through the code in the debugger just to get their mind wrapped around the code again. Even worse (and yet very common) is that the changes were built upon and used by other aspects of the product. Now the developer or developers have to figure out all of the possible side effects of working on this code because it is coupled to other features!

At this point the developer will say, "Enough is enough. Next time you tell me exactly what you want in great detail. You spend your time and effort instead of you spending mine."

Why will the developer say such a thing? Continuing with the above scenario (based on real world experience) the developer knows that since the acceptance test of this feature has taken so long that the odds are that the related features have not been used either. It is possible that the related features work correctly, and in that case the code has to remain the same for those features and all new code has to be developed for the feature in question. It is possible that none of the related features built are correct and that some should be one way and some another. Do you get the picture now?

Such work is very costly. It costs time, money, and morale.

Maybe I will blog about Morale Debt some day (previous posts have been made on Code Debt, Market Debt, Product Debt, etc).

Without timely acceptance of features/changes the costs of corrections increase. In an attempt to avoid issues caused by untimely acceptance the natural tendency is to require more detailed specifications, requirements, and designs. When this happens you can officially kiss Agility good bye.

Acceptance of features/changes by users is more important to me that having unit tests! If you made me choose between users giving timely feedback on acceptance or having unit tests I would take the users timely feedback.

Timely acceptance, in my opinion, is less than three days.

If you do not have timely acceptance of features/changes then you can be sure your development process is not Agile. Being Agile shouldn't be the goal, but being efficient should be the goal. Maybe I should rename this post to: "There is Waste without timely Acceptance". Yes, I like that title better!