Overwhelmed With Work?

Have you ever felt you have been inundated with too much work? You have been delegated a multitude of tasks, everything has been pushed onto you and you just don’t know what you should be working on, you just keep switching between tasks and get nothing done.

The reason nothing gets done is because you keep switching between tasks, in other words multitasking.
So how does this prevent you from getting things done. Well, let’s keep this simple. Say we have 3 tasks to do. A,B and C. Each task takes 10 units to complete. A unit could be minutes, hours, days, weeks it doesn’t matter. For this example, we’ll use days.

Now let’s say we do A, B and C in sequential order. What is the lead time to complete A? Well, 10 days. What is the lead time to complete B? 10 days, C? 10 days again.
Nice and simple.

Now let’s say we do a split. We do half of each task, let’s say that the first half is development. The second half is testing. Deployment to production is negligible. So we stick with 10 days to complete a task.

So we do all our development up front.
5 days for A, 5 days for B and 5 days for C. Then we do our testing. 5 days for A, 5 days for B and 5 days for C.

Now, what is the lead time? For completion of A, it is now 20 days. We have doubled our time! For B, it is also 20 days, and the same with C. OK, the overall time is still 30 days, but let’s say there is an issue. Say, during the first 5 days of B. It takes 6 days. Now it takes 21 days to complete A. A is now over due. But not only is A over due, B and C are over due. The more the delays, the more the cascading affect.

This is a basic example, but there are other things you need to consider with multitasking, context switching. Changing between tasks means a mental dump and load for the next task. Then when you switch back, you have to remember what you had previously done, and then continue on. This context switching takes time. If the two tasks are completely different, then the switching time is less. If they are similar, then the switching time is longer. For those tasks that take minutes or hours that require a high level of concentration, and most IT work does require a high level of concentration, being “in the zone” when working is when you are at your most productive. Getting in the zone takes time and breaking that concentration drops your productivity. In most cases, quite significantly.

So in the modern workplace, why is there multitasking. Quite simply, people get assigned more than one task at a time. You know the drill. Your boss needs something done, looks to you and asks if you can do it. You say yes because you are only working on one task. It happens again and again and now you are juggling 3 or more tasks. Then you look at your colleague and you see that they are only working on one task, or worse yet, they are twiddling their thumbs.

This seems to be standard practice in many organizations,but what is the alternative? It’s simple, instead of pushing, try pulling.
You have your backlog of work. No one is assigned a particular task. If you are free, you take the next task in the line. This methodology allows you to work on one task at a time and focus. It allows even distribution of work load among people.

In Agile, this is represented by the Kanban board. Funny name Kanban, it comes from Toyota. In Japanese it literally means “signboard”. In order to limit inventory in Toyota, cards were used to indicate when someting was used. For example, say you have a tub of bolts used to attach a door to a car. There would be 2 tubs. The first where you take the bolts to attach the door, the second for when the first runs out. Attached to each tub, is a card. When you run out of bolts, you start eating from the second tub. The card on the first tub is then used as an indicator for someone to get you another tub of bolts. This tub becomes your second tub. The taking of bolts from inventory then triggers a purchase order to purchase new load of bolts. Toyota has got this down to a fine art where they get several deliveries per day of parts such as bolts to be used within that 24 hour period. Anyway, back to Agile. Since IT work is non tangible, cards are used as an avatar. The kanban board is a signboard or visual indicator of the progress of the work. People “pull” the cards from “todo” to “doing” while limiting them self to only one card in this column, then they “pull” the card to “done” which then triggers the “pulling” of the next card off the “todo” column. If something is blocked, then this “can” trigger a second card to be pulled from “todo”, but keep in mind, this should be the exception rather than the norm. During the retrospective, it should be investigated and discussed how to prevent the particular instance of a blocked card from happening again.

Now, a question. How do you limit the amount of work done if you have tasks that take 10 days as per your example? What happens when something more urgent comes in?
Well, the first mistake I did with my example was to use tasks that took 10 days. Ideally you should have tasks that take only 1/2 to 1 day. That way if something more urgent comes along, there is only a half to 1 day wait.
But what about an emergency? Such as something goes down, we can’t wait half a day to a day to get things back up and running. Well, this is an exception. In the case of an emergency, its all tools down and the emergency takes priority. Everyone who needs to be involved gets involved. Fix the issue, then once everything is back to normal then you resume the process.


When there is resistance to being Agile or doing best Agile Practices, “Pragmatism” is usually used as an excuse to skip important practices or disciplines, or due to lack of knowledge.

For example, “We are going to skip the Retrospectives because we are under the pump and we need to be pragmatic”

In this example, the work is seen to be important, and the retrospective is not. So it is dropped.
Why is this bad? Retrospectives are a way to look back on the work done in the past sprint and see how it can be done better. If they are dropped, then you loose the learning part of Agile, which is one of the main parts of Agile.
It could also mean your retrospectives are not bringing value. If that is the case, another format may be in order.
Another example of pragmatism being used for skipping important practices and disciplines is skipping planning sessions.

“We already know what we are doing, so we don’t need to plan”
This can happen in a “Command and Control” type structure, the person giving the orders doesn’t need to plan as he is giving the orders to those below him. This again isn’t agile, just another excuse for cowboy practices but of a different kind.
There is minimal team involvement, which can lead to people “switching off” as they have no say or control.

Another way pragmatism can be used as an excuse is to “Brute Force” the work.
“We have 50 servers to set up, we don’t have time to automate, we have to do it manually”.
At the end of the 50 servers installed, you have no automation. Something else will come up preventing you from automating, and the next time you have to provision another 50 servers, that will be done manually too and so on and so forth. This is what I like to call the death spiral of work.

At the moment, I have no answers on how to get around the “Pragmatism” argument, especially if you have no authority. I would recommend education, but even that isn’t a guarantee as those resistant are less likely to be open enough to be educated.