Explaining time boxing to your clients

If you like this, share it with the world! Share on LinkedIn0Tweet about this on TwitterShare on Facebook0Email this to someoneShare on Google+0

Today I had the honor of speaking at Kravdagen (Requirements Day) 2017: my topic was “my agile coach is talking shit!”, and among the topics I covered was the habbit of some coaches to be unable to explain why the methods and tools they advocate will actually benefit the client. And also today, I saw an interesting question on LinkedIn. The question was “The agile manifesto says nothing about time boxes, so why do we take them for granted in agile?” Sometimes we get so accustomed to using a certain tool or practice that we forget why we use it, or even keep using it when it no longer makes sense to do so! Inspired by this, I decided to write a piece about how I explain the benefits of time boxing to my clients.

Balancing focus and change

“Responding to change over following a plan”, reads the agile manifesto. Yet even in agile, too frequent changes can become disruptive. If we are never allowed to focus on completing something, we will end up with a lot of work partly done, and no work ready to be delivered. Agile teams thrive on change, but the change has to be controllable.

By working in small time boxes, the agile team gets the chance to focus on completing a handful of features. Anything outside of what is covered in that time box is open to being changed, but for the duration of the time box, the team knows exactly what they should prioritize.

Summary: time boxes allows the team to focus on the #1 prio, while letting the customer change what is the #2 prio!

Making sure stakeholders know what they’re getting

If you are a stakeholder to a team adapting agile, a major source of worry is the feeling of not knowing what you will get from an agile team. While our inner cynics may be tempted to point out “You never know what you’re going to get from your waterfall projects either”, this perceived lack of security is a serious challenge that must be overcome if you are to win over your teams stakeholders.

By dividing up the delivery time line into small time boxes, the stakeholder gets a very real way to measure what they’re getting. Are they getting valuable deliveries after each time box? If they’re not seeing any value after 2-3 time boxes they have the right to feel worried. But if they’re gotten valuable deliveries the last 5 time boxes, they can probably feel fairly secure they will get one at the end of the current time box as well. Compared to the false security of getting a spreadsheet that shows everything being green for 3 months but still not having seen a working product, deliveries after each time box gives amazing predictability.

Summary: time boxing, and delivering after each time box, allows the stakeholders a higher degree of security than big-bang delivery!

Enforcing feature breakdown

Everyone who has ever worked with product development knows that big features are impossible to estimate. This doesn’t just go for time estimates; it is very hard to estimate risk and impact of a large packet of work. The best way to understand the complexity of the work you’re planning to do is to break it down to smaller pieces.

Because time boxes are quite short (most teams use 2-3 weeks), only smaller pieces of work can be planned for a time box. You cannot fit in massive work packages in a 2 week time box, which means that the only way to plan any work is to break your work packages down into chunks that fit into time boxes.

Summary: by time boxing, we help ensure that work is broken down into manageable pieces, which in turn helps us estimate complexity and analyze impact and risk of said work!

So, those are some of my thoughts on how to explain the benefit of time boxes to clients. If your clients ask you why they should time box their work, what do you tell them?

If you like this, share it with the world! Share on LinkedIn0Tweet about this on TwitterShare on Facebook0Email this to someoneShare on Google+0

One Reply to “Explaining time boxing to your clients”

  1. Great post, Sam – Thanks!

    I would like to add another benefit of timeboxing:
    If the iterations are kept short, then stakeholders are less tempted to add requirements for features “just in case they might need them”, which is something which frequently occurs in waterfall. If the iteration is shorter, the stakeholders are more comfortable with adding features as they go and as they get validation of which features are considered more valuable by real user feedback. This in turn means that the development of many “less than useful” features can be left out. This leads to less waste – everyone wins!

    Sam, can you expand on how to tackle the challenge of long deployment times leading to that features cannot be completed within the sprint? (Mainframe systems w/o automated deplyoment and no automated testing)

Leave a Reply

Your email address will not be published. Required fields are marked *