Kanban came from the Toyota Production System (TPS). The idea is that you don't stockpile parts, they flow as you need them to the production line, minimizing your work in progress. If you want to read more about Kanban and software development, here is a good article.
On this project, the product owner had already pulled together some requirements before we stepped in. Our first step was to organize the requirements into a backlog and get him to prioritize the work. Then we asked him when he wanted the next release to be ready.
We did some high level estimates and then cut the backlog in half, saying we thought we could get through half of it by the release date. That was the first step to reduce our work in progress.
I have two developers on the project, so they each picked a feature from the top of the list and got working. They did some more requirements gathering, design, and build and unit test...keeping the product owner involved throughout the cycle. They then did a demo for the product owner, getting his approval that the work was done. At this point, these features were ready for final testing (by another group), and the developers picked more work to start on.
What has really made the Kanban approach work well here is that the team was small, the work could be timeboxed, and the product owner was involved and flexible about how the work was delivered.
Like Scrum, Kanban doesn't dictate specific software engineering practices. In this case, the developers are following some standard practices that we use on other projects and I have another team member doing code reviews as part of our QA process. The final testing is being done be another group in the organization and because that decision was made after the project got started, we don't have them looped into the Kanban approach. We are planning an iterative approach to testing, so they aren't waiting for all the work to be done before they start. We'll have to work on better integration of the testing approach on our next project.
So if you have a small project (maintenance releases work well) and want to try something different, consider Kanban. I've found that focusing on one or two features at a time make the team more efficient at getting the work done.
