From the eXPerience: being agile in a non-agile environment

I think this is the main challenge today for XP and agile in general. After all, customers are alike at work and in restaurant: they do not want to see the kitchen, they want dishes (Vera dixit)!

The principle is that software is a part, important but only a part, of a more general process that involves a lot of different agents and roles, technical and not technical (and God -- if it exists -- save Kent Beck to having told us that businessmen do not interfere with technical decisions, and vice versa). But the problem is not in the principles and values (where agile starts, even without any technique, BTW).

Ok, we should collaborate instead of constangly negotiate with our customers, but, how if the customer isn't next? it is fun to work with a customer on site, but this isn't what usually happens... So, agilists are trying to cope with this sort of problems, where the environment doesn't collaborate, so to speak.

A proposal, presented by Willem van den Ende and Marc Evers, is to read the behaviour of your environment as a cultural pattern. It is a way to understand your context in order to know if and how to lead it to an effective change.

0. Oblivion. The most simple pattern is the oblivious one, or: "pattern? what's that?" Some are totally unaware they are developing software, so that they even not distinguish users from developers... The only good thing is that it is a (un)pattern highly customer-oriented.


1. Variability. The next step in evolution is the variable pattern, or: "do whatever you feel at a given moment". It is highly cooperative and it values craftmanship but it encourages heroism and it is individual-dependent, so it is not robust at all.

2. Routine. The inverse of variability is routine, or: "we follow standard procedures every time (except panic)". This is an attempt to impose order to disorder, and you can feel it every time you see a management-by-controlling approach. The pitfall is well-known: lack of trust (except on silver bullets).

3. Steering. The jump is on steering, as the pilot of an aircraft who adjust the plane every time, in order not to change route! The keys to this are agile practices, as retrospectives or stand-up meetings, which garantee feedback control and endorse trust among members, or the principle of visibility (stick cards and diagrams on the wall).

4. Anticipating. Next jump is anticipating, where you let people experiment even if everything goes well, in order to make extraordinary things ordinary. Culture becomes congruent, i.e. you are able to transfer cultural practices in different context in order to consciously manage change. This is described in the Toyota Way Book about lean development.

I think that remembering these patterns is useful so to let the environment some realistic change. As Pascal said in the XP Loops session, XP does not tell you if it is worth to start a project, but it tells you when to stop it, even if it isn't finished.

So, This approach seem to work well for me, at least in the simulation game had in pairs (simple rules: in 5 minutes, let the other know a case study of yours and in pairs you classify; the patterns where presented induring two different pomodori). Of course, the transition in never a one-zero game. In the case I presented to my peer, I described it as a 70% routine, 20% oblivion. The reference book is System Thinking, which is one of my aNobii desiderata. ;-)