Timebox all things. A “timebox” creates a strict deadline, a finite amount of time to complete tasks. 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 cycles, the concept of a time box extends to meetings, the amount of time to be stuck on a bug before asking for help, and more.
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this habit:
Steps to first adopt this habit:
One of the biggest problems with old-fashioned, plan-based software projects is the long periods of time with no feedback. In those dark times, teams typically coded like mad. Then just before an impending deadline, they’d start holding demonstrations only to learn they had overlooked key aspects of users needs, or that those needs had changed.
Early Agile methodologies discovered that shorter feedback loops enabled teams to adjust their aim and actually hit the target the customer wanted them to hit. Instead of arguing with the customer to convince them they wanted what we’d delivered, we showed them our work and discovered what they really wanted.
How much of your work are you willing to throw away?
How much of your work are you willing to throw away? Make that the length of your development time box. The popular notion of a two to four week “iteration” is too long. You want feedback faster. You can’t work any faster than the feedback you receive.
But in the beginning you might want to stick with the common approach that dictates “no requirements changes” within the timebox, and “one big release at the end.” However, those are not “responding to change over following a plan.” If you’re transitioning from much longer release cycles (months or years), however, start with a two week time box with a release at the end.
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 show that development efforts have higher success rates when tackling smaller amounts of work. We take advantage of that.
The timebox also provides a mechanism to identify teams with problems early. If a team struggles to complete working, tested, features within the time box, perhaps it’s a random, one-time issue (yes, problems like that do still crop up). But if a team consistently can’t make significant progress after multiple time boxes, 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 is struggling, you’ll know in a few weeks, and can work with the team right now.
Timeboxes also boost morale. 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.
But after developing this way for a while, you want to begin to “shorten the timebox” by relaxing the big ceremony at the end. Instead of one release at the end, release several times within the time box period. Address changes as they occur rather than waiting, if it makes sense to do so.
The goal is to continuously deliver value and user abilities.
Remember, a development timebox is a starting point, aimed at helping the team transition from a 6-12 month (or longer) release cycle to trunk-based development with continuous integration and deployment.
Shrink the time box until delivery becomes continuous.
In order to accomplish the tighter feedback loop, we recommend adopting the TracerBullets habit to enable key features to be demonstrated as early as possible during development.
What about unplanned work? How best to handle emergency bug fixes, maintenance tasks, and so on that come up?
A trade-off exists between responsiveness vs. productivity. If you insist on stopping the team to respond to an issue, you ruin productivity. If you never let the team address unplanned issues, you ruin responsiveness. What you need is a compromise: buffer the unplanned work to some degree. (see TeamWideInteruption)
Defer unplanned work to later the same day, later the same week, or in the next development time box, 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 have confidence that you’ll address the issues within some known period without becoming completely interruptible.
Shorter development time boxes force you to ruthlessly automate tasks such as build, test, deploy, and database adjustments.
A bad technical lead or manager will tell the team what work they must take on during a development time box. 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.
If the team is consistently getting 10% to 20% of their work done, the team is over-committing. Enabling the team to consistently over-commit enables dysfunctional behavior. A good team averages between 90% and 110% of their commitments.
What else could you apply a time box to? What else has a lot of unknowns, a lot of risk, and no end in sight?
←Prev (StorySlicing.txt)(Set Team-wide Interruption Protocols) Next→
Follow @growsmethod in the Fediverse, or subscribe to our mailing list:
Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.