The Hidden Reasons Your Teams Are Underperforming (It’s Not What You Think)
Julia was running out of patience with her team of developers. It was not a quality issue nor was it a question of not meeting deadlines. In her eyes, they were underperforming, listless and lacked self-organization. She had hoped Scrum training would improve their performance and it did…for a few weeks. But now they have reverted to their pre-training behaviors. As an experienced engineering manager, she knew something needed to change, but was unsure what action to take.
Does this scenario sound familiar? In my previous article, I identified the five factors that are necessary to support self-organization. But what does a leader do when, in spite of making sure these five factors are present in your environment, your developers still refuse to self-organize?
How Are the Developers Organized?
In general, managers only have two choices when trying to organize a group of product developers. Product developers can either be part of a working group or a real team.¹ These choices have a profound impact on the group’s ability to self-organize, so let’s briefly define them below.
A working group is a collection of people organized around a strong leader who is responsible to deliver on the group’s purpose by integrating each person’s individual work products. A real team is also a collection of people but they share leadership, collective work products and mutual accountability in order to achieve the group’s purpose. IME, the choice between a working group vs. a real team boils down to the nature of the work.
Business-as-Usual vs. New and Unusual Problems
When the group’s work is generally well-understood, standardized and familiar, I consider that work to be business-as-usual (BAU). Stuff you need to do to keep the lights on. For a development team, BAU work is the operational work: maintaining the network, managing licenses, writing standard operating procedures, responding to incidents, upgrading (or hardening) the network, implementing small changes or updates, etc. If there is a need for people to work together, they are coordinating their work to reduce duplication of effort and to identify who can most efficiently complete the work. And because the work is BAU, there is little (or no) need for discovery. In the Scrum world, BAU work is considered simple or complicated.
However, not all work is BAU. When the group’s work is unfamiliar to them or they discover that BAU solutions are no longer sufficient, they have what I call a new and unusual problem. A new and unusual problem is any scenario where the group does not know the solution upfront. In fact, by definition, a new and unusual problem does not have a single solution, but multiple plausible solutions. As a result, the people doing the work must collaborate to discover the best solution that meets the needs of all stakeholders and is sustainable. For development teams that build (or extend) digital products and services, most of their work will be new and unusual. In the Scrum world, any work that is new or unusual is considered complex.
Self-Organization is Optional for BAU Activities
Now that we have a way to distinguish between BAU work and new and unusual problems, we can start to see why some development teams lack self-organization: the work is not complex. When the work is not complex, friendly coordination among professionals will provide teams with good enough for now results. Self-organization is nice to have, but not essential.
However, when the problems are new and unusual, then coordination among peers will not produce the desired outcomes. Complex problems require the entire group to leverage everyone’s knowledge and experience to identify multiple plausible solutions. Then, the group must work together to discover, implement and support the best solution. IME, when working with complex problems self-organization is absolutely essential for success. Without it, teams fail.
Leadership Implications
As a leader, the first step you need to take is to determine if the majority of the group’s work is BAU or new and unusual. IME, if nearly all the activities the group is expected to complete are predominantly operational and support, then their work is BAU. If nearly all the activities the group is expected to complete are related to creating, testing and deploying new functionality, then their work is new and unusual.
If you have a BAU team, then the most effective way to organize the developers is into a working group. Stop trying to enforce self-organization and collaboration among the team members since it is not required for success. Just be happy with whatever levels of self-organization and collaboration are present within the team. If you want to create a real team around BAU work, then go for it! Of course, in a working group the leader becomes the bottleneck for delivery.
If you have a team whose work is new and unusual, i.e. complex, then the most effective way to organize them is into a real team. In this case, you absolutely have to have self-organization and collaboration. If there is no self-organization, you will not achieve your goals. To accelerate the emergence of self-organization, there are two actions to take as a leader. One, identify the team’s current stage in the Tuckman model. Two, reinforce the five factors which enable self-organization: constraints, autonomy, visibility, metrics and emergent leadership.
In the final article of this series, I will explore what to do when your organization is the problem!
1 – There is a third state many product developers fall into, a pseudo team. But membership in a pseudo team is often due to neglect and should never be the destination. Why? Because the performance of a pseudo team is significantly less than a working group or real team.
