What’s a time-box?
When working with people who are new to “agile” development methods, particularly Scrum, I notice there seems to be a great deal of confusion about the concept of a time-box.
Time-boxes are baked into Scrum at multiple levels. The Sprint is a time-box, and all the standard Scrum events are time-boxed. Yet, many people who adopt Scrum pay little attention to this aspect of the process. They begin their events late and they extend the time of an event if they haven’t yet met the objectives.
I don’t speak for the inventors of Scrum, but my understanding of the time-box mechanism is that it has two key functions for a team and organization. When people don’t use time-boxes in a way that enables those functions, it suggests they don’t quite understand what the time-box is for.
Time-box defined
A time-box is a fixed time interval that has a specified start time and purpose. When the time expires, the people working in the time-box stop what they are doing, even if they have not yet achieved the purpose.
Time-boxes encourage ongoing improvement
Many have observed that organizations, development areas, delivery teams, and individuals do not maintain a steady state of effectiveness in their work. If they are not steadily improving, then they are steadily deterioriating.
One function of time-boxes is to provide a mechanism to encourage ongoing improvement.
Consider a hypothetical software delivery organization that operates on a six-week release cadence. In effect, this six-week period is a time-box. It has a fixed length, starts at a known time, and ends promptly whether or not all the intended objectives have been met.
Cyril Northcote Parkinson observed, “work expands so as to fill the time available for its completion” (“Parkinson’s Law,” in The Economist, Nov. 19, 1955). In our hypothetical organization, software teams have learned to function in a way that comfortably fills the available time to prepare a release.
If the organization wants to improve delivery performance, one of the steps they might take is to shorten the release cadence to, say, four weeks. The software teams are uncomfortable with this, and they say so. Their impulse is to revert to the previous release cadence, because they know how to “cruise” with that cadence.
The shorter time-box for releases introduces a level of discomfort, hopefully not so much as to destroy the organization, but sufficient to encourage people to think about how they might change the way they work so that they can deliver in four weeks instead of six.
How does this encourage improvement?
There’s an idea from the Lean school of thought called muda. It’s activity that doesn’t directly add value to the product the customer is paying for (or thinks they’re paying for). In software development and delivery work, this includes things like planning, tracking work hours, demonstrating regulatory compliance, providing information for auditors, ensuring the application is secure; in short, anything other than the functionality customers want.
The idea of muda isn’t that these activities are useless; they may be necessary in order to keep the work moving along (like planning and measuring the work), or to satisfy legal requirements the company has to follow in order to remain in business (like regulatory compliance or collecting sales tax from customers). The point is that these are not the reasons customers chose this company versus a competitor; customers are paying for the system’s functionality because that’s what enables them to carry out the tasks they need to complete. The other things have to be in place, but they aren’t what the customers are buying.
I think this is an important distinction, because we want to focus our time, effort, and investment on satisfying customers. Other activities may be necessary, but we want to satisfy those needs with a minimum of time, effort, and money. If we don’t distinguish between value-add and non-value-add activity, how will we know which activities to maximize and which to minimize?
A common mistake when people are first adopting Scrum is to maximize the Scrum events, as those are the things that are documented and talked about the most. But Scrum is about getting work done, which means the time that is not spent in Scrum events should be maximized. The events themselves are overhead; they are muda. That’s one reason they are time-boxed: So they will reduce value-add time by a limited, known, and consistent amount.
In their book, Lean Thinking, Womack and Jones suggest there are two categories of muda. Type 1 Muda is non-value-add activity that we must support. Type 2 Muda is non-value-add activity that we can do without altogether. We want to stop doing Type 2 Muda and minimize the time, effort, and cost of supporting Type 1 Muda.
The teams in our hypothetical organization are probably doing at least some things that aren’t really necessary.
I recall one organization where we had to fill out three different time sheets to track our work hours: one reporting hours per week, one reporting hours per two weeks, and one reporting hours from the 1st to 15th and 16th to end-of-month. Upon investigation, we learned all three formats were holdovers from the past; each had been the company standard at some point. Only one was actually used by anyone, for any purpose. We were able to dispense with the other two.
In other cases, I’ve seen standard processes that included duplicate or redundant reviews or data extracts for metrics, with the same metrics reported in multiple formats for different managers. In those cases, we were able to eliminate all but one of the reviews or extracts.
Those are examples of Type 2 Muda. We can simply stop wasting time with those activities.
Customers don’t seek out a supplier because of the way the supplier plans its internal work. Therefore, planning is muda. We have to plan our work somehow; we can’t just stop altogether. So, planning is Type 1 Muda. Therefore, we want to learn to plan our work in a way that minimizes the time, effort, and cost of doing it.
Less-than-optimal technical practices can also be seen as muda, as they have negative effects on continuous flow, lead time, cycle time, and product quality. Those factors reduce the delivery capacity of the team as well as potentially damaging customer satisfaction.
On a technical level, there may be things teams are doing that they needn’t do at all. More commonly, they are doing things that are required, but they are expending more time and effort than necessary. Sometimes, a team can achieve a necessary outcome in an alternative way that increases the relative amount of time available for value-add activity.
For instance, a team that conducts scheduled, formal code reviews might adopt pair programming as a standard development practice, and eliminate the need for the formal code reviews. They still achieve the purpose of the code review, but they do so in a way that involves less non-value-add time.
Taking the same idea to the next level, if the team conducts a daily stand-up, they might adopt mob programming or ensemble programming, and eliminate the need for the daily stand-up. They still achieve the purpose of the stand-up, but they do so in a way that involves less non-value-add time.
Similarly, a team that spends a lot of time performing “manual” regression testing prior to each release might be able to automate some of that testing, and reduce the amount of non-value-add time to prepare a release. They still achieve the purpose of regression testing, but they do so in a way that involves less non-value-add time.
We can’t manufacture hours, but we can consider ways to reduce non-value-add-time, leaving proportionally more time in the day for value-add activity. The time-box encourages this kind of thinking by introducing challenges in meeting the objectives of an activity within its time-box. When people react to the challenge simply by extending the time-box, they defeat its purpose and fail to achieve any improvement.
Time-boxes improve planning predictability
In many organizations, and particularly larger ones, the planning of software initiatives is unreliable. Leaders and stakeholders need to have at least a general idea of the cost and delivery time of any given initiative.
On one level, they need this information to make the “go/no-go” decision for the initiative. Once work is in progress, they need to know the delivery capacity of the organization in order to project delivery dates accurately enough to launch marketing programs and set up their accounting to maximize the tax benefits of capitalization.
A common issue is that people on delivery teams are afraid to tell the truth about how much work they can deliver. They assume they are expected to deliver literally everything that anyone in a position of formal authority demands, or they will be fired. In reality that situation is very rare; organizations would not be able to function very long if they operated that way. Yet, people’s fears are real.
The most common way people attempt to “do everything” is to work overtime and do “death marches.” That creates irregularity in their work. No one can work large amounts of overtime on a sustained basis. Their effectiveness varies inversely with their level of fatigue. Sometimes, people have to “crash” and take a day or two off to recover from the latest death march. During those days, their delivery effectiveness is zero.
In Lean terms, this kind of variability is called mura, or unevenness of flow. If flow is not steady, it’s difficult to see what a team’s “normal” delivery performance might be, or how the team is likely to perform in the next month or quarter.
When all the teams in an organization are operating this way, they will be at different points in their up-and-down cycles of flow at any given time. There is no way to measure the organization’s delivery capacity at all, let alone use that information for planning.
The idea of a time-box, as applied in Scrum, helps alleviate this problem. In principle, a software delivery team has no “meetings” and only pauses in value-add work to carry out the Scrum events, wherein all the non-value-add activities are encapsulated. As the events are time-boxed, the team knows exactly how much time they have for value-add work.
The Scrum time-boxes work in concert with other factors to improve planning predictability. Teams are cross-functional and dedicated, with as few external dependencies as is practical given the realities of the organization. Team members no longer have to attend arbitrary meetings that interrupt their focus in the middle of the day and that have no definitive ending times. Any planning that is based on estimation will be more predictable than before, as everyone knows exactly how much time is available for value-add work, they know they will experience a minimum of context-switching overhead, and they have only a few dependencies that may cause unplanned delay (and possibly none at all).
The Sprint time-box has an additional function relevant to planning predictability. Rather than depending on estimation, we can plan work using forecasting based on empirical observation of a team’s demonstrated delivery capacity. What makes this possible is the fact the Sprints are all the same length. Given a fixed-length time interval and a cross-functional, dedicated team with a standard amount of value-add time per Sprint, we can depend on the near-past performance of the team as an indicator of the team’s near-future delivery performance.
Remember there is no steady state; that’s why we can’t use this method for long-term forecasting. The team’s delivery peformance will be changing gradually…hopefully for the better. At the organizational level, differences in team performance tend to wash out, and we can use aggregate numbers for longer-term planning than we can at the single-team level.
Time-boxes support capacity planning
Historically, in corporations that separate information technology from “the business,” the IT department is treated as a cost center. Business units request work from the IT department. Business units have no awareness of (and often no interest in) the delivery capacity of the IT department. They simply throw requests into the IT department as if it had infinite capacity.
Another way to say “infinite capacity” is “bottomless pit.” That’s the way many business organizations view their internal IT departments. While the people in the IT group feel as if they are overworked and doing everything possible to satisfy stakeholders who don’t appreciate their effort or respect their skills, the stakeholders feel as if they can never get a straight answer from the IT people, never get results aligned with their needs on time and on budget, and that the IT people lie about what and when they will deliver.
Time-boxes do not fully or automatically solve this problem, but they do help the organization see and quantify their true delivery capacity. Knowing the capacity of the IT department helps business leaders understand what is or is not possible based on a given budget and time frame. They can prioritize initiatives appropriately and ask the IT department to carry out the most valuable ones, in view of the true capacity of the organization.
They also have empirical information to help them decide whether to increase the capacity of the IT department. Exactly how they do so is a different question, but lacking accurate information about today’s capacity, they have no basis on which to plan the capacity they will need for tomorrow.
Summary
Time-boxes can improve planning predictability and encourage process improvement at multiple levels in an organization. But if people short-circuit or side-step the time-boxes in order to avoid temporary discomfort, they risk losing the potential value.
A team that extends the time-box for Sprint Planning because they weren’t able to prepare enough backlog items for the new Sprint denies themselves the opportunity to learn how to plan more effectively.
An organization that moves release dates because they weren’t able prepare all the functionality they intended to release denies themselves the opportunity to learn how to get things done within the standard release cadence.
And if they aren’t steadily, intentionally improving…