Project Practitioners > Does Your Agile Organization Have Cancer?

Does Your Agile Organization Have Cancer?

By Brian Irwin

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. 


Not all comments are posted. Posted comments are subject to editing for clarity and length.


LOL! That might be the best prescription for this problem that I've ever heard! (Or would that be a proscription? har.)

I totally agree! In many cases I think that the root cause of this thought process is also based on competing priorities within the divisions of the company, and a lack of cohesion with communication up to the senior team! Is there some way that we can package this article out and send it to every CIO in the Country? I also, would LOVE to just STOP IT!

Thank you for the comments DeAnna and Margaret. I think one of the biggest issues that is inhibiting anyone correcting excessive WIP is an inability to say NO. In my experience, commitments are made on the behalf of others without first considering whether the organization has the ability to take on the extra work. Many times, people do not say NO because they fear it will be "career limiting". In my case, I've probably already limited my career by being outspoken.

Love the cancer reference. You are right on many fronts. We have an obligation to be realistic and focused on quality. Having a tremendous portfolio of WIP doesn’t make you more successful than an organization or team that completes the same amount of work (or probably more!) in a more controlled and logical fashion. With high WIP, you also run into the case where team members battle the acceptance of new work and agile principles.

Thanks Ann - I'm glad others get it.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.