Have you been involved in an ‘agile transition’ (or some other form of process improvement)?
Have your co-workers complained there was not enough process?
Have your co-workers complained there was too much process?
Bob worked as an ‘agile coach’ and had experienced all of the above.
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
- 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
- Hands-off management
- Performance and quality totally dependent on individuals
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.