Most software teams seem to lump together the terms Analysis and Design into one pre-development phase. This is unfortunate because with enough effort in first determining what you wish to build (aka Analysis) it is possible to understand the domain enough not to need up front architecture (aka Design).
I find this much like a children’s connect-the-dots puzzle. For example, if each user story (or requirement) is flushed out ahead of time, it might be possible to view and understand the entire domain without connecting any lines.
Understandably, it may not be possible to completely comprehend the domain solely on user stories. In essence, the definition of design or prototyping – connecting the minimum number of dots together to understand the full picture.
Determining what needs to be built is the hardest part of development. Now that the development team has a shared vision of what needs to be accomplished, they can fill in the implementation with relative ease.
This process, while simple, still takes a lot of maturity to accomplish. Some pre-develoment teams attempt to solve the entire puzzle at the same time of gathering the requirements. Attempting to solve a larger puzzle with only a subset of the information is only an exercise at best. Lack of information, misinformation, and unorganized information may all start leading your team to start drawing pictures of the domain that do not represent the true domain.
Do not fall prey to Analysis Paralysis; sometimes good enough has to be good enough. Equally as dangerous is false starting by assuming that you have enough information to act upon. Remember that being agile does not shield you from prematurely drawing a picture of a horse’s ass instead of an elephant.
