The Prime Waste – Busyness

There is a common feeling that indicates the presence of all 8 wastes. It was best described by my former leader when he summarized what team members were telling him:

I’m too busy doing my job, to do my job.

By taking a step back, it becomes obvious how constant busyness undermines the business by inviting all 8 wastes and creating a vicious cycle.

Overproduction, Inventory & Defects

Fans of Toyota will recognize that I’m starting with Taiichi Ohno’s most egregious waste; overproduction. This is intentional. Overproduction can be seen as enabling the other wastes, however, overproduction is more accurately seen as the problem’s symptom, not it’s source. The root issue tends to be a bias toward busyness.

If I only feel valuable when doing my job, that is what I will do. Often there are metrics, rewards, and even my continued employment that all hinge upon spending time doing that thing for which I was hired (write code, test software, write specifications, etc.).

If my goal is to keep myself busy, that is very attainable. I will create as fast as I can and pile output upon whichever unfortunate fool happens to be next in the chain. I don’t care if those team members can keep up; it only makes me look better if they cannot. It’s their job to figure out how to keep up.

Even worse, my success may be measured by the build up of a work backlog for the next team (someone needs to make sure they’re busy). The bigger that backlog, the greater the testament to just how awesome I am; that whole QA team can’t keep up with my coding speed – so congratulate, reward, and promote me.

Once I’ve buried the next team under a mountain of work, I don’t stop and look for opportunities for my own process improvement (test automation, new techniques, refactoring, etc.). I’ll get more accolades by starting the next project or iteration early and further burying my extended team under an even bigger backlog.

The worst part about this cycle is that by constantly running ahead of my team, I’m delaying feedback loops.

If QA finds a bug in my code, I’ve already forgotten about that module and I’m a full sprint into something else. Now we need to have a debate about which is more important, the quality of some feature from weeks ago that is “done” or avoiding “thrash” by staying busy on our new #1 priority.

Which is more important; quality or busyness?  Too often, busyness.

On the bright side, once all of those defects pile up, we can introduce a maintenance team that can be kept busy fixing all of the work we were too busy to do right the first time.

8. Sustainable development, able to maintain a constant pace


Adding unnecessary (or unrequested or lower value or gold plated) features is a sure-fire way to get some kudos upon delivery, especially if still delivered on time and on budget.  Even better, it shows how well we utilized our time by staying busy doing stuff.

Then, there’s the scope we convince the client to add.

What if traffic to your website suddenly increases 100 fold? You’ll certainly need dynamic load balancing in the cloud if that happens, so let’s make sure we implement that best practice now. 

We could defer that work until the need presents itself or challenge ourselves to see if we can handle the load with a more conservative approach, but that won’t keep us busy.

Was there a different project of greater value that could have been started? Possibly.

Did we take the time to invest into our own processes by automating integration testing? Possibly, but probably not.

Do we know for a fact the the client actually wants and will use these features, or are they simply things we thought they may want at some point in the future? According to the Standish Group’s 2013 Chaos Report, about 50% of software system features are essentially never used. If we spent more time questioning what we should be doing (or finding more conservative ways of doing it) we may not look so busy, but would that be a bad thing?

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Motion, Transport & Waiting

Motion & transport are busyness that create the illusion of productivity.

What if I were an analyst or PO? If I need to talk to a lot of people then the value I’m generating could be measured by how full my calendar is, right? That’s a testament to how busy, thus important, I am.

Unfortunately, this becomes a vicious cycle. When information is needed by an engineer, it cannot be extracted from my brain (transport) because the I’m too busy in all those meetings. The more team members need my answers, the busier I become. This can escalate until team members are waiting days for answers. Should they just send an e-mail and hope for a clear enough response? Should they just work on lower priority work until they can get an answer? Should they just guess at what the answer might be and hope for the best?

It’d be a shame if the engineers stopped working in order to draw attention to the problem; they can’t get the information they need to add client value.

More to the point, which is more important for me as the analyst or product owner with all that knowledge; the meeting I’m busy with or making sure that those directly adding client value have what they need to be successful right now?

4. Close, daily cooperation between business people and developers

Unused Creativity

This may not be the prime waste, but it is the most costly to the team members, to the business, and to society.

If I keep myself too busy, I don’t give myself the time to reflect and improve.

These improvements could be in my craft. These improvements may be investments in the development of junior teammates. These improvements could be in the processes of my team. These improvements could be in the processes of my extended team. These improvements could be shared with the whole organization (or to the world). These improvements could yield more software of greater quality to our clients.

Too often, these improvements come slowly or not at all.

We’re too busy doing our jobs to do our jobs the way we know they ought to be done.

9. Continuous attention to technical excellence and good design

How Agile Tackles Busyness

By using a short term, iterative, PDCA cycle, we get many benefits.

Cross-functional teams can make sure they are planning only as much as they can complete together. Rather than focusing on keeping everyone busy, we shift the conversation to what needs to be done to deliver client value.

As interruptions come up (they will) we can now judge their value versus the plan and make an informed decision. If our goal was just busyness, we’d just toss that interruption onto the list of things to do and just keep trying to keep up.

We can also check our performance against the plan and reflect. This gives us a chance to see how we can improve. It can be in our skills, our process, or anything else. But to that point, we take the time to implement these changes which will help us deliver more value in the long term.

3. Working software is delivered frequently (weeks rather than months)

How Do I Do That?

This is not easy.

What is often missing, is patience and discipline.

The ultimate goal is not to “be agile” today and coast forever. It’s to create the opportunity to recognize and implement the next step in our journey of continuous self improvement. Creating these opportunities means that we must create a plan, we must execute it (learning by doing), check against what we expected, reflect on what we learned, and figure out the next step in our journey.

There is less “doing” in that process than most people are comfortable with. It feels as though we’re not doing what we’re supposed to be doing (writing code, testing, etc,). It takes a lot of will power and long term vision to recognize that the best thing for team, the organization, and the client is to move a little slower so that we can ultimately move much faster.

What If I Don’t Know How To Do That?

What if you apply agile and lean concepts incorrectly?

Don’t worry.

If you’re regularly reflecting and learning, you’ll find those problems and fix them. Even if you apply the concepts perfectly, you’ll still find problems and fix them. Reality is messy, it will offer you chances to improve. The most important thing is that you give yourself and your team the time to reflect, to learn, and to try new ways to improve. Give yourself time to ask hard questions and make sure you’re solving the right problem and not just finding the fastest way to stay busy.

However, it’s ultimately up to you to find a way to be a little less busy doing your job, so that you can actually do your job.


Here is some litmus tests for busyness in your professional life.

If you’re in a direct value-adding role, are you taking time to improve the process of software delivery systemically for the long run, or are you trying to maximize your productive time to keep up with the schedule?

If you’re in an indirect role, are your efforts focused primarily at supporting those directly adding client value or are you not as close to them as you’d like because other projects are keeping you too busy?

Leave a Reply