Those Pesky Design Meetings

Designing software is a tricky thing. Programming languages, domains, white papers, hardware, and people all play a part in molding the systems that we create everyday. There are some agile (and sometimes not so agile) software professionals seem to balk at the idea of spending more than a few minutes during a meeting to reason through the problem before trying to write code. They always quote Kent Beck in XP Explained:

... design meetings were going on for hours without resolution. So I bought an ordinary kitchen timer and decreed that no design meeting could be longer than 10 minutes. I don't believe the timer was ever used, but its visible presence reminded everyone to be aware of when a discussion had ceased being useful and had turned into a process for avoiding going and writing some code to get the answer for sure. (p. 60)

However, if you read the quote in context you may gain a different perspective:

But perhaps the most important job for the coach is the acquisition of toys and food. XP projects seem to attract toys. Lots are of the ordinary brain-teaser type recommended by lateral thinking consultants everywhere. But every once in a while the coach will have the opportunity to profoundly influence development by buying just the right toy, and staying alive to this possibility is one of the coach's greatest responsibilities. For example, on the Chrysler C3 project, design meetings were going on for hours without resolution. So I bought an ordinary kitchen timer and decreed that no design meeting could be longer than 10 minutes. I don't believe the timer was ever used, but its visible presence reminded everyone to be aware of when a discussion had ceased being useful and had turned into a process for avoiding going and writing some code to get the answer for sure.   (p. 60)

When I read the quote in context, I interpret them as Kent responding to the amount of waste his team was generating during design or planning meetings. More precisely, the team did not know how to resolve *disagreements* using meetings and instead would argue for hours about what approach would be best. He then decreed the "10 minute rule" in order to motivate them to resolve those design disputes with code samples and not just words. In other words he needed them to do something different because what they were doing *wasn't working*.

I like to use design meetings as a tool to help develop consensus around an iteration plan/design, however I have noticed that my team has been storming quite a bit recently. I think going forward when there are disagreements between team members, I am going to encourage the team to set up a few spike stories or experiments to help prove or debunk those design ideas.

I'll let you know how it goes.