A Business Technology Place

Technology Constipation

We all want to be regular.

Something we all have in common at work is the desire to have a regular and predictable cadence of work output. Doing so just makes life easier. It’s rewarding to our customers when they receive their goods and services within expected boundaries. It’s good for the well-being of our team dynamics and mental happiness because everyone achieves the goal together and feels the satisfaction of customer acceptance.

Work methodologies agree on this concept as well. Systems such as Agile software development and Lean aim to create flow and eliminate unevenness in a system.  Unevenness brings excess inventory within the system that is apparent when materials, supplies, and outputs start to collect in areas while waiting for the next step in the flow to process them.

Technology Constipation.

I had never really thought about excess inventory like constipation before this week. But while looking at the portfolio of technology work and the length of time some projects had been in the system, I started to see the pains and strains of organizational team members to keep up with the work. When technology projects don’t keep a regular cadence the tendency is to continue to start new work to meet stakeholder expectations for delivery. That’s a recipe for technology constipation.



Finding relief.

Pushing more work is analogous to painful straining. It gives the allusion that the team is working harder, but in the long run it will only make things worse.  Work system methodologies like Agile and Lean have a manual describing the steps for better workflow and reducing inventory. These steps require management support, team culture fit, a common approach, and persistence over time. But you we can’t let the symptoms of the problem overwhelm us and paralyze the team into inaction.

Here are some good initial steps for technology teams to find relief:

  • Communicate with internal customers about the build-up of inventory and future demand. It’s more than being transparent with your customers it’s also about involving them in the decision making of priorities.
  • Focus on current work in progress to finish what you’ve started while not taking on other work. This is like telling a person with large credit card debts to stop putting more purchases on the card until they are paid-off. Otherwise the cycle continues. Stakeholder support is required for this!
  • Start to analyze existing work streams with an eye for implementing agile and/or lean tactics. Iterate, review, reflect, and repeat.

One thing is certain; it’s good to be regular and painful to experience back-up of solution delivery. That’s reason enough to start or continue working towards better flow of work.

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