April 18, 2008

...Learn TDD with Codemanship

Keep Design Sessions Focused "In The Now"

A very common mistake that Agile teams make is when they try to design the software in their planning sessions.

I can kind of understand the temptation. The developers don't really know what's going to be involved in implementing each story, and the project manager wants accurate-ish estimates. So they dig a little deeper. And the danger is that they'll dig too deep, and then keep digging, leading to a monumental design effort lasting hours - or even days.

It might seem as though this is time well-spent, because when developers pick up the stories to start work on them, the design's already been agreed.

In reality, though, the developers will have forgotten what design they agreed almost as soon as they moved on to thinking about the design of the next user story in the plan. You see, our flimsy brains just won't hold more than a thimble-full of useful, detailed, accurate design information. And - short of resorting to an Object Z formal specification - any notes taken in the meeting will have errors and ommissions. That's guaranteed.

Which, sadly, means that when the developers pick up a user story to get started on it for real, we'll need another session to pin down the design again and load it into our puny Earthling memories.

It's also much, much easier to make mistakes if we try to solve a whole raft of problems in one sitting than if we tackle them one small chunk at a time and allow ourselves the luxury of time needed to focus in on that little problem. Designs produced in marathon sessions tend to be wrong more often than designs produced in short, focused sessions.

That would be a duplication of effort, and it's unthinkable really that the developers should eschew doing design when they pick up a story, so the duplication should be removed from the planning meeting if at all possible.

Won't that make our estimates less accurate, though? Well, actually... no. In practice, all the evidence suggests that it isn't true that the more we analyse a requirement, the better our estimates get. Indeed, our first instinctive guesstimates tend to be about as good as it gets.

So be mindful when planning and estimating discussions start to dig deeper than we need to make a quick, instinctive judgement of relative complexity, and be disciplined enough to find a little time for collaborative as soon as you pick up a new story.


Posted 10 years, 5 months ago on April 18, 2008