First time Kanban
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.infrared contact lenses
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.marked cards lenses