Wednesday, September 22, 2010

The Zen of Kanban

I'm using Kanban on one of the projects that I'm overseeing right now. It seems to be a perfect fit for this particular project.

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.

Wednesday, September 01, 2010

When to Multi-task

One of my LinkedIn Groups had a discussion this week about multi-tasking, sparked by an article in InfoQ. The article talked about the cost of context switching and some of the other costs of multi-tasking. There conclusion, which I generally agree with was;
Context switching between projects takes time and is a cost to the organization. The more projects involved and the more complex the projects, the higher the cost. By focusing on one thing at a time for a longer time period, individuals can work more efficiently.

So is there a time when multi-tasking is ok? The answer is Yes. Harvard Business Review had a recent article on this topic and they sited a couple instances when multi-tasking could help you.

One idea that struck a chord with me was to multi-task when you are stuck. If you're trying to solve a problem and can't make any progress, step away, go do something else, and come back with some fresh ideas. I do this a lot with work...if I feel like I'm not getting anywhere, I'll go get a cup of coffee, talk to a colleague, or even surf the internet for a few minutes. When I get back to the original task, I've come up with an idea that gets me past my roadblock. Next time you're stuck, try it.