The Fundamental Step Towards a Self Managed Team

I have recently heard a saying that "a perfect manager is the one that you don't need".

At first, such a saying might be interpreted as offensive, implying this manager is useless, which is the reason he (or she) is not needed. But, let's think about it, a manager that can orchestrate everything such that the team can manage without him is a damn good manager.

A self-managed team is a manager's dream. Obviously, it does not mean that there is no need for a team leader, but a team that achieves self-management allows the manager the so-necessary time to focus on the important things and guarantees that tasks are still getting done appropriately while he is absent.

When considering self-managed software teams we can discuss issues such as the team's collaboration, commitment, ownership and so on.
However, a more fundamental step towards a self-managed team is to reduce the team's daily dependency on the team leader.

In this case, we need to ask ourselves, when does the software team need its team leader?

1.    Task definition
The team leader sees the broader picture and is aware of future directions because he takes part in all relevant meetings. However, although he knows what needs to be done, this isn't always properly reflected back to the team resulting with the team missing the vision. For a team leader, when it comes to defining tasks, it's the easier to write a single-liner task knowing what stands behind it. The problem is the team cannot work with it without further explanation that can be done only by the team leader.
 

2.    Tasks allocation 
Without proper task allocation team members might find themselves working on less important tasks, or having nothing to do at all. Not to mention the possibility that multiple team members may work on the exact same task.
If the team leader is the only one to know what the required tasks are and what work is already in progress, then the team leader is the only one who can allocate new tasks to the team members. The allocation is also affected by the team members' proficiency and the team leader's management methodology.
 

3.    Making decisions
When the tasks are being detailed, it's easy to forget why they were originated, that is, what purpose they serve in the bigger picture. which makes the team leader the only one that can make conscious decisions concerning them.
In addition, he has the experience and the authority to make professional decisions, and the team members might find themselves waiting for the team leader to decide.
 

4.    Reviewing the tasks
In order to perform a meaningful review the reviewer needs the professional knowledge and review the task in light of its requirements. Because of that, a team leader might find it hard to allow others approve tasks prior to the delivery. Whether it's because he is the only one who knows the purpose of each task, or it's because he is the professional authority.
In this case he might quickly become a bottleneck for task delivery, if he is the only one that can review and approve the tasks.
 

What can be done about that?

Have a well-defined backlog. Such backlog that will contain the tasks and a well-defined methodology for working with it can answer the team's daily needs.

It's true that having such a backlog requires a lot of ongoing work, even when apparently there is no time for it. However this is the way to reduce the dependency on the team leader and is the base for the team to work as a team.

A well-defined backlog sums up to three main things:

1.    Task definition
The focus here is on how to define the tasks, after they've already been determined (how to break down the tasks has an entire separate doctrine that alone can fill a whole post).
When the tasks are properly defined, the team leader isn't the only one that can understand the tasks. It helps the team make conscious decisions because they are aware of the original needs. It enables the team become more independent, think of the solutions and judge whether they meet the requirements during development and review.

·       Tasks should reflects the needs- Not only what we want, but what we need. Tell the story behind the story

·       Tasks should be self-contained- everything the team needs to know about the task should be stated, in a way that even a developer new to that feature will understand what needs to be done. Tasks should contain links to other sources, if required.

·       Definition of done is clear- The criteria for determining that the task is complete. The theory behind this can be the subject of a post of its own.

·       It can be good to include some team members when defining the tasks, to make sure they understand it, and that nothing is missing

2.    Backlog grooming
This means ongoing work to make sure the backlog is ready to work with.
In this way when a developer needs a new task he can take the task with the highest priority that is unblocked.

·       All tasks should appear in the backlog

·       Tasks need to be prioritized

·       Dependencies should be reflected in the backlog

3.    Backlog Methodology

·       Have a board that reflects what the team is doing
Tasks can either be in TODO, BLOCKED, DEVELOPMENT, REVIEW or DONE.
In this way team members can take tasks without worrying whether someone else is already working on them. Furthermore, there is always an updated status to whom it may concern

·       The team makes decisions together

·       Team members perform code reviews.
A code review is just like another task. When a developer needs a new task, he can review another task if it's prioritized. The priority of the review is derived from the priority of task.
We need to aspire that everyone will be able to perform code review, and it's our task to train junior developers to be proficient at it. This in turn reduces bottlenecks and increases the team's knowledge of the system. By emphasizing reviewing the tests, even a developer who isn't familiar with the implementation of a certain part of the system can still review changes to it.

·       The team is versatile- It's not a must, but it does significantly contribute to the ability of the team to work as a team, in contrast to a group of individuals

Surely, it's not easy to implement all of those things, but certainly worthwhile and facilitates the team's progress towards self-management.

How is it on your team?