I recently watched a video on InfoQ from Agile 2008.  It was Ron Jeffries and Chet Hendrickson entitled “Natural Laws of Software Development - Deriving Agile Practices“.  Concerning Agile practices, the cast was somewhat elementary.  However, If you are new to Agile, I would highly recommend it.  Personally, I found a few nuggets.

Mr. Jeffries said “If there is a QA interval planned in the project, we believe it causes programmers to do bad work, because it makes it too tempting to skimp a little bit on doing the job right so as to get things done”. 

If there is a test phase or iteration, in the project, will the developers will cut corners because they know a testing phase will find the issues?  Will they will focus on getting the development part of the work done and less on a fully tested product?

Even if you don’t have a distinct QA phase after the iteration, this can still happen if you have testing members on the team.  The developers may not pay attention to the quality as heavily, because they know a tester will look at the product.

Does this mean that we should remove the testing phase?  You might think it would shed light on the problem.  I would think carefully before doing that.  You might pull the rug out from under the team.

Mr. Jeffries goes on to advocate the importance of completing work at the end of the iteration.  The entire story should be complete and ready to ship.  The end product of the iteration must be checked.  Every project manager knows that at the end of the milestone you need to have a way of knowing that the milestone is complete.  If the milestone is less complete then you believe it to be, that will make more difficult to determine the completeness of further milestones.

The team members must take responsibility for their output.  In my first job as a programmer, I was the only programmer on the team.  There was also a single tester and a team of support people.  The support people did some testing on the programs as well.  Incidentally, this is the only team I have ever been on where there were more testers on a team then developers.  If something went wrong, no-one questioned the testers ability to find the mistake.  However, I did get some feedback on my development skills.  Giving me the responsibility for correctness made me test the application even more.

I’ve been in other settings where the developer’s attitude was “software has bugs, that’s the way it is”.  That makes it hard to improve, because you believe no improvement will help.

If you don’t get what you expected, communication can be to blame.  The expectation must be set that at the end of the iteration, the work is done, development, testing, everything.  If at a later date, it is found that there are defects or the story is not complete in some other way, that feedback has to be brought back into the team.  The team must take responsibility for making the improvements in the product and the process.   The team should also look out for competing expectations.  “Get the quality perfect and take on 10 more points per iteration” is a recipe for failure.  The team should make tradeoffs are clearly understood.

Share This