So, where are we now? Over the last few weeks we have looked at the first 5 of my agile principles -

• They are built around small, self organising teams

• The team has a clear vision of what they are doing and where they fit into the bigger picture

• The team has a well defined backlog of work

• There is a content authority responsible for making sure decisions are made quickly

• There is a clear bidirectional service agreement between the team and the rest of the organisation

We have a pretty good setup going now - we have an efficient delivery engine (the team), a destination (the vision), a route (the backlog), a navigator (the content authority) and last time we added a clear service agreement, so the team and organisation know what's expected of each other. With this sort of structure they can really start to get things done. But there is still one more thing to add to make the team really high performing - the ability to improve.

This is where my sixth principle comes in -

• There is a fast feedback loop that allows the team and organisation to optimise both the process and the product.

This is probably the most important principle of all. Given just a good feedback and improvement mechanism (and a matching desire to improve, of course), an organisation should be able to evolve towards a high performing delivery model on its own. I suspect they would independently discover the other principles given enough time (though given the short time horizons organisations typically work to, I don't recommend running this experiment and would start with all the principles not just this one).

Feedback loops are vital. As I have written before, anything without a fast feedback mechanism quickly becomes legacy, whether it's a product, a business process, the organisational culture or anything else. Feedback, and particularly fast feedback, is essential if the organisation and its teams are going to perform well over the long term. Setting up a process that works well today is easy, setting something up that will still be running well and unchanged in 10 years time is impossible. What you need to do is set up something that works well today and can evolve into something that runs well tomorrow, and the day after and so on. Feedback is essential to long term performance.

There are three key features of feedback loops that must be remembered - first, everything needs a feedback loop. Everything. The product (or whatever it is) the team is producing needs a feedback loop. Is it still the right product? Is the team still the right team to produce it? Have our user's needs changed?

The team's own processes need a feedback loop. Are the processes we use still the best fit for what we are doing?

The service agreement between team and organisation needs a feedback loop. Is the support we receive the right sort of support? Are we providing the right service to the organisation?

Everything needs a feedback loop.

Second, feedback loops must be bidirectional. Both parties must be able to change each other. This isn't just the organisation telling the team to change things. The team should be able to change the organisation as much as the organisation should be able to change the team. The team needs to be able to feed back to the organisation that the team isn't having its needs met (or that its needs have changed) and the organisation should change to meet those needs.

The team should also be responsive to the needs of the product. The needs of the product should dictate the skills of the team as much as the skills of the team should dictate the features of the product.

A feedback loop that only runs one way is just someone in power telling someone with less power how they think they should behave. Proper feedback is a dialogue where both parties are equal. This is really hard for many organisations, particularly those with a very hierarchical structure to adjust to.

Lastly, feedback loops must be fast to be effective. Slow feedback comes too late and too infrequently to learn from. The traditional post project review - done once, at the end of a project - is a great example of slow feedback. It's too late and too infrequent to learn anything. Most organisations have a process like this and the feedback goes into a great big database and never gets seen again. Knowledge about systematic problems emerges so slowly that the organisation can't learn from it. By contrast, the retrospectives from scrum and other agile methodologies is a great example of fast feedback. It happens while the project is still running so the project can improve and because it happens often, systematic issues emerge quickly and the organisation can learn from them.

OK. That's 6 principles. Do we have enough now to make our team agile? Yes, but there is still one principle to go. This one comes into play when we start moving beyond individual teams and start looking at the whole organisation. The last principle is a scaling principle -

• The organisation should be self similar at scale.

We will look at this last principle next time.