When to Start Coding?

I attended a talk by Dave Hussman at an Agile Bazaar event a few weeks ago at IBM’s offices. In attendance were developers from expansion stage software companies, big established companies, and members of senior management teams.

It was sponsored by a number of software vendors, including VersionOne, an OpenView Venture Partners portfolio company, and the leading tool for Agile software development teams.

His talk was entitled, “Products and People over Process and Dogma.”

The people part I addressed in last week’s post, In Agile, People Come First!.

Dave spent a good deal of time speaking about the right time to start coding. Dave remarked that many teams that were focused on following best practices process of Agile Product Development were not necessarily focused on the right things.

The mentality was: Give us a story, we’ll code it in a short iteration, show it to you, and go from there.

Well, that’s all good, but perhaps the team shouldn’t start coding just yet. Does everyone on the team understand the story? I mean, really get it? The ‘why’ and the ‘for whom’? How it fits into the bigger picture of the interface, the use case, the product, the user’s life?
Has the team done analysis to think through the different ways in which the functionality could flow? The edge cases? What could go wrong?

Has the team thought through the different approaches to implementing the story? How it touches other code and the architecture?

I have seen first hand what happens when Scrum teams, following all the prescriptions of the Scrum methodology, fail to do the above multiple times.

The result?

Software that may meet the acceptance criteria of a story and definition of ‘done’ at a superficial level, but ultimately has quality issues, behaves in unpredictable ways, and is often not delivered on time.

So if you’re a software developer, the next time you’re about to start writing code, ask yourself: Am I really ready?