Monday, June 20, 2011

Something on Continuous Integration

In the past I have been experiencing some weird practices concerning CI. In the following article I will outline some do's and don'ts when implementing continuous integration.

First and foremost it is ok to break a build that is why the thing is there you know. Comparing the number of broken builds against the ones that don't break is not a good measure of quality instead measure the time to fix the build.

Do Integrate static code analysis in your build like FxCop, Ndepend and Simian. Giving you early feedback on your code quality. If the tools give you warnings solve them as well. If you keep up on regular basis this will keep your code base clean.

Do Integrate your Unit tests to run every build. Again providing early feedback on integration issues.

Do provide visual feedback (Andon) that give people an immediate feedback when a build fails.

Don't force developers to do a get latest, run all their unit tests and then check in. This is a waste of time. But when a build fails fix it!

Don't seek who broke the build. Something that is very common is that people are very eager to investigate who broke the build and pointing fingers. Instead look what broke the build try to fix it, this will enhance collective code ownership.

Don't check in, close your laptop and sprint out of the office. This practice kills team morale.

Tuesday, June 14, 2011

Determine Iteration Length

Something I come across quite often is that teams don't consciously determine the iteration length of their sprints. They usually take 2 weeks as some default length. This is not really the way to go… Lets see what criteria we can put forward to fine tune the iteration length.
Here are the 3 major factors to consider:
  • Project Duration
  • End-User commitment (how available are they to provide feedback and input)
  • Maturity of the team
The shorter the project the shorter the sprints enabling to have more feedback cycles, minimizing the risk building the wrong thing. This however will require a significant amount of commitment of the stakeholders (weekly review meetings, availability to clarify and develop the product backlog with the Product Owner,...). Short sprints also have one big advantage they are more prone to fail… The reason why I see this as an advantage is that problems will surface more quickly, enabling your team to address them and thus further minimizing risk.
The second factor is also quite important: are there end-users available to provide feedback and are they easily accessible? One thing to keep in mind is that people are not used to the fact they will have to be available for a project throughout its duration. In the past they participate in workshops in the beginning of a project and in acceptance testing testing near the end (oh sweet memories :))
Finally you should consider how mature your team is. This means how experienced are they with agile practices such as Test Driven Development, Continuous integration, Test Automation, Collective Code Ownership (instead of finding out who broke the build, investigate and fix what broke the build), being cross technical (no specialist like the database guy, the UI guy, etc.). This however does not mean there is no room for specialists and that everybody has to be a generalist but everyone chips in where needed. A big obstacle are teams that divide work parallel with the layers instead of what i call "slicing the cake", this means implementing a feature from front to back, this will enable them to incremently deliver software.

For more information see: Agile Estimation and Planning from Mike Cohn