Steering software development
This is the next installment in a series of blog posts on Jerry Weinberg’s cultural patterns of software development organizations.
A Steering culture focuses on improving what you develop, through steering the software development system based on feedback about its outputs. Steering applies the concept of feedback control to software development management.
Oblivious, Variable and Routine cultures are based on lack of trust and power. Steering, Anticipating, and Congruent cultures on the contrary are trust-based: managers and customers trust developers to deliver a good job and create quality software, developers trust managers to remove impediments and to provide guidance instead of micromanagement, everyone is part of one team. I find a trust-based environment much more enjoyable to work in. It is also more efficient because it reduces the amount of communication and time spent on contract negotation.
Steering software development means observing the outputs (which includes software, bugs, happy team members, burned out programmers, etc.), comparing the observations to a plan, and taking action if a deviation from the plan is found. The actions are supposed to reduce the difference between what is observed and what is desired. In the field of organizational learning this steering process is called single loop learning. See also the illustration below (based on the diagrams in Quality Software Management vol. 1 by Jerry Weinberg).
The controller can be management, but this is not necessary. It includes anyone who influences the system, like a project manager, a Scrum master, an agile coach, or a technical lead.
A Steering culture introduces different ways of feedback and uses it appropriately. Testing is an important form of feedback. In Routine organizations, testing is a phase at the end, which in practice results in uncontrollable chaos and quality problems. In a Steering organization, testing is an measurement process that provides information for decision making and interventions. Testing is something that you can add to different processes: unit testing for rapid feedback on the impact of the code you’ve just changed, continuous integration for feedback on integration problems, automated acceptance tests for feedback on what’s done.
An example from an agile project:
After the review of the current iteration, you determine the current velocity, the amount of work remaining, and the number of open defects (observations).
You notice that you won’t be able to finish the work planned for the release next month unless you remove 5 stories from the plan (comparing to the plan).
You discuss this with the customer, who juggles priorities and cuts scope for this release (action).
Other examples of actions are: adjust the plan, add or drop requirements, add, remove, or train people, give a pep talk to the team, celebrate team success, and do nothing.
When everything is going well, Routine and Steering organizations look the same. When problems arise, a Steering organization has a repertoire of routines and is able to adapt instead of panicking. In a Steering culture people learn to pay attention to subtle signals and seemingly insignificant data, because big, runaway problems often start as small, manageable deviations – act early, act small. Daily standup meetings are an effective tool for surfacing issues quickly. Also pay attention to the emotions in your team, these are an indicator of other troubles. A Steering manager can use weekly informal one-on-one meetings with everyone as a tool to gauge emotions.
In a Routine culture, processes are defined but often not understood. This is why people drop them as soon as things run awry. In a Steering culture, processes are not always completely defined, but they are understood. You know why you do the things you do. As a result, you will be more inclined to stick to the processes in hard times. A Routine culture regards processes as explicitly definable and executable by interchangeable programming resources developers.
A Steering culture acknowledges that parts of the processes can be explicitly defined (explicit knowledge) but that there is also tacit knowledge involved – the know-how in the heads of the people, which cannot be written down easily.
Links
- Chris Argyris & Donald A. Schön, Organizational Learning II: Theory, Method, and Practice
, about single and double loop learning
- Ikujiro Nonaka & Hirotaka Takeuchi, The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation, about explicit knowledge vs. tacit knowledge
- George Dinwiddie, It’s all about feedback
Do you wish to transition to a trust-based, steering culture? Would you like to learn how to steer your projects effectively? We can help you – feel free to contact us.
