One of reasons why I like Kanban so much is because it doesn’t force you to formalize your process. You don’t need to set strict time-boxing for example. If you want to – fine do it, but if it doesn’t suit you fine no one forces you.
If you happen to work in environment where priorities change very often, and we do work like that, you’re likely to reject time-boxing since this approach doesn’t reflect process you follow. We didn’t want time-boxing and this was one of main reasons we rejected Scrum initially.
Iterations were bad. At least that’s how we thought.
After some time I realized we basically had iterations. Sort of. We didn’t set time constraints like “we’re going to do features which fit 2-week period.” But we started grouping features into releases like “stories A, C, E and F which are top priority at the moment are going into the next release.” It was taking as much time as needed to complete a group of stories so it wasn’t time-boxing really but still a small and (mostly) closed set of work items to do.
Why we started doing that?
- To make releases easier to plan. As I saw sticky notes moving from the left to the right I could estimate when we were going to deploy new set of features in production environment.
- To have more frequent releases. With no real release planning we ended up with not very frequent deployments. At least not frequent enough for me. When we added some planning we set some boundaries for our work and made it easier to deploy more frequently.
- To make version control look less like hell. We don’t use distributed version control so every time we want to release we need a branch in our code repository. If we had a few branches actively used bugs would have to be fixed in each of them, so we’d like to avoid having plenty of active branches. If we had only one branch and we wanted to release only completed features, leaving those under development aside, it would be quite a challenge. Having small feature sets going into development and adding a branch every time we start new set brings an order to version control.
So we ended up having pseudo iterations. Not as strict as in Scrum but still. I can’t say how long the next iteration would take but it most likely won’t take more than 3 sticky notes. I can’t promise I won’t add anything to the scope during the iteration but if it happened I had good reasons to do it (e.g. adjusting the app which would stop working after deployment to take latest case).
Seems like iterations aren’t such a bad thing after all.
Check out the whole Kanban Story.
Leave a Reply