Agile methodologies are creating a big number of teams that work with multiple behaviors like cross-functional, multidisciplinary, and self-management. Those values allow teams to act in time and make decisions quicker than usual teams. Many times the problems that agile teams have, arise due to misunderstandings about the meaning of self-management incurring in micromanagement.
To better understand the concept of micromanagement in teams, we need to understand how actually agile teams should be performing. Instead of micro-manage, agile teams have the possibility to decide by themselves instead of waiting until the superior gives them permission to keep working.
Self-management is: Empowering the team to have control over their own actions. It requires the involvement of team members not only by the workforce, but also by expressing ideas, contributing to making decisions, and sharing ownership over the project. (Source)
These kinds of changes in management avoid having a person behind us trying to explain how we should be working or making the decisions that allow performing in our work. Sometimes micromanagement gives us micro signals that something is going bad. We want to share with you some mistakes that you could be incurred, and that are actually increasing micromanagement on your team and with it, the problems.
Product backlog prioritization
At the beginning of every sprint, the product owner decides which tasks the teams are going to be working on. But sometimes the product owner just decides for himself about the way the team should work without asking and looking for other people's opinions.
You need to talk with your team and decide which is the better way to solve the current problems and look for the team's opinion. Opinion from people that actually will be making the job and know better all the alternatives. Also, this time will help the product owner to explain why those requirements are needed and are being prioritized. Defining better requirements with all the team present will help the team to work in the same direction and facilitate the performance.
This collaborative backlog construction will help all the team to better understand why they are working on some features. Also, now they have this self- management structure to work with freedom because they know what they are doing.
Developers need to understand what they are building and why they are building a product. They should be able to say ‘I was involved in the discussion of this feature. This feature is my responsibility. I own this feature. I am in charge of it’
It can sound a little obvious but not inviting the team to participate in estimation is a big micromanagement problem. Sometimes this task is perceived as a top-down task making this feeling about superior people in the team and not like equitable people. Product Owners or managers making estimations for all the members is a very harmful and uncertain action. They will decide based on what they know and probably with less time than the real-time needed to finish a task. Who knows better the time that a task can take than the team?
The team should be in the estimation meeting and need the freedom to participate. This will not just avoid misunderstandings about the task importance, but will help the team to make more accurate estimations. Team and developers can better estimate their own tasks and must be encouraged to be good estimators of the features that they implement. Nobody wants another person to make their estimations.
Check this incredible tool to make accurate estimations with your distributed team and save time & money!
Although managerial involvement in this regard continued to be fairly high by most agile evangelist’s standards, avoiding sprint overloads and allowing each developer to estimate his or her own tasks did lead to a drastic reduction in the number of regression bugs.
Avoid designing and development in isolation.
Design discussions should be collaborative in all teams. If you let your developers work on their own and chose the design, and so on, this behavior will incur in refactor or rework, rework that can be avoided. This means that developers and designers must be involved in design discussions. It is necessary to make all the team understand why they are choosing those designs and also designers need to understand why some designs can be coded better, and thinking in the design and platform as a whole
Redefining Work overload /Changing requirements changing the backlog
Many times managers or product owners have this problem: the task named the priority changes and now there are other tasks that need to be finished earlier. The most common action is to tell the team and change everything to finish those tasks. But sometimes sudden changes can be harmful to our team, not just because they are currently working on something and they will have a stop to do it; because you never consult or at least speak with your team about it.
Redefining workload must be done with all the team and explaining why they need to change. Conversations like this will help you to avoid the decrease team’s spirit and also the members will understand and give better opinions about which is the right way to tackle those sudden prioritizations. Always have in mind that the team is doing the job, they need to be considered in the conversation.
But changes in requirements are common practice for agile teams. They need to adapt to change quickly to find solutions to new problems. That doesn’t mean that this should be done in isolation. When the team perceives that these changes are just for management decisions and they are just workers, team spirit, the culture of trust, good communication all of those can be harmed with isolated decisions.
Sometimes customers need the changes. In situations like this, the product owner needs to advocate for the customer, because customers are very important for all the teams. But also the Product Owner needs to advocate to make the customer understand why maybe the changes won't be possible during this sprint. Even explain to them that developers are making their best and making good decisions about how to make the job.
new features were viewed less favorably by developers, who were distraught when they were told that a feature completed by them either had to be changed or a new one had to be coded in its place. Developers felt that they had no control over the development process.
Disproportionate workload also can be perceived as micromanagement. The hard tasks will be for workers with more expertise, making the biggest workload for them. Sometimes this problem arises because the team defines tasks as individuals with a lot of microtask in it. Since some members have a bigger workload, a workload that most of the time is determined by the management team, it makes micromanagement that much more evident and incurring in work overload.
It is necessary to disband those tasks to make a better-detailed workload and fairer distribution for all the team. This will not only avoid overload to some members but equally distribute workloads amongst all the developers in the team and will make the team feel safer to work better with their workload.
Mike Cohn explains in which scenarios micromanagement is useful for our agile team:
The daily scrum is about micro-managing the team's daily work plans and making sure that everyone is doing what they say they'll do.
Continuous integration is put in place so that the minute some developer screws up and breaks a build, it becomes known.
Pair programming is about making sure that programmers don't lose focus, don't goldplate, don't work on only the fun stuff, and that they clean things up.
Agile is not about micromanagement, but it's about the team micromanaging themselves and for their own benefit. (Source)
Self-management is a value that helps our team to perform better and make quicker decisions. That's doesn't mean that all the team is going to work in what they want is about perform and make decisions that help the team's goal. Talk with your team and always have in mind their opinion and their job. Micromanagement can be hard to avoid but the right practices will help you to keep improving.
Remote agile teams can make the most of agile ceremonies, but they need the incredible tools to take their agile practices to the most. Check them!