Timeboxing or Flow?

This is a chapter from Amplio Development: The Path to Effective Lean-Agile Teams

Timeboxing is looking out to the future to see how much work you can do in the specified timebox. Flow is looking at the next piece of work and getting it out as soon as you can. You can put flow into a timeboxed system, but that is not the same as just using flow. The decision to use timeboxing, as in Scrum, or flow, as in Lean and Kanban, is an important one. It is often a good decision to make early on as it creates the context for many other practices and will be the basis for how roles cooperate with each other. However, it should not be considered a one-and-done decision. Many times starting with timeboxing is a good one to make the transition to Agile easier. Once basic Agile practices are underway, going to a flow model can further the transition. But just as often a flow model may be better because it can be much less disruptive. In this section, we’ll discuss how to make this decision. Timeboxing (also called using sprints or iterations) is when a team decides what they will build over a particular length of time. It is the common practice of Scrum and SAFe to use timeboxing. Scrum tends to use 2-4 week timeboxes they call “sprints.”  SAFe uses 2–3-month timeboxes they call program increments. Flow is when items of value are pulled by the team and done to completion at which point another item is pulled. Flow may be done with many items in play or only one. This latter approach is called “one-piece-flow” which is often popular in manufacturing but not recommended as a general rule. There are two extremes (#1 and #4 below), and hybrid approaches are possible. These are:

1. Pure timeboxing. Decide on what work will be done within a certain pre-determined period of time and don’t worry about the order the work is done within the timebox.
2. Timebox the work, but do the work selected in a flow-like manner. That is, try to keep as few items in play as possible without slowing the team down.
3. Flow with timeboxing. In this case, an “item” to be worked on can be worked for a particular amount of time. You’re still thinking flow but have decided that working on a certain amount of work within a short interval.
4. No timeboxing of work, just work on items of the highest importance but do have a cadence for coordination.

If you’re going to do timeboxing, it is recommended that you do flow within it.  This speeds up the completion of individual items and therefore speeds up feedback and the delivery of value. The choice of using timeboxing or flow is not always a clear one. Many factors are often involved. Some of these factors predispose a team to choose flow or timeboxing. Many times, however, this choice will best be made after going through the required objectives and seeing how to best meet them. When it’s not clear, it’s often best to choose the practices that appear best and make a choice after going through the list of roles, events, artifacts, and rules and using the practices chosen. Regardless of which practice is chosen, the focus should always be on value delivered and keeping work-in-process as low as possible while not impeding workflow. However, sometimes the choice is clear right up front. These are the factors that may have you decide upfront which approach to take:

Reasons to timebox

1. People may be more familiar with timeboxing. They may have experience with Scrum already. But be wary of proponents of timeboxed-based approaches claiming teams new to Agile should always start this way. That’s more marketing hype than truth.
2. Either due to familiarity or how the team likes to work, timeboxing would be an easier transition for the team.
3. The team is clear about what needs to be built and releases will likely take a few sprints (timeboxes) to be completed.
4. Releases typically take more than one iteration to build.

Reasons to use flow

1. You are building a new product and working in a discovery mode with Minimum Viable Products. Flow makes more sense here because you can’t plan very far ahead since you are not sure what the product is.
2. You are doing a significant of maintenance work (including being mostly a support organization). This means the time spent working on new functionality will be interrupted by maintenance items.
3. As maintenance work increases the difficulty of planning new work becomes more difficult.
4. The team is continuously interrupted by other teams.

From a mechanistic point of view flow typically gives better results. The reason is that with a flow model you focus on releasable items to build and work on fewer items. It also makes it more likely problems will be solved immediately instead of waiting for the retrospection. Since teams should release when work is ready, not necessarily at the end of the timebox, planning beyond a release that will occur in the next iteration makes sense.  That said, it’s important for the team to decide what they are more comfortable with.

The difference in how timeboxing and flow shows up in work

When timeboxing is being used, especially if it was selected because the teams were not experienced, there is a tendency for teams to open too many stories. The focus is on getting the sprint plan accomplished. While there may be an intention to release part of it early the commitment is to the sprint, not the early release. This often results in many stories being open throughout the sprint and many get closed towards the end of the sprint. This is not an efficient way of working and delays getting feedback to the end of the sprint. When flow is used the focus is on what is being released next. This prevents opening up stories that relate to what will happen after the release. This focus tends to prevent too many stories from opening and increases cooperation. Note, however, that this attitude can be used even when timeboxing is used – and it should be.

A potential challenge with timeboxing and management

A common challenge teams face is management asking to insert a new request into the mix. This is very easy for them to justify when timeboxing is used because it just adds one more thing to the pile. Working a little harder is expected.  When flow is used, work is clearly sequenced – we work on items in order of value. It is easy to show management that injecting this new piece of work into the sequence slows everything else done. That doesn’t mean management will abide by this, but it does make it clearer that there are consequences. This also sets the stage for making work interruptible, a useful technique.

What to start with

In whatever way your team starts, you can move forward and change as appropriate. Regardless of which approach you take you always need to have a cadence. This enables the coordination of different teams and roles.

This is just a preliminary decision

As you work through this book, you may learn concepts that have you change your decision. There are times when how you work changes as well. For example, you may start working on a new product and decide you want to use flow. After some time, you understand what needs to be built and shift into a time-boxing mode. After it’s released, you may be more in maintenance mode and shift back to flow. The critical thing, however, is to stick with the method you chose during the period you chose it for. Also, even when you use timeboxing, you will be doing flow within the timebox.

How Timeboxing Can Create Waste

Question to students: When do customers know what they want?

Answer: After we show them what they don’t want.

Question: So when do we want to show them something?

Answer: As soon as possible.

There are tradeoffs in using timeboxing. It’s quick to pick up and useful as a start. Using timeboxing can often be the best approach short and long term. But it has some inherent disadvantages in many situations. These are:

1. In the middle of the timebox (sprint in Scrum), you may discover that the rest of the work to do isn’t as important as what you had planned. You can, of course, swap the work, but there is a likelihood that the analysis time you spent on the pushed-out work didn’t need to be done.
2. If you find you come to the end of the timebox and haven’t started some stories, then you’ve wasted time analyzing them.
3. If you decide not to carry them over, they may need to be re-analyzed by the time you do get to them.
4. With more stories available to do, people will likely open more stories than needed. This challenge can be overcome with discipline by incorporating flow into the timebox. But if you do that, you don’t need to plan the timebox – just take the essential items as they come.

If you’re ending up having stories open at the end of a timebox, shorten the timebox.

Many Scrum teams face the problem of having stories unopened at the end of a two-week sprint. This represents waste because even if the stories are carried over to the next sprint, the analysis is two weeks old. And they may need to be reanalyzed as well. Analyzing two weeks of stories takes more time as well. You also can’t take advantage of what you’ve learned from previously done stories. Using 1-week sprints will mitigate this problem. Quicker building, quick discovery. Shorter-term meetings. Of course, if getting customers and product owners together is impossible every week, you may need to make sprints longer.

If you’re fully doing flow in the sprint you will discover you only need the sprint for two things

Sprints are useful for creating a vision. They are also useful for creating cadence. But cadence can be applied with or without timeboxing.  Since you can release when enough value is present, you can drive from what you are going to release. If you’ve selected iterations and now have a sense of how to do flow, consider this:

Since you want to release when value is ready, should you focus on the sprint goal or on what you can release first within the sprint? Which will speed up the release?

If you focus on the release and do flow in the sprint- what’s the purpose of timeboxing?

Warning: If you are doing Scrum, don’t just abandon sprints because you are having challenges with them.

Sprints serve a purpose. Just abandoning them is not a good idea. Flow can provide an alternative set of practices, but you must:

1. Have small batches
2. Focus on completing what you start
3. Manage work in process and accumulated risk

It typically takes more discipline to use flow than timeboxing, but the savings can be significant.

Doing this properly changes “we do Scrum but we don’t do sprints” to “we do Scrum except instead of sprints, we use flow.”

Timeboxing tends to slow down interactions with customers

This is a case study by Al Shalloway

When you are building something you are absolutely sure of, you can often go off and build it and then come back to have a review by the customer. But this does add risk as even when you are sure you understand, you often won’t.

In the mid-90s, before I was consciously doing Agile, I had an important client that wanted a report. I had a history with them that they’d ask for things only to tell me later that I hadn’t gotten it right. So when they gave me their requirement I decided to mock it up with their own data.

The client was a large spa, and they were asking for a services report by all their technicians (i.e., hair stylists, masseuses, colorists, …). They wanted both the detail by type of service for the client and also totals by department. It was an involved report but only looked to take a few days to do. So I got confirmation with the mock-up, created the report, and showed them the results feeling very confident I had nailed it.

Not at all. They didn’t like it and told me what I had done wrong. I admit I was pretty puzzled – they had seen the mockups and I had given them a report based on that. These people were not stupid, nor not caring (they were paying me by the hour). What happened?

On reflection, I realized that seeing a report’s results is not the same as running the report yourself. They looked at the mock-up report, but didn’t truly understand it.

A few years later when I got into XP and about emergence of requirements, I realized had I done the report in an Agile way, I could have saved the time required to mock it up and would have gotten it the first time. I should have created a report with stylist totals and gotten confirmation that was right. Then I could add revenue by department and get confirmation again. I could have repeated this each time, adding a little function, validating it, and then moving forward. This would have worked. And I’ve done this since and have seen it does.

Timeboxing gives the illusion that we know what to do for a few weeks. It hides the waste caused by not having more feedback with the customer / product owner. While it may not be possible to meet as frequently as useful, at least be aware there is a cost to that.