Currently I find myself in various roles. At times as Scrum Coach, as trainer, as sales guy. When interacting with companies in the IT domain, at times, I have the impression that stuff like “best practices”, recipes, and clear guidelines are necessary to convince managers – or at least provide them some sort of certainty.

My usual answer to questions like “how would you do X?” is mostly “sorry, it depends.” Most of these times I find myself giving a weak answer. At a recent interaction with a psychologist, I was able to see a pitfall in the questioning rather than my answer. Let me elaborate on that.

Traditional Change and Process Management

The pitfall of traditional organizational change management is driven by clear structure, routines, and a blue print to roll out. According to Jason Little such programs despite their clarity and certainty show a 30 % success rate.

30 % success.

Seriously? Why? And even better, why would I introduce a change management effort that promises clear structure and success, but fails 70 % of the time? The answers to these questions are grounded deeper.

The best model that described it to me comes from understanding company culture, and how to influence that. Besides others, John Roberts did some research on Organizational Development, why it succeeds, and why it fails. We have to take a systems thinking point of view to understand his reasoning.

Every system given the constraints is perfect in what it produces. Taking the company, department, team, or whatever container you may find as a system, it produces an output that is optimal with regards to the current constraints. That output is the company culture, the department culture, or the team culture. Culture consist of shared values, beliefs, mental models, norms, and language. What does matter to us? How and why do we do business? How do we interact with each other? and so on. The bottom line is that we can only influence that output of that system by influencing some or all of the inputs. But what are the inputs that result in company on happening? Roberts also has an answer for that.

First there is the architecture. That usually is reflected in the formal architecture of the company, or the organigram. But architecture goes also beyond the formal structure of the organization. It is also grounded in the informal architecture that exist between two department leads that used to work closely together with each other. They are so used to work with each other, and override the formal architecture with their informal network to get “stuff done”. Have you been there? I have.

Another input lies in the routines of the system we are concerned about. These include the formal processes and procedures that we agreed to deal with. But just like the architecture routines are also about the informal procedures. Overall it matters how we get work done, how we gather and spread information, and how decisions are made.

The final input to the system that produces the culture of a given system lies in the people. This includes their skills, abilities, their motivations and fears, their attitudes to work and risks, and their very personal interests and preferences.

Overall we get the acronym PARC for People and Architecture and Routines produce Culture.

Limitations of traditional organizational development methods

I was once involved in a company where the CEO was replaced. What followed from this change in management was a larger reorganization of the company. The next three to four months were not so pleasant when I saw stuff happening for all the people involved, a more traditional change manager was brought in, and changed stuff regardless of the people involved. Eventually I was able to move on to greener pastures. Three years later, I heard rumors that the new CEO was replaced again.

Traditional change management efforts are great at producing certainty for managers on the routines and the architectures. New team structures are found quickly that overcome the limitations that we can see up until now. Sometimes these introductions are accompanied with interviews to grasp the status quo. The same goes for a reorganization of the development approach.

These frameworks and approaches are great at producing two pieces of the PARC mixture: the (formal) architecture, and the (formal) Routines. And from understanding the PARC model we can now reason there is also something they leave out. Mainly these are the people, and their abilities. Another thing are the informal architecture and routines. Let’s take a closer look at these in turn.

People

I admit, I work together with a personal coach. She has a background in psychology, and makes me learn a lot about psychology and underlying models all the time. A while ago she told me about a training class she was giving to an IT department. Their managers kept on asking for “best practices” and clear recipes. She explained that’s not how a psychologists thinks about human endeavors. There is not human(x, y, z) produces awesomeness.

A psychologists rather thinks in probabilities. For example if someone is resisting a change that you would like to introduce there are several possibilities why this happens. It could be that the person is resisting the change because it resonates with a terrible childhood memory where he got beaten up. Or it could be that the person fears to loose his status with the change. Or it could be that the person is not convinced, or a late adopter for anything new. All these underlying causes result in different actions that I can take to make the change more likely with that person.

Unfortunately people are not simple systems, but rather complex in nature. That means that it is hard to predict what will happen all way before interacting with people. We are rather better set off by probing some response with tiny experiments first, and then see what happens, and adapt our strategy and tactics based on that response based on heuristics. Just like Deep Blue could beat Kasparov with better calculated heuristics, we can influence people better with better heuristics (sorry, I don’t know how to make you calculate better).

So, the first ingredient that is missing from more traditional change efforts lies in the people involved. But what would be the consequences to forget about these people? High? Low? Here is an anecdote that I went through a couple of years ago.

I was part of a Scrum team with overall six team members. We were eagerly working with unit tests and TDD to produce great code. Unfortunately we failed to deliver anything for two Sprints straight, and the pressure from the ProductOwner started to pile up on us – besides the fact that we were anxious and ashamed that failed to deliver on our planned results – I mean even to the degree that we finished one story in two Sprints.

So we sat together at the team retrospective to identify and overcome the problem that was hindering us. Long story short, we found that two team members could not work together. We were using a lot of pair programming. But these two guys just couldn’t work together. After we had the issue transparent we dealt with it by stating that it would be ok for them not to pair, and find other partners, and maybe find some conflict resolution for them in the mean time.

The next Sprint we delivered twice the stuff that we planned because we dealt with that people problem.

Disclaimer: Your mileage may vary.

Informal architecture and routines

Water cooler conversations can have some dramatic effects on how much stuff gets done – positive or negative. But why do these informal structures exist, anyways?

Taking a systems thinking viewpoint here, whenever a system does not get something from the formal architecture and routines, it tries to compensate for that with informal ones.

For example, if I am working in sales, and I feel like I don’t get enough stuff to reason my next salary increase, I will explore informal ways to connect with team members to do me a favor for my favorite customer. Maybe I can circumvent the formal process through a requirements management system, the ProductOwner, team lead, or whatever you have.

Or I might decide to meet regularly with the project manager after work for lunch, and try to get some details from him that are hidden from me at my workplace.

These examples show the power of informal connections and routines. But they form a backslash when I try to introduce a different company culture by introducing formal architecture and routines. The old culture will try to find a loophole in the new structure because us humans prefer familiarity over comfort. That means in the context of the informal ingredients to the culture, that we will try to find informal architecture and routines to produce the same culture as before again. Pity if you focus solely on the formal ingredients, as you will miss out so much transformation that might happen otherwise.

Coaching, anyone?

Last week at Agile 2013 I was once again confronted with the question on “now, what does an Agile coach do?” Here is the bottom line: He keeps the people and the informal architecture and routines in mind to make culture shift. At least a good one. That means that he makes suggestions for sending people on trainings, helping them grow personally, and intervene with informal routines and architecture that undermine the desired target culture.

The problem arises with the nature of the human being. We are complex beings. So, we can’t simply roll out a blue print for change to happen. If we try that, and loose focus on the informal structure and architecture, and the people involved, we will introduce new formal ways of work that have nothing to do with the lived reality – and certainly not with the culture we strive for.

In Scrum and also in Kanban we therefore need someone with the skills to help us with transforming these missed out elements. For example, Scrum has certainly something to say about the routines (think meetings and delivery procedure) and the architecture (think about roles). We still need a coach (which could be the ScrumMaster) in place to help us with the other stuff. It’s even harder for Kanban as Kanban addresses the (formal) routines, but does not say anything about the architecture whatsoever.

So, if I were a manager, the bottom line is this: I can either choose (perceived) certainty now by rolling out a blueprint to the routines and architecture, and have a 30:70 chance this succeeds in a resulting culture that is sustainable and produced better results. Or I could deal with the uncertainty by probing my environment and the people in it, and make more informed decisions about where to go. (And we are likely to find out we need to go somewhere else after we sent the first few probes.) Does this sound familiar? For me it does.

I don’t know what you need, but I know to get it. That’s why it depends even though you are looking for more certainty.