Dreamfeed

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.

Transitioning to agile means going from a Variable or Routine culture to a Steering culture. Indicators for a Steering culture are the ideas of empirical process control, embrace change, and apply-inspect-adapt.

The agile community provides all kinds of process models that are in fact mental models of software development: e.g. Extreme Programming, Scrum, Lean Software Development, Crystal Clear, the stories people tell, external consultants’ pet peeves. These are a good source for routines to choose from.

Practices like daily standup meetings, short iterations, frequent releases, iteration retrospectives, test driven development, continuous integration, big visible charts, stop the production line mentality all help improve the visibility and stability of the software development system.

An agile transition has a number of failure modes. I will briefly describe three of them.

Agile backlash

Introducing visibility can be scary. I have seen and heard about multiple XP and Scrum initiatives that got killed because the sudden visibility of problems and (lack of) progress was threatening to middle management. Instead of becoming a Steering culture, it remains Variable or Routine. I’ve met for example a manager who waved away any agile practice as soon as it didn’t fit with his own agenda, saying that you shouldn’t be dogmatic with agile…

To reduce the backlash problem, ensure higher management support for your agile initiative.

Agile by the book

Now that agile has crossed the chasm, I see more and more organizations that do agile ‘by the book’, basically going through the motions without a good understanding of why they are doing it (saying e.g. that you should stick to the rules). This is ok if it’s a temporary phase in the transition process. When people start understanding the ‘why’, the organization can transform to an effective Steering culture.

If a team gets stuck in this phase, it basically settles on a Routine culture. It will go awry sooner or later and the people will blame the agile ‘method’ for the problems.

An experienced agile coach can help you through this phase.

Agile getting into a rut

Steering is based on finding deviations between observations and objectives. This is the basis for improvement. If everything is running smoothly and going so well that there are no obstacles any more, there’s a risk of complacency. Peope forget why they are doing the things they do and the system slowly becomes a Routine culture.

To avoid this failure mode, you can train yourself and your team to become conscious of this process and learn to introduce changes and experiments just for the sake of change. Learn how to keep the software development system awake by jiggling it. It’s a first step towards an Anticipating culture.

Would you like coaching and guidance in transitioning effectively to a Steering culture? Would you like to learn how to jiggle your agile system and how to keep it alive and kicking? We can help you – feel free to contact us.

• Ronald Doelen has written a nice blog entry about his CITCON Europe experiences
• James Shore wrote about an energized work experience; the story is an instance of the systems diagrams I published earlier this week.
• I discovered a good article on the Satir change model by Steven M. Smith.

• Willem and I have been working on working on a proposal for a new website for a not-for-profit organisation supporting a community of practice. This has resulted in a nice systems diagram about the dynamics of attracting traffic to the website and the associated costs and benefits.

To establish an effective Steering culture, you need:

• a mental model of how the software development system works
• process visibility
• process stability

Mental models

You need an implicit or explicit mental model of how your actions affect the system and its outputs. Routine managers tend to use simple, linear models, relying on prediction by extrapolation. This leaves little room for variation and unforeseen changes. Managing in a Steering environment means you apply more sophisticated mental models, taking into account nonlinearity and cause-effect relations separated in space and time (systems thinking).

A typical Routine manager for instance assumes the amount of work done is directly proportional to the number of hours put in. So when the project is getting behind, he mandates lots of overtime. His mental model is illustrated by the causal loop diagram below.

The diagram shows three variables that you can measure or observe: the number of hours per week, the amount of finished work, and the amount of work left to do. If the number of hours per week increases, the amount of work that gets finished increases as well (indicated by the causality arrow and the +); if the amount of finished work increases, the amount of work left to do decreases (the inverse relationship is indicated by the -). This is a balancing loop (indicated by the scale symbol), because at a given moment the work left to do decreases rapidly enough to be finished before the deadline.

What happens in reality is that things speed up at first, but after a few 80 hour weeks, the exhausted developers create more and more defects and the project completely runs out of control. The diagram below shows the dynamics. After a delay (indicated by ||), fatigue will take its toll, resulting in more defects and more work for the developers.

This creates a self-reinforcing loop (indicating by the snowball), pushing the system towards collapse – resulting in things like burn out, people getting sick, people leaving.

A Steering manager knows that overtime can work for a short time only. After that, people will become stressed and tired and will make more and more mistakes that add up to the work left to do. She also knows that the effect of work to do on the hours per week is a management decision: she can decide not to increase hours, but instead make sure the team gets enough rest.

Note that a Steering manager will usually not get into this situation; she will detect early on that the project risks getting late, when there is ample time to change the plan, get new people up to speed, or renegotiate with the customer.

Visibility

If you can’t observe or measure what’s happening, you’re not able to know if things deviate from the plan and you have nothing to base your actions on. As an example, you can observe how a culture handles failures and defects.

In a Variable culture, where customers and developers work closely together, the customer reports a defect directly to the developer, who fixes it right away. This makes it hard to get insight in things like the amount of defects reported and solved or the amount of new defects introduced after fixing a defect.

A Routine culture doesn’t regard a defect as information, but as something to assign blame for. As a result, defects are moved around like hot potatoes, ignored, blamed on the user, classified as ‘minor’ (i.e. it won’t get fixed – learn to live with it), or relabeled as a change request. Managers buy fancy bug tracking tools, but these are not used effectively. Because of the blaming associated with defects, making defect handling more visible will run into a lot of resistance.

Scrum and Extreme Programming provide simple and effective ways of increasing project visibility, e.g. through velocity, burndown charts, story walls, or kanban boards. So these process models can help you transition from a Variable or Routine culture to a Steering culture.

Stability – If the software development processes are not stable, you don’t know what the effects of your actions are. If e.g. your project velocity varies wildly over many iterations, your burndown chart becomes meaningless, and you can’t promise your customer anything.

Introducing automated testing at different levels (unit, integration, functional, acceptance) helps to stabilize your projects.

Links

• George Dinwiddie, It’s all about feedback
• Peter M. Senge, The Fifth Discipline: The Art & Practice of The Learning Organization, about systems thinking, mental models, and organizational learning.
• Donella H. Meadows, Places to Intervene in a System
• Linda Booth Sweeney & Dennis Meadows, The Systems Thinking Playbook

Would you like to explore systems thinking and mental models as a tool for better understanding and better decision making? Would you like to get a grip on your projects? We can help you – feel free to contact us.

Last weekend, I participated in CITCON Europe 2007 in Brussels. CITCON stands for Continuous Integration and Testing Conference. It is part of a worldwide series of short Open Space conferences. The session results can be found on the CITCON wiki.

I liked the conference: good atmosphere, interesting people, met a few new people and a number of the usual suspects at agile conferences. The Open Space format proved again to be a good process for high energy and peer to peer exchange of experiences. It was just a bit short – one evening with opening and agenda creation plus one full day of sessions.

Being an Open Space fan, I was also interested in how Paul Julius and Jeffrey Fredrick facilitated the process. They did a good job at organizing self-organization . For a lot of participants this was their first Open Space event and they liked it. There also was self organizing wall, with a growing number of sticky notes, about the next conference location, people looking for work, work looking for people… – great idea, I’d like to do something like that for the next Agile Open.

I liked the Helping teams to change behavior session in particular, hosted by Jeffrey. It was about ideas, tools, and techniques for bringing change in teams. He mentioned models like Crossing the Chasm by Geoffrey Moore and the Satir Model of Change. The stuff was new to most of the participants in the room.

Links

• Open Space Technology
• Agile Open conferences
• Satir Model of Change (pdf)

Would you like to learn more about how the Satir tools can help your teams change effectively? We offer workshops and coaching, feel free to contact us.