Øredev 2010 - Day 2 - Tim Jeanes

Here's the post-sauna sea pool at Ribersborg Kallbadhus last night. This somehow seemed a good idea despite an air temperature of only 3°C. Exhilarating, but we all shrieked like girls. We also noticed that scarcely any locals were joining in...

Session 1 - Koans and Katas, oh my! - Cory Foy

This was a largely hands-on session where we spent most of the time writing actually code, so there's not too much to blog about beyond the basic principles of katas and koans.

Both are exercises whereby you hone your coding skills outside of the normal flow of day-to-day work.

Katas are essentially simpler exercises where you already know the solution: we worked on the FizzBuzz problem and Conway's Game of Life. The point of the exercise is either to experiment with different ways of reaching the solution (such as implementing TDD or BDD, or using a novel coding pattern), rather than focusing on working out the solution to the problem itself.

Koans, on the other hand, are longer exercises that are more clearly defined by an instructor. These focus on guiding you through the principles of a language or a coding practise, leading you to pick up the concepts by writing simple pieces of code.

Katas are something you'd expect to do many times over to hone your skills in various areas, whereas a koan is something you'd work through once in order to pick up particular knowledge.

Session 2 - A Practical Introduction to Kanban - Joakim Sundén, Marcus Hammarberg

I selected this session as I thought it could be particularly relevant to us at the moment. Kanban is a practice we've been considering taking up at Compsoft, if suitably modified to fit our particular needs.

We started with a hands-on exercise where people simulated the various departments of software development. In this task we were just sticking different coloured dots onto post-it notes, and the point was to experiment with different ways of working to ensure there aren't bottlenecks, that people aren't idle, that the customer is happy with the final result, and that no one feels too pressured.

The two main principles of kanban are to work to an agreed capacity, and only to pull work from the queue when it is required.

Limiting work in progress minimises risk: the shorter your lead times between starting work and getting feedback, the less unconfirmed work there is in the system. The more unchecked work there is, the more potential there is for that work to be wrong - either buggy or just not what the customer requires any more. Work in progress should be limited to the capacity of the team. Working with smaller units of work can help to keep the process time streamlined. Where possible, having a cross-functional team can minimise bottlenecks.

The amount of WIP in a software context is difficult to track as it's not visible: there are no stacks of half-built physical goods sitting around. Thus visualisation is critical. Post-it notes of the wall to track the volume of tasks and where they are in the system helps everyone to see where the work's building up, where the bottlenecks are and hence where the waste is.

Though SCRUM incorporates many kanban principles, it allows for more flexibility than strict SCRUM. Often it can be impractical to set a fixed sprint time-box for a portion of work, especially where (as we often find) we're juggling many different customers simultaneously.

A general principle (though not a hard rule) is to focus on finishing work rather than starting new work. Even though it all has to be done sooner or later, it's generally beneficial to help get items that are already started finished, rather than bringing more unstarted items into WIP. The customer appreciates this as it means the higher priority tasks get delivered sooner, rather than there being more lower priority tasks in the pipeline.

Moving post-it notes representing tasks between columns identifies bottlenecks early and can prompt appropriate reaction. Different coloured notes can represent whatever you want - be it different priorities, different customers, bugs versus features versus change requests, etc.

Each department's columns has a WIP limit. Those these can occasionally be broken, this should always at least prompt a conversation about what the underlying problem actually is. It's also worth including the customer's acceptance as a column, so they can be prompted to keep up with their involvement in the task.