Tuesday, July 28, 2009

Coolban: Part 2 – Meet the Column

Picasa Content
Picasa Content

The Kanban Board is usually, well, ehem, a board. However, due to our team's room excess of shelving we are left with only one whiteboard in one wall. A quick survey with facilities brought more impediments to our walls emancipation, if we remove the shelves they need to get painted, which would happen over a weekend after the approval of the project.

That put my R-Mode to the task of finding alternatives bringing the focus to the column that splits our window in two halves. The Autobots that inhabited the place had a tiny cork board right there which they graciously took away along with all the other boards before we moved in. At least I can thank them for the inspiration.

Getting a table in a column is at first challenging. I thought of using all faces and having a wrap around table. The other logical choice was considering rows instead of columns for each stage of our process. Now I had a clear picture in my head. To make it real I went raiding for office supplies and found post-it, clear tape and to my surprised colored paper.

The next decision was about the direction of the flow, either top-down or bottom-up. Top-down seems more natural, giving the notion of gravity to the board. I can even dream of the possibility of needing just gravity to get the stories done.

Each row should have a consistent design that most be flexible, uniform and pretty. So we used a color per row for the title and the kanbans (slots where the story can be placed). It came out so pretty that there was no need to specify the capacity per row. It can be seen by adding story cards and empty kanbans.

The first stage represented was obviously Code with blue. It could also be called Development but that kind of diminishes the importance of testing. For this stage we set two available slots, our team has three programmers so this will ensure pairing. It is also advised in general to set the limits below 100% of the capacity. It is proven that slowdowns happen well below 99% of usage.

The stage that followed was Testing colored in Green. With two Testers on the team it was an easy decision to allocated only one slot. It looks like the testers could take more but so far the programmers have been slower. So even if they have more capability the constrain of 1 seems more reasonable. With this we have set a limit of 3 stories in progress (WIP).

It is also important to notice that Kanban is about the whole team collaborating. It exploits the specialized knowledge of each team member in its corresponding stage. While expanding their general knowledge due to the interaction forced by the limits. For instance, a tester could pair with a developer while the other takes care of the story on the Test stage.

The next stage was Build ironically painted in red. A story that made it this far is considered very low risk for the team given that we practice CI. We gave it an allowance of 3 and decided that a story would make it here after it's preapproved by our PO. It would only leave this stage and the board once the story makes it into the integration environment, it's demoed and closed.

The only missing stage is Ready in yellow. This is the first stage in the process with a limit of 2 stories. It is fed from a cloud of stories that the team committed to get done during the sprint. It is meant to clear the stories dependencies from other teams and leave them ready for coding with their corresponding acceptance tests.

There's also an additional row at the bottom of the table colored in pink for Problems. We have no limits for this row and it's not a stage of the flow. It is there to offer visibility of team impediments. I am looking forward renaming it to Kaizen signaling ideas for improvement. But so far they feel more like problems.

At this point you might wonder where is the Done stage, where's the champagne? We are all about celebrations but a wall fill of done stickers is a luxury we cannot afford. I would consider it a waste of space regardless. To minimize space and keep the trophies at sight we are looking for a spike but they seem a bit too retro and hard to find.

There are rules or control checks to allow a story move from one stage to another. It can go from Ready to Code once it has defined the acceptance tests and cleared any external dependency. From Code to Test when it's available in the sandbox and passes the acceptance tests. From Test to Build when the PO has preapproved it. And out of the column after the story is deployed, demoed and closed.

At any given time a story might get a red or green sticker signaling a special condition. Red stickers signal unplanned events like requests that were not flushed out in the Ready stage. Green stickers are for expected temporary events like in what build number is expected to get integrated into the mainline. This increases the visibility of impediments making it easier to track and resolve them.

With the column in place the buzz started within the team. Some called it information radiator or visual board or simply kanban board. Initially I called it Kanban Column, which evolved into Colban. Once the name Colban was proposed in the team chat the first reply was "cool". And the term Coolban was adopted, because, well, it's cooler.

2 comments:

  1. This seems like an excellent way of tracking WIP. In fact, on my high performing Scrum team, we employ a very similar approach, with the addition of our "faces" on the board as well - it allows the team to quickly see who is actually working the open story (saves a little time)

    My only concern about this method is WIP limits - do you have a WIP limit, and, if so, how is this tracked on the board? How can one quickly garner that information by quick glance

    ReplyDelete
  2. Hi Scott

    Just updated the picture ... the limits are more obvious now ... the stories are sticky but they are placed in pins ... also notice the south park characters are the sponsors of the story ... i'll blog about what a sponsor is in Coolban :)

    cheers
    mike

    ReplyDelete