Kanban - A small practice project

A few months ago I completed my first Kanban project. The team was small and the introduction informal but it went well.



Background

The team comprised 5 people. A technical manager, 3 web developers and me. They managed many projects simultaneously which resulted in a great deal of task switching for the developers.

There were no detailed plans and few team planning sessions. The technical manager was able to keep track of the teams goals on the fly. As tasks and priorities changed, the team would be notified.

Three of the team members had experienced a full agile project in the past which resulted in the team continuing daily stand-up meetings. They stated that they wanted to continue using TDD but that hadn't persisted as strongly. While one of the developers had used TDD in the past, they did not use it consistently, and the rest of the team did not have any training on the technique.

Project

The project was estimated at 2 weeks and involved a UI replacement of an existing web application. A couple of minor business flows were going to change but essentially it was just large segments of the site getting new HTML/CSS. All HTML/CSS was developed by a 3rd Party design company so the in-house work was limited to verifying what was delivered and implementing the designs.

Process

We started with a little presentation on what Kanban is. Ran through some examples of how a project might be run with a focus on software projects. The whole team was in attendance along with a couple from other teams and a Director.

Feedback seemed good with statements like "We need something like this" and "I wish we could get all teams to do this".

From there we got the team together to chunk up the tasks and played Planning Poker to come up with some high level estimates on how long it would take. Each task was written on a post-it note and stuck on a white board in the left hand column ready to be pulled forward into the work in progress.

The columns we started with were:

o Backlog
o Work in progress
o QA
o Complete

Even though "everything had to be done" it was agreed that some were more important than others so a loose prioritization scheme was devised that ensured that the correct post-its were pulled forward first. The manager took on the role of adding priorities to post-its in the Backlog column when needed.

Results

Team members initially needed some encouragement to move the post-its on their own. This soon past as they were offered the opportunity to take control of the work they were going to do.

By the end of the first day we had blocked tasks. We started adding red stickies to the post-its but eventually moved them to a new blocked column between the Backlog and Work in Progress columns.

When asked, the team said they liked the process because it helped them see what was needed and completed.

A great indicator of the teams investment was the exclaimation "Wow, look how much we have got done" as they looked at the completed column full of post-its.

Since the team was switched to and from other projects the estimated two weeks was not an elapsed time but the project was released before the business needed it.

Comparison with Agile

We did take the time to estimate the stories which wouldn't necessarily be part of a Kanban project. However, there was concern about the completion time which needed some up front guestimates to allow the team size to be predicted.

Beyond release estimating, no time was spent planning what tasks should be worked in the first iteration. While it was only a two week project, in a Scrum or XP project we might have tried for 2 one week iterations. Not doing this did save us a little time and since the Kanban board continued to show tasks getting completed there was always a clear understanding that things that were getting completed.

Additionally, without iterations we didn't ever ask ourselves about what to do if we had not finished the estimated work in the iteration. Instead we maintained the column constraints and monitored how long items stayed there.

If this team ran all their projects using Kanban, the lack of planned iterations might allow some projects too fall through the net. This can be handled with simple organizational changes so shouldn't be a risk.