Timeboxing is a time management tool that helps to keep the focus on the priorities by limiting the available time for task completion. You allocate a reasonable amount of time to an activity, and that activity must be completed within that time frame.

Do you have deadlines that you set for your staff or vendors when something needs to be done by a specific time? If no…. then this post may not be for you and we should be having a totally different conversation. I am going to assume you answered “Yes” or “Yes, sometimes,” because most things have some sort of a deadline that hopefully isn’t completely arbitrary.

Scenario

Let us imagine a situation where you have a project. This project has an estimated completion time of 6 months. You are a major stakeholder on this project, the primary customer or manager. A lot of the decisions fall on your shoulders.

We are a couple of weeks in, and the project manager needs you to make a decision. He/she gives you a couple of days to think about it and has a set meeting to go over it, asking for a decision during the meeting at the latest. You are sent an email to remind you of the meeting and the need to make a decision.

You can A) Prepare to make a decision (Make arrangements with the needed people, etc.,), B) Ignore him/her and not think about it again, or C) get offended about being told you have to make a decision by someone beneath you; you will make your decision whenever you feel like.

If you answered “A,” congratulations! You have a much higher likelihood of making your 6-month deadline on this project.

If you answered “B,” please re-think this and make some time. Delaying some decisions may cause a delay in the project. Lots of little delays can derail a project’s timeline.

If you answered “C,” please find a new job. You shouldn’t be a manager, and your staff will suddenly appreciate you more when you quit.

Timeboxing in Agile

A lot of Agile frameworks use something called timeboxing. These are basically a set amount of time for making decisions. The purpose of the timebox is defined, and a limit or duration of time is set. You are not allowed to go over the set time. Now, you don’t have to use timeboxing, but it can provide a consistency that people will learn and adapt to. This is the time we have, do it and get it done within that time.

Timeboxing actually is the source of a lot of complaints in Agile, causing people to believe that Agile is not very agile as some of the methodologies require strict adherence to timeboxing. While I can agree with some of the complaints about Scrum, the problem isn’t usually timeboxing.

One crucial part of timeboxing in Agile frameworks is that it creates a structured and repeatable system. You know in advance that the planning session is coming up in one week. You know in advance that it will last up to four hours and only four hours. If you cannot prepare for it, Agile or timeboxing isn’t the problem.

Books on Timeboxing

• Timeboxing: A Complete Guide
• Everyday TIME MANAGEMENT: Mastering the art of timeboxing, project chunking and estimation (Skill Development Series)

It is not inflexible for the sake of being inflexible. It is inflexible to help create decisiveness and propel the work forward. If you made the wrong decision, there is an opportunity to change in the future or in many cases have other components worked on while you investigate some decisions more for the next iteration. That is part of the adaptation process.

The point being, you have to be proactive. You have to think about things ahead of time and what you would like to accomplish within a timebox. This may require meetings and discussions with other people before the beginning of the time box. If you have regularly recurring timeboxes, the beautiful part there is that you already know the timebox is going to happen and you have time to prepare in advance.

I get it, people are sometimes busy. You probably have other duties. Well, this is a duty that is just as important as those other duties. You may have to delegate out some decisions. You may have to negotiate what is being worked on next within the project. But you cannot ignore it and let the timebox lapse.

Flexibility, to a point

A gymnast, graceful, and agile. They can move and flex in ways most ordinary people cannot. But there will be limits to how flexible they are. The muscles can only stretch so far, the bones cannot fold into each other.

If you take away the bones, it will make the gymnast pretty flexible. They may not be able to move forward or backward very fast and might resemble a blob on the ground, but you can pick them up and fold them a couple of times to show off their flexibility.

They lack structure. The very thing preventing ultimate agility by the gymnast is the very thing that is allowing the gymnast to use the agility they do have.

The same goes for timeboxing in Agile. They need structure, they need bones. Many use timeboxing to help provide that structure. That isn’t the only way, but it is probably the most common way. If you take away that timeboxing, refuse to make or participate in set duration decisionmaking, you are taking away the bones. I hope you have something to replace it with that will work.

Agile will bend for you. Agile will flex and be forgiving (perhaps to a fault). But it needs some structure and guidance to help propel it. Getting rid of structure in the hopes of making it more agile (agiler?), creates a whole bunch of other issues. One flaw with other methods of doing things is that you have to chase people down to get things done, and they never get done on time. Adhering to a timebox can help ensure it does get done in time.

Reflection

Too many problems arise when companies decide they don’t want to adhere to the “strict” timeboxing or other structure put in place. If it falls apart, you can’t blame the Agile methodology or framework. You can’t blame the timebox.  You have to put limits in, and you have to adhere to them. Infinite flexibility just won’t work.

See some rationale for when you can ignore certain timeboxes in Agile

I get it though, my initial thoughts on Scrum when I first learned about it years ago were along the lines of, “that seems strict for something they call Agile.” It wasn’t until I got onto a project where every time I tried to get decisions and set deadlines for those decisions that I understood why we need timeboxing. If this were your initial thinking, I would strongly suggest giving it a second thought. I know Scrum can be dogmatic, almost cultish, and it may not work for everything – but forcing decisiveness may just be what you need.

Sources:

Images from https://www.pexels.com