Outsourcing and Test Driven Development

I imagine that most of you have aleady heard of Test Driven Development (TDD) where the tests that software should pass are written BEFORE the software itself is written. The list of tests is essentially just a formalised way of listing success criteria (and indeed requirements) very precisely. More than precision, this approach gives you a very fast indication of your REAL progress, since the newly written code either passes or fails the tests*.

Test Driven Development is a software development approach usually associated with agile development methods such as those championed by the Agile Alliance. It is usually assumed that agile development requires a team to be collocated, working intensively and exclusively together, and so little attention has been paid to the role of these methods in outsourced development.

For better or for worse** however, many of us are on one side or the other of an outsourcing arrangement. I discovered in my work that using test driven development as a mechanism for both validation (are we building the right thing?) and verification (is it working?) can be hugely powerful.

There are a number of reasons for this:

  1. Well-written tests can explain requirements much more efficiently than traditional requirements documents. Even when there are misunderstandings, the SUM of the different tests specifies the right functionality.
  2. Tests are technical and so can overcome communication barriers with added precision. Even just not sitting next to your developers (or designers) can cause communication issues. When you add the moder-day reality of offshoring as well as outsourcing, this can be exacerbated.
  3. “The customer” (whoever they might be) can be involved in the creation of the test suite. This helps to ensure that the right functionality is being created in the first place since we can check that what the software does is what the customer desired/expected very easily.
  4. Showing the number of tests passed can be a much better indication of progress than the traditional “percentage of task complete” measure. You know exactly how much of the programme actually works at any given time.
  5. Tests can be automated. Then you essentially end up with an automatic checklist of desired behaviour, so that every time a change is made you can pinpoint other areas of the code that might have been affected and refactor quickly, rather than waiting for bug reports to come in from live use.

Hopefully as agile development methods become better and more widely adopted, an increased number of the firms providing outsourced development services will start to use them as standard. In the meantime, it can make a huge difference to your projects if you manage to introduce them ahead of the curve.

What have your experiences been with test driven development and outsourcing? Share in the comments.

* Provided your tests are well written, that is. Of course, writing good test cases is a skill all of its own!

** The pros and cons of outsourcing your development definitely deserves another post! Or arguably an entire book!

Tools Don’t Matter

Every time I do a talk about project management, someone asks me what the “right” software is for the job. I love being asked this, because it’s an important topic.

My honest belief is that tools don’t matter.

Project management is about people. Picking some all-singing, all-dancing piece of software is not going to make things magically go right. It’s only when your processes are already working that the right software can help you make things run more smoothly and efficiently.

Net, focus first on getting the processes right. Then worry about selecting the best software for the job.

Keep in mind, however, that adoption is of supreme importance when selecting tools for project management. At the end of the day, you may need to compromise on features for the sake of pragmatism. It doesn’t help anyone if you have a fabulous project plan that no one can read, or an issue list that no one will update!