agilejava.eu

By introducing CruiseControl or other continuous integration tools, you also have the opportunity to introduce the concept of “peer embarrassment”. When someone delivers their code, the continuous integration tool kicks in to do the compilation, code analysis, run unit tests etc. and finally the build results are mailed to all the developers.

In case of a build failure it will be clear to everyone who broke the compilation, tests, violated coding standards or whatever went wrong. This is embarrassing for the developer and he/she will probably try to avoid this the next time…

Be aware, though, that there is more than one way of avoiding mistakes. One way is to do the things right, for example by ensuring that all tests are running with green bar before making a code delivery. Another way is to cover you ass by neglecting to write tests or, even worse, removing failing tests before delivering…

The assumption that a heavier methodology with closer tracking and more artifacts are “safer” for a project than a lighter methodology wit fewer artifacts has developed over the years. This heavier-is-safer assumption is often caused by the fear project managers experience when they get to far away from the code. Since they no longer can determine the state of the project with their own eyes, they tend to introduce more reports, decision points, coordination, meetings etc…..as opposed to trusting people…
Alistair Cockburn discusses some constraints in methodologies that add more burden than safety in his book “Agile Software Development”. This book is good reading!