Timebox all the things. A “timebox” is just a strict deadline, a finite amount of time to accomplish some task. The idea is that you stick to the timebox and go with the results you have, whatever they may be at the time. Although you might usually think of iterations as timeboxed development, the concept of a timebox extends to iterations, meetings, the amount of time to be stuck on a bug before asking for help, and more.
The chief benefit of using a timebox is to reduce risk and reduce wasted time and effort.
A timebox for a meeting ensures that you reach a decision, instead of languishing in (often paralyzing) indecision. Knowing that the meeting, or even this topic, only has 10 minutes remaining can help push you out of the debate and into something more productive.
A timebox for team members who are stuck ensures that they‘ll seek help, and not remain stuck indefinitely, wasting more valuable time.
A timebox for development is called an iteration. An iteration should be long enough to accomplish a small set of tasks/features, but short enough to comprise easily disposable work to minimize risk.
Iterative development leads teams to break down their work into more manageable tasks. The traditional, and very risky, approach of allocating months for a single task can’t hold up if the team is working in two-week iterations. This short, artificial boundary forces the team to do just enough analysis to understand what the larger task looks like, and how to decompose that work into smaller units.
Studies have repeatedly shown that development efforts have higher success rates when tackling smaller amounts of work. The iteration idea takes advantage of that.
The iteration also provides a mechanism to flag problem teams earlier. If a team can’t complete most of their task in a two week iteration, maybe it’s just a random issue (yes, problems like that do still crop up).
But if a team can’t make significant progress after multiple iterations, while other teams can, that’s good feedback to indicate which team needs help. Instead of waiting six months or a year to discover that a team has an issue, you’ll know in a few weeks, and can help fix it now.
The iteration is also a morale boost. There’s something inside of us that likes to succeed. We love to cross finish lines. We can harness that desire to win and provide a finish line every two weeks. It’ll help everyone learn more quickly when we fall short, and build momentum quickly when we succeed.
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
Steps to first adopt this practice:
At this stage, you just doing work in increments. At the next stage, we’ll expand on this idea and add practices to set up for the demo and get better feedback at the end.
The length of time allocated to a timebox is important: it needs to be as short as it can be and still work. Here are some guidelines, stick to these limits for now:
What about unplanned work? How best to handle emergency bug fixes, maintenance tasks, and so on that come up?
There’s a trade-off between responsiveness vs. productivity. If you insist on stopping the team cold to respond to an issue, you will ruin productivity. If you never let the team address unplanned issues, you’ll ruin responsiveness. What you need is a compromise: buffer the unplanned work to some degree.
Defer unplanned work to be later the same day, later the same week, or in the next iteration, depending on the severity and priority. Don’t drop everything every time an issue comes up, and don’t ignore critical issues for weeks either: time box your response to emergencies, so that other parties will have confidence that you’ll address the issues within some known period without becoming completely interruptible.
Iterations can be one to four weeks. Most teams use a two week iteration. A one week iteration forces you to ruthlessly automate tasks like testing, deployment, and database adjustments. Trying one week iterations for a few months can be an eye opening endeavor.
Start your first iteration with a group StoryRefinementMeeting.
A bad technical lead or TeamLead will tell the team what work they’ll be taking on during an iteration. This is a very “command and control” approach, and removes the team’s ownership of the work. It also means the team has no reason to scrutinize the work description, acceptance criteria, etc. That violates our concept of bi-directional transparency and accountability; that’s no way to run a growing organization.
If the team is getting 10% to 20% of their committed work done, then the team is being given too much work. Enabling the team to consistently over-commit is simply enabling dysfunctional behavior. A good team averages between 90% and 110% of their commitments.
What else could you apply a timebox to? What else has a lot of unknowns, a lot of risk, and no end in sight?
Combine your testing work with your development work. Don’t create separate stories, and then blame testing for not finishing “their” work. It’s the team’s work and the stories aren’t done until they’re shippable. Not tested? Not accepted. Next iteration, finish on time and help out the QA team! Help them verify another team member’s work, or help automate the acceptance tests.
Timeboxing is best taught by someone who’s experienced the practice. If you have another team in your company that’s already timeboxing, ask for a prisoner exchange. This is where you trade a team member for a few days or a few weeks (maybe a few months?) and they can work alongside your team, explaining how they run this meeting, or deal with that problem. Your team member, the one sent to the other team, is immersed in that team’s practices. Each team has something to share with the other. This side-by-side immersion shares everything the team does in a variety of contexts.
Another approach is to bring in a coach or mentor for a few months. This isn’t a permanent addition, but someone to guide and teach while your team learns the ropes. Coaches are often external to the company and mentors are from within, but in both cases we’re introducing expertise in a position of authority.
Whether you introduce peer expertise, with a prisoner exchange, or hire a coach, it’s important to introduce experience to the team. Lessons can be learned the hard way, through trial and error, but you’ll advance much more quickly by learning from other’s mistakes.
Anti-patterns from the Hall of Shame