One important concept of agile work practices is the notion of timeboxing. It means that the work that needs to get done - ideally a finished product or product increment that can be delivered to a client - needs to be finished within a specific time frame using a limited set of resources. Usually, those timeboxes are quite short. In many cases they only last days, sometimes two weeks, and in extreme cases even hours.
There are a number of benefits from this practice, and many of them have something to do with innovation.
First of all, timeboxing obviously creates a result faster. The team working on the product is under a positive pressure to create results and due to that pressure gets into better flow. Needless to say that this only works when also other agile principles are respected, such as a clear briefing, open communication channels, self-organisation in teams and others. If those elements are in place, the time pressure creates a positive flow.
Secondly, timeboxing helps get feedback from the client faster. If the team spends a few days on the creation of a product which is then shown to the customer, the product can then be adapted to the feedback to the client in following work cycles. This leads, over several cycles, to a better outcome that will be accepted better by the market. And this is, ultimately, better innovation.
Thirdly, and this is one of the most important benefits from my perspective, the team needs to take difficult decisions due to the limited time and resources and therefore need to have high quality conversations to reach conclusions. The trade-offs that are made should always be made in respect of customer value. What will truly add value to the customer, and what are merely sidetracks that the team can easily neglect? This leads to high customer focus and, again, to better innovation.
And the last point is quite cool, really: Managing projects like that avoids tons of overtime, saves money and keeps everyone on the team in a nice work-life-balance.
Working with highly productive teams who are comfortable with the idea of timeboxing is a pleasure. But it is the teams that are new to the thought of timeboxing and feel uncomfortable and bewildered by it who really are the most interesting to me.
What usually happens in teams that are new to the process or where a majority is new is that the thought of timeboxing is so new that they filter it out and just ignore it, accumulate overtime and complain a lot about the limited time they have. When at the end of the work cycle the agreement they had committed to (finish the work in the agreed amount of time, with the allocated resources) is reviewed there can be quite long faces when this commitment is addressed. The nice thing is: It mostly only happens once, teams learn to deal with timeboxes very fast in the following cycles, sometimes they have to learn it "the hard way".
We are working with ad-hoc teams a lot, so they have to get used to the principles and the way of working in quite a short amount of time. We try to balance that by always adding people to the team who are more experienced in the practice and can help the team in the capacity of facilitator. Still, new teams have a hard time accepting the idea of delivering results in a set amount of time.
What comes into the picture at this time is the concept of scope. Managing scope is very important when you have limited time. Yet managing scope is again a complex idea that needs to be experienced over and over again to sink in. You can, actually, get almost anything done in a specific timeframe and at good quality if the scope is flexible. It means that you have to decide how you can fulfill the task in a good way but without all the frills and extras that you would normally add if you had no clear constraints.
I will need to write about scope in another post because we have had some pretty impressive findings, but this post is really dedicated to the idea of timeboxing.
In our journey into agile we have had more than one frustration moment with timeboxing at the beginning, because all people involved need to pay attention to the idea of the timebox when dealing with the project:
- The champ (we use this expression for the person who interacts with the customer and finds out what he really needs and then creates the backlog to create the product for the customer - in other agile practices this is called a product owner) needs to pay great attention when creating the briefing for the team and when choosing the work items for a work cycle. The items must be crystal clear, self explanatory, achievable and challenging at the same time.
- The team needs to pay attention what they commit to. They cannot enter that commitment lightly. They have to ask the champ a lot of questions and need to be sure that they know what they are committing to. This can take quite some time.
- The team needs to self organize and assume the responsibility for the outcome. There is no one coming in every day asking them how they are doing. They can tackle the workload in any way that they agree is best, using the allocated resources and time, without having to get approval for every step they are taking.
- It is very important that the team has access to a facilitator who makes sure that the team can work uninterrupted, makes good use of time and has the conversations that are necessary to take the tough decisions they need to take. In our version of agile the facilitator is chosen within the team, from the team, by the team. The role of facilitator can also change during the project.
To help the team accomplish their task they again use different tools, whether it be a simple tasklist or (preferred) a kanban board (we like www.kanbanery.com as well as www.kanbantool.com) is not so important. But visualizing the work in some way is. It must be clear for the team what the progress of each task is, who has pulled it and what it's status is.
When a team has gotten the hang of the idea of timeboxing, scope and self organisation, it is amazing what they can achieve in the time they are given.
There are a number of benefits from this practice, and many of them have something to do with innovation.
First of all, timeboxing obviously creates a result faster. The team working on the product is under a positive pressure to create results and due to that pressure gets into better flow. Needless to say that this only works when also other agile principles are respected, such as a clear briefing, open communication channels, self-organisation in teams and others. If those elements are in place, the time pressure creates a positive flow.
Secondly, timeboxing helps get feedback from the client faster. If the team spends a few days on the creation of a product which is then shown to the customer, the product can then be adapted to the feedback to the client in following work cycles. This leads, over several cycles, to a better outcome that will be accepted better by the market. And this is, ultimately, better innovation.
Thirdly, and this is one of the most important benefits from my perspective, the team needs to take difficult decisions due to the limited time and resources and therefore need to have high quality conversations to reach conclusions. The trade-offs that are made should always be made in respect of customer value. What will truly add value to the customer, and what are merely sidetracks that the team can easily neglect? This leads to high customer focus and, again, to better innovation.
And the last point is quite cool, really: Managing projects like that avoids tons of overtime, saves money and keeps everyone on the team in a nice work-life-balance.
Working with highly productive teams who are comfortable with the idea of timeboxing is a pleasure. But it is the teams that are new to the thought of timeboxing and feel uncomfortable and bewildered by it who really are the most interesting to me.
What usually happens in teams that are new to the process or where a majority is new is that the thought of timeboxing is so new that they filter it out and just ignore it, accumulate overtime and complain a lot about the limited time they have. When at the end of the work cycle the agreement they had committed to (finish the work in the agreed amount of time, with the allocated resources) is reviewed there can be quite long faces when this commitment is addressed. The nice thing is: It mostly only happens once, teams learn to deal with timeboxes very fast in the following cycles, sometimes they have to learn it "the hard way".
We are working with ad-hoc teams a lot, so they have to get used to the principles and the way of working in quite a short amount of time. We try to balance that by always adding people to the team who are more experienced in the practice and can help the team in the capacity of facilitator. Still, new teams have a hard time accepting the idea of delivering results in a set amount of time.
What comes into the picture at this time is the concept of scope. Managing scope is very important when you have limited time. Yet managing scope is again a complex idea that needs to be experienced over and over again to sink in. You can, actually, get almost anything done in a specific timeframe and at good quality if the scope is flexible. It means that you have to decide how you can fulfill the task in a good way but without all the frills and extras that you would normally add if you had no clear constraints.
I will need to write about scope in another post because we have had some pretty impressive findings, but this post is really dedicated to the idea of timeboxing.
In our journey into agile we have had more than one frustration moment with timeboxing at the beginning, because all people involved need to pay attention to the idea of the timebox when dealing with the project:
- The champ (we use this expression for the person who interacts with the customer and finds out what he really needs and then creates the backlog to create the product for the customer - in other agile practices this is called a product owner) needs to pay great attention when creating the briefing for the team and when choosing the work items for a work cycle. The items must be crystal clear, self explanatory, achievable and challenging at the same time.
- The team needs to pay attention what they commit to. They cannot enter that commitment lightly. They have to ask the champ a lot of questions and need to be sure that they know what they are committing to. This can take quite some time.
- The team needs to self organize and assume the responsibility for the outcome. There is no one coming in every day asking them how they are doing. They can tackle the workload in any way that they agree is best, using the allocated resources and time, without having to get approval for every step they are taking.
- It is very important that the team has access to a facilitator who makes sure that the team can work uninterrupted, makes good use of time and has the conversations that are necessary to take the tough decisions they need to take. In our version of agile the facilitator is chosen within the team, from the team, by the team. The role of facilitator can also change during the project.
To help the team accomplish their task they again use different tools, whether it be a simple tasklist or (preferred) a kanban board (we like www.kanbanery.com as well as www.kanbantool.com) is not so important. But visualizing the work in some way is. It must be clear for the team what the progress of each task is, who has pulled it and what it's status is.
When a team has gotten the hang of the idea of timeboxing, scope and self organisation, it is amazing what they can achieve in the time they are given.
