Question to students: When do customers know what they want?
Answer: After we show them what they don’t want.
Question: So when do we want to show them something?
Answer: As soon as possible.
There are tradeoffs in using timeboxing. It’s quick to pick up and useful as a start. Using timeboxing can often be the best approach short and long term. But it has some inherent disadvantages in many situations. These are:
- In the middle of the timebox (sprint in Scrum), you may discover that the rest of the work to do isn’t as important as what you had planned. You can, of course, swap the work, but there is a likelihood that the analysis time you spent on the pushed-out work didn’t need to be done.
- If you find you come to the end of the timebox and haven’t started some stories then you’ve wasted time analyzing them.
- If you decide not to carry them over, then by the time you do get to them they may need to be re-analyzed.
- With more stories available to do it is more likely people will open more stories than needed. This challenge can be overcome with discipline by incorporating flow into the timebox. But if you do that, you don’t really need to plan the timebox – just take the important items as they come.
If you’re ending up having stories open at the end of a timebox, shorten the timebox.
Many Scrum teams face the problem of having stories unopened at the end of a two-week sprint. This represents waste because even if the stories are carried over to the next sprint, it means the analysis is two weeks old. And they may need to be reanalyzed as well. Analyzing two weeks of stories takes more time as well. You also can’t take advantage of what you’ve learned from previously done stories. Using 1-week sprints will mitigate this problem. Quicker building, quick discovery. Shorter-term meetings. Of course, if getting customers and product owners together is not possible to do on a weekly basis then you may need to do sprints.
If you’re fully doing flow in the sprint you will discover you only need the sprint for two things
Sprints are useful for creating a vision. They are also useful for creating cadence. But cadence can be applied with or without timeboxing. Since you can release when enough value is present, you can drive from what you are going to release. If you’ve selected iterations and now have a sense of how to do flow, consider this:
Since you want to release when value is ready, should you focus on the sprint goal or on what you can release first within the sprint? Which will speed up the release?
If you focus on the release and do flow in the sprint- what’s the purpose of timeboxing?
Warning: If you are doing Scrum, don’t just abandon sprints because you are having challenges with them.
Sprints serve a purpose. Just abandoning them is not a good idea. Flow can provide an alternative set of practices, but you must:
- Have small batches
- Focus on completing what you start
- Manage work in process and accumulated risk
It typically takes more discipline to use flow than timeboxing, but the savings can be significant.
Doing this properly changes “we do Scrum but we don’t do sprints” to “we do Scrum except instead of sprints, we use flow.”
Timeboxing tends slow down interactions with customers
This is a case study by Al Shalloway
When you are building something you are absolutely sure of, you can often go off and build it and then come back to have a review by the customer. But this does add risk as even when you are sure you understand, you often won’t.
In the mid 90s, before I was consciously doing Agile, I had an important client that wanted a report. I had a history with them that they’d ask for things only to tell me later that I hadn’t gotten it right. So when they gave me their requirement I decided to mock it up with their own data.
The client was a large spa, and they were asking for a services report by all their technicians (i.e., hair stylies, masseuses, colorists, …). They wanted both the detail by type of service for the client but also totals by department. It was a fairly involved report but only looked to take a few days to do. So I got confirmation with the mock up, created the report and showed them the results feeling very confident I had nailed it.
Not at all. They didn’t like it and told me what I had done wrong. I admit I was pretty puzzled – they had seen the mock ups and I had given them a report based on that. These people were not stupid, nor not caring (they were paying me by the hour). What happened?
On reflection I realized that seeing a report’s results is not the same as running the report yourself. They looked at the mock up report, but didn’t truly understand it.
A few years later when I got into XP and about emergence of requirements I realized had I done the report in an Agile way, I could have saved the time required to mock it up and would have gotten it the first time. I should have created a report with stylist totals and gotten confirmation that was right. Then I could add revenue by department and gotten confirmation again. I could have repeated this each time, adding a little function, validating it, and then moving forward. This would have worked. And I’ve done this since and have seen it does.
Timeboxing gives the illusion that we know what to do for a few weeks. It hides the waste caused by not having more feedback with the customer / product owner. While it may not be possible to meet as frequently as useful, at least be aware there is a cost to that.