Every (yes—EVERY!) organization that I’ve ever worked for or with has had cancer. Indeed, several of the projects I’m aware of have also had cancer. This has largely been true regardless of the methodology used. The specific stage of cancer has varied, as has each prognosis; however, all organizations I’ve encountered have been diseased with one type of particularly aggressive form of cancer. The specific type of organizational cancer I’m talking about is having an excessive amount of work in progress (WIP) at any given point in time.
For organizations in general and agile organizations, in particular, the result can be virtually terminal. In agile organizations, the unit of capacity is the team, not individual roles such as developer, tester, tech writer, architect, project manager, etc. However, the team is usually a cross-functional mix of these (and other) roles. When I hear executives speak of resource allocation and optimization, it’s usually in reference to individual roles. Rarely do I hear anyone speak of optimizing work within an organization with respect to team allocation to work. Let’s examine why that is.
Using the example of a test manager, the thinking goes like this: I am a Test Manager and I have a team of testers. I have hired each of those testers to perform testing. If they are not spending all of their time on one particular project performing testing, then they are not being fully utilized. Therefore, I will allocate those testers to other projects so their remaining testing capacity can be utilized. My reply, “FLAWED THINKING—STOP DOING THAT!” The problem is that by optimizing the allocation of individuals to projects (50% on project A, 25% on project B, 25% on project C) you unknowingly and/or unintentionally sub-optimize workflow within the entire organizational system which may have dire consequences.
The first potential issue is that you may have introduced unnecessary and artificial dependencies between projects that may have, in no way, been dependent on each other previously. If one project experiences a slip it usually results in a slip to the other projects. Secondly, this is usually done without any consideration for the cost of delay that is associated with the slip. Let’s consider the economics. This single point alone can justify abandoning this practice from a business case standpoint.
Let’s assume the fully-burdened annual cost to keep a tester on staff is $120k. This cost includes salary, vacation, benefits such as medical and life insurance, building costs and maintenance, and perhaps even other incidental or miscellaneous costs—sometimes referred to as General and Administrative (G&A) costs. At 50% utilization this would represent a $60k overhead for which we would not be realizing any return on that investment. But, this thinking excludes a number of factors. First, the assumption that 50% utilization means there’s absolutely nothing the tester can be doing during that time. This is rarely, if ever, the case. In an agile project, there is always something to do. Since this is a tester one of the initial thoughts that come to my mind is fully automating tests and continuously adding to automated test suites, harnesses, and regression tests. Additionally, in agile, there are really no distinctly individual members. The team owns the work from beginning to end. Therefore, this person can be helping on other tasks and expanding their skill set. Professional development may also be an option. Additionally, innovation happens during slack time, not during “fully utilized” time.
Let’s assume that, just maybe, crunch time is occurring on project B but project A is now in need of this tester’s skills. When tension is high and urgency is higher, decisions typically aren’t made based on rational, business-based criteria. The problem is that project A may be delayed due to the need for the tester to complete work on project B. This may be due to any number of reasons but my experience tells me it’s usually due to a noisy sponsor or executive. But, what if the cost of delaying project A is $250k of lost revenue per month? The economics of this situation is pretty clear to me. Paying $60k annually (50% of lost tester utilization) to avoid $250k of lost revenue per month is an easy choice. I will pay it every time. Unfortunately, companies rarely consider cost of delay. Worse yet, what if the delay of project A results in a competitor beating us to the marketplace? That’s a cost that can be irreversible to recover and, in extreme cases, may even spell the end for the company. Ask yourself what the cost would have been to Apple had another company beaten it to market with a device comparable to the iPhone.
Let’s explore another reason not to do this—throughput. Any first year computer science or engineering student is familiar with the term “thrash” (my apologies to non-software engineers reading this post). It’s the state that a computer’s processer gets into when its instruction queue gets to approximately 70% of its capacity. This is a point of diminishing returns. The processor is working so hard to get through all of its processes that it can’t swap work in and out fast enough and it pays a penalty. This same phenomenon is present and occurs in organizational systems. With too much work active, a penalty is paid. This penalty is lost worker productivity (low morale, high turnover, disengagement), reduced throughput (the amount of work that can get through the system) and increased cycle time (the time it takes new work to get through the system). In other words, your organization (or project) cannot deliver as quickly.
So, what are we to do? First, don’t think that you are powerless. If you don’t speak up about the issue, who will? If not now, then when will you? Do you own shares in the organization through an employee stock purchase plan? As a shareholder why wouldn’t this concern you? Become intelligently disobedient and speak up. Help leadership identify the need to eradicate this cancer before it becomes toxic and terminal to the employees and the organization as a whole.
In short, STOP IT! JUST STOP IT!