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.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
4 comments… add one
I am following your Kanban story from the start and I’m waiting to see how it will turn out for you.
Still, I can’t resist the filling that you will end up with modified Scrum, wondering if rules you have avoided were hurting your real life agility or you just avoided them because they seamed hard. I know I do wonder for my Scrum adaptation.
I’m waiting to see what we’re going to end up with too.
Very insightful remark about Scrum. I don’t think however this is the case.
First, I never rejected Scrum because it seemed hard. I’ve rejected it because in a few places we it would bring us much trouble, time-boxing being the most significant one.
Second, I never stated I don’t like Scrum or won’t use its techniques. We employed some of them before we even started with Kanban.
Third, I don’t think our we could be called a Scrum team. I think we’re pretty far from that. Even if we have kind of iterations we still don’t use time-boxing. Definition of our iteration is “contains few MMFs” not “takes two weeks” which is an important difference.
The other thing is how much you can change methodology and still call it the old name, but to be honest – I don’t care. No matter you call it modified Scrum, Kanban or whatever, if it works for me that’s great.
By the way: thanks for this comment. Food for thought.
I personally always wanted to avoid task estimations because I could never get it right and it consumed time to estimate issue. So it seamed as pure waist.
Off course, over time I found out all hidden benefits of estimations, even the wrong ones.
Here are my thoughts on Scrum after completing the course, maybe it can be useful or you may help with your point of view.
http://vukoje.net/post/2009/07/21/Things-learned-at-Scrum-Master-training.aspx
Estimation is generally tricky. For a developer it is additional task which doesn’t add a value. The more detailed estimation you do the more time you have to spend on this.
On the other hand for a PM, or generally for management, estimation is often invaluable. Take a customer who doesn’t want to follow agile development – they just want to know what they’re going to get and when. Sure you can have agile process implemented internally but you still sell a project for a customer the old-school way thus estimation is inevitable. The same situation happens when sales folks need to know how much they have to charge client for a project.
By the way the same problem is with time tracking. From developer’s point of view it is a waste of time. For management this is very important information.