They say that when all you have is a hammer, every problem looks like a nail. It’s the same in business – when all you have is a project management methodology, everything looks like a project. Most organisations have become very project focused. Everything is a project. New release of software – project. Some process change – project. That’s great. Projects are good. They are certainly better than the ad-hoc approach we had before projects. But projects do have some drawbacks.

To work out what the drawbacks are, we need to look at what a project is. A project is defined (by the PMI who should know) as something that has a defined scope, a defined start and a defined end date.  So projects are finite in length. Anything without an end date isn’t a project, it's business as usual.

When a team is behind its targets, the natural instinct is to work even harder to catch up. Sometimes though, the best thing you can do is… nothing.

Let’s look at a team. For various reasons, they have done several sprints' worth of work with no test environment available. How can this be? Let’s just imagine that they work for a hypothetical large company with a ludicrously complex process around setting up test environments. I’m sure such things never happen in real life, but just go with me on this one.

Normally, the phrase 'project vision" or "project goal" elicits a collective groan from any team in which it is used. This is because project vision statements are generally... well... crap. Whoever puts them together inevitably feels it necessary to slip into management speak and string a bunch of fairly meaningless weasel words together – "we will proactively leverage our synergies to achieve outcomes consistent with our values going forward...". Lots of words but no actual meaning. No wonder people greet them with a groan.

Some agile teams do well. Many don't. In my experience, there is one consistent thing that separates the teams that succeed from those that fail and that is sound engineering practices. Foremost among those sound practices is Test First (or Test Driven) design.

Having a solid test suite that runs frequently is a key to agility. By frequently I mean every night at least. Without frequent regression testing, teams become risk averse and unwilling to make changes in case something breaks. In an agile environment where change is encouraged, this can be a death sentence for an agile project.