Red Flag: Command and Control Management
Every attempt at transition can have issues. Some issues are fairly common regardless of who attempts the transition. No matter who tries to cross the Sahara there will be a lack of water available during the trip. These common issues are often called red flags.
Every desert crossing attempt is unique. The people and methods involved vary. Some may be making the trip over the course of week, others in just a few hours. In each of these circumstances the best way to address the lack of available water is very different.
In Agile transitions there are also red flags. Just as with crossing the desert each Agile implementation is different. As such there is not a proper way to address every issue every time. The more similar organisations are the more similar the solutions may be, but even that is not a given. Today we are looking at the Agile red flag of a Command and Control Management.
I have seen a lot of talk lately about what happens to middle managers during Agile transitions. These middle managers traditionally told people what to do and ensured it was done. This Command and Control Management style is generally frowned upon in Agile circles. It should be no surprise these middle managers often resists changing to Agile. They might play the game while preventing true change. It turns into a situation where people use lingo from the agile world while going through some motions, but nothing really changes organizationally.
The military is the classic case of command and control. In my four years in the Navy a significant amount of time was spent on a submarine with about 120 other people. We all had specific jobs to do. In normal operations there was time to question why we did things the way we did. In abnormal circumstances the time taken to question an order by any member of the crew could result in the deaths of not only the whole crew, but outside people as well. The soldiers (team) must have absolute trust in the commander (manager).
Extreme examples aside it is not normal for a company to need the level of immediate obedience that can be required in emergency or combat situations. Agile transformations generally plan for these middle managers to assume roles such as Scrum Master, or become managers in an employee development and HR sense only. Agile generally looks for the manager to trust the team to make decisions, not the team to trust the manager’s direction.
If a manager cannot stop command and control actions it could cause problems in the Agile transformation. Customer Collaboration and Responding to Change are both expected to happen at the team level. In the principles giving individuals trust is explicitly spelled out. The team is defined as self-organizing. None of these attributes will thrive in a command and control culture.
In an Agile transformation the command and control manager needs to push vision and goals instead of assignments and tasks. Start to dish out the why and leave the how to the team. This will not be easy. Start conversations with “how can I help” instead of “what are you doing.” Trust that a successful team will look good for the manager and let them succeed. Think of every task handed out as a distraction from the goal already given. Stop micro-managing, but don’t stop leading.
As a counterpoint I would like to float the idea that command and control, while not a good fit for software development, can be successfully used in Agile situations. Some of the primary tenants of Agile are responding to change and prioritizing people. Some industries might need command and control in the moment, such as fire and rescue. They will also benefit from listening to individuals and responding to change over time. Even in software development there may be a time when a task of fixing a bug needs to be commanded onto someone, or controlling exactly how two software products interface is required. As long as the individual is still more important than the process, change is responded to over time, working software is delivered, and the customer is involved it could still be an Agile environment.
