- Oblivious – we’re not aware that we’re developing software; there is no separation between user and development, e.g. a manager who writes Excel macros to support his decision making process.
- Variable – we do whatever we feel like at the moment; performance depends mainly on individuals (superprogrammers, “heroes”), e.g. a small startup with a few very skilled programmers developing the first product version quickly and efficiently.
- Routine – we follow our routines (except when we panic); e.g. an IT department that establishes a waterfall project management methodology as the right way to run all IT projects; this kind of works for projects that aren’t too complicated, but when applied to a brand new, important, complex project, everyone drops the standard process and works 60+ hour weeks towards the end of the project, in a desperate attempt to get the project finished.
- Steering – we choose among our routines by the result they produce; e.g. an agile project with short iterations provides insight in the results at the end of each iteration, through product demos and iteration retrospectives. This gives the product owner the opportunity to steer the product and the team the opportunity to adapt their way of working.
- Anticipating – we establish routines based on our past experience with them; e.g. explicit risk management activities that help to anticipate or prevent troubles instead of reacting to the troubles when they arise.
- Congruent – everyone is involved in improving everything all the time; it’s a culture of continuous reflection and improvement of processes, continuously improving the baselines; as a non-IT example, the idea of the Toyota Production System is to establish and sustain such a culture of continuous improvement.
If these patterns look familiar to you, that’s not a coincidence: they have the same origin as the CMMI maturity levels (they’re both based on the ideas from Quality Is Free by Philip B. Crosby), except Oblivious which was added by Jerry Weinberg. The patterns are not maturity levels however. Steering or Anticipating is not necessarily better or more mature than Variable or Routine. It’s all about whether a specific pattern fits your context or not.
In the context of strategically relevant IT projects, I believe it’s worthwhile to transition from a Variable or Routine culture to Steering and then to Anticipating. I’ll elaborate this in one of the next installments; for now, I’ll just mention that agile development principles and practices help you a great deal in making the shift to steering, but they don’t provide enough to help you establish an anticipating culture.
The next installment will be about the Routine pattern.