Ian Cooper [MVP]

Someone at work, new to agile approaches, asked me about when agile projects do design. I thought I would share my answer in case others were still wondering, and to try and explain where experience may have lead to us activities that are not textbook.

The short answer is ‘all the time’ and ‘just-in-time’. The long version is ‘all the time’ in that we are always thinking about design during story gathering, planning etc. which is why you want as many people on the team involved as possible. When we say ‘just in time’ we mean that we leave it to the ‘last responsible moment’. Of course the hard part is figuring out when the ‘last responsible’ moment is. I like Alistair Cockburn's model that the objective of any activity ins software development is to provide just enough for the next activity to take place. So we would tend to do just enough design to let us being development.

Being more concrete: 

• Agile projects do design through TDD, so called emergent design or incremental re-architecture.
• XP supplements TDD with pair programming, so at least two people design everything.
• XP recognizes that some design needs to be all team, and has an optional CRC path, in each iteration, for contentious design choices or complex problems.
• Crystal does not mandate pair-programming, and scales to larger teams, so it has more ceremony. It’s not uncommon for a crystal project to model the core domain model up front.
• Most agile teams recognize that there is a nebulous conception or inception phase when you gather user stories, organize and understand them, do just-enough modelling,  set up build servers etc. It is the great unspoken step of many agile methodologies.
• We care more about the domain model when modeling than about the infrastructure. Early on I would never tend to model the infrastructure.
• Any ‘up-front’ modeling, before coding, is high-level, not low i.e. we care about classes, roles, responsibilities, and collaborators, but not attributes, methods etc. I tend to favour Rebecca Whirfs-Brock’s Responsibility Driven Design for this, and would consider this her Exploratory Design phase.
• The conversation is more important than the artifacts the conversation produces. This is why CRC cards are great because the artefact is less important than the design discussion among the team and running the scenarios. You may produce a UML sketch of the system at the end, but it’s just an aide-memoir to the discussions, not a blueprint. It is also why design needs to be ‘all-play’. We don’t want to punt documents over the wall to developers, we want them to be involved in the activity of design from the beginning. That way the documents don’t inform, they just record the discussion. That’s what a document is after all.
• CRC cards also work well because they have feedback - running through scenarios. We tend to divide up the cards and throw a ball between participants as the system calls their classes act. That means you get some testing around your design as you do it.
  
• Remember that you are looking for ENUF, just enough design to make the next step, development, possible. If you end up throwing away too much of your initial design when you get to coding you have created waste, which we are trying to avoid, so don’t push this exploratory design step too far. Just do enough to answer the key questions
• Be proportional. If you have ten user stories you may not need much of a conception phase. If you have two hundred you may need more.