One of my favorite things about being and Agile coach is connecting with the Agile community through conferences, meet-ups, and other networks. Because of these connections I get to interact with Agilists all over the world. Over the past few months I’ve noticed a concerning trend coming from the Scrum Master community. They are telling me with excitement, “I’ve finally worked myself up to two teams!” Some have said they are now working with three or four teams. The thing that concerns me is that they seem to view spreading themselves across multiple teams as an accomplishment. I am hearing pride in “being busy” and “being able to handle more” and that tells me that we still have work to do. It tells me that there may still be an anti-pattern running rampant in our Agile organizations telling us lies.
The belief that “the more I can handle and the busier I am the more valuable I am to the company” is left over from days when sustainable pace wasn’t a part of the culture. The truth is that busy does not equal productive. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. It is not to ensure that everyone is at least 100% (or more) utilized. Agile processes are supposed to promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. When we are running at 100% (or more) of our capacity we cannot maintain that pace indefinitely. At some point, we burn out mentally, physically, and emotionally. We cannot afford choose utilization over productivity. Our primary measure of progress should be working software, not how much more we can get done with fewer people. The efficiencies in an Agile organization don’t come from piling more work on fewer people. They come from improving our technical practices, increasing automation, increasing quality, lowering technical debt, collaborating, and learning to continuously improve our processes. These things give us the ability to produce more without adding employees because we stop tripping over ourselves and can run along a clear path.
I read the following question from a user on stackoverflow.com:
“Does running your servers at 100% CPU usage cause any issues or is it just good CPU utilization? My servers have 8 physical cores constantly running at near 100% for “open hours”/10 hours per day. The program is architected to run on 8 threads – and it fully uses them. Performance is good but the infrastructure guys are worrying about the “maxed out servers.” I think it’s just good use of available resources. What’s the point of having lots of core if they are not all fully utilized?”
The problem with this line of thinking is that when resources are fully utilized they don’t get more done. Contrarily, less gets done. They move slower, wait time increases, and so do errors. Here’s the response someone gave to this question:
“Almost without exception it causes issues, or will cause issues down the road (as demand grows). 100% CPU utilization on a web service server is not good. If your CPU utilization is at 100% it means that each time the server gets a new request there is a 100% chance that the work will have to wait some amount of time before the server gets started on it. The typical performance sweet spot is about 70%. Does that sound low? If so, remember that 70% utilization doesn’t mean that 30% of the CPU is being wasted. Instead, it means that 70% of the CPU’s capacity was used over a sample period. For CPU measurement metrics, a sample period is something like 2 seconds. During that 2 seconds the breakdown of that 70% is uneven. In other words, it may be something like 100% for 1 second and 40% in one second. For short bursts like that, 100% utilization is okay because we know that if a piece of work is delayed it is only for a brief period. (One that won’t make the human waiting upset.)”
I’m wondering, if we adhere to this rule with our hardware resources, why don’t we realize that the same rule applies to our human resources?
I’ve been in the position where I was a scrum master on one team doing an excellent job. I knew the pulse of my team and they were growing rapidly and performing better than ever. Then, I was given a second team. Sure, I had enough down time in my average week to handle facilitating Scrum events for two teams (in theory) but because I was toggling between two team rooms I missed a lot on both. On sprint end/start days I felt very pressured. I ran from one retro to the next on and often couldn’t compile the improvement plan into a consumable format until two days later. I fell behind updating information radiators and had less time to think analytically through what was happening with each team. Over time I saw that both teams were maintaining, even growing some, but the rate of growth was slower than when I had only one team.
Then, something tragic happened. I was “doing such a great job” that I was asked to take on two more teams for a month to fill a hiring gap. I felt like a total failure. I had to choose which teams I was going to work with and leave the others stranded. I had no clue what was going on in any of the four teams because I wasn’t spending enough time with any of them to catch the important conversations. My teams all felt abandoned by me and had to pick up the slack felt by my absence. While in my manager’s eyes nothing fell to the ground because my teams were mature enough to fill in the gaps without me, my teams felt all the pain and none of the benefit.
I learned a very powerful lesson through that experience. Being utilized at 100% (or more) capacity didn’t make me a super Scrum Master. It made me a terrible Scrum Master. On a ledger somewhere it may have looked like the company saved money by utilizing me to full capacity but the impact of the hidden cost was much greater than the financial gain. We would have done better to allow the third and fourth teams to work without a scrum master for that month. Instead, we caused four teams to operate without a scrum master by spreading me too thin.
What message do we send as an organization when we tell our teams we expect them to plan their sprints at 125% of their capacity? It’s a message that says we do not value sustainable pace. What message do we send when we tell our employees we want them on multiple teams so we can fully utilize their capacity? It’s a message that says we do not value sustainable pace. What message do I hear when Scrum Masters tell me proudly that they are working on multiple teams? I hear that they have forsaken the Agile principle of sustainable pace. I hear an anti-pattern. It makes me know that though we have come far we still have more work to do before becoming truly Agile.
Tandem Coaching Academy 