I often see organisations who have decided to ‘go agile’ and have picked Scrum as their methodology. If you look around the Agile community, Scrum is one of the most widely mentioned and popular agile methodologies. Scrum is pretty simple to understand (most things that are good are also simple) and really embodies a lot of the agile values. However, after a few sprints, I often see Scrum projects running into difficulties.

Why does this happen? First of all, let’s look at the decision makers who are usually involved in going agile. More often than not, the decision makers are ‘leaders’ in the IT or Business departments. By definition, these ‘leaders’ are individuals in senior positions, and are usually no longer involved in the day-to-day creation of software. Their focus is often on governance, project management, processes and the like – the bigger picture if you will.

Scrum is great for the business (and indeed project managers – although some project managers will debate this long and hard). It’s clear, easy to understand and offers the business the ability to change its mind, re-prioritise and re-focus. And we all know that’s one of the biggest benefits in going agile.

However, perhaps we should spare a thought for the guys that actually create the software – the development team. Developers often start off loving the thought of agile. They are promised that they will have the chance to be much more involved in understanding the requirements; and they are told they won’t be ‘committed’ to dates that are impossible to meet, dates that other people have already promised. This all sounds good – until change starts to occur.

So much of what is good in agile is based around accommodating change. An inexperienced agile team will often promise the business that it can ‘more easily accommodate change’ – note my italics – and that sets an expectation that the business remembers.

The reality is somewhat different, of course. Change can only be ‘more easily’ accommodated when we have a set of good development practices in place. We all know the ‘change costs’. Agile should reduce the cost of change, but cannot completely alleviate it. The real effort in change comes not from making the change itself but from checking what else you have impacted – i.e. the testing.

If you remove testing from any development cycle you would always have a quicker project. However, the end product is bound to have too many bugs and won’t be fit for purpose. We have all learned this the hard way but, on agile projects, this lesson seems to have gone out of the window. On agile projects we encourage change, but sometimes we forget that the developers have to re-code and re-test their work.

This is where Scrum is poor. Whilst it covers the ‘process’ side of Agile, it doesn’t do enough to enforce good development practices. We need more, from a developer’s perspective, to help accommodate functional changes – we need some mechanism to constantly build and test our application components to make sure we are not breaking things and introducing technical debt (I will cover this in a separate posting). The things we need sounds awfully like Test Driven Development and Continuous Integration. Don’t these things originate from methodologies such as Extreme Programming (XP)?