Make place for design time in Agile
In extreme programming, the business value the customer wants is specified in stories. Once a customer gets used to working with us in an agile fashion, it becomes almost like a magic wand, where the customer can ask for anything they want, and we deliver.
However, there are some pitfalls in working with the stories-style specifications that extreme programming mandates. One is that it is easy for a team of developers to immediately start churning out code to solve the story.
In our experience, it can be better to have a technical design meeting around each story, before development work commences. Reason being that just before carrying out a story, there is an opportunity to solve the story by writing less code, or even by removing code. And the less code there is in the project, the lower the complexity and maintenance costs.
We like to call these meetings technical design meetings. They give the opportunity to raise questions like:
"Isn't this similar to...?"
"Do we need this?"
"Will this not be rendered obsolete by..."
"Can we not re-use..."
"This is wrong"
"Why don't we solve this, this way instead"
These are the type of questions, where you take a broader view, and transfom the problem, flipping it on its side and seek out broader and different solutions than whatever sprang to mind first. These questions are hard for a single developer to pose, since his or brain likely is already zooming in on a solution, and it it is actually also hard for a programing pair. A design meeting, again in our experice, should consist of three to five people, and last for ten minutes to anything up to 3-4 hours.
It may seem like a waste of hours at first, since no code is written, but to get to a better design is worth so much, that the few times the design meetings seem to drag on too long are more than compensated for the times where really good decisions were reached.