Most people in the agile world agree that it's good to timebox meetings. Interestingly, many in this group don't like the idea of having a time-boxed sprint. Instead, they prefer some sort of continuous delivery, such as Kanban.
So how can we explain this divide? The argument for timeboxing meetings is pretty simple: it helps keep the meeting focused and prevents it from lasting too long. Wouldn't this be good for the development process as well? Why do we see the value in timeboxing meetings, but not the development process?
I wonder if this group of people just have a sour taste in their mouths from their experience with scrum. Sprints in scrum often bring back horrible memories of day-long planning meetings and terrible estimates.
I don't want to go back to that, either, but couldn't our development work benefit from some sort of soft date or at least an overriding goal to work towards? This does not need to be a firm commitment, it simply helps in setting priorities. If we explicitly state that our goal for the next few weeks is to add feature X, we'll set aside other tasks that don't help with the stated goal.
Let me be clear — this does not set anything in stone. It is much more lightweight than a scrum sprint and does not carry the same level of commitment or predictability. It's also important to note that this would not rule out continuous delivery — code could still be released in the middle of the time box as soon as a logical chunk of work was finished.
Just as timeboxing meetings helps us make sure we discuss the most important topics, doing the same thing with our development process helps the highest priority items surface to the top and ensures the team is on the same page.
The biggest benefits I've seen from timeboxing are that it keeps us focused on our current task while keeping a little bit of pressure on us to deliver by a target date. Before timeboxing can make any sense you need to have a really good grasp on the scope of your task. If you truly understand the scope of your task you will be able to estimate the amount of work required and can therefore set a reasonable target date. If you discover something during the sprint that you missed in planning, or if requirements change, it can dramatically affect your ability to hit your target release date. The agile thing to do there would be to either adjust scope or the target date.
ReplyDeleteThe main risk I've personally observed with timeboxed sprints is that the sprint end date is treated as though it is fixed in stone. This leads to a number of undesirable behaviors such as working nights and weekends, incomplete testing and sometimes settling for an incomplete or barely usable implementation that just gets the job done.
I am currently a fan of the kanban inspired agile practices because:
1. I know I am always working on the most important task (as defined by the product owner)
2. I don't need fine-grained time estimates because delivering quality software is more important than meeting a deadline
3. When something unexpected comes up I can immediately react without fear of "missing a deadline"
This does require discipline on my part to keep working hard and efficiently every day. The product owner, and by extension the company, must also trust that I am doing my job to the best of my abilities. Working in such an environment is very stimulating to me and I get a lot of satisfaction from delivering quality software.
Hi Marvin,
DeleteYeah, I mostly prefer kanban as well, but I do think there's some benefit to a soft timebox. If not, then why do we all agree that timeboxing meetings is a good thing?
To give you an example, at work we have been doing kanban. However, we made a push recently to get a new feature out in the next few weeks. It was not a hard date, but it was something to strive for. Since then, we have been much more careful about our prioritization. We quickly pushed off the things that don't need to be done yet, and prioritized the things that do need to get done. Rather than skimping on quality, we've just been more judicious about what we'll put in as part of the feature -- we've been forced to simplify. Because it's a soft date, we haven't felt any pressure to work hastily.
I know that dates are often used to justify working overtime or skimping on quality, but it doesn't have to be that way. Strict kanban is a simple, lightweight process, but it doesn't force you to be as careful with your priorities and you can lose focus if you're not careful.