In Part One of this blog I discussed how we set up the kanban board and the process we used to try out kanban for the first time on our own internal Timesheets application. Here is what we learned about the process.

The first thing I learned, as Scrum Master on the project, was that there was a major downside of not having the planning poker session. We came to a story where the developers got totally confused and actually were working on a completely different story to the one they thought they were working on. In discussions we would reference them with the story card number, but the story the developers were talking about was a different one to what the Product Owner was looking at. The 2 stories were very similar, but this led to a few hours of waste for a pair of programmers trying to analyse what they were supposed to be doing. It wasn’t until the pair swapped the next day that the new person on the pair realised something was wrong. This is a great advert for paired programming and swapping members of pairs every day, however the problem could have been avoided in the first place had we done a proper planning session and discussed each story together as a team.

Kanban really helps to see bottlenecks, and our bottleneck was with UAT. Unfortunately we didn’t have anyone doing UAT until near the end of the 3 week cycle. This meant that our UAT column had up to 15 stories in it at one stage, even though the column limit was 2. This couldn’t have been avoided as nobody but the product owner or someone he could assign to the project could help out in UAT. I think this proves that if your UAT is done by someone with limited time to work on the project, then limiting the stories in the UAT column is not practical.

We also noticed early that stories were being held up in ‘Needs a Fix’ and not being pushed through to testing quick enough to keep the tester (myself) busy. So bearing in mind the principle of ‘developers need to help testers out when there is a bottleneck in testing’, I got my hands dirty in the code and helped fix a couple of bugs. In an ideal agile development team, testers would be able to jump into development and help them out when there isn’t much testing to do, and vice versa.

Originally we thought that having about 3 active cards marked on the board with the date they entered the ‘Ready for Dev’ column would be enough to get a picture of how long our lead time was. However we found it often got confusing. Half way through the iteration I started marking every card as it entered the ‘Ready for Dev’ column, and this worked much better. I then marked on the board the time it took for the quickest and slowest stories to get completed, plus the median of the stories currently ‘active’. This gave us an accurate reading of how long a story should take to travel to the ‘Done’ column, and gave us a real time view of how long it was taking our current stories compared to the average for that iteration.

Having no story points worked great for an internal project like ours, but for some of our clients, this won’t work, especially the clients that we bill per story point. In future I would strongly suggest still having a planning poker game, but maybe just 5 stories at a time, once they are done, do the next 5 stories. This keeps the planning sessions short and the stories fresh in your mind when they are picked up. It might mean doing a planning session every couple of days, but they will probably only last 15 minutes instead of 3 hours like they sometimes seem to drag on for.

Otherwise, the process has worked very well. Limiting stories allowed in the columns has pointed out where we had bottlenecks and helped us to rectify them before a major problem was caused. I also especially liked having a limit on the ‘Ready for Dev’ column as it helped to prioritise what the developers would work on next, helping to get the main stories done first and some of the nice to have stories at a later time.

To bring kanban to a paying client would be more difficult without having a proper planning day with good estimations. I think the best way for us to accomplish this would be just to change our current SCRUM process slightly to add the column limits idea of kanban. Maybe this means we will then be using a hybrid of processes, a scrumban if you like.