November 11
Agile and Just-Enough Design
I'm always amazed at the number of people that believe that if you are doing agile you do not do analysis or design. What changes with agile is not whether you do them, but when you do them or to quote Kent Beck "[the] question is not whether or not to design, the question is when to design".
Agile collapses the waterfall model: analysis-design-code-test into a single phase: build that includes all activities all the time. So we write our code test-first, folding our testing activity into the act of implementing; we design as we implement, revising our theory of how to deliver a software solution as we deliver it. The reason agile takes this approach is feedback. By merging these three activities each one gives rapid feedback on the others and makes change easy (and cheap). So the first thing to recognize is that agile does all the activities, just all the time. The second thing to recognize is that agile does its analysis, design, and testing at the same time as development to avoid wasted effort. The attacks provide immediate feedback to each other when conducted in proximity, feedback that helps us refine our efforts, feedback which allows us to make low cost change in-phase, instead of high cost change out-of-phase.
But in addition to this, agile methods do have an analysis period up front where we gather the users' requirements and begin to uncover how we will model them, before we start building. Some agile methodologies are better at talking about this phase than others, but it remains implicit in the nature of planning activities such as blitz planning or the planning game that we must have done the work up front to gather the user stories or use cases that we will then estimate against. Projects tend to have to leap over some sort of governance gateway to begin, and while the amount of ceremony varies by organization, we often have a need to know just enough up front to understand if we can solve the problem and how expensive it is likely to be. The number of stories we need to gather for approval, the whole 'project', the first few iterations, or just the next iteration tends to depend on the maturity of both the organisation and the system under development.
Of course when we gather those stories or use cases and estimate them, we are doing some design, even if it is only tacitly in our heads, because we are beginning to think about how we will implement them in order to estimate and cost them. For me at what point you cross the line between analysis and design is not an easy one. I have heard it stated that analysis is something that can be discussed with the user, design is what happens after that, but the boundary is murky in a lot of writing.
Methodologies do differ on to what depth this upfront analysis goes. How much do we sketch out in advance, how much do we defer to the iteration in which the story first appears. The methodologies I know (XP, Scrum, Cystal) all capture user stories or use cases to create a requirements list for the system. Classically, XP defers further investigation until the iteration where we build. Crystal recognizes the need for a little more upfront activity called an Exploratory 360.
With Cystal's Exploratory 360 we want to do just enough to ensure we have captured the knowledge we need to decide if and what to build, but no more. We don't want to know how we will build, but be sure about what the user wants us to build. In order to defer cost until it is needed, upfront we only want to capture the elements of the domain that are essential, because we otherwise risk doing detailed analysis for requirements that never get implemented. In an exporatory 360 we typically: capture key use cases and actors, sketch the core of the domain model, spike technologies that may be involved, and then using the planning game or blitz planning sketch out a project plan. Cockburn says of this analysis that it is done "in a coarse-grained fashion, to detect whether the intended team and projected methodology, using the intended technology around the projected domain model, can deliver the intended business value with the projected set of requirements according to the draft project plan. The exploratory 360° results in a set of adjustments to the project setup, or in the most drastic case, a decision by the executive sponsor to cancel the project (better now than later!)."
Remember here that the domain model is the layer of your solution that should be comprehensible to an expert user, not all the other objects that go toward making software run such as UI widgets or persistence technology. It's the place of Domain Driven Design's Ubiquitious Language. Focus up-front on the domain model only. The other objects will emerge as we build, from our discussions on how to automate this domain. It is the builders not the expert users who care about them.
This is not big-design up front it is just-enough design to get us started. It is a few days of activity, or perhaps one or two weeks for a large project.
Beck in the 2nd Ed. of XP recognizes the value of this activity: "McConnell writes, "In ten years the pendulum has swung from 'design everything' to 'design nothing.' But the alternative to BDUF [Big Design Up Front] isn't no design up front, it's a Little Design Up Front (LDUF) or Enough Design Up Front (ENUF)." This is a strawman argument. The alternative to designing before implementing is designing after implementing. Some design up-front is necessary, but just enough to get the initial implementation. Further design takes place once the implementation is in place and the real constraints on the design are obvious. Far from "design nothing," the XP strategy is "design always.""
The trouble for most people is figuring out what the 'just enough' is. The push from agile methodologies early on was against the BDUF style of methodologies such as SSADM and an environment of vendors pushing CASE tools. So the emphasis was on doing design during the build phase, not before. Activity was about weaning people of their BDUF addiction. But as more people approach agile from a zero-methodology background, where there was little or no design, we have to be careful to reinforce the message that agile methodologies do design, but do just-enough to get to build.
Tools 
Help
