Tomorrow we plan to present the material in much the same way as at Qcon London, and spend the extra time we have on doing exercises with the participants, much like we did at XP Days Benelux and London last year, now with new and improved exercises . We’re getting better at presenting the patterns in a non-linear fashion and getting the idea across that one pattern is better than the other, but that they each have a context where they fit best.

After Beyond Agile in France, we took up the nice task of re-ordering most of the presentations, and drawing some of the choreographies you could see in the notes, so that we could tell stories more effectively, show the patterns in a context where they fit and explain why some choreographies are easier than others.

We start off with asking the audience questions about too much or too little process and whether they have been involved in some way in an agile transformation. At qcon, surprisingly little hands went in the air for any of the questions – so that might mean that agile is not that mainstream yet… We expect most people to have worked in either routine and/or variable cultures. Several people raised their hands on all questions . So that means it is a decent starting point – it is easy for most of the audience to picture what these cultures feel like from their own experience. Some of the others require a bit more explanation, as they are more uncommon or less easy to spot.

Routine and Variable can also help explain an endless source of conflicts within an organization. At Agile Open France there was a session on “Dev vs Prod” (Development versus Production – most of the participants worked in some kind of IT organisation where the Developers – people who program the programs – are not responsible for keeping the programs they make up and running – that is the responsibility of Production). Developers often prefer a variable way of working – being flexible, trying out new stuff and making the customer happy. When they hand their stuff over to Production, they are faced with forms and procedures – indicative of a Routine Culture.

Now, why would Production have these procedures?

Because (amongst other things), they have past experiences with Development handing in code that ‘Works On My Machine’, and even if the code does work, most software they have to use is Legacy Code. As Gildas noted at Agile Open France, most production software (e.g. mail servers, databases, some web servers) don’t give feedback until you restart it and go live. Some do some syntax checking (e.g. the apache web server), but even that is uncommon.

So any change to a production environment has a good chance of breaking it, which leads to the Production people getting complaints and working nights to get the whole thing back up and running. Wait, did I say working nights? That doesn’t sound very Routine, now does it…

Often when something goes wrong, a routine organization will temporarily go into a Variable state, in the hope that order will return soon. In the case of Production, going Variable is more unpleasant, because if you’ve been doing this for a while (I have, as a side project), you can feel in your gut that something might go wrong again, requiring even more heroic fixing… And this always happens when you least expect or want it (say, the day before you go on holiday…).

The two pictures with arrows already show two uses of the patterns:

• Predict and explain conflicts between parts of an organization
• Transitions from one pattern to another (and back) and why they happen.

And that ‘fixes’ one of the ‘defects’ we had in our presentation last year: explain early on in the presentation what we use these patterns for – we usually needed the Q&A round to explain the ‘why’… I hope to follow up with another post on another ‘why / how to’ : guide transitions from one cultural pattern to another, and explain why some transitions feel easier to me than others.

When Bob moved to the ABC Bank, he tried to repeat his recipe for success (weekly planning meetings and standups) and then later add stuff. This also would enable developers to deliver more value. Instead of being happy, they asked: “where are the documents, and procedures? How does my role/job description fit in a multi-disciplinary team? (‘I like the security my role provides’) Where are the handoffs?”

This time Bob found himself in a place with a Routine cultural pattern – everyone follows the rules, questioning or evolving the rules is not expected behaviour. And when you introduce for instance bits of XP, Scrum or Kanban, people might complain there is not enough ceremony. We’ll explain why that is later. For now, Bob could not say more than “don’t worry” to the people who were worried about their job…

Bob learnt that a routine culture works well if the context is well known, and is characterized by:

• Feedforward control,
• There is a best way to develop software
• Silver bullets
  • Methodologies
  • We need a tool!
• Management by controlling
• Process oriented

We often find routine cultures in ‘Production environments’ (e.g. hosting of web-applications) and environments like banks and insurance companies where stability is more important than innovation. Organisations with a waterfall process (which I considered so far to be a red herring, as I didn’t encounter it much, but I’m getting more work in this area) can also be considered to be routine.

When Bob worked at XYZ Widgets Inc. , he wanted to introduce weekly planning meetings and daily standups to track progress and release products sooner with less overtime. He expected happy responses at the customer’s site. Instead, several of the programmers went : “oh no, not a one hour meeting every week! Just leave me alone to code. And those ’standup meetings’ every day, do I really have to be there? Can’t you do them without me?”

Later, Bob figured out he found himself in an instance of a ‘variable’ cultural pattern. Developers (usually a few) work very closely with a customer, and do whatever they feel like to give the customer what they want. Don’t bother to ask them when they can deliver – they won’t be able to give even a rough estimate. But, at some point they will deliver, because they like the customer.

Bob experienced that variable culture works well if the problem/challenge is small enough, and is characterized by:

• Close cooperation between customers and developers
• Craftsmanship
• Hands-off management
• Performance and quality totally dependent on individuals
• Heroes

Come to think of it, a variable culture goes pretty well with the values of the agile manifesto… So is it any wonder that co-workers in a routine culture are afraid when you mention the manifesto? They see heroism, variation in quality and they don’t dare to care about innovation, because their environment traditionally thrives on providing stability… And there is no reason to risk sacrificing stability (unless there is a crisis of course…).

Marc and I presented another iteration of “Beyond Agile – People versus Process” at qcon. This transcript was inspired by the re-done introduction. I plan to write some more soon… We had an article in production that we’re going to rewrite based on last weeks Agile Open France. The choreographies, the random order and the questions you saw at the top of this post worked well, so we are going to do more with that.