Our company is on the path towards adopting full agile development practices. As the senior “manager” this fits into three of my goals:

  • Software excellence
  • Delivering maximum value to clients as soon as possible
  • Sustainable pace

But this is not just a management initiative. It’s being driven by some of our development staff as well. The rest of the team is coming around over time as they “see what’s in it for them”.

Recently, we tried to implement full test driven development (TDD) on a small two person project. While it furthered our knowledge of what we didn’t know, unfortunately the project velocity dropped to zero in the first iteration. Now to be sure, this does not mean no work was done.

Agile is about delivering client value. So we’ve adopted the rule (as stated by Mike Cohn in his book, User Stories Applied) that at the end of the iteration, only fully completed stories count towards iteration velocity. Without going into details, the stories were not 100% completed and even if they had been, the amount accomplished was far less than what would have been accomplished without using TDD.

At the end-iteration retrospective, the TEAM decided that in order to maintain the project schedule and budget, it would be necessary to back off on the “all” TDD objective. I agreed with the assessment but added one condition:

The developers would continue to write at least a few tests (TDD or unit at their discretion) for areas of the code that would most benefit. This matches JP’s (Jean-Paul Boodhoo) advice when he visited, start with Unit Testing key components that would benefit and grow your ability as you learn.

You see, setbacks are not failures, they are opportunities to learn. Agile is not a destination, it’s a journey towards software and process excellence… always improving and moving forward.

That reminds me, I need to see how that testing is going…