There’s a lively discussion on the web about traditional and agile management methodologies, and about if and how they could or should be combined. As so often when discussing methods, it is easy to forget to ask what really the job is like that needs to get done. So let’s take a step back.
A team working on a software is solving many and complex problems. The job of management is to ensure that the team gets and stays on a direction towards developing a good solution. So to discuss management approaches for problem solving teams, one needs to understand how such teams act inside.
Teams are complex systems
The main characteristic of a complex system is that it shows behavior which can’t be fully predicted. The system is emergent, or in other words, the whole thing is more than the sum of its parts. Typical attributes for complex systems are a large number of parameters, intransparency (in terms of unknown parameters and dependencies), non-linear reactions or time-lags of reactions.
Good examples are the economy (think of how the reserve banks and governments try to get a handle on it since the crisis started in 2008), the human body (think of side effects of medication) or the weather (almost any forecast tells you something different for tomorrow).
Teams are complex systems as well, because already human individuals are. How a group of individuals interacts is just as unique and unpredictable as a single person is.
How are complex systems controlled?
That’s obviously now the key question for any manager and management stakeholder of software developing organizations.
The bad news is: Complex systems are difficult to control from outside. There is not enough knowledge around to know in advance what outcome some operation on the system may produce.
Because of this missing knowledge complex systems need to be controlled in a different way – with a so called feedback-control mechanism:
1. Define a desired target state
2. Operate (i.e. adjust some parameters)
3. Measure the result you get (caution, possible time-lag of reaction!)
4. If necessary, go back to step 2 and adjust again.
You do this iteratively until you have reached the desired target state.
This may be just like the heating in your house, when you try to find a setting that makes it cosy for you. (I keep on adjusting mine since years, trying to find the optimum between comfort and preserving energy. My problem there is that I have a very slow feedback cycle – I can’t see how much oil is consumed on a given day, I only know how much they put in the tank when the winter season is over.)
What does that mean for managing teams?
Traditional management typically exercises control from outside with command-and-control (“you do this, you do that”). The assumption is that the steps required to solve a problem can be defined upfront and can (or even must) be dictated to a team.
What we know today about problem solving and teams however gives no explanation why this should be effective or the method of choice. Telling a team not only what problem to solve, but also how to do it, gives more constraints to this complex system. More constraints usually make the job more difficult and lead to a lower overall optimum.
Example: You want to increase the temperature in your house by 5 degrees. Your heater can do this in 2 hours. Now, as an additional constraint, you allow a maximum fuel consumption of the burner of ½ liter per hour. Now the heating takes 4 hours. If you’d add another constraint, say you want the heating in maximum 3 hrs, the system will fall short at least one of the goals (or even all if poorly managed).
The same is for teams: Developing the software is one goal for the team (obviously it should be the most important one). Making the team follow a predefined plan is setting a constraint to this. Enforcing a process, a certain role setup, the use of certain documents and tools, separate supplier teams (e.g. offshore), all these things are adding more constraints. The more goals there are, the more difficult it is for the system to operate smoothly and to reach a good optimum on any of them.
The key lessons:
- Goals are constraints – so be careful about what you set as a goal. The less aspects you measure, the better the results will be for those you care most about.
- Therefore, clearly define and manage the priorities of the goals
This is basically the conclusion the agile philosophy came to – give a team one goal (the software), measure it frequently (short iterations), and apart from that let the team work and find its most productive style of working together (don’t dictate processes).