The first joint AgileScotland / AgileNorth mini-conference via skypecast happened last night (April 16th) and was a great success! We had 12-15 attendees for the whole two hours, and we were entertained by seven short and very varied sessions, four of which were supported by “slides” via HTML.
Aspects I liked:
- Some sessions provided visuals by means of HTML “slides” hosted by Paul Wilson; this was a good format, easily accessible to all, and helped to overcome the lack of other visual cues.
- The presenters put their photo on their first slide, which really helped me visualise who was speaking.
- Having a number of very short sessions made for a lively and varied evening.
- Leigh Mullin did a great job of chairing the evening’s activities, and sent encouraging chat messages to the presenters during our sessions.
- Everyone put themselves on mute during the presentations; the levels of discipline and courtesy were extremely high.
- During and after each session the group sent questions over Skype chat to the speaker, which the speaker could field as he wished; I kept mine in a queue and answered them at the end, but others did differently, and both approaches worked well.
- Charles Weir opened his session up as a discussion, and that worked surprisingly well too.
Some areas in which we might learn from the experience:
- Some speakers (me in particular) took a lot longer than their advertised time; next time it might be worth trying fixed-size 5-minute slots, plus 5-minutes for discussion, and rigorously enforcing that timetable.
- Two hours is a long time, particularly when one has no non-verbal feedback; perhaps 90 minutes would be long enough.
- It was hard to follow those speakers who hadn’t provided visuals; we should probably make them mandatory.
- During the planning stages we had floated the idea of holding open some kind of chat room, but in the end we relied solely on one-to-one chat messages; in future it might be beneficial to enable all attendees to see the questions being asked.
(You can read other attendees’ comments on our mailing list – NakedAgilists)
Overall this was a very enjoyable evening, and I’m very much looking forward to our next one. Hats off to Clarke, Adrian, Paul and Leigh for brilliant organisation.
Tomorrow night sees the very first joint AgileScotland / AgileNorth mini-conference via skypecast! We have almost a dozen short 2-10 minute presentations in a packed 90-minutes – including my retelling of a testing dilemma and developing a sense of urgency from this blog. See the NakedAgilists Yahoo group for joining instructions.
This year my stay at SPA2006 is limited to only one and a half days. Nonetheless I plan to attend some interesting sessions, and in the next few posts I’ll describe my impressions of them. The first of these was Thinking for a Change:
In this 3-hour workshop Pascal van Cauwenberghe and Marc Evers led us through the construction of two of the five Theory of Constraints Thinking Tools. We divided into groups, such that each table comprised one “customer” – someone who had a problem to be solved – and a number of “consultants”. The objective was for each group to build a Current Reality Tree for their customer’s problem, and then to build a Future Reality Tree for a possible solution. The problem on our table was set by Emmanuel Gaillot, who wanted to understand some specific behaviour of the managers in an organisation he had worked with.
Now, I had already read the book Thinking for a Change, and frankly found it quite disorganised. Pascal and Marc had also found the same, so for this workshop they had picked through the book and defined a step-by-step process for building CRTs and FRTs. They took us through this process just-in-time, at each stage showing us the next step using their worked example, and then giving us 5 minutes to perform the step on our own problem. This made for an absorbing three hours, in which we actually got to try the whole process from end to end on a real-life situation.
Unfortunately our group got a little bogged down at various times, mostly due to our particular problem being way too large to solve in a dozen 5-minute chunks. Nevertheless we had fun, and we gained practical experience of building a CRT and a FRT.
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.
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.
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…
My Jidoka and Hexagonal Architecture sessions have been accepted for XPday Benelux 2005 in Rotterdam this November. Looks like a great programme – shame I won’t be able to attend everything!