One of the problems with agile development is that it’s subject to changes, so means you’re in danger of changing it into something which isn’t agile. How do you know when you’ve gone too far?

This isn’t a problem for seasoned agile practitioners, but it’s a concern if you’re just starting out, or working with people who are. It’s certainly something I found looking back at my early agile days. There are some non-obvious or difficult agile practices which one might omit, but which make a big difference. How do we know what to watch out for?

My suggestion is to ensure there are some fixed points. Then you can evolve the process without straying from the ideals. My rule of thumb for creating fixed points is this:

Could I stand up at an international conference and be sure that my process would be generally indistinguishable from that of any of the speakers?

With that in mind, here’s what I’d want to be sure I did before I stood next to my peers…

Daily stand-up meetings at a set time

There are three things here: daily, stand-up, and set time. Making the meeting daily can be difficult, but having spoken to people who hold weekly meetings it’s pretty clear that they take up the same time in the end. In addition, daily communication keeps people veering too far off the track.

Insisting the meetings are stand-ups might be difficult and there’s no clearly tangible gain — after all, if you keep the meeting to 5 minutes, who cares whether you’re sitting or standing, or bouncing on one leg? But this important to me because it instills a sense of urgency. A sit-down meeting fails to distinguish us from our document-heavy, procedure-driven colleagues. It’s entirely psychological, and all the better for it.

Making the meeting at a set time can be difficult, particularly if the lead has other responibilities. But this is important to me because it forces people to focus on the project. It says “The train’s going at this time — be there or get left behind”. It tells people the project won’t wait for them. It keeps the team to a rhythm.

Iteration kick-offs and/or close-downs

It’s surprisingly easy to get away without these: some of last iteration’s story cards might not be finished, so the team just carries on; new story cards become available when the old ones are done, which could be any time. Iterations blur.

But a formal meeting to mark the iteration boundary again ensures the project and the team keeps to a rhythm. Coming up to the boundary it ensures people know ahead of time that they’ve got something to aim towards, and deadlines always focus the mind. Entering the new iteration it gives people the chance to think afresh and renew their goals.

Mid-project retrospectives with the whole team

An end-of-project retrospective is good, but mid-project retrospectives are agile. They ensure the team really is seeking to improve not just for the next project but for the current one. It can be difficult to see the benefit of retrospectives (another time-consuming meeting), nor do I think they’re not very obvious. I certainly don’t recall them cropping up in the Extreme Programming Explained or in Agile Software Development with Scrum. One way to keep retrospectives effective is to ensure any actions are (a) objective and (b) assigned to named individuals. This way improvements will be much more tangible.

Continuous integration and testing

This is certainly an obvious feature of agile, but it’s also difficult. If the project is anything more than a few days long it’s worth spending the time up front to get the continuous integration and testing working. This ensures rapid change and frequent delivery. Otherwise it’s very likely that features and fixes will regress, that this won’t be discovered for long periods, and fixing the regression will take a long time, too. Agile is about frequent delivery and constantly moving forward at a regular pace. That can’t be done without continuous integration and testing.

Frequent customer demos

Again, not necessarily obvious because while agile talks a lot about on-site customers it doesn’t often talk about the common case of customers not being around as much as you’d like. Frequent mid-project demos are the next best thing — at Guardian Unlimited we call them “show and tells”. A customer demo has two benefits. First, it steers the team towards feature-driven development rather than architecture-driven development. (It’s very hard to impress a customer with a data object layer.) Second it encourages prioritisation of the next batch of features.

Anything else…?

There’s much more you need to do to be sure you’re being agile, but to my mind the things above are easily missed. So next time I create a team for an agile project I’m going to make sure we start with some fixed points, and evolve round those.