Some of the major problems with traditional, waterfall-style approaches to software development projects are caused by their lengthy, formal analysis and design phases at the beginning of the project. The problems caused include:
- the analysis and design phases taking much longer than originally
expected squeezing the schedule for both development and testing phases.
- the results even if beautifully formatted, are incomplete,
ambiguous, over-specified in areas that are generally familiar, and
under-specified in areas that are not, with a fair share of errors
- communication between specialist teams is mainly by text and diagrams, less efficient than face-to-face.
Much of the appeal of early agile approaches like eXtreme Programming was the eschewing of lengthy, formal analysis and design phases at the beginning of the project.
The major premise behind eXtreme Programming was originally to avoid doing unnecessary work by doing the simplest thing to meet the requirements currently being work upon, and postponing everything else until the last responsible moment. Nevertheless, even eXtreme Programming advocated creating an overall metaphor for the system at the start the project. It neglected to explain in any detail what form this metaphor should take and how much time should be spent producing and agreeing it.
Similarly, Scrum expects the Product Owner to prepare an initial Product Backlog
but deliberately does not elaborate on how this should be done and to
what level of refinement before the first Sprint Planning session.
Unfortunately, in many cases, this under specification has led to anybody wanting to do any form of initial analysis and design before coding started being dogmatically derided as being a proponent of BDUF (Big Design Upfront). This took software development to the opposite extreme of BDUF. We had NTUF projects, No Thought Upfront, and this proved equally disastrous.
As usual with extremes, the pendulum eventually starts to swing back to the centre, and a more pragmatic view emerges. Feature-Driven Development (FDD) has always espoused the benefits of building an initial, overall object model as a means of building a shared understanding of the overall problem domain. The idea is not to nail down detailed requirements, or make low-level design decisions, and it is certainly not the goal to produce a comprehensive, detailed object model in some overly-complicated and expensive UML modeling tool. The idea is to do just enough analysis and design to make the building of a reasonable, initial, overall feature's list and plan possible.
This sort of pre-development iteration work is increasingly appearing as discovery or exploration phases. I call this Jedi work; Just Enough Design Initially. Of course the obvious question is how much is just enough? The equally obvious answer is that it depends. For example, if you find yourself specifying the precise types of primitive attributes in class definitions, it is well past time to stop. However, if you have not spent any time on some significant areas of the problem domain you know are within scope, you still have initial work to do.
While rules of thumb might exist, the answer to how much is just enough is ultimately a judgment call made by the team based on experience. After all, one does not become a Jedi Master overnight.
Of course, even within this initial work, agile principles apply. The accelerated analysis process for this initial work pioneered by Peter Coad and adopted and adapted for FDD by Jeff De Luca involves cross-functional teams working iteratively, delivering frequent, usable results especially when combined with Peter Coad's 'modeling in color' strategis and patterns.