During the Agile & CMMi session in Toulouse (with @yassinezakaria) someone challenged me. I had just presented the 5 maturity levels of agile as defined by Scott Ambler. The first level being “rhetorical agile”. “Marketing” agile if you prefer, the kind that sells, regardless of what happens afterward. So someone challenged me: “how do I know if I’m doing good agile or marketing agile?”. Caught up in the session and surprised by this question, I wasn’t able to answer precisely. The answer seemed too obvious to me. And yet it was far from being so.

This question first raises the issue of our ability to audit agile. Is it possible to audit an approach that aims to be self-organized, in continuous improvement, in a complex world where it’s not easy to reproduce pre-established patterns?

What defines a good agile approach today, versus a bad one? Can we audit an agile approach? Even though some people I know refuse to do so, I don’t share their opinion. First let’s agree on the term “audit”. I’m basing this on the Wikipedia definition (it suits me): “a control and advisory activity that consists of an examination by a competent and impartial agent and a judgment on”… Not necessarily a grade or a rank or a certification, but a judgment, an opinion. Exactly as in the context of a retrospective, or a continuous improvement exercise. If I have this opinion, I’m able to tell the person who questioned me (and naturally if I take the time to do an audit) to give them a judgment, an opinion.

So how do you audit an agile organization, an agile group, an agile project?

We can base this on the 3 levels provided by different methods and agility more generally:

Level 1, the values of the manifesto and different methods

Interaction, capacity for change, collaboration etc. to which, if we are in a scrum environment, we add: transparency, inspection, adaptation; or if we are in an XP environment: respect, courage, feedback, communication, simplicity, or both. We can also integrate at this level the values of Lean: respect for people, continuous improvement.

Level 2, the principles of the manifesto

for example: “Simplicity–the art of maximizing the amount of work not done–is essential.”, or “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”, or Lean principles: See the whole, eliminate waste, flow, pull, etc.

Each of the principles flows from the values, it’s an implementation of them. Values therefore take precedence over principles.

Level 3, the practices of different methods

The daily standup of scrum or XP, code refactoring from XP, the Scrum retrospective, limiting work in progress in Kanban, etc.

Each practice flows from the principles and values. Values therefore take precedence over principles, which themselves take precedence over practices.

Everything should bring you back to the values, the link with them in each of your agile activities must be permanent. It doesn’t matter if you twist, transform, invent practices as long as you respect the agile values to which you refer. These can be reduced to your discipline alone: Scrum: transparency, inspection, adaptation; XP: feedback, respect, courage, simplicity, communication. But these are atomic. We can’t imagine doing adaptation without inspection, we can’t imagine inspection without transparency.

It’s on these points that agile auditing becomes complex. It’s easy for me to say if a daily scrum is conducted correctly, or if the sustainable pace of XP is respected. It’s much more complicated to say whether an organization, a project is transparent or not, whether a team has been courageous or not, whether there has been enough respect or not.

For practices I know, I have knowledge; both subjectively and objectively I’m able to judge whether people respect or not the practices of the daily scrum or sustainable pace.

For values (I’m leaving aside principles: they’re situated between the two) I have an opinion and not knowledge. I can hardly assert subjectively and objectively whether the value of transparency is respected, but I have my opinion. (On these approaches, with knowledge and opinion, you must add faith and you’ll have the 3 degrees of assent described by Kant in his Critique of Pure Reason).

To formulate an opinion I operate as Comte-Sponville does in his “Spirit of Atheism” when he questions the existence of God (this was necessary on these feast days when everyone gorges themselves in memory of a little guy supposedly born in a stable): with negative arguments. I don’t know if you’re agile, but I believe I detect when something isn’t, I have my opinion on that. I have an opinion on things that don’t seem agile to me, in this I constantly refer to the values of agility or the methods you deploy (XP, Scrum, Lean, etc.). My opinion is based on my knowledge (and therefore my experience).

It’s my opinion that when team members’ tasks are assigned nominatively with a precise and very constraining duration by a person external to the group, we are not agile because we don’t respect people, nor their ability to self-organize. It’s my opinion that if a team is composed solely of certain types of so-called technical profiles and they work in isolation from each other, one of agile’s objectives is not achieved in that it advocates collaboration across different profiles who must learn to work together. The second example seems less “serious” to me than the first because it violates fewer values and principles. (If I’m asked to put “grades” on these opinions I’m capable of it, just as I’m capable of giving a rate with figures for these missions, and as my banker demands a certain sum from me at the end of the month for my house: figures are just a convention).

Have an opinion on your agility? Observe your processes, your principles, your values relative to those proposed by agility. Try to project yourself through “negative opinion”. Before anything else you must be aware of what agility is (this is probably why the question from the auditor (there’s another meaning to the same word) at the Agile/CMMi session surprised me at first).

To finish,

Values are few in number, to try to make a metaphor: they form massive pillars of an immense hall where you can organize yourself as you see fit. These values are the only constraints but they are indispensable, without them the hall collapses. If you respect these pillars, you’re free to do as you please, and it’s this freedom that is a source of richness and innovation, of progress. In agile we speak of liberating constraints (I believe Thierry @thierrycros whispered the expression to me, which comes from Paul Valery): “liberating constraints says the poet like the geometer, “works with great constraints require and generate the greatest freedom of mind” [found here].

Here then is a complement to my answer: to apply agile well, have strong constraints linked to the values or principles or practices of your agile methods and respect them imperatively. Values are indispensable, make your choice in the principles and practices but be careful, atomicity is very important.

Some examples to help you understand this notion of “constraint”:

• Scrum: The product owner is responsible for the backlog, priorities and validation. Is he really responsible?
• XP: Collective code ownership: can all developers act on all parts of the code, even those they didn’t write? Can they truly do so?
• Continuous improvement: is there genuine reflection on continuous improvement with real actions taken?

Hence also the predominant importance of moments of questioning, analysis and improvement. The retrospective is the flagship and revealing element of an agile practice.

Naturally we’re never totally accomplished, we tend toward agile, toward an idealized application of all the values.