When he was a toddler, my son had difficulty with transitions. He wanted to keep doing whatever he was doing, and didn't want to stop. Transitions would generally result in crying and general bad feelings all around.
Two things helped this problem considerably. First, I happened to have a timer on my digital watch. I started using the timer, saying to my son, "OK, 5 minutes until we have to go." When the timer beeped, he would happily stop what he was doing and would move on without any fuss whatsoever. The second way this was helped was after reading about children who have transition issues. A common strategy to help is to tell them what's going on and when. For example, "We're going to swimming lessons, then to the grocery store, to Home Depot, and then home."
Through dumb luck and research, the meltdowns essentially stopped. To this day, over a decade later, my son asks what's "on our agenda" when we go out.
Coaching Point
We use timeboxes quite a bit in Agile. Timely feedback is one excellent reason for doing so. Another reason is to provide some consistency and rhythm to the process. When the timer beeps, we move on. The meeting ends. The iteration is complete. We ship the software built in that release. Everyone knows this rhythm and abides by it.
Timeboxes also provide focus to our work. A quirk of human nature is that our work will expand to fill a vacuum, i.e. if we're given six months to complete something, we'll find a way for it to take six months! This is known as Parkinson's Law. If we create horizons of 1-3 weeks for intermediate checkpoints and 2-4 months for releases, we must find a way to focus our work in order to deliver business value over those time-frames.
Short timeboxes also force us to break work down into small enough chunks that they can be delivered within the length of the timebox. This functions as a great way to avoid, or at least decompose, complexity in a system.
The Product Owner creates a prioritized backlog of work to be completed and a release plan showing what we think is going to be the work for the next while. That "agenda" can change, but those changes usually involve all team members, and are certainly communicated to them. What the team will be working on is crystal clear. It can change, but not without consulting the team. This prioritization process is itself another benefit driven by timeboxing – in order to work on the most important features first, the stakeholders must really think about what “important” means to them.
So, timeboxes work to direct our behaviour in a way that allows us to focus our work into a comfortable rhythm. Timeboxes help to avoid the stress caused by larger transitions through this predictable rhythm, and create a sustainable pace for all involved in delivering a product.
Oh, and don't tell my son that when I said I set my timer for 5 minutes, quite often it was actually 2 or 3.
Two things helped this problem considerably. First, I happened to have a timer on my digital watch. I started using the timer, saying to my son, "OK, 5 minutes until we have to go." When the timer beeped, he would happily stop what he was doing and would move on without any fuss whatsoever. The second way this was helped was after reading about children who have transition issues. A common strategy to help is to tell them what's going on and when. For example, "We're going to swimming lessons, then to the grocery store, to Home Depot, and then home."
Through dumb luck and research, the meltdowns essentially stopped. To this day, over a decade later, my son asks what's "on our agenda" when we go out.
Coaching Point
We use timeboxes quite a bit in Agile. Timely feedback is one excellent reason for doing so. Another reason is to provide some consistency and rhythm to the process. When the timer beeps, we move on. The meeting ends. The iteration is complete. We ship the software built in that release. Everyone knows this rhythm and abides by it.
Timeboxes also provide focus to our work. A quirk of human nature is that our work will expand to fill a vacuum, i.e. if we're given six months to complete something, we'll find a way for it to take six months! This is known as Parkinson's Law. If we create horizons of 1-3 weeks for intermediate checkpoints and 2-4 months for releases, we must find a way to focus our work in order to deliver business value over those time-frames.
Short timeboxes also force us to break work down into small enough chunks that they can be delivered within the length of the timebox. This functions as a great way to avoid, or at least decompose, complexity in a system.
The Product Owner creates a prioritized backlog of work to be completed and a release plan showing what we think is going to be the work for the next while. That "agenda" can change, but those changes usually involve all team members, and are certainly communicated to them. What the team will be working on is crystal clear. It can change, but not without consulting the team. This prioritization process is itself another benefit driven by timeboxing – in order to work on the most important features first, the stakeholders must really think about what “important” means to them.
So, timeboxes work to direct our behaviour in a way that allows us to focus our work into a comfortable rhythm. Timeboxes help to avoid the stress caused by larger transitions through this predictable rhythm, and create a sustainable pace for all involved in delivering a product.
Oh, and don't tell my son that when I said I set my timer for 5 minutes, quite often it was actually 2 or 3.
Comments