Should I Kanban?

Recently, Bryan Morris sent me a link to his paper Yes We Kanban! That was timely, because I’ve been asking myself, should I Kanban?

I have been following an Agile Scrum approach on two projects so far, with two different employers. In both cases, I started off with physical cards on a physical board, the daily 5-minute stand up meetings in the hallway and a 2-hour long sprint planning meeting every other week (two hours is not enough time unless the backlog is groomed and pre-prioritized). On one of the projects, the backlog became too large and I started to track the cards in a spreadsheet. After about 10 sprints and hundreds of additional cards in the backlog, I had exceeded the capacity of the visual basic scripts I had written to update the different sheets and, it would crash too often to be usable (I wanted all the projections and tracking to be automated). Finally, I migrated to an on-line system called Jira, using the GreenHopper Scrum board. The on-line system has allowed me to keep track of hundreds of cards, and it simplified my reporting to upper management so much that I would not want to do another project without it.

I will talk about two difficulties I encountered. The first one is in getting certain types of cards to close (more later), and in getting the sprints to actually burn through the cards we commit at the start of the 2 week sprints. Many of the sprint burndown charts look like a parabola starting at 30 story points, peaking at 50, and ending the sprint at 30 again… or 25 when we’re not too distracted by unplanned work. Despite this apparent lack of control, the relevant work got done and we taped out ahead of schedule, under budget, and we sailed though product integration! But there was too much unpredictability for my liking. This made me wonder if I should have chosen Kanban rather than Scrum. Coincidentally, that is when I heard about Bryan’s paper.

There are things I’d like to solve with the way I handle the process, regardless of Scrum or Kanban: some types of cards linger, and the fact that burndown charts look like an upside down parabola is very annoying. It seems these are two symptoms of the same cause: the lack of criteria for letting a card enter the sprint. Over time I got better at coming up with a definition of “done” (integration server, self-checks and coverage implemented, etc), but it seems I am not as good at defining when a card is ready to enter the system: many cards enter the sprint with good intentions, but they need further breakdown before work can be done (i.e. the work should be to break down the work, not attempt to do all the work).

Also, there are cards that are placeholders for work that gets done later. I create those cards ahead of time in an attempt to predict the total amount of work for the project. This helps us plan for resources, but later on when a person is assigned the actual work, I don’t necessarily review the cards I originally created… and when the work is finally assigned, some engineers prefer to do their own planning and write their own cards. Failing to obsolete the placeholder cards bloats the system. Like everyting else, this needs attention, and yes, full time management on my part. Because I still like doing the work rather than planning it, I have to become even more efficient at planning, to make time for the actual work!

In Scrum, I have converged to story point estimates that match the number of days but I insist that the work must be estimated in a relative way, not in an absolute way. I usually use 1, 3, 5 or 10. We have learned that higher numbers only mean we’re not ready to start the work. Stories are usually assigned to a person with up to 10 points per 2-week sprint. So in Scrum, I assign a work load over a fixed time period, and I load each person with up to 10 points. In Kanban, there is limit on the number of items per column, and each column represents a work queue (design, implement, verify, etc). It looks to me that Kanban is closer to the spirit of work queue management which I discovered in reading The Principles of Product Development Flow by Reinertsen, than Scrum. But it also seems to me that a column could represent either a closely knit team or a single person (e.g. a single person handles all the physical design work items).

So circling back to the paper, I found it to be very descriptive of how to apply Kanban to ASIC/FPGA development, with lots of examples and good advice. It describes the metrics Kanban provides to measure your performance, and I could relate to the stories told in the paper. It will serve as a good basis for when I implement Kanban.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: