Dreamfeed

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.