Raphaël Pierquin has scanned the first batch of session notes from Agile Open France.
Some of the attendees are excellent (visual) note takers – even notes of sessions I did not attend speak to me. Enjoy (works best if you can read a bit of French, although the glyphs also speak volumes)
Does this look like a place of work to you?
Hotel Arnold at dawn
To me neither. This was my place of work for three days during Agile Open France. The effect it has on me is hard to explain, I hope the pictures help paint a clearer eh, picture.
The new year seems to be an excellent time to think about your time management. It seemed to be for mine, and around new year I was chatting with Marc. Marc said “I’m reading a new book on personal productivity”. That made me think. Marc is one of the most productive people I know, so why would he bother reading yet another book like that. He has many, and I knew him since before he had any of those or was into, say methodology. Then, just like now, he is one of the most productive people I know.
“So, why bother?” I asked him.
“I’m productive, but I would like to do it with less stress”. I can understand that. And then I thought that by thinking about more productivity and less stress, you might achieve they opposite. I’ve met some very relaxed people. Were they thinking about stress? Probably not. Not thinking about stress may be like not thinking about a banana. You’ve probably read about research where they ask people to not think about something a banana, for instance, and it turns out they think more about it when you ask them not to…
Take Getting Things Done, for instance. The book has as subtitle “the art of stress-free productivity”. I have the book, and have tried it a couple of times. To me, it seems to have too many moving parts. Even if you take just one part, it might cause you stress. For instance, Johanna Rothman just wrote how Inbox zero is hard for her. GTD states that you should end every day with an empty inbox.
I tried that a couple of times, and after a while I could not get it to work either. In the mean time, I was stressing about it, worrying that I was not working to the norm I had set myself… Thus achieving the opposite of what I set out to do.
So, before Marc got around to explaining that The art of getting everything done by putting it off to tomorrow, and the main principles are of his shiny new tool, I came to the conclusion that it might be best for me to eat my own dogfood, and apply to myself what I tend to advise to teams these days:
Reflect, find out what works for you and do more of it (and do some experiments every once in a while to see if something else would work even better).
Trying out another methodology would not work for me at the moment, because, I might be worrying if I was ‘doing it right’. Asking if you’re doing it right is often the wrong questions to ask… And following a methodology to a T might give you more stress, and thus less productivity, instead of the other way around.
So don’t think about stress, I wish you a relaxed day!
Marc and I just got word from Jason Gorman, that our session Responsibility Driven Design with Mock Objects has been accepted for the conference that has outlawed index cards, post-its and lego: the Software Craftsmanship Conference in London, February 26.
The year is getting off to a good start – we did an iteration on the session proposal January 1st. To fit with the spirit of the conference, we’ve added a coders’ dojo to it. I look forward to going back to the BBC site, having facilitated in-house dojos before.
I’m still wondering what happened with our other proposal – the continuous integration install party. It might not have gotten through, but I guess we could run it as a BoF (possibly at the SPA conference in April, also in london).
Chris Matts is drafting comic strips on real options and financial options in the new decision coach blog he and Olav Maassen started yesterday.
I particularly liked the draft on Financial Options, it explains a number of not so intuitive financial instruments and techniques (e.g. naked short selling and futures) in such a way that I find them easy to understand, and possibly explain them to others. Not a bad thing to have in turbulent financial times. Chris’s goal is to make them understandable by ‘basically everybody’ – I encourage you to go and read it, and give him some feedback on bits you don’t understand.
In other news today:
Emmanuel Gaillot just blogged about our upcoming French Refactoring Training.
January 28 and 29 at the office of Octo Technology in Paris. This training will be in French. We ran it together in-house (also in Paris) and it worked quite well 
. The training was good fun, we did even more things dojo-style (including demos) than I normally would, and we made time for hands-on systems thinking. I think with the experiments we’ve done this year, that we’ve finally found a good way to do systems thinking with programmers. It seems to be a bit more intuitive for managers and coaches, but presented in the right way, it turns out developers find it eXtremely valuable. Surprisingly (not 
) the topic the developers chose for their diagram was not entirely technical: how too much labour turnover was hindering their productivity and maintenance.
In other other news: the QWAN newsletter is out. It has some instruction on how to do your own temperature reading, conference reports and the public courses agenda. Enjoy!
Now it is time to relax after a busy and period. Maybe I’ll finally get around to posting photos from all the conferences we’ve been to since october…
I wrote a teaser post about iterative and incremental rebranding of eXperience Agile in September… It’s been four months and almost as many newsletters since then . So time to de-tease the blog…
Marc suggested to do part of the upcoming newsletter as a Temperature Reading, so besides getting some information, our readers also learn a technique, and it helps us structuring our own reflection over the past year. It’s been about a year since Marc, Rob and yours truly sat together after xp days london to discuss closer collaboration with courses and coaching (but still as loosely coupled as possible, because we like our independence).
A Temperature Reading has five questions, the order of which you can vary, depending on the context (see Temperature Reading for explanation and the default order, I’m going to do something different here).
When I saw the proposed stages for agile 2009 last week, they looked a bit bland to me. A lot of the fun and risky stuff seems to have been taken out (musical stage, breaking acts, questioning agile). Ok, open space (I love open space) is still in there.
The 2008 conference was quite good for such a large event. Things that contributed to it were, in my opinion, scrapping experience reports as a separate track and instead having lots of experience reports everywhere as well as the breaking acts and questioning agile stages. Yes, you can have those topics spread out, but having those topics front and center (what is the first thing you see when you look at the conference? its the stages. So the first thing you see is: ah, critical thinking, wild new cideas).
If you want to support new ideas, and at the very least keep up the outward appearance that the agile community invites and supports them, leave a comment on David Andersons’ blog post “The case for an agile fringe” .
I also left one at Johanna Rothmann’s (2009 conference chair) response “I’m Disappointing Already” outlining some of the forces I’m seeing. Johanna ems to take it personal, which I think is unfortunate. Sometimes folks in the kanban camp seem to do the same – getting their sessions rejected for earlier conferences must have been very painful. The reasons for rejection were probably systemic, and it seems some of the systemic reasons have been fixed in 2008, now 2009 seems to be sliding back (and yes, kanban is now establishment, but it will happen again to new new stuff).
So, let’s stop taking it personal, and improve the system; no regression, if we can easily prevent that please – carry out one refactoring “replace experience reports stage with fringe stage”, that’s it.
That’s it for today, maybe I’ll post more later. I’m going back to XP days London (which is one big fringe lots of new ideas and critical thinking going on, and the open space is an integral part of the program, which seems to work fairly well at this scale.).
Here are my conference photos. Portraits mostly . Enjoy
Eric Lefevre and I co-organized a coders dojo at CITCON Amsterdam a few weeks ago. A coders dojo is where programmers meet to collaborate on a programming challenge, so that they can improve their skills.
The dojo takes its’ inspiration from martial arts, where practitioners get together to repeatedly practice excercises (‘katas’), amongst each other or guided by a teacher.
Coders dojos exist in many shapes. The form I often use is called ‘rand
ori’ : one or two people prepare an excercise, explain the excercise to the group and start pair programming on the excercise in front of the group, using a video projector. After five or ten minutes one of the original pair rotates out, and someone from the audience rotates in. Rotation continues every 5 or 10 minutes.
yours truly and Eric Lefevre kicking off the Randori
This is also the form Eric and I used at CITCON Amsterdam a few weeks ago. We both had posted a coders dojo on the open space schedule. I wanted to do a dojo with Mockito (a relatively new mock objects framework for java), so that I could try out a modified excercise for an upcoming training on Responsability Driven Design with Mocking. Eric wanted to do a kata on legacy code, so that he could experiment with an excercise he uses in courses.
We decided to apply some courage and try to see if we could combine the two: use Mockito to add tests to Eric’s case. We started after very little preparation: while we were preparing a heated debate with other conference attendees on how to teach mocking and what (not) to use) already started… We introduced the case and started to work towards adding a test. We found a defect in the only test present (it was not completely legacy code ), and we let the audience decide whether we should fix the test first.
The audience decided we should fix the test. We listened. Therefore we did not show how to use Mockito… Fixing the test eventually took the better part of the coders dojo, and we never got around to having the participants to try out Mockito to make a test running. Eric already summarized what came out of the mini retrospective at the end of the session.
The audience vs. Ivan Moore and …
Coding in front of an audience can be confusing at times
I would normally delete this test, guess its intention(s) and re-write the test from scratch. The reason this test was so difficult to get working, was that it was trying to do multiple things. In making the test work, it started to test even more things, so while fixing it, it became increasingly more difficult… If we had rewritten the test, we would have discovered this early on. We then would have noted the other things to test down on our ‘to do’ list, gotten a green bar quickly and then moved to the next item on our to do list.
Programming as a spectator sport. Henk Van Voorthuizen, Marc Evers watch Intently, Jamie Dobson takes notes (he was making a diagram of sorts I believe).
Having some of the most clever bastards of Europe in the room made this session extremely interesting. It definetely showed me there is ‘more than one way to do it’, and that includes refactoring and adding tests to legacy code. Some will do nothing without a test, some will use automated refactorings only (me) and then add the first test ASAP. Many of these strategies work most of the time… “Many people can be right most of the time, not all people can be right all of the time”, and that shows in a dojo. Most strategies would work to make the situation of the legacy code base better (better factored and/or more tests), but changing strategies every few minutes does not .
As Eric says, I’m sure we’ll do better next year. One thing I would try would be to spend more time at the start demonstrating and setting out a direction before rotating in someone from the audience. That way, I would expect less confusion by the participants, and more work in the same direction. This is what I normally do during courses, but the session slot had so little time that we (erroneously) skimped on it.
In the meantime, I’ll be doing some more experiments in (ab?)using mocking tools to shorten the “time to first test.”
All works on this site are licensed under a
Creative Commons Attribution 3.0 Netherlands License.
me.andering – Willem van den Ende is written, photographed and drawn by Willem van den Ende and people who are kind enough to donate comments :)
me.andering is powered by
WordPress
Entries (RSS)
and Comments (RSS) and proudly hosted by Wyrd Web.