Kanban is a pull system. Period. In Kanban everyone pulls the task from the previous stage to another. Developers pull tasks which are ready, quality engineers pull tasks which are built, release managers pull those which are tested, and so on, and so forth. Basically every operation on the board happens that way.
Well, almost.
There is one interesting thing I realized talking some time ago with Nadia Zemskova in Copenhagen. In one situation we usually have push instead of pull operation. When? Consider a typical Kanban board where a backlog is split into two columns: long-term backlog where you put everything you’re going to build and short-term ready column or to do queue where you put just a few tasks of highest priority at that moment. The board which looks like that:
Now, what is happening here is usually a part of job of product owner or product manager: they have to choose what the most important thing to be build at the moment is and push them into production process. Um, have I just used the word push?
But that’s exactly what happens. When working with backlog we don’t just pull first thing from because first we have to decide what is going to the top. When we prioritize features we look though all of them as we theoretically have to compare every possible pair of features and say which one is more important or more urgent. We actually decide what exactly will be built in the first place. We push a bunch of features into to the top of the queue or, in other words, into production process.
From this point the whole process is pull but the first stage works the other way round. There are two differences between first stage and the rest.
First, when prioritizing features we usually work on big pool of them – actually all of them which are in the backlog. Later we usually don’t have more than just few features to choose among and very often we can pretty safely assume all of them will be completed soon enough.
Second, at the beginning prioritization is crucial part of our activity – we make conscious decisions what should go first and what should go next. Later in vast majority of situations we can use simple mechanisms like first in first out and it would work well. At the beginning we can’t go with something like that as we’d be building our software in rather random manner. And that doesn’t sound like a great idea if you ask me.
That is why we retreat to the good old push to manage backlog.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
12 comments… add one
I’ve had the same thought but eventually decided they are all the same. When I finish coding a story I push it to qa if wip limits allow or I’d I push it into a ready q between Dev and qa. But it is still pull because the downstream side is signaling the need for more work. The 1st columns are no different.
But I’m glad you posted this so it could be discussed.
Good point! Product Owners must have the ability to push work to the team. They also have to use good judgement in managing the “To Do” queue (in your example). That queue cannot be allowed to get too long or it simply becomes an extension of the backlog.
To be a little more clear on my point, your PO or Product Manager owns the TO DO column. It is that person that is pulling work into the TODO column. They can only pull work into that column when the WIP limit allows.
@Andrew – I either haven’t understood you fully or I don’t agree with you. I mean as long as we’re discussing product management part our thinking is the same. However I don’t agree that further down the line you do the “pushing” anywhere. If a developer has just finished building a feature he puts it in done subcolumn of development column but it still affects the limit of development column. The feature isn’t pushed away from development until quality engineer doesn’t pull it from there. It can happen instantly, but it can take long days – depends on a situation.
A difference in product management is that when product owner pushes a feature to the short list (to do column) it affect the limit of to do. Of course it is possible since product owner is sort of owner of this column but the mechanism is different than in the rest of the process.
The PO pulled J & H into the todo column with limit 2 just the same as dev pulled F & G into the dev column with limit 3.
@Andrew – The difference here is the pool of features you choose from. While for a developer it is pretty much whatever comes next for PO it should be a careful choice of features from a backlog.
There’s one more difference. If you look at the developer they care little about the previous column (to do) and in PO case backlog is sort of crucial in terms of choosing the right things to do.
I’m not orthodox so I don’t see a point in arguing over names but no matter how we call these two situations they are different.
Pawel, I’m with Andrew on this one. PO pulls from “Backlog” to “Todo”, I can’t see the push. If they have to chose between different tickets, so be it; whenever there’s a column with more than one ticket and without a explicit pull strategie, you’d have to chose which one to pull next. Amount does not matter.
The way I see this: PO pulls from “Ideas” (colunm which in PO’s head or in the customer’s head) into “Backlog”, and from
“Backlog” into “Todo”. From there on, the team pulls it out of “Todo”.
@Berndt – I guess I’ve just launched kind of academic discussion over definitions, and the one I don’t really want to follow. At least not unless we have a couple of beers at hand. Possibly nice German lagers or bocks in Munich :)
Anyway, let’s set a context here. I consider a situation where we have sort of big backlog, e.g. a couple dozen features, and rather small team which also means limits on the board are like 2-3 at best.
Now, if I think about any other place on the board besides backlog/to do columns I see a situation that a team pulls basically whatever is on the top.
Then, I look at backlog and see this chaos of different features: critical changes, must-haves with no super-short deadline, nice-to-haves and this functionality, which CEO asked you directly about. Whenever something new pops up you just grab a sticky note, fill it with the details of the task and add it in one of few empty spaces in the left half of the board working as your backlog column.
Form time to time the team needs to know what’s next. And in this very case product owner doesn’t come to the board and doesn’t pull whatever is on the top of the backlog. They carefully choose a couple of features among the whole long list of sticky notes.
It actually is totally different than the whole rest of the process. We may discuss over names, which wasn’t really my goal, but the point is, this part of the process is managed a very different way.
We may call it prioritization, that’s fine for me. However, it seems so similar to old-school methods. Yeah, the same which actually tells people what to do now and what to do next. Except we don’t do it up-front and for each team member individually, but we do it just-in-time and for the whole team. Anyway the mechanics is kind of similar.
If you split the ToDo column into two, Ongoing and Done, and you just happen to rename it to “Refine”, then you can see it as a pull-all-the-way. The PO pulls item into Refine, in my team we would then see if we know enough about the item to be able to move it into done ourself, if we need the PO or another expert. We can only move it to in progress when it’s refined by the team, with or without any kind of expert.
@Leif – I’m not that orthodox to make it pull by all means. Choosing features to build, or to refine, is always some sort of explicit choice done by PO. And this choice, in its mechanic, seems to me more likely to push, not pull.
It may work differently when we have a healthy replenishment scenario, e.g. there’s a backlog with a limit and it is replenished once there’s some free capabilities. In this case “pushing” or prioritization transferred outside of the part of the flow mapped by he board. From my experience, it is rather a rare case though.
The way I understand it, “pull” does not mandate mechanically taking just what’s on top of the preceeding step. It may need some analysis and thinking in order to make concious decision what exactly card to pull from TODO to DEV. It really depends on the agreed policy.
E.g. – sometimes PO may delegate decision on priorities to downstream. Whether this is a good idea or not is a different question.
Or it could be the other way around: the policy could be “always build in the sequence of customer’s request”. In this case all the pulling is mechanical.
—
In the given board I can see two points which are eligible for PUSH – the two unlimited columns: BACKLOG and DONE. So maybe someone is pushing on top of PO filling in his backlog – but I don’t think PO itself is pushing into TODO.
—
I came to this blogpost thinking more about the reasons to have separate Backlog and TODO columns (I had such question today). I think it’s often useful to have both. But Backlog is kind of unusual column, is it technically part of the kanban system? – I’m not sure… Maybe it’s used to feed it but it’s before and outside it.
@Yavor – I’ve had a similar discussion recently. What happens when we rule backlog out from Kanban board? Well, we don’t have any explicit push on the board but it doesn’t mean it’s not happening. After all how the team chooses work? Are they free to pull whatever it is according to the set rules?
Or maybe, there is some prioritization done by either a client or a product owner anyway and we just don’t see this decision because we decided to exclude it from the board?
My point is that push isn’t bad by definition. It belongs to a few places throughout the flow. The only thing we should avoid is pushing work onto the people. On the other hand push to the waiting queue is a different animal.
You raise another interesting point though, which is the one about backlog organization. I would say that it mostly depends on how the work is defined by the client. From my experience it is still a pretty rare situation when the client replenishes backlog with small batches in a regular way. More common way is throwing a big bunch of features on the team and then prioritize continuously, thus to do columns which simulate small batches of work.