Common Sense - Test Driven Design [TDD]

Last week, I spoke in Washington DC at the Certification Network Group's  seminar.  This seminar addressed the need for certification groups to establish their technology  requirements before beginning an  internet search or calling technology vendors for demonstrations and to understand how to have technology be a productive tool rather than take a life of its own.

The one method explained to help them in successful completion of their projects was to use an Agile approach. business process can help achieve a successful , I explained how an Agile Business Practice will help not only in this very important  first stage, the how step, but throughout the entire project. Since there was only one software development company in attendance, only one person had heard of Agile.  To explain this method, I used the basic Wikipedia definition: ...it is [sic]  a group of software development methodologies based on iterative development,  where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.  This is a very simple definition but the highlighted the needed points:

•  It is Iterative
• It is Cross-functional
•  It is Customer Driven - both Internal and External

We discussed the benefits of  short iterations, stand-up meetings, huddles [retrospectives] and the use of a collaborative tool, in this case a simple Wiki.  As I asked for questions,  my software development person stood and asked - "What about  applying TDD -  test driven design - to these types of project?"  I looked at him and very cleverly stated,  "I have never really thought about that, let's explore this at the break."  Well the break came and went but the discussion never occurred but it did get me thinking.


TDD, very simply put,  is a process used in software development to produce continually working code by first writing a test for requirement/feature and then writing the code for that requirement.  Since the test is written first, theoretically the new code, written to the requirement should  pass the test. By following this method, you should always have working code.  Kent Beck, in his first book on Extreme Programming Explained brought this back into programmers tool kit. 


So, can TDD be used as a tool outside of software programming,  in project management or sales?  I say yes and we should  apply test driven design to all sales and project management.  It is basic common sense. As we work with our clients, we should always be applying  metrics or test to make sure the desired outcome is going to work to create a win-win for all involved.

Examples of these tests might be:

• Do all stakeholder understand the outcome of this sale/project?
• How will this sale/project bring value company/association?
• How will it bring value to our customers?
• Has this data been validate by  both customers and stakeholder?
• Are the requirements real?  Have they been validated?
• Have budgets been correctly created - not leaving out important line items?
• Is the ROI understood by all stakeholders?

So, we may not be writing code to our tests, but to create successful sales we must continually follow a test driven design format.  Make sense?