program development and documentation

Had an interesting discussion with one of my colleagues the other day. He said that the team he is working in has adopted a 'sprint' approach. I thought that was good, until he went on to say that he had no time to document the work that was being done. That is not at all good, and goes against one of the main principles - "Done means done". In my view, if work is not documented, then it is not completed. It becomes impossible to maintain, and hard for someone else to deal with when the originator goes on holiday (or is ill).

It is something I will bring up at the monthly staff discussion group next week.

testing and Agile

One of the problems regarding how to test in an agile development team is the area of system integration and I include performance testing as well. It is all well and good getting the designers to write tests for their pieces of work, but who can write the tests that cover those units being integrated into a working whole?
The plan we have come up with, and one that seems to work reasonably well is to have the integration testing done "one sprint behind" the development work. Of course, it is mostly automated scripts so that regression testing can be performed easily.
The difficulty of writing tests whilst the code is being developed can best be seen when trying to test user interfaces. It is quite possible that the position of buttons, selection lists and text areas changes whilst the program is being worked on, so writing tests that check for the operation of those items is best left until the work is done.