Dreamfeed

Routine – we follow our routines (except when we panic)

Willem wrote that a routine culture is not focused on results. Instead, it’s focused on methods, processes, and procedures. The underlying assumptions are that you are in a known, more or less predictable context and that you know that certain procedures and methods predictably lead to desired results. So to get to your results, focusing on steps, procedures, methods should be enough. It’s basically feed forward control of your software development system.

Working from these assumptions, it could make sense to blame the method or blame the person following the method if you don’t get the desired results: by following the method in the right way, you should get the right results, hence wrong results mean either the method doesn’t work or the people didn’t follow the method.

A Routine culture can work, as long as its underlying assumptions hold. A pitfall here is that when the methods are working well, they get reinforced, making them more and more efficient. The software development system gets more and more adapted to its context, but also less and less resilient to changes in that context. The assumption that the correct method produces a correct result becomes a ‘truth’. The system will get into trouble when either the context remains the same for a long time and then changes radically or when the context changes subtly over time and these changes are detected when they’ve grown big.

If a method doesn’t work any more, most people still try to make the best of the situation. There grows a tension between the espoused theory – the official method – and the theory in use – what people actually do to get results. This tension can be useful to stimulate process innovation (for more information about espoused theory vs. theory in use, see Organizational Learning II by Argyris and Schön).

A dysfunctional reaction is to cling more and more to the methods and blame the people for the results becoming worse. Now the theory in use and the espoused theory start to run widely apart. The link between them gets lost, some people focus on the method, trying to carve it in stone (without a defined process, how will we know who to blame?), others just try to get things done in spite of the Method. The painful tension between what actually happens and what ought to happen is covered up with a blanket of undiscussability – if you try to discuss the gap, you’ll be punished. Even the undiscussability is undiscussable. This is basically a Train-Wreck Management culture, with lots of blaming from management towards development. Now your organization is in deep trouble, a useful intervention could be to get a new job. There are other ways to get your organization out of this mess, but that’s a topic for a future blog entry.

A congruent response to the tension between espoused theory and theory in use is to acknowledge the end of the illusion that your methods are working, embrace the chaos, and move through practice and integration into a new status quo (in terms of the Satir model of change).

So within a known, more or less predictable context, a Routine culture can work. You should however frequently verify the underlying assumptions and improve your methods if they aren’t working any more (see also the Standardized Work principle of The Toyota Way). If you’re doing this, you’re in fact moving towards a Steering culture, by using feedback from your results to manage your software development system.

The next installment will be about why a Routine culture is often not appropriate for IT projects.