The Reality of Management in Agile

Over the last four months, I have written a dozen blog posts concerning management of software development. I will write more, but I’d also like to draw a line under this mini-series right now—there are other things I want to write about.

Management in and of software development is an important topic, and simply abolishing it is simplistic. Although, as I said earlier, sometimes the management is so bad that getting rid of it is an improvement.

Right now, I’d like pull together some of the key arguments I have made in this mini-series. And I’d like to start with the words of Fred Brooks:

“The quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.”

Brooks, Mythical Man Month, 1995

Perhaps the key argument I'm trying to make in this series is that there is “management” work to do—the same as there is coding, testing and customer understanding.

Such work is legitimate, and just because it isn’t coding, testing, or requirements analysis and gathering, doesn’t make it irrelevant or trivial. Manager-less teams might well reduce the amount of work, which is good, or might redistribute the work, but there is always a residual amount.

Much, if not most of this work, involves decision-making. Such decision-making usually requires authority and may require making decisions with less than perfect information. Sometimes the missing information is unknowable or is only knowable at a prohibitive costs (time, money, etc.).

Consequently, doing management work requires skills of its own, but it requires intuition even more than skills. For instance, as I've stated before, it takes an engineer to manage engineering. Non-engineers managing engineering work usually lack intuition to make effective engineering decisions.

Once you recognise managing as a skill in its own right, the question then becomes, "Is it better to spread the work around or centralise it in one place?"

Other things to consider are:

• All who are called manager are not.
• There are many non-commissioned managers.
• Some managers and some NCOs are specialists—not really managers.
• Much of management is administration—it might be reduced, delegated, or dispersed, but some still remains.
• Some administration requires authority but perhaps not as much as we might think.
• If it is to be done right, some administration requires engineering knowledge in an engineering environment.
• Managers deal with the messy, irrational world and attempt to interface it to the rational world.
• Management work is contextual—it is hard to give specific advice because there are so many variables and so many of the variables are unknown or unknowable.
• We may well see more management work migrate to engineering space and be automated.
• Managers don’t do anywhere near as much planning and strategy as is commonly supposed, and, as a consequence, they don’t exercise as much authority as is supposed.
• Managers get things done by working through people. As a result, managers spend a lot of time persuading and reasoning with people.
• Managers spend a lot of time firefighting.
• Managing is part science, part engineering, part craft, it is a skill and requires intuition.

Allan Kelly is a consultant who advises companies how to implement Agile for their software development teams. He is based in London and works for Software Strategy Ltd.