Myths of agile: “Agile is just micromanagement”
I’ve seen quite a few “Agile sucks” and “Agile is dead” posts making the rounds lately. They get trotted out every year or so and spark some lively but uninteresting debate.
Most of these are just clickbait and are not worth discussing. But some are sadder and tell depressing stories of “agile” projects dominated by micro-management, that crush the spirit of hapless developers. Stories of megalomaniac product owners, sadistic scrum masters, and development teams sent on death marches in an approach that was created to avoid death marches.
But the common theme of these stories is that Agile is used for micro-managing people and their work. This should never happen, and it is a dishonest abuse of the word “agile”, if it happens.
Agile projects have micro-work but not micro-management
Agile shouldn’t lead to micromanagement, despite what you may hear
It might seem that agile software development could lend itself easily to micro-management. And that’s because the work is divided up into very small parcels, and those parcels are defined explicitly and made visible and can be individually controlled.
On a Waterfall project, micro-management is unlikely. The scope is defined into big chunks, backed up by big requirements and big specs. And a team of developers will say “we’re going to grab these three specs and build these three screens in this system”. Then they run off and nobody sees them for two months.
Then they come back and show what they’ve built and the stakeholders find out what they’re getting. On Agile projects, you have small teams with embedded product owners building small components based on small “user stories” or similar in small time slices.
So is agile micromanagement? Should Agile projects be suffering from micro-management all over the place? Wrong. If they’re done properly, they should have little or no micro-management at all. Why? Because the team members manage the work, not the “boss” or the “manager”. And if that doesn’t happen, you can’t really call it “agile”.
Agile teams are empowered teams
Empowered teams, who are trusted to find their own best way to do their own work, is a core concept of Agile and has been from the very beginning. Yes, it is in the Agile manifesto. Here it is:
Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.
And also here:
The best architectures, requirements, and designs emerge from self-organizing teams.
As shown, it is a fundamental part of agile and has been from the very beginning. If you do not have empowered teams, you’re not doing agile. If you do not trust your team to find their own best way to do the work, you’re not doing agile. And if your teams are not self-organizing, you’re not doing agile. It’s that simple.
The next few points apply to Scrum, which is the system I know best and am most familiar with, but most other variants of agile have pretty similar rules around these things.
The team chooses what work to pull into the sprint
At the beginning of the sprint, in the Sprint Planning meeting, the team (not the product owner, not the scrum master, the team, if you don’t believe me go read the Scrum guide) chooses what work to pull into the sprint. Note: this could be “nothing whatsoever”. The team is 100% empowered to say “none of this work makes sense, we’re not doing any of it”. Or “none of this work is sufficiently defined to be pulled into a sprint, so we don’t have anything we can work on”.
This is of course very rare, and would probably be grounds for the scrum master cancelling the sprint altogether. But it is worth pointing out who has the say here: the team. That is, the people who do the work. They choose what work they do.
If they don’t get to do that, you’re not empowering your team, you’re not following Scrum, and you’re not doing agile. Because the agile manifesto says you need to have empowered and trusted teams. And because the Scrum guide says that the team decides what work to pull into the sprint.
The team chooses how much work to pull into the sprint
This follows on from the last point: the team decides what and how much work to pull into the sprint. So death marches should not happen in Scrum, or very rarely and only for a sprint.
If the team makes a gross mistake in their estimation, and pull what they think is a manageable amount of work into a sprint but it turns out to be much harder than they thought, then they can revise their estimations and predictions for the next sprint, and only commit to a much smaller amount of work. The team chooses how much work they do each sprint.
This is also in the Scrum guide, and it is also in the Agile manifesto:
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
See? Sustainable development. Work at a reasonable and continual pace. Nobody can force an agile team into a continual death march because nobody can force work onto the team. The team pulls work into a sprint. Nobody outside the Scrum team can push work into a sprint. In Sprint Planning, Backlog Refinement or any other time during the sprint.
The team chooses how to do they work that they pulled into the sprint
The team is responsible for coming up with a plan for how to do the work. The product owner does not get to plan how the work is to be done. The scrum master does not get to plan how the work is to be done. The Scrum guide is explicitly clear on this: again, go read it if you don’t believe me. Here it is, clear as day:
Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint.
I cannot see how they could make that any clearer. If your developers don’t get to choose the work they do in a sprint, and how they do it, then you are probably not doing Agile and you are definitely not doing Scrum. Go read that quote above if you’re still not convinced.
But doesn’t this lead to chaos? And nobody doing any work?
You might be thinking “but this is madness! People are fundamentally lazy slack-arses. They only work hard because there’s a big strong leader yelling at them and telling them what to do and how to do it. And reminding them that their paycheck is on the line if they don’t pull their socks up. If we let people do whatever they want, nothing will get done! Everyone will be slacking off, or wandering around in a hopeless mess, crying out for some clear directions!”.
This is a manifestation of a sad and misguided “management 1.0” line of thinking. This is what Frederick Taylor thought, 100 years ago.
The world has moved on. We are not building widgets according to a scientific textbook anymore. These days, we are engaged in collaborative knowledge work. We need to empower and trust our people, so they can get the best job done that they can. You need to empower and trust your people, or you need to stop working with them.
You need to trust your teams
I work with teams and I trust them to find the best way to do the work. I don’t tell them what order to do the work in, I don’t tell them which person picks up which task. And I don’t tell them when to start this or to stop that. I don’t tell them how many unit tests to write. And I don’t tell them which UX design approach to use.
I trust them to do all of those things.
That’s because I work with people I trust. I trust them and they trust me. I trust that all the people I work with will do the best job they can, with the current resources and information and time that they have. I don’t peer over their shoulder, I don’t spy on them. And I don’t micro-manage their work. So I don’t believe that agile micro-management. And I don’t think that agile sucks.
If you don’t trust people, don’t work with them
Life is too short for bad projects, grumpy bosses, unhappy workers and micro-management. If you don’t trust the people you work with, don’t work with them. Sack them, or sack yourself, and go work for another company.
Well, that’s my rant for the day. Please tell me what you think!
Frequently asked questions
What is a common misconception about agile and DevOps?
There are many of these agile misconception. This one about documentation is a very common one. But there are others, such as that agile means no planning, agile is fast and cheap, and agile is dead.
Is agile a form of micromanagement?
I have hopefully answered that no it is not micromanagement at all! Please re-read the article above if you’re not sure, or contact me if you want to discuss further.
Is Jira a micromanagement tool?
Jira is a common tool used in the world of software development. It does not necessarily lead to, or avoid, micromanagement.
Does agile have managers?
There definitely is room for managers in an agile world, though it is a different role for managers than the one they may be used to. It will involve more servant leadership, for example.
