But How Do I Know They’re not Sandbagging….
Trusting your team presents opportunities for real improvement
Introduction
Whether you are doing Scrum, SAFe, LeSS, Scrum @ Scale or any of the other wonderful agile methodologies, there is one cross cutting mantra – those who do the work size the work. The team, the Agile Release Train, the Tribe, whoever is going to do the work sizes the work. While the product owner or product manager prioritizes work, it is the team who says how much work there is and how much they can honestly commit to. Often when I explain this balance between the team and product owner, many managers ask, “but how do I know they’re not sandbagging?”
According to the urban dictionary, sandbagging means “….to deliberately perform at a lower level than you are capable of.” Thoughts of Star Trek’s Scotty come to mind, as he always overestimated his effort by a factor of 4 so Kirk would think him a miracle worker. This kind of thinking is, at best, problematic for an organization’s agile journey. At worst, it can derail it entirely.
Trust – An Essential Component of Agile Thinking
First, it demonstrates a lack of trust between management and staff, that unless a trusted “expert” estimates the work, creates deadlines, then somehow coerces the teams to commit to that schedule, the teams will game the system to reduce their workload. That somehow, the engineers the management has hired are looking to do the least work possible with the minimum amount of effort they can get away with.
This thinking is toxic and will immediately derail the agile journey. Agile thinking is based on trust and without trust, the collaboration and powerful reflective thinking Agile requires will not happen. Without trust there is no “individuals and interactions” and with no individuals and interactions, there is no Agile. The team may blindly walk through the agile ceremonies, even score themselves high on an agile maturity survey, but it will be agile in name only with little of its benefits.
Busy – Not Necessarily Productive
Second, it demonstrates old industrial age thinking on the part of a management that equates busy with productive. The industrial age is characterized by time and motion studies, standardization of work and mass manufacturing. In this era, the faster a person worked, the more they produced. Management focused on keeping production high by keeping staff busy. This may work for mass manufacturing where time and motion studies have distilled work down to simple repetitive work, but it does not work with cognitive work like software development [David Pink Drive: The Surprising Truth About What Motivates Us [Hardcover] Pink, Daniel H, Riverhead Books, New York 2009]. In fact, as Donald Reinertsen called out in his book Product Development Flow, “…operating a product development process near full utilization is an economic disaster.” A qualitative presentation of queuing theory analysis can suggest why this is the case.
Figure 1: Simple Queue, and single server node CC BY-SA 3.0 WikipediaQueuing theory is the study of the behavior of queues. What happens when you have a bunch of things to do held in a waiting area for something that does them? There are a wide variety of different queuing models, but for our analysis we will just present a simple queue with a server – like a line up at a cashier. In our case, we can imagine the waiting area filled with work for the team.
Figure 2: Server behavior as load increases (team gets busy)The two above graphs show what happens to throughput (getting things done) and delay (how long it takes to get things done) as we start increasing the load on the server. As many managers would expect, as we increase server utilization – busy-ness – output increases. But only to a point. At around the 60 or 70% utilization we see that we are in the saturation zone where increasing the load does not increase throughput. At some point, the system has too much work and throughput collapses, a phenomenon known as “congestive collapse” where everyone is running around “hair on fire busy” and nothing is getting done. Classic thrashing. I’ve seen this movie many times and it never ends well.
The lower graph shows how long it takes to get things done, or the cycle time as the load increases. While we get more done as the server gets busier, we also see that it starts taking longer to get things done. As we enter saturation, the cycle time increases dramatically and when we go into congestive collapse it stretches into near infinity, as everyone is running around hecticly with nothing getting done. Together, these graphs show why trying to keep a team busy, loading them to 100% is an economic disaster. Rising cycle times means we cannot effectively predict when work will get done. An item that we estimated could take two days assuming the team was “under-utilized” could take weeks when the team is saturated. Just think of the difference in commuting when a highway is “clear” and when it is “busy.”
Some more progressive managers will say, “well we don’t do that, we only load our teams to 70 or 80%.” Here is the problem with that argument: how do you know the team is only loaded to 70 or 80%? Generally, these managers have taken the team’s capacity in hours and then only scheduled 70 to 80% of those hours. But this again is simply managing busy-ness as a proxy for getting things done. If there is no adaptive feedback, and no analysis of cycle times and output, how do you know what the real loading of your team is? The team could easily be 70% scheduled yet deep into saturation, even approaching collapse.
Turn the Ship Around
So, if loading up our teams to keep them “busy” is not a good tool for managing staff and work, then what is? First let’s dispense with the idea that somehow our team – the team you hired – if given the opportunity will sandbag their estimates. If you believe this then you have a real serious problem on your hands. Absence of trust is the fundamental dysfunction of a team [The Five Dysfunctions of a Team: A Leadership Fable, Patrick Lencioni, 2002, Jossey-Bass, San Francisco] and you need to work on the root cause for this lack of trust.
The good news is this is a fixable problem. There are numerous great stories of how low performing teams quickly became high performing with a change to how the teams were managed. Two great case studies for turning a team around are David Marquet’s “Turn the Ship Around” of how the worst performing submarine in the US Navy become the best, and NUMMI – the New United Motor Manufacturing Inc , where the worst auto manufacturing plant in GM’s portfolio became the best following a joint venture between Toyota and GM.
Alternative to ‘Busy’ – Predictable Delivery
The second part of managing our teams and work is rather than using “busy”, which we already established, is a poor proxy for getting things done, why don’t we just drop the proxy and ask the real questions we’re interested in:
- are we getting things done – “ throughput”
- how long is it taking for us to get things done – “ cycle time”
We no longer care if people are “busy” and stop managing busy-ness. Rather we care if we’re getting things done, and how long it takes to get them done. Our focus becomes on the predictable delivery – consistent cycle times – of value. We measure real outcomes, perhaps outcomes like, how many of our iteration goals did we reach? How long does it take us to get a story done, a feature into a product, a defect fixed? Teams manage their “work in progress” limits and experiment varying them to optimize their cycle time and throughput. These are far more powerful tools for managing work than keeping everyone on the team busy.
Conclusion
So, if you find yourself or someone you know asking the question “well how do I know they won’t sandbag their estimates” when it is suggested the team estimate and manage their work, then think about what you are really asking – how can I trust this team?
The good news as we have highlighted in this post, is this also can open many opportunities for real improvement.
