I attended Israel Gat‘s session with this title at Agile 2010. I was already familiar with some of the concepts based on a private seminar given to my coaching circle by Michael Spayd.
For me organizational change is a hot topic since I keep running into it when adopting Agile practices.
Schneider Model for understanding Culture
Israel introduced the Schneider model for understanding company culture. The idea is to use survey questions to categorize the dominant culture into one of four categories (see below).
Many companies we work with are a control culture while Agile is all about Collaboration and Cultivation and (sadly) to a lesser extent about Competence.
You Can’t Change Culture
“Culture is singularly persistent” – Drucker. It is estimated that it can take 10 years for the culture to change in a large company.
Consider the chart in the middle of the diagram below. If we want to be successful in adopting Agile (or anything else) it is essential to focus on harmony with the existing culture. Pushing for different culture will lead to conflict.
Agile adoption leads to conflict
This is an observation rather than a pejorative. With the best intentions Agile will accidentally lead to conflict within the organization. The example given was of different cultural biases within different departments.
For example, Competence in Engineering and Control in Operations. In addition to differing departmental objectives, us vs. them thinking will also create tension. Israel talked about the Outmodel that describes perceptual bias that we create when we have limited information about a situation. The idea being that by design of our organization, there will be conflict between the groups and Agile adoption only makes this worse by perturbing the system.
One idea proposed by Israel is to create a boundary object between different groups. In the case of Development (Engineering) and Operations, one could use Technical debt as a way of measuring the quality of the code to satisfy ops that the code was production worthy. So a boundary object that has a quantitative measure is very helpful. IMHO, there is much more than this required to ensure that code is production-worthy, but that’s another story.
What I learned about myself
In one exercise we broke into the four groups to explore the different cultures. I went to Control because I have struggled with a few organizations with this culture. What I discovered is that I personally have strong control tendencies. I also discovered that control can save a lot of time by decisive action. The trick is knowing when to apply it. I experimented with my workshop later in the conference and was happy to see that very strong direction around group logistics and exercise structure can make a session more coherent and valuable.
And now for something completely different
Clarke Ching shared a great 6 min animated video on organizational change by Eli Goldratt.
