There were a few great discussions about culture and the impact organizational culture has on how you can approach Agile transformation or adoption at this weekend’s Toronto Agile Open Space. During one session we dove deeper into the people behind the culture and talked about why labelling an organization with a certain culture and thereby aligning practices to that culture isn’t as simple as it appears to be.
Take the example we used of a control culture. Control cultures, as defined by William Schneider, succeeds by getting and maintaining control. At it’s best, control cultures can be extremely efficient when they optimize their rules and processes and at their worst can spin without progress while trying to strictly define and optimize those rules. The Re-Engineering Alternative goes into greater depth about the strengths and weaknesses of each of the 4 culture types (control, collaboration, cultivation, competence).
What I disagreed with in our discussion is the assumption that Kanban aligns well with control culture. It’s not that simple. An organization may have a dominant culture of control, and depending on the size of the organization, teams and departments will establish their own identity and sub-culture. From a management or executive perspective, Kanban, and more specifically Lean, *can* align well with control cultures because of the explicit tools and practices, the visibility of the work, cycle-time, lead-time and a whole host of deliberate practices that give managers and leaders data they need to find problems and make improvements. More plainly stated, it’s not the fluffy Agile stuff that means absolutely nothing to a new CEO who has 2 years to get profitable.
What about the team level? Teams within control cultures can use whatever method works best for them like Scrum, XP or Kanban….or anything else for that matter. Taking this a step further, at an enterprise or portfolio level in an enterprise organization, Kanban can be quite effective for visualizing projects, programs, products and more. Enterprise organizations have much more complex systems where work flows through and have, dare I say it, handoffs to downstream teams or departments. Purists obviously will challenge that with the typical “build cross-functional teams, hug everybody, break down those silos!” and while I agree on a principles level, reality in some enterprise organizations is that their structure isn’t able to support that. Yet. As an example, while working in a large enterprise organization, it took us 5 months to get approval to get a cross-functional team together and we had to plug-in our output to downstream “traditional” groups.
Another example, I’m working in an enterprise transition now and we’re using Kanban across the portfolio, plugging functional groups into each other by making the work visible and eventually we will (or might) have some dedicated project teams that make use iterative approaches, including Scrum. We can roll up project and program status from any team or functional group area into a larger Kanban system that speaks to management by showing them flow, which is what they are concerned about. That will help us define capacity, set expectations, find bottlenecks and determine our next transformation steps. Kanban is much less disruptive and sometimes it’s a better choice to start with, again, read the system and decide what’s best. Scrum will expose dysfunction quickly and painfully and I find novice coaches preach the Scrum gospel without ever actually having worked in an enterprise where there are strong functional silos, finger pointing and sometimes anger towards other groups. I’ve been there. A few times. I’m actually a bit miffed at myself for being a “beat you with the Agile stick” guy earlier in my career.
Semi-rant over.
Then we got into the people aspect of culture. Again in this session the topic of “how can we manage resistance” came out. Read my last post about that. Resistance is a surface response. Imagine you are a developer and someone comes up to you and says “I have this great book on TDD I think you should read. It’ll really help you.” How would that make you feel? Bringing in Kanban, Scrum, XP, Zomblatt or any other change is a change. People transition through change no matter what their organizational culture is and it’s pretty ridiculous, IMO, to say one method is going to work better in a certain culture without considering the people being affected by the change. If people were fungable, meat-based, programming units, or robots, maybe it would be that simple.
Take me for example. I love change because I love solving problems and change brings problems for me to solve. That’s who I am, it took me years to understand that and learn patience. Someone who loves detailed plans and doesn’t like un-certainty may naturally fight against change because that’s who they are. Someone who loves people will feel they need to make sure everyone going through the change is ok. Some people find change exciting because it’s new and shiny. All these people will be affected by change in different ways. You know that guy in the meeting who doesn’t agree with everybody else about the newest change to that process? There’s a reason why. Maybe he doesn’t understand what the change is. Maybe be doesn’t see the need for the change. Maybe he’s in the wrong meeting room. Maybe he is just being an asshole. Listen to his opinion, show him you understand and move on.
Here’s a diagram of how the 4 MBTI temperaments can be affected by change. Again, people aren’t robots, there are extremes to temperaments as well, I am strongly introverted. So introverted in fact after the open space I had to run home to a dark corner to get my energy back even though everybody else went out for drinks. I’m working with a strongly extroverted fellow and sometimes I have to tell him I need time to internalize when he’s flying at million miles and hour!
This is the Satir change model. A change (foreign element) is introduced and you spiral into chaos until you hit the transforming idea. Then you integrate the transforming idea into your identity and arrive at the new status quo. I’m the blue guy (SP). “Yay, problems to solve!!!” This is great for me, maybe no so great for the SJ (Orange). I can bring in change for the sake of change leaving the SJ to thrash in chaos which will inevitably frustrate them and then they could be labelled as “resistant” or “not a team player” because they won’t go along with that change. The NF (green) simply may want to hug everybody and try to satisfy everyone affected by the change. By the time you read this, the NT (red) has already gotten bored and moved on.
Again, these are based on natural preferences of temperaments and they will hold some truths for some people, people are too complex to say “because I’m an SP I can’t learn empathy to help people transition” Types and temperaments aren’t to be used to pigeon-hole people, I use them to be aware of myself and my natural tendencies so I can adjust to others around me.
Understanding organizational culture is important, understanding the people within that culture is much more important.
If you’re interested more in this topic, Don Gray and I are doing a half-day workshop on people and culture at Agile 2012.