Dreamfeed

I’ve been thinking about the relation between the different cultural patterns of software organizations and the model of explicit and tacit knowledge that Nonaka and Takeuchi present in their book The Knowledge-Creating Company.

Oblivious and Variable cultures lean heavily on tacit knowledge - the knowledge that cannot be articulated well, know-how, knowledge in the heads of the people who do the work. In Variable cultures, sharing of knowledge doesn’t take place in a controlled way, but by diffusion and chance. The master-apprentice model is an important means of knowledge transfer. In an Oblivious culture, there is usually no knowledge transfer to speak of.

A Routine culture focuses on explicit knowledge - explicit procedures, routines, methods, documented e.g. in handbooks. Knowledge is transferred by documenting everything and having people read the documents.

In a Steering culture both tacit and explicit knowledge play an important role - you need both to be effective. Processes are usually understood, but not always completely defined. People in a Steering culture know that you can document certain aspects of products and processes, but they also acknowledge that you need other means of knowledge sharing as well. You can recognize this in several agile practices, like pair programming, having the team in one room, and daily standup meetings.

Anticipating and Congruent cultures focus on creating knowledge from the interaction between tacit and explicit knowledge, like Nonaka and Takeuchi describe in their book. They describe organizational knowledge creation as spiralling between tacit and explicit knowledge and between different levels within (and beyond) the organization - individual, group, organization, inter-organization.

I’d like to explore this more in depth in future blog entries. In the mean time, if you have any ideas or experiences you’d like to share, please let me know.

Last week, Willem and I ran our People vs. Process: Cultural Patterns of Software Organizations session for the first time. We received very good feedback from the people at Atos Origin, it helped us a lot in improving the session.

We originally proposed the session as a presentation, but we couldn’t resist making it a bit of a workshop by adding a number of exercises.

Next week, we’ll run a shorter version of the session at XP Days Benelux. A few days later, we’ll do the long version at the XP Day conference in London. If you’d like to learn about different organizational culture patterns and how you can use this knowledge to make your agile initiative more effective and sustainable, join us at one of the two conferences. XP Day London has already sold out, XP Days Benelux has a few places left.

We’ll put the slides online after we’ve finished refactoring the presentation. If you’re interested in having the People vs. Process workshop in your organization, don’t hesitate to contact me.

In the current agile wave, quite a number of organizations are transitioning to Steering. A Steering culture often works quite well, but it has limitations:

• The risk of focusing too much on stability - the development process becomes stable, but performance and productivity stabilize as well; you miss opportunities for changes leading to productivity leaps.
• You need the deviations from plan to remain effective - you reduce deviations by identifying and removing the special causes of variation, but once you have no deviations any more, there’s no basis for improvement.

Martin van Vliet writes about how you can handle bugs in a Scrum project. Making bugs visible and prioritizing them in this way makes the process more stable and predictable - looks like a Steering context.

A step beyond Steering is to start wondering why you create these bugs at all. Don’t do this in a blaming way (i.e. don’t track and punish the developer who did it), but take a systemic view: your current processes did not prevent the bugs from happening. What can you do that you detect these bugs earlier - before they are released to the product owner? Can you detect them right after a developer writes the code? Or can you even prevent them altogether?

we establish routines based on our past experience with them

An Anticipating culture acknowledges that you need stability as well as changes to keep improving performance and productivity. It systematically and consciously introduces changes, not only in response to things that have happened, but also in anticipation of possibilities - thing that can happen. Everybody becomes a change artist to some degree: change becomes part of daily life, everyone learns to cope with it and to manage it.

It’s double loop learning, from a systems point of view - in addition to steering the system, you also explicitly and consciously control the models and priorities of how you steer:

An Anticipating organization tries, evaluates, and refines different mental models, applying plan-do-check-act at the product and the process level. It assumes that the right process will produce the right result (like a Routine culture). If it doesn’t, that’s information you use to adapt the processes or invent new ones (unlike Routine).

You need mental models of how change happens in your organization and how you can influence these change processes. I find the Satir Change Model and other models and tools by Satir very useful in this respect. The book Fearless Change by Mary Lynn Manns and Linda Rising is another good source.

Example practices of an Anticipating culture are scenario planning, project premortems, risk management, and retrospectives. Note that risk management in an anticipating way means exploring the possibilities of successes and failures, not the pre-emptive blaming and covering-your-ass you find in some Routine organizations.

Most agile processes recommend or prescribe iteration retrospectives. The basic format is to briefly discuss something like what went well/what didn’t go well. This adds some process reflection, but it doesn’t make an organization Anticipating. The standard format may become too repetitive, for instance.

There is much more to retrospectives: try out different things from the Agile Retrospectives book by Diana and Esther and take a next step towards an Anticipating culture. In the retrospectives, you can e.g. decide to introduce changes, even for things that are currently working well. You can also use tools like systems thinking, diagrams of effects, and the ToC thinking processes to make your mental models explicit.

Links

• Norm Kerth, Project Retrospectives - the first and leading book on project retrospectives
• Rachel Davies, How to Live and Learn with Retrospectives
• Gerald M. Weinberg, Quality Software Management vol. 4 - Anticipating Change - discusses in depth the transition from Steering to Anticipating; not an easy read, but well worth it
• Tim Lister & Tom DeMarco, Waltzing With Bears - risk management is project management for adults

Would you like to have retrospectives that are more effective and more fun? Do you wish to take your agile initiative a step further towards a culture of anticipating change? We can help you, feel free to contact us.