Australian Scrum Community

Something I meant to post about a couple of months back was Jason Yip’s excellent article on conducting effective Daily Scrums (otherwise known as ‘stand-ups’ in XP-speak). The article is titled It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings and is a must-read for all ScrumMasters. It came in handy when I was doing some Scrum training with Joseph Pelrine in February. It seems that English-speaking agilists aren’t the only ones who find this interesting as this article has now been translated into Japanese!

Thanks to “Richard Banks“http://richardsbraindump.blogspot.com/ for the recent reminder on this one.

Quote of the week:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. —Brian W. Kernighan

Via Titus Brown

Simon Brown, author of the Pebble weblog application, books and other things, has an interesting post on agile.

Are you really agile or just ad hoc?

I suspect that this is quite applicable to many people “doing Scrum”. For a while now I’ve been collecting job ads from Seek that mention Scrum. All of them are looking for people with experience using agile, but they tend to ask for it in a general sense. e.g. “Experience with agile methods like Scrum, XP, etc.”

Of course, mentioning agile processes and methodologies in a job ad may be a ploy to interest high quality candidates.

If you were to apply for one of these positions then asking Simon’s questions while in the interview might be revealing.

A paper is available from Microsoft Research titled “Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies”. It takes a look at two Microsoft projects and reports on the effort involved in writing tests versus the reduction in defects. Interesting stuff.

Project A
A C++ networking library. Test-Driven Development (TDD) required 25-35% of additional effort, resulting in a defect density of 2.6x less than that of an equivalent project not using TDD. The team was highly experienced in the domain and language used.

Project B
A C# web services product. TDD required 15% of additional effort, resulting in a defect density of 4.2x less than that of an equivalent project not using TDD. The team was had medium experience in the domain and language used.

The paper states drawing conclusion from these figures is difficult because there are a large number of context variables in software development. e.g. Team experience, team size, management experience, language, product type, etc.

Via Steve: Developing on the Edge.