A Business Technology Place

Level the workload for development team leads

Incoming work.

If you work in IT you know that some days it feels like work requests appear from every direction possible and then some. The IT group is a service organization at its core and there is a strong drive to satisfy all customer requests in a timely manner.

For the development group within IT, incoming work results in new projects to create code, fix defects, or mitigate security vulnerabilities. It’s very easy to over allocate the development team leads because the natural tendency and customer desire is to solve all the requests quickly. Inevitably, unchecked incoming work will overburden a development team lead. That creates a large bottleneck in the flow of work and then the rate of production code pushes becomes erratic as the amount of work-in-progress increases!

Load level.8560840624_c67c5c1fef_z

Many modern workflow systems, including Lean, Six Sigma, and Theory of Constraints show the benefit of leveling the load within a production system. Effectively, the idea is to eliminate overburden on people and machines to make production more even and eliminate wastes. In my IT shop we have evolved to a regular prioritization meeting to review current projects in progress, prioritize work not started, and look at the allocation of team leads responsible for executing the work. The intent of the meeting is to level the load of current work that the team is processing.

But the team lead assignment review is a newer component of our process. We realized that even though we were meeting to assign priorities to projects that we had not considered the capacity of the team lead when assigning work. Initially, we looked at the capacity of the entire team and quickly overburdened our team leads. This clog of work stressed our team leads and disrupted the flow of work output for the team.

Now we look at our active work and continuously ask the question, “Have we over allocated our team lead in this area?” When the lead has capacity for new work then it’s pulled from the backlog of prioritized project requests.

This is a simplified look at a much larger concept, but an easy practical step to implement. Maybe it will spring an idea for you to use if you face the issue of over allocation.

Onward and Upward!


Reducing work-in-progress for software development

One of the important concepts of the Theory of Constraints is to reduce the amount of inventory in a system to help with the overall goal of increasing the rate of throughput of the system. Inventory is defined as the money that the system has invested in purchasing things that it intends to sell. In software development, inventory is things like software licenses, equipment, or even process artifacts that comprise the components of a release.

The typical start of software development processes is to estimate requests for business stakeholders. The requestor wants an estimate of cost and time while the software manager needs the estimate for planning people allocation, time, etc. Once labor is expended on the estimation effort and some type of answer is generated then the system has a level of inventory in it (the estimate becomes an artifact and money is spent to generate it).

If the request is rejected at this point it becomes process waste because money was spent that will have no investment return (although better to spend a little money early than to realize you need to cancel later). If the request is moved into a queue that awaits the next step in the process then it becomes inventory. The problem arises when the requests hit the process bottleneck and start to queue. The work-in-progress  becomes a growing inventory which extends the time before the company can start to realize a return on their investment.

A growing inventory of estimated work in queue

A growing inventory of estimated work in queue

Thinking back to the Theory of Constraints, we want to reduce the amount of inventory in the system. One way to do this is to control the rate at which requests are released for the initial estimating step. Instead of estimating every request that enters the system and then placing the estimated effort on the backlog, we can place new requests into the product backlog. The product manager is responsible for prioritizing the backlog based on the business value, not cost. Then when the team is ready to start working on a request the product owner and the team work to estimate the scope of work of the top items on the backlog. Think of it as pulling the top x items off a shelf. The idea is to pull as many items of the top of the list that the team can fit into one cycle of the software machine (an agile sprint).

This technique closely mirrors the agile methodology of Scrum. I like it, because it also helps to reduce the inventory in the software machine and works towards delivering software for an earlier return on investment to the business. The product backlog acts as a buffering mechanism to control the release of work into the system.

Work queues outside the software machine (buffer) to reduce inventory

Work queues outside the software machine (buffer) to reduce inventory

Do more with less by working smarter

I haven’t kept count of the most commonly used phrases I’ve heard in my professional career. But “limited resources” has to be at the top and this phrase talks about people more than objects. It’s a given that there is always more work that businesses want to do than they feel like they can accomplish with the current number of people. If that were not the case then the business would let go of people to match capacity with demand.Resource Constraints

In my experience, most business leaders typically approach resource constraints by trying to hire more people or by ignoring the situation and letting the day-to-day tasks run as-is. Hiring more people is a difficult battle in most businesses and ignoring the situation certainly doesn’t provide answers.

I try to approach resource constraints by examining the underlying processes of how people work. Maybe I’m wired differently and don’t mind examining processes to find opportunties for improvement. Maybe I don’t mind fighting the battle of getting people to change existing processes. But if an organization is to work smarter, then it must examine underlying processes and not be afraid to make adjustments.

In the book Blue Ocean Strategy, Kim and Mauborgne describe this technique:

“instead of getting more resources, tipping point leaders concentrate on multiplying the value of the resources they have.”

The Theory of Constraints looks at the underlying process as well. This management paradigm teaches us to first find the constraint within a process and then to exploit the constraint by shifting resources, managing work queues, and possibly adding capacity.

At the end of the day, changing existing processes within an organization can be as difficult as justifying new hiring. But I would argue that it’s a more worthwhile endeavor. Throwing more people at some problems might provide a brute force solution. But the underlying process will eventually bog down the productive output and you’ll soon here again the infamous phrase “resource constraint”.

Find a way to multiply the value of what you have by first examining the underlying process for inefficiencies and also by making sure that underlying processes contribute to the overall goal of the organization. Easier said than done, but if it were easy then everyone would do it.