Øredev 2010 - Day 2 - Tristan Smith

Koana, Katas, oh my!
(Corey Foy)
Corey started with a discussion of the differences between professional Software Development and other professional careers, pointing out that other critical jobs such as Doctors and Firemen don't do their learning on the job.
His point, while acknowledging that not all software is life critical, but certainly the cost to a developer of major failure with a new technology implementation on a project for example could be the loss of their job, a pretty critical issue for them.
The differences between Koans (a focussed learning exercise) and Katas (honing skills to problems with known solutions) were expounded with illustrations from martial arts. Shu Ha Ri learning was also talked about where Shu is learning by example, following steps thoughtlessly to learn a new thing. Ha learning is where analysis of the subject, why am I doing this, what if I do it an alternate way and Ri learning where the subject is instinctive. In martial arts, this would be where you know the katas and karate moves so innately that you could automatically defend yourself for example.
Other than the knowledge drop, the majority of the time was spent working on some katas where we in pairs solved solutions such as Fizzbuzz and Conway's Game of Life using Test Driven Development. Deleting our code after each iteration and starting again from scratch each time.
Interesting too was that the room had maybe 15 people in it from all language backgrounds and yet everyone managed to work together and storm through the problems.
A practical introduction to Kanban
Kanban is a Japanese methodology for process improvement and control.
It originated in the Toyota Manufacturing Factories after research into the Supermarket model of demand controlling the rate of production.
Kanban has some key principles:

• Limit the work in progress.
• Stop starting (new work), start finishing. (Using a queue where only one task is taken when the previous task is done.
• Visualise the flow of work so that bottlenecks and other issues are easy to see.

After a brief overview, came the guys initiated a dot game where 8 people were divided up by job role. A post it note on the table had a dot based design and different coloured dots were given to the different roles. Business Analyst, Designer, Developers, Tester, Project manager and Customer.
http://www.netobjectives.com/the-dot-game
In the first iteration the process was defined, each person would do a batch of 6 instances of their job (putting their coloured dot on the post it) before passing the batch to the next person.
What quickly became clear was that there were bottle necks and dependencies that led to undue pressure felt by people, some people were kicking their heels while others were slaving away. When the first batch was complete, the customer rejected all the work.
None of the team ever asked for feedback from the customer, everyone had their own interpretation of the spec and the feedback loop was too long as there was no feedback until the entire batch was complete.
Two more iterations of the exercise allowed changes to be discussed which brought customer feedback into the process and more individual informed involvement.'
It was a good way of highlighting some of the key strengths of Kanban, the problems experienced in the first instance where caused by too many items being processed, inefficiencies due to lack of visibility and slow response to those inefficiencies.
Some of the other points made along the way:
Context switching (limited by the 1 item at a time flow) tends to result in about a 20% loss in time per item, this has a major impact if you're repeatedly having to context switch. Some research they pointed at showed that context switching equates to a 10 point drop in IQ.
Work in progress also includes items that are complete but have not been released yet, or not been taken up by the next department (Dev > Testing > Customer Acceptance).
The higher visibility of problems means that bugs for example have a number of extra costs, there's the delay downstream for the time Testing takes, then the context switching tax of going back to a previous problem domain (and possibly project).
Catching issues earlier leads to a lower cost to change in requirements, making it easier for customer change requests to be processed.
Shorter lead times mean greater motivation, the higher perceived (and actual) productivity leading to a positive feedback loop.
Moving on to the Kanban board, tasks are added and prioritised with colours showing the task type or scope (bug, feature, maintenance).
Avatars appended to the bugs as the tasks move across the board through departments make it obvious who is working on each task. Tasks are pulled from the list, and pushed to the done / next stage by that person.
As each task gets moved, date entered can be added to make it easier to see the lag times between work coming in and being done. Deadlines can be added as well as extra data such as TFS Item Ids.
Each department has a specific Work in Progress max task number so that teams are limited to their capacity.
http://www.kanban101.com
Image from mountain goat software
Some really useful information given, the slides of which we'll put up when we get them. We'll certainly be looking to implement a lot of the key features of Kanban in our current Scrum methodology, it fixes some of the issues we sometimes find where inflexibility of times / tasks can be an issue.