book, Refactoring to Patterns , addresses this issue in a somewhat different way. By discussing refactoring in the context of patterns, Kerievsky shows that just refactoring isn't enough. You have to refactor to a good design concept (a pattern). Examining the works of other Agilists indicates a similar pattern that supports both refactoring and evolutionary design (i.e. Scott Ambler's Agile Modeling and Martin Fowler's Patterns of Enterprise Architecture , Refactoring: Improving the Design of Existing Code ). Ambler and Fowler propose developing a good conceptual design (anticipation) and then evolving it over the life of a project (adaptation). This is not the same as BUFD. It's conceptual design (fast, flexible, and informal) followed by evolutionary design (of which refactoring is a part), based on concrete feedback.
Getting back to business process analysis, I am in no way advocating a return to the huge up-front requirements definition disasters of prior years, but I do believe that many development efforts could benefit from better business process (or product) understanding by the development team. Some degree of business process understanding, rationalization, and automation potential needs to be anticipated in early planning so that the later details, like features and use cases, can be put into context. Furthermore, business process design should be evolutionary, just like the software design: develop an initial business process framework or skeleton, implement both the software and the improved business processes incrementally, and then adapt both the process and the software.
The prime Agile mantra is to deliver customer value. Paving the cow paths doesn't usually deliver the highest value, so maybe a little attention anticipating business process design can raise the value we deliver.