On Feedback Loops and Agile

I was talking to Matt Frank the other day and he mentioned something important - agile is all about feedback loops. I've been thinking and reading over this concept for a while now and I've come to the conclusion that feedback loops are a good way of explaining agile and a quick way of measuring the quality of an agile process.

If we think about a developer view of XP, he/she has many feedback loops to encourage higher quality work: pair programming, TDD, story demo with the customer, task boards, morning stand ups, the XP coach (or scrum master if you insist), testers, continuous build, iterations, frequent releases, retrospectives, and of course end user feedback (and there's still more - trust me). This rather large list of things we do just to help the developers deliver value is at the heart of why agile can deliver quickly and efficiently over time - the sheer amount of feedback helps to ensure developers write functionality that is consistent with what has come before and provides the required value demanded by the customer now.

Now, we don't always have all of these things, but for any agile process we may have either just left them out or replaced them with something else - but by simply counting the number of things we do for feedback we can get a nice little quality measure of how hard our process is working to aid our developers.

Thinking in terms of feedback loops also shows up a large gap in the agile processes that I've worked on - what about everyone else on the team? Customers get to write stories, choose what is built, see it being built, demoed and may even get to test it. So customers have it pretty good too. Testers, well testers are an odd bunch, a developer left gibbering in the corner may be all they need. But actually testers have a fairly fast feedback loop in terms of submitting bugs and seeing them fixed and may also participate in the creation of acceptance criteria, see those criteria implemented in automated acceptance tests and eventually see those tests keep the developers on target.

So, who's been left out? Well those poor BA's, you know the ones who have never had a real role in agile but are called in as 'translators' or 'mediators' or even worse: second rate substitute for a disinterested customer who doesn't care enough to participate in the development process themselves. I'll have to get back to you on this one, I've been meaning to ask our in-house BA experts Matt Frank and Steve Lennon about this, and I'm sure there's a chap at XTC who has some thoughts on this.