– Hari

Thanks, and your welcome! :)

You’re right in that the simple mechanics that I’ve laid out are nothing new or unique. The truth is, the mechanics of Kanban are necessary, but not sufficient. That is, if we only focus on the mechanical pull and signaling processes, we’re not going to see the real benefit that a process control system like Kanban can bring. We need to look past the simple mechanics and see how a pull system like Kanban can enable change and improvement. That’s where the real magic happens.

Again it seems to be a new word for all the basic tenets of software development and process management.

Good Summarization and Simple Writing. Thank you.

In my experience, most solo-development efforts have a natural tendency toward limiting the work in process, because most people want to see the results of their work as soon as possible. most people want to get stuff done before they move on. you may not have an explicit model of your process, or an explicit WIP limit; but I would bet you have an implicit model – how you like to do things; and an implicit WIP limit – you don’t like having more than X number of things going at once, because you don’t feel like youre getting anything done.

I don’t think the size of the team matters, really. I think the determining factors are centered around the metrics, performance, and delivery needs of the project in question. If you are doing ‘solo’ development for a customer, and the customer wants to know when features will be delivered, then a Kanban system may be appropriate for you. If you are able to focus on a limited number of requests and measure your performance for lead time and cycle time, you will be able to give better estimates of time to delivery for feature requests. … but if you’re doing a side project for yourself, or someone that is not concerned about delivery date of features… then it may not make sense to do a formal Kanban system.

(Side Note: I’ve purposefully left the metrics of a Kanban system out of this post. there are some great leading and trailing indicators that can be generated very easily, though. I’ll try to talk about that in a future post.)

Would I be wasting my time by trying to apply Kanban even if just for educational purposes?

One thing to think about when you have a situation where a developer is sitting idle is to examine what caused the situation to occur.

If the developer can’t pull in any more work, then it means that there is something downstream preventing the queue from freeing up. Typically, this might be a build up of work in the QA cycle.

So, you might look to find ways to help free up work in QA.

The ideal, as I understand it, is that the flow through the system should be continous, where each stage takes on and frees up work at the same pace, and so when it doesn’t happen that way, it is an opportunity to improve your processes.

But of course, this is an ideal and so it shouldn’t surprise if it isn’t perfect. Contrast it though to other situations. I’ve worked in departments where I was literally idle 75% of the time during certain periods of time, because everything was done in strict waterfall fashion of the negative type (not all waterfall is bad, but that’s an entirely different topic).

@tim – you know how to reach me. :)

@Tom Quinn,

that’s one of those “it depends” situations. :) there is no hard and fast rule for what you should do if a person is not allowed to do work. In fact, the only “right thing” to do, is to determine what the most economical option is for that person.

generally, we don’t want to have bottlenecks in our system… but there will likely be times when it’s better to idle a person, than have them overproducing and creating additional waste.

to get a much more in-depth perspective on situations like this, I highly recommend reading Donal Reinertsen’s “Principles Of Product Development Flow” book. It deals with the financial impact of decisions in product development, and offers various economic frameworks to manage queues and buffers, starvation and overwork, etc.

@DevelopingChris,

Good comment – that’s something I obviously didn’t talk about, but it’s important to understand. a pull system, like Kanban, does not “force” us to work via pull and signals. rather, we are all required to know and understand the rules and work within them. helping others get unblocked is often the right thing to do. once again, though, it comes down to the economic factors of your situation.