Management cost vs self-organizing team.

In this article I would like to explore my view of a very important and frequently overlooked part of Agile software development and how this can sometimes come in conflict with the current business structures.

It's the concept of self-organizing teams.

First I'll start by looking at how the Agile world looks at the concept and the importance of it to that world.

The Agile manifesto and principles have a lot to say about self-organizing teams and the way the team members should work together. I'll list a few below in the order they are appropriate for this article.

"The best architectures, requirements, and designs emerge from self-organizing teams."

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

From this you eventually end up in an ideal world with a group of around 3-9 team members with all the skills between them to deliver the work from end to end. They should be co-located. The classic office pod with the whole team sitting together within ear shot of each other.

The underlying reasons are based on the amount of connections most people can maintain and also the interaction cost of adding more people to the group. The amount of connections goes up exponentially. To understand the problem better play around with the interactive tool about the amount of connections needed between teams members shown here below.

  Amount of team members: 7 with 50 communication connections between them.

What does 42 communication connections mean? For 10 minutes a week you'll need 6 hours 50 minutes for all the connections Per team member it will take up the following of his week 2.50% of a 40 hour week. The probability of a clash every week is: 1-e^{-42^2/(2x240)} = 97.47% 97.47% change of a clash in meeting.

At this point most organizations move to have a full time role created to manage the team. But what is the financial benefit from having this role. It’s a difficult question to answer because the inherit value is the impact on the team’s performance. To find that out what is difficult. You’ll have to remove the person, measure performance, put the person back measure the performance and then do that for a few teams.

First question: Can you measure it? Second question: Can you get a clear result? Third question: Will you ever try such an experiment?

So that is not really a possibility, to find out what the benefit is. But on the flip side the cost is measurable and open to exploration. You can get payroll data and work out the cost of management.

This cost is then carried by the team members and you’ll quickly realize that the amount of people that report to every manager makes a massive impact. This manager to employee ratio can make a massive difference to your staffing costs, culture and agility.

I suggest you play around with the following visual tool and have a look at what happens to a ratio of 1 manager to 2 employees.

  Ratio of employees to a manager: 4

  Number of employees: 50 with 18 managers.

What does 18 managers for 50 employees mean? Your total employee count is: 68 Percentage the management take up: 26.47% of all employees. The percentage of employee productivity increase needed to break even: 36.00% improvement per employee.

Had fun?

Great. This should give you some insight into why Agile promotes self organized teams and are moving away from traditional organizational structures.

You'll come to release that leadership is still needed if not more so and that your leadership should be able to light a fire within your employees.

Unfortunately not all managers are leaders and as Agile techniques have a way of highlighting dysfunction quickly this is sometimes seen as a threat to them and they then turn on it.

This is part of the reason why "lack of management support" is the number one reason for agile adoption failures in organizations.