In a previous post, I shared a couple of quick thoughts on the need for high-performing teams to have goals. In this post, I want to focus on the touchy subject that has become timeboxing. It’s become cool for Agilists (including thought leaders) to wax negative on the technique. The popularity of the Kanban Method – an approach that does not use time boxes (at least explicitly) – has contributed to the unpopularity of timeboxes (and approaches that use timeboxes). In fact, it is now common to hear teams that still use time boxes as part of their development process described as not being progressive, stuck in the past or not modern.
Let me start off with an assertion. If you work in a context where time is bounded in some form or fashion, then you are working within a timebox. For example, if there is some work that needs to be completed by a certain date, we have a timebox.
If you happen to work in an environment where “whenever it gets done, is when it gets done” then this post may not be for you because time isn’t a constraint in your environment. Time is unbounded. Then again, you may still get some value from using timeboxes in such environments so feel free to read on.
Not Just An Agile Thing…
Timeboxing is a classic work/time management technique that is decades old. When we timebox, we are dedicating a specific amount of time to accomplishing a particular goal/task/activity. It’s really that simple. If you set aside thirty minutes every day to playing the piano (like I do), that thirty minutes is a timebox. If you set a software release date of this date next year, then you have a timebox of one year. Timeboxes can be long or short.
Timeboxing, as a time management technique, brings high levels of focus and attention to work that is being done within the timebox. I was recently reminded of the power of timeboxes in a story someone shared with me. They had given an associate of theirs an assignment but after several months, there had been very little traction or progress and it was becoming frustrating for everyone. They had a meeting and decided to assign a “box of time” to the assignment and then assess progress at the end of the “box of time”. Before you knew it the assignment that had dragged on for months was completed in a matter of weeks. The timebox brought much needed focus that had been lacking. (It should be noted that the inability to assign a “box of time” to an activity is an indicator of the state of the system.)
High-performing teams have goals. The best goals have a time component associated with them. When time is involved, we have a timebox present (be it implicit or explicit). For many Agile frameworks and methods, timeboxing is foundational construct.
Popular in Agile Frameworks…
Agile frameworks and methods such as EVO, Scrum, XP, DSDM all make use of explicit timeboxes. These timeboxes are traditionally very short periods of time (one to four weeks). The different methods also prescribe the use timeboxes differently. Some prescribe fixed duration timeboxes while others allow for dynamic duration timeboxing.
Most of the methods for which timeboxing is foundational associate a batch of work items with a single timebox e.g. completing a set of user stories in a Sprint towards a Sprint Goal.
Having individual work items have their individual timeboxes (fixed date) for is more common in the Kanban Method, which, in my opinion, also uses dynamic duration timeboxing.
There are pros and cons with the different ways that timeboxes can be used. There are also external factors that need to be taken into consideration when deciding how to use timeboxes. Be open to experimenting and trying new things if your team works with timeboxes.
In The Wrong Hands…
Any construct can be misused and timeboxes are no exception to this. The misuse of timeboxes by senior leaders, managers, Scrum Masters, Product Owners etc etc has led to the falling out of favor of timeboxes in many software development circles. The timebox is essentially used as a weapon against teams instead of an instrument of help for teams. The pressure of the two-week Sprint is something that many teams have come to dread and sadly it shouldn’t be so.
A lot of this misuse has it roots in Theory X thinking where organizations operate with the tacit assumption that people dislike their work and will do anything to shirk responsibility hence external control and direction is required in order to make sure individuals in the organization do work. With this mindset in place, timeboxes are used as a control mechanism by people in positions of “authority” (such as managers, Product Owners and Scrum Masters) BUT not the team itself.
Have you worked in or know of organizations where teams are told by someone outside of the team of HOW much work they need to get done in a Sprint or iteration before they even started and then are measured based on this as the progress? Some popular Agile scaling frameworks (that will not be named) come awfully close to reinforcing such practice. In these cases, timeboxes rule the teams instead of the teams ruling timeboxes.
There Is Still Goodness…
However, just because something can be (and is) misused doesn’t mean it isn’t useful. Timeboxes are very useful when used as a technique by teams for their own self-control and self-management. When timeboxing is used to bring focus to goals and aims, it can be particularly helpful. When used to ensure feedback is occurs in a timely fashion, it is also beneficial.
In my next post, I’ll take a look at practices that can help teams minimize the need for explicit timeboxes.