I observed a little twitter conversation this week where one person was attempting to decide if “TDD” meant Test Driven Development or Test Driven Design.  After quite a few posts one stuck out:

"What I care about nowadays is shipping stuff."


Couple this conversation with a blog posting by Nate Kohari and I think there is an interesting conversation being framed up.

What we see is the natural tension that sometimes exists between product owners and implementers.  What makes this interesting is that some people who made a living as implementers are now becoming hybrid product owners-implementers.  I believe this unique perspective can help our industry.

I guess I experience some of that when we started AutoClick back in 1998.

AutoClick was to be a brand new web application for car dealerships.  It was my sincerest desire to do software development correctly.  At the time doing software development correctly meant waterfall…big up front design and LOTS of documentation.  Frankly all of that process took a lot of time and really made it hard to ship features.  Sometimes it took more time to update the documentation than it did to implement the feature.  To me this made our process impractical for us.

As a developer I wanted rigorous process, but as a company owner I wanted to sell stuff.  So, in the desire to ship features that add value quickly, I ended up overcompensating by applying almost no process, no documentation and no discipline.  The business team would just call a developer and tell them what change to make and they did it quickly.  Sometimes even before I knew about it. The end result was brittle, inconstant software that I was scared to death to deploy.  We couldn’t trust any of the old documentation and regression testing simply did not happen.

What I found out that there is no process checklist that I can apply to all projects.  I also learned that each project and even each feature can have their own “personality” that can’t be ignored.  The key is to find the right amount of process to apply for a particular job and team that satisfied the needs of the project and the business and adjust accordingly as the situation changes.

At AutoClick in about 2002, we began doing short, feature based development cycles.  In between releases we would evaluate our process with the goal of making it better.  We made adjustments that were acceptable to (or at least understood by) the business and that were focused on delivering value/features first and foremost.  In this, I think, we became a good software development organization.

Since then I have heard of the agile concept of the Retrospective, and it immediately rang with me.  The Retrospective is one of our most powerful tools to help us get to the correct amount of process that keeps us organized while still meeting the needs of our business.  Spend some time looking at your processes while they are being applied and make the small changes that make it better and pretty soon you’ll find that you’ll have your project right where you need it to be.