The funnel and the marbles. A tale of team productivity
Earlier this week I witnessed a fierce discussion about team productivity. More precisely a discussion between a group of managers about the productivity of one of the teams in the company. Time to revisit team productivity.
In the eyes of the abovementioned managers the productivity of the team isn’t as desired. It is too low. Of course. Too little features are delivered by the team per period of time. “We should add more work to the backlog of the team,” one of the more traditional managers claims. “Having more work will increase the teams productivity,” he motivates. “It is just the other way round,” states another, agile oriented, manager. “When we add even more work to the backlog of the team, they will slow down even further.” The first manager looks surprised. “When the team works on too many things at the same time, there is no focus,” the second manager continued, “So they will work on many things and finish none.”
Different teams are just different
Team productivity is a delicate subject. In the early days of agile, about twenty years ago, there were long debates about the topic, where people tried to compare the productivity of different teams using relative scales such as story points or function points. Fortunately I haven’t seen many of these debates in quite a while. It seems that we have learned that estimation at low level, such as in story points, does not add much value. Different teams are just different. With different people, different levels of experience, different requirements, different technology. That helps.
However, there are still a lot of organizations where managers are wondering whether their teams are going fast enough. Such as the managers in this tale. Since there are hardly any absolute scales that score the speed or velocity of software developing teams, managers quite often consider teams to produce too slow based on gut feeling. Often, managers only see the tip of the iceberg. The fact that a team only produces a few features per release might seem sluggish, but the underlying functional or technical complexity of these features is often overlooked. The first question managers debating team productivity should ask themselves is: do we really know if this team is slow, or do we just think the team is slow? Interestingly enough, we could ask the same question about teams who seem to go fast: do we really know if this team is fast, or could they be even faster?
In my opinion, discussions on team productivity arise at management level usually because they want their teams to just go faster and produce more features in less time, without knowing whether these teams are already delivering at top speed or whether the teams are making a mess. In case such as these, decisions on how to “help” the teams in question to be more productive tend to be made ad-hoc, based on gut feeling and raw assumptions. But these decisions are really delicate. Taking the wrong measures can easily destroy team motivation.
But how do you go beyond gut feeling on this delicate topic? Whenever I coach organizations and teams where such questions are frequently asked, I tend to use the metaphor of the funnel and the marbles. Let’s consider an ordinary kitchen funnel for pouring liquids in bottles and a bag full of ordinary marbles. Let’s assume that the mouth of the funnel is wide enough to allow the marbles to go through. Time for a small experiment.
Let’s drop a single marble in the funnel. As the mouth of the stem fits the marble, it will fall right out. You will have already understood that the marble represents a feature, and the funnel represents the team. Let’s now drop a few marbles in the funnel, with short time intervals between them. As you will have guessed, the marbles will fall out, one by one. This means that if features are dropped into the team at sustainable pace, the team will be able to handle them at the same pace. Feature in, feature out.
We could have several runs in our experiment, with shorter and shorter time intervals between dropping the marbles into the funnel. At some small interval, the marbles will bump into each other and not fall through the mouth of the funnel at the same intervals anymore. In team productivity this situation represents that where more features being dropped into the team than the team can handle. What will happen is that the features not being delivered will pile up.
Now as a last step let’s throw the full bag of marbles into the funnel. What most likely will happen now is that the funnel will get cluttered and only a few, if any, of the marbles will fall out of the mouth. This is the point where teams usually give up. Too many items are added to the backlog, and the team cannot see the forest through the trees anymore. When you do this to a team, it will burn out, and people will want to leave the team and potentially even the company.
The right strategy?
The right strategy to reach the optimal sustainable pace for a team is to throw the exact right number of marbles into the funnel. When too little features are on a team’s backlog they will slow down, as the more traditional manager in this tale stated. In fact, teams follows Parkinson’s Law: work expands to the time available. As a result, teams spend all the time they have delivering the few features they are charged with. But on the other hand, when you add too many features to the backlog the team will have trouble focusing and will come to a standstill, as the more agile manager stated. By adding even more features to such a team’s backlog, the situation becomes worse. Working on too many different features at the same time, trying to deliver anything at all, will cause loss of focus and context switching, which are both ineffective.
So, depending on the situation at hand, both managers in this tale could have been right. And also, both of them could have been wrong. The question that remains is which of the two managers was right in this particular situation. For that a glimpse at the team’s backlog and Kanban board will do the trick. A quick look at Jira shows that the team in question has 35 open stories on the board, and 144 stories remaining on the backlog. Working on 35 stories at the same time is not a good sign. The team will constantly be switching the context they work in and not have focus. In this particular case, pushing even more work on their backlog will only make the team switch context even more, focus even less, and finally deliver even less. Focus is crucial to delivering features and products. The second manager was right.