Don’t Design That Yet!

Posted Thursday, February 07, 2013 8:22 AM by Nathan Zaugg

I’ve been following a very interesting discussion going on in the local Agile Roundtable group. They have been talking a lot about how agile is really a “conversation with the situation”, a conversation that involves product owners, end users, and developers. At the heart of the discussion is a tendency for people to push out the agile principles of “don’t design that yet” in an attempt to eliminate risk. Funny that all of the experts weighed in stating that they know from experience that the result will only increase risk.

Anyway, someone posted this article that I think is quite interesting. (

Some statements of note are:

“Did you catch the up front design there? Statements like "knowing more about what to build" implies that someone spent whatever time was necessary to figure out what to build. When stories were large - estimated in weeks, and up to 5 weeks at that, not many details were resolved to give those estimates. Those details were deferred for resolution later – immediately before or during the development iteration. Developers were expected to collaborate with those in a customer role to arrive at what those details were. … [Otherwise], the developers who get these user stories miss out on a lot of context they might have had back when stories were large and conversation was more mandatory.”

“The second approach, deciding what the application looks and behaves like early, I think is the most risky - and involves the most upfront work. In this approach we've had to decide up-front – and hastily at that – what tool our users need to solve their problems - then slice that tool up the way a butcher slices a side of beef. We then build each cut a piece at a time.”

I’ve had this battle quite a bit lately. In one hand you have management who would really like to know when to expect the new product so they can start marketing it. On the other hand you have effort going into up-front design that traps us in the conversations of yesterday overriding the reality of today. It’s often been my experience that much of the design has to be re-thought once the developer begins the process of implementation anyway. Not only were some of the details missing in the original conversation but months down the road the conversation may be a whole lot different leading to confusion about how what the customer wants integrates to the “master plan”.

I sincerely believe that if we really practiced the principles of Agile and have the conversation with the situation – delaying the design of any specific piece; we will get to market faster overall.