Dreamfeed

I’d like to invite you to propose session(s) for the Agile2008 conference (4-8 augustus 2008 in Toronto). It is the biggest international conference on agile development.

Would you like to tell about your agile adventures in an experience report? Do you have words of wisdom for a tutorial? Would you like to explore questions and issues in a workshop? Propose a session!

This year’s review process is iterative and transparent: until the end of February, you can update your session proposals based on the reviews you receive. You can also give feedback on other people’s session proposals. If you have a rough idea for a session, but not a perfect proposal yet, that’s also ok: just propose it and refine your ideas based on the feedback you receive.

I’m producer of the Agile and Organizational Culture stage. Linda Rising and Diana Larsen are doing a wonderful job in helping me organize it. So I’d like to ask in particular for sessions about topics like:

• interaction between agile and culture
• culture change
• agile itself as a(sub)culture
• agile in different cultures across the world
• working with different (sub)cultures in one organization
• …and anything else that relates to agile and culture!

See you next year in Toronto!

Here’s a summary of the six cultural patterns of software organizations we’ve been writing about the last months.

The Oblivious culture has taken away fear of computers and brought IT within reach of ordinary people (i.e. non-IT people). There is no separation of user and developer, which makes this culture very agile, adaptive, and customer oriented. The risk of an Oblivious culture is that the systems being developed grow complex without anyone noticing. If people finally notice, the impact of errors can be huge.

The Variable culture values craftsmanship and fosters innovation. There is close collaboration between user and developers. This culture is results oriented, management is hands off. Performance and quality are fully dependent on specific individuals. Sometimes it’s a culture of heroism. The risk of a Variable culture is the lack of knowledge sharing between individuals, and, as a result, no development of the organization as a whole.

The Routine culture brings order to chaos. It applies feedforward control, assuming a well known and predictable environment. The culture is process oriented. People assume there is one best way of developing software (methodologies) and look for silver bullets. Management manages by controlling, often resulting in micro management. In this culture you often encounter blaming and lack of trust. The risk of a Routine culture is going awry when getting into unforeseen circumstances.

The Steering culture makes extraordinary things ordinary. It applies feedback control, is results oriented and based on trust - act early, act small. Testing is an essential part of many feedback loops. The risk of a Steering culture is getting stuck in a local optimum: by focusing on stability you can miss process changes that lead to a much cheaper, better, faster way of working.

The Anticipating culture makes everything more efficient, moving out of local optima. Change is managed consciously and introduced deliberately. Everyone is involved with change. This culture is process oriented, continuously reflecting and improving - if it ain’t broke, fix it! Typical practices are full blown retrospectives, risk management, and scenario planning. The risk of an Anticipating culture is getting so involved with processes and meta processes that you miss out small, subtle possibilities for improvement.

The Congruent culture makes sure continuous change, reflection, and improvement are rooted in the culture: these become part of the organization’s DNA. A Congruent culture is highly customer oriented.

A nice article about moving towards a more congruent organization, is Beyond Blaming: Congruence in Large Systems Development Projects by Jean McLendon and Gerald M. Weinberg.

Together with Willem, I’m writing a paper about the cultural patterns model. We will first publish a Dutch version, an English version will follow soon. If you’re interested, let me know and I’ll send you a copy. We also welcome volunteers for reviewing - in return, you’ll receive an honourable mention in the paper

We’ve toured around with our People vs. Process session. At XP Days Benelux we did the session in 60 minutes, which proved to be a little on the short side for the exercises and discussion the session generates. At XP Day in London we had 90 minutes, which is about the right amount of time.

According to the feedback we received, most people liked (or even loved) the session; it made them think and gave them new insights, like why agile does not always work. The slides are available for download (PDF, 1 MB). I enjoyed both conferences a lot. Lots of people have written about their experiences, see e.g. the reports about XP Days Benelux.

If you missed us at the conferences and you would like to know what this fresh perspective on organizations and teams is, let Willem or me know. We’d be happy to run the session at your place and let you see things in a way you’ve never seen them before…

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.