Time boxes help teams develop the discipline of building small pieces of valuable software.
But time boxes are in some sense artificial. What if you finish early or late? Well, this is one of the uses for measuring velocity so we can schedule the right amount of work within an iteration.
Iterations should be as short as possible but some teams feel the need to work on bigger batches. This is usually because they have a big release mentality where they want to deliver a full feature or many features to the user at one time. But users often prefer to have change happen incrementally rather than all at once and some features are bound to be wanted more than others. But in long release cycles, all features are treated essentially the same and you have to wait for all of them to be done before you can start using any of them.
There is a term that we use called market cadence, which is the speed at which a market can assimilate new features in their software. Nowadays, with more and more companies having a strong online presence, the market cadence is nearly instantaneous so it makes sense to build for value, to always stay focused on creating the most value possible with the people you have available.
Some teams have legitimate reasons for long release cycles such as synchronizing with OEM hardware that’s on long release cycles. But most of the time we expect new features to come out and bugs to be fixed automatically and in the background, which is entirely possible and turns out to be highly cost-effective for most companies.
We want to keep iterations as short as we can make them while still producing some value. That gives us the greatest opportunity for feedback and learning, and it also gives our customers early access to features so they can start getting value from them early, and developers can start getting feedback on how to make them better sooner.
Iterations generally tend to be somewhere between one and four weeks in length, with the sweet spot for most teams being two weeks.
Some teams tell me it’s not possible for them to deliver value to their customers in a period of only two weeks, but this is generally a sign of a broken software development process.
There are forces that drive sprints to be longer and there are also forces that drive sprints to be shorter. Generally speaking, the shorter the sprint the better. One of the keys to being successful with Agile software development is being able to build software incrementally so we build what the customer needs and it’s built in a way that’s straightforward to maintain and extend in the future.
Regardless of how long your iterations are you should always strive to produce shippable software at the end of each iteration.
When teams are able to break tasks down to about four hours—half a day’s effort—they can then move to a scope box system such as Kanban and continually work on smaller tasks without time boxing.
Time boxing can be appropriate for many other tasks outside of software development. I know teams that do heating and air conditioning repair as well as system administrators who use Scrum successfully in the course of their work. Many of the ideas from Lean and other Agile methodologies are being assimilated in other industries and this is very exciting indeed.
Previous Post: « Podcast on This Agile Life
Next Post: Time Box to Scope Box »