jidoka at SPA2006

I’ll be running my trusty Jidoka workshop again soon, this time at SPA2006 in March. I ran the same session at XPday in London last November; see feedback from Lasse.

Lean manufacturing is based on two pillars: Pull and Jidoka. Agile methods focus most of their attention only on Pull: customers pull features or user stories from the development team, and the development team carries out every task just in time and without building up inventory. Jidoka – the policy of stopping the production line whenever a fault occurs, and then fixing both the fault and the cause of the fault – has been largely forgotten. Jidoka is what keeps value flowing fast through the process, iteration after iteration. And yet there are no published studies or collections of Jidoka practices as applied to software development.

The session’s objectives are to learn about Jidoka on a production line, and to discuss its application to adapting a software development process in a learning organization. Participants will play a Jidoka Game which demonstrates the beneficial effects of “stopping the line”. The group will then work together to describe, discuss and discover “jidoka moments” – points at which software development projects are, could be or should be stopped in order to prevent faults passing downstream. It’s a fun session, and I hope informative too.

xpday5

I spent another enjoyable day at XPday5 yesterday. As always, it was great to meet up with old friends and colleagues, although I never seemed to have the time to get into real conversation with anyone!

I was there to run a new version of the jidoka session, this time including games and a working group. The new format was great fun, and I’ll be running it again at SPA2006 next spring.

My main highlight of the day was Tom Gilb‘s introduction to ‘quantifying any quality.’ This was a compressed introduction to the Evo method’s approach to requirements, in which projects set numeric goals for everything from usability to maintainability to innovation. I was stunned by this approach, and spent some time over lunch quizzing Tom further. Tom’s thesis is that most of what we call “stories” or “requirements” are actually solutions to deeper business and user needs. Tom ferrets out those underlying needs, quantifies them, and then leaves the development team to decide how best to meet them. This chimes well with some of my experiences, so I’ve vowed to study Evo in detail during the next few months.

reflections on xpdays benelux 2005

Last week I spent an enjoyable day at XPdays Benelux in Rotterdam. I ran a couple of sessions, attended a couple more, and met up with friends old and new. Here are brief recollections of the highlights in my day…

The day began with every presenter offering a 1-minute sales pitch for their session. I got to do two: one for Hexagonal Architecture and one for Jidoka. A minute is longer than you’d think, and I’d guess that most of the pitches were over inside twenty seconds. I decided to be a little different, so I had everyone stand on one leg – hopefully to demonstrate that the standard layered architecture model compromises agility…
Continue reading

AgileNorth 2005 retrospective

The conference was a great success, with over 50 attendees! Many thanks to the committee (Phran, Katie, Ant, Donna and Paul) for all their hard work organising everything, and to the various speakers for giving their time to create such a full and varied programme. We have collected feedback from the attendees so that we can ensure next year’s event is even better.

Here are a few thoughts on sessions I attended…

What is Agile?

The day began with a re-run of my overview of agile software development. After discussion with Brian Button I tightened the schedule and the process, and I thought it went very well this time. The variety of topics raised by the audience was challenging and encouraging, and of course we only managed to scratch the surface…

XP Teamwork – a goldfish bowl led by Charles Weir

The original descriptions of eXtremeProgramming suggested that a project’s staff would play only three roles: Developer, Coach and Customer. But in reality, the role of Customer is very hard to fill using real people. In this session the group discussed the difficulties of setting up an effective Customer role, using a format in which only those sitting in the four central chairs may speak. The topic swerved around depending on the mix of people in the chairs at any time, and I think some good insights were gained. Rachel Davies contributed a great deal from her experiences coaching XP teams.

Test-Driven Development – a demonstration by Brian Swan

In which we began the development of a blackjack game, with Brian driving and me pairing. We ran out of time, but still got some basic techniques and functionality in place.

Refactoring – a workshop with Ivan Moore and Duncan Pierce

Duncan and Ivan presented a piece of Java code that included loads of smells, and the group identified them and refactored to remove them. There was lots of discussion among the more experienced members of the group; some wanted to keep the design naive, while others wanted to introduced new classes to represent some of the more obvious domain concepts. Very enjoyable.

Finally, note that Andrew Beacock has also blogged about the day.

Off to Germany

Like Willem, I’ve just received news that I’ve had a workshop accepted for XPdays Germany in November. As with all of my current exploits, this workshop will involve looking at the connection between lean principles and software development. In this case we’ll be mapping software value streams to figure out how much time features spend sitting around waiting in various states of development on their way to giving value to a real user. Should be fun!