I had read about Kanban as applied to cars by Toyota as part of making something physical but not really as something you could apply to software development. The principals do seem to make sense when applied to software development
- try and produce a steady amount
- eliminate errors that will need to be dealt with later
- produce only what is needed
- let the production pull the resources it needs rather than be pushed at
Lots of the ideas seemed familiar/evolution from extreme via scrum. Seemed Benjamin was moving from an unproductive scrum environment towards trying to create a more dynamic and effective process. So he was constantly evolving the processes and systems his team was using towards a more efficient system that could more adequately estimate how they were going to complete. He also had some good examples from some rather ‘broken’ sounding large organisations he had worked for.
- Having to do demo on the fire escape to avoid the agile hating boss.
- Testers who were paid by the test, so producing a lot of tests of not much value.
- Even applying systems you might use at work to your kids problems. Kanban dad?
He was interesting as well on ‘people problems’. One example he gave was a list of tasks that had to be code reviewed by two programmers. They were mostly still to be done a week later. When he asked the reviewers why they hadn’t reviewed the code they replied that they thought the other reviewer looked very busy. :)
Cue some getting to know the other people in your team/organisation activities.
He was also keen on paper systems, he would rather track progress by moving post-it notes on a grid on the wall that everyone can see instantly. Rather than by using a fancy computerised tracking system. He found post-it’s easier to adapt and if he wanted to change the way they ordered the process it was just ripping some masking tape off a wall and moving post-its.
Benjamin must be doing wonders for post-it sales. He seems on a mission to paper the worlds walls with them :)