In the Loops

Martin Fowler looks for a rigoruous definition of "agile" software development practices, and measurements of which practices may be more effective than others.

...agile methods fundamentally expect teams to decide what process to follow and furthermore expect teams to actively and regularly change their process. Any attempt to define a rigorous process that can be tested for conformance runs contrary to this philosophy...

How can you do a survey on whether agile methods are more effective that alternatives, or whether Extreme Programming is more effective than Scrum, when you can't get a clear definition of what Scrum is in the first place? If a client wants a system built using Extreme Programming how can they tell if it's really being done?

The first part of the quote above *is* the definition of agile in my experience: if the team decides what to follow and actively improves their performance then they are "being agile". The second part of the quote becomes less interesting in this case.

Comparing textbook definitions to each other is less interesting than comparing an agile team to its own history. If the team is improving then that's the goal.

A useful excercise for a team when considering their own agility is for them to explicitly describe their feedback loops (plural), who should be in their loops for which information, and how are decisions (and their timing) made in each of these loops.

(Hint: many problems in an organization of any size occur, and are therefore obscured, outside the boundaries or on the border of the "team" per se.)

Using this approach Scrum, XP, and other approaches become possible sources of improvement and less a necessarily well-defined instruction manual that can be graded independent of actual performance.