Meet you at XP2006!

The 7th International conference on eXtreme Programming and Agile Processes in Software Engineering is going to take place on June 17-22, 2006, Oulu, Finland. According to the program, despite its name the conference is going to be focused more on the Agile Processes, than exactly on XP.

Among the speakers there are Kent Beck, the father of eXtreme Programming; Mike Cohn, the founder of Mountain Goat Software – strong Scrum supporter; Michael Feathers, author of Working Effectively with Legacy Code and a lot of other Agile Alliance founding members and board members.

It is going to be a great conference with a lot of interactive workshops and useful tutorials both for Agile novices and practitioners. It is definitely worth to ask your boss let you go there. Until 19 May there are special early registration fees, so hurry up!
See you there!

Lowest defect rates – faster schedules

We are not rich enough to buy cheap stuff.
– Russian proverb

Did you know, that the products with the lowest defect rates have the shortest schedules?

The statistical research on about 4000 software project mathematically proves that savings on the QA, throwing away the code reviews and unit testing is the worst decision a manager could make in order to speed up the progress. The cuts in the testing will undoubtedly bite the project back.

Steve McConnell from the Construx Software in his Software Quality at Top Speed (IEEE Software magazine, July/August 1996) has a nice diagram, that illustrates the typical defect – development time relationship very well. On the right of the 95% line are the life-critical projects, where it is reasonable to sacrifice the development time in order to produce the bullet-proof products. Unfortunately, too many managers believe they are already on the right part of the diagram, while they are far on the left.


Image used with permission of the author

How is the situation in your company? Do you try to cut the schedules by canceling the testing or code reviews? Did it ever help?

Definition of ‘Done’

During the last Agile SW Development Practices Seminar in Vantaa the participants shared a set of stories about how the switching to the agile development methods proceeded in their companies. A reasonable amount stories included a mention about that without the agreed definition of “done”, nothing was completely done.

Own experience

Few weeks ago, when starting a new project, our team decided to try figuring out what our ‘done’ means. It was a total surprise to discover that within a small and rather coherent team of five persons we had three different points of view.

Importance of ‘done’

People are different. They have different experiences and perceive the software development projects from the different perspectives. When developer tells that this or that feature is implemented, he often means, that all the functions are implemented and are ready for optimization, refactoring and extensive testing. On the other hand, when customer or manager hears that the feature is implemented, he often expects it to be ready for the release. This inconsistency can lead to the system composed of inconsistent components: half-tested, half-documented, half-optimized and eventually half-ready for the release. That’s why an explicit and concrete definition of “done” is the small, but important checkpoint in the software projects. Pay attention to this issue, talk it over with your boss and your customer. As a result of a rather small effort investment, you’ll have much getter grounds to describe the project state. A typical definition could be as simple as: “‘Done’ means, that the feature is implemented, reviewed, unit tested, but not necessarily documented”.

What do you think? Do your customers always share your point of view on what the “feature is implemented” means?