Scrum, Agile, XP and the real life

I mentionned it earlier : I have joined the techiteasy.org mob. This is a bunch of passionated and motivated young professionnals blogging collaboratively on the IT world, the internet culture and entrepreneurship.

Scrum and XP from the trenches

I have just posted my first contribution : this is about the Henrik Kniberg e-book : Scrum and XP from the Trenches. I was kinda procrastinating about this book for a while but then Fred strongly recommended me the read.

I had the opportunity of managing a team of server side developers in the mobile industry and this post is about applying these agile methodologies during that time.

Agile Project Management

We were releasing a new version of our online platform (30+ java modules) on a monthly basis. While not doing Scrum, there are many of the above principles (items 1 to 4 in the list) we were applying and I can tell : once we started, it really improved the team productivity, the quality and the team morale. Just that the daily status meeting was weekly instead. But some developers definitely need a daily one.

Applying XP principles was a different story … We tried with the three following ones :

• Test Driven Development(TDD)
• Continuous integration
• Collective code ownership

Test before you code

What has been more complicated is to have developers writing unit tests which, bar few exceptions, they never did until then. This helped making sure the distribution of the module was not buggy. You know how it is : developers never have time for such thing.

So the best is to ask them estimates to write the tests and then allocate them the time. Oh ! and you have to make sure you protect them from support to ensure they dont jump on something they’d rather do, such as investigating a very rare and tricky and thus exciting problem for instance.

This unit testing effort saved a hell of a lot of time to integration team as our module releases were less buggy.

But it costs some time on development side as it is a pain to write test for years old code. So the best is definitely to have a TDD approach, when tests are written as part of development, before the actual code. At the end of the day, this makes everybody feeling more comfortable and this is priceless.

Continuous integration

We were pretty lucky to have an expert in java integration issues, tools and scripting language in the team. He wrote a utility that runs everynight and compile the whole platform, runs unit test and detect issues related to libraries version inconsistancy. The latter happens to be one of the best contributors to tricky productive system issues.

Having all modules to use the same version of a given library was pretty complicated to achieve. We had to allocate specific time to developers to do the appropriate changes but the ROI was pretty straight forward : this also proved to save a lot of overhead efforts, this time to deployment and operation teams.

Collective code ownership

Let’s put it frankly : we failed miserably on this issue.

We had a bunch of excellent and very experienced developers. The problem was their relationship with their software modules (read : their baby). Some of them would not want to have their baby be taken care of by strangers (read : their fellow developer sitting right next to them). Pair programming ? Dont even think about it. Code review ? you must be kidding ! Collective code ownership ? no effing way.

There are many advices in the Scrum and XP from the trench book to have developers applying those. A shame this book was not published a couple of years ago …

Technorati: Scrum, Agile, XP, Project-management