We brought one exercise, to be carried out by pair programming. A pair can choose what ever programming language they want to use. We try of course to get an interesting variety of languages to learn from. We ran three 40 minute timeboxes. Each timebox consists of 25 minutes for actual work, and 15 minutes reflecting (about three different solutions presented on the projector accompanied by discussion). Some people switch pairs from one timebox to the next, so they can get hands-on experience of trying to solve the same problem in different languages. The goal of the exercise is not to finish first, or have the cleverest solution, but develop a solution that is idiomatic in the language one is solving it in, so that we could compare notes afterwards.

This time we had three pairs working in smalltalk (cincom smalltalk as well as squeak), two pairs in ruby, two java, and further pairs in Scala and Haskell.

A few pairs wrote examples using Rspec or Scalaspec, most pairs wrote ‘classic’ XUnit style tests. Some worked completely outside-in, other bottom up, and quite a few from the middle outward (me and my pair amongst others).

Some things that struck me:

• at least one of the smalltalk solutions I saw did not strike me as very idiomatic smalltalk (admittedly, the presenter said it needed refactoring, so they went for make it work/make it right).
• Nat Pryce noticed that collections were processed easier (and with less code) in the Haskell and Smalltalk solutions than in Java.
• The smalltalk pairs were the first ones to finish setting up their development environment and getting to work (Rob did a timecheck, the smalltalkers were the only ones working on the problem already). Having an environment that contains almost all the tools and libraries that you need gives a big speed boost at the beginning. What was more striking still was that all smalltalkers used environments they just installed and had not used before; I installed squeak last weekend, the others were using a fresh beta version of their environment.
• Many people had not seen (much of) haskell/ruby/smalltalk style of iterating over collections using blocks/closures, luckily these idioms seem to be trickling down to Java and C#.

As with the previous instance of Flying Horses, the Haskell pair was moving towards a complete solution the fastest. This may be because the exercise we use seems to find itself in Haskell’s sweet spot (parsing and manipulating data).

On the whole, the level of engagement was pretty intense (about half the participants continued working through the breaks, even though we emphatically tried to get them to stop ), participants said they got to see some very different ways of solving a problem from what they knew, so they came out of the workshop with puzzles to investigate further.

As one participant mentioned, code presentations work up to a point. They show what a pair has done, but it is hard to see what steps they have taken to get to the solution. Seeing the sequence of steps (and experiencing it) when you are part of a pair (especially with someone you don’t know) is very valuable. I’m interested in suggestions for getting more of the sequence of events (rather than the solution) out into the presentations.

We have tried letting people work with task lists and presenting from there (works somewhat, but may cause pairs to loose to much time on their small design up front).

Let a thousand languages bloom Below are the flipcharts summarizing some of the things people learnt from the workshop.

I planned to write individual posts about new and upcoming workshops, but the rate at which we get invited and accepted to conferences this fall outstrips my ability to post new entries I have to post now, before the conferences themselves are over… I hope you’ll join us for at least one of these. We’ll be doing some hard-core programming workshops as well as more enterprise and facilitation oriented sessions this fall.

First up is Scan-Agile next Thursday and Friday in Helsinki, Finland. Marc already wrote about our Story Testing workshop.  I’m also very much looking forward to participating in the Scan-Agile Open Space, which now has its’ own day.  The main reason for me to return to Scan-Agile this year, is that last year it had very strong participants (and presenters, but good session organizers are only part of what makes a conference worthwile). Having my own unit tests ripped to shreds by critical participants was interesting and valuable. So I’m glad this year all participants get more space. We had some discussion on Twitter about ‘is kanban a failure mode of lean? (and what that means if it is so)’ that merits more than 140 characters… should make for lively open space as everybody involved in that discussion will be there . If I haven’t motivated you to join us, check out Vasco Duarte’s series of motivational posts about Scan-Agile.

Next up is the Practical Product Lines conference , October 20 and 21 in Amsterdam, Netherlands. There we will be hosting a value stream mapping workshop, as described by Marc. We decided to try out more conferences outside our regular schedule of agile conferences – preaching to the choir is fun, and helps us improve our understanding, but going out into the world and sharing what we’ve learned is at leas as valuable. We thought it would be interesting to bring our understanding of value stream mapping, and take participants’ experiences with product lines, should provide an interesting mix.

Freek Leemhuis of Devnology asked us to send in some proposals for the Devnology community day, saturday November 7 in Baarn, Netherlands.  We did, and they chose three of QWAN’s sessions for the program:

Refactoring to concurrency (with Scala) grew out of a series of commits I did for a product I’m developing with Marc, micro-ISV style. We needed some background processing to make our application more responsive, and I wanted to take small steps, be sure that it worked and have everything covered with tests. So I first refactored, until introducing concurrency was just a one character change. This session shows you how to do the same thing, with scala or another language.

Flying Horses – cleaner code in other languages. This session was inspired by a dojo description from Emily Bache (I don’t have the link handy right now, will insert it later). Rob ran with it and tried it out at Agile Open Holland last month. We’ll bring an application written in one language, everybody gets their laptops, a pair to program with and translates that to their favourite language. At first as literally as possible, and then make it ‘more like their language’. Then we will discuss what makes code, e.g. pythonic, javaic, C-sharpish etc. based on the examples we just created.

Give your code some love is a demonstration (a series of prepared katas) of us doing tiny refactorings on code that looks allright at first glance. Tiny refactorings then show that there are quite a lot of things we can do to make the code express its’ intent better. This session was heavily inspired by Ivan Moor and British Mike Hill ’s Programming In The Small workshop at the software craftsmanship conference in London earlier this year.

Jfall, conference of the Dutch Java Users’ group, November 11 in Bussum, Netherlands, sees Rob and me doing TDD As If You Meant It, inspired by Keith Braithwaite’s session of the same name at, again, the software crafsmanship conference in London. Keith kindly gave us permission to reuse the name. We are happy to see more people applying unit testing. Very few, however, seem to be really doing Test Driven Development. In this demonstration we hope to give the audience a taste of what test-first programming can do for you.

Xp Days Benelux, November 23 and 24, Mechelen, Belgium I already described Retrospective Hero with Nicole Belilos of Task24 and Agile Politics – (re)discover the politician in you at XP Days Benelux with Emmanuel Gaillot of Pyxis

and Finally, XpDay London, December 7 and 8th where I’ll be pair facilitating the Open Space with Rachel Davies.

Wille Faler asked on Twitter earlier this week about how people who go to conferences a lot do work. All of the conferences above are one, maximum two days, that leaves plenty of time in the rest of the week to do ‘actual’ work.  The other thing is, writing is a poor medium (for me at least, even though my blog does seem to travel reasonably well these days) to show our passion for software development, going out to conferences helps us connect with other people who are equally passionate about our profession. And sometimes this then leads to actual work. Which leads me to the following:

Shameless plug:

At the moment I’m looking for a new project to work on, either as a developer, agile coach and/or project leader. contact me if you know of a place where my skills would add value. Also, all of the sessions above and more are available as customized in-house training.

Sandra, one of the product owners, explains her point of view, Serge listens intently as facilitator

Now, lets' hear the second group of product owners, with their position

Nicole and I thought it would be fun do design a simulation game around facilitating retrospectives. At first we came up with a sort of board game, but after some brainstorming we thought a role-play would work better – our board game was turning out to be a bit too simplistic for our taste.

These are the benefits we proposed for our session at XP Days Benelux 2009, November 23/24:

• Learn new techniques by applying them to a simulated real world situation
• Experiment with techniques you already know – do something different with them
• Hold an emergency retrospective to ‘get to the bottom of it’ and come up with sustainable solutions quickly.
• Get some fresh ideas to do group reflection on emergency situations and longer timespans

At XP Days we have an hour and 45 minutes, for the try out at Agile Open we decided to see what we could do in a 60 minute timeslot to get as much feedback as possible on our game ideas. For the XP days version we were thinking about playing two simulation rounds, in which the participants get to deal with a) facilitating during an emergency situation and b) facilitating a retrospective over a longer period (weeks or months).

We were most curious about facilitating in an emergency; what we expect to learn from these simulations as hosts is observing facilitators ‘in the wild’ under controlled conditions and seeing how they behave, and what techniques work in which circumstances (we have our preferences, but they do not necessarily end up in the simulation). For the longer-term retrospective part we still would like to do a trial run. contact me if you’re interested in hosting it.

Therefore we designed a role play that happens in a Bank, something went terribly wrong and after the facilitator comes in on a monday morning he or she is asked to facilitate a ‘hero retrospective’ : find out what went wrong quickly and get the group to agree on some actions.One or two participants play facilitator, while the other participants play roles like product owners, helpdesk boss, development team and systems administrators. We give everybody an overview of the situation, and then each role receives an envelope with a more detailed description of what happened from their point of view. This leads to a group situation where everybody has partial information, so one of the challenges for the facilitator is to surface all the relevant information quickly. (I won’t say much more, because I fear that would spoil the simulation in case you come and play it…)

We creatively brainstormed the situation and roles based on our own experiences. And it worked. One of the players asked me ‘does this happen?’ about something that I experienced during a meeting; some of the assignments and poses of the roles seem far-fetched, but things get political when people have to divide resources, and as a facilitator you’d best be prepared to not be surprised about that

You might say ‘that is not a retrospective’, and you may be right; that is something that we want the participants to figure out and discuss in the debrief. And at Agile Open they did. Participants found that for effective facilitation you need to find a technique and style that fits you, the participants and the context. Some ‘participants’ preferred a ‘businesslike’ style, focused on only content, while others seemed to prefer also getting the mood of the people on the table.

In writing this sounds like knocking down an open door, but the emergency role play was pretty intense, with at least one facilitator behaving differently from his own expectations. We really did manage to create a stress situation .

Now we have to pick up the pieces and figure out what to do next with the simulations and the workshop. The participants gave us a good amount of useful feedback. The roleplay worked well, so we are going to keep that, but how to fit it into an overal workshop seems to, ehh, depend . We introduced two techniques before the simulation, and encouraged the facilitators to use one of those two. Next time we may only chose one, and see how that compares between groups, or alternatively (especially in an in-house course where we have more time), start out without a specific suggestion, roleplay and learn from the debrief, maybe explain a technique and try again, and see what difference that makes.

In reviewing the session for XP Days, Pierluigi Pugliese suggested we add observers to the list of roles, and give them specific instructions. That seemed to work well.

Jorrit shares his observations with the group

Since we are operating a kind of pull system for workshops, we asked ourselves beforhand: what do we want to learn from the try-out (does the simulation work? This is the first roleplay I helped create.), and what is the least amount of work we need to do to get that feedback. Therefore we created all the role descriptions in dutch…

Deborah Preuss wanted to participate, and while she speaks and understands a couple of languages, dutch is not among them. So we improvised and gave her, as an observer, the task to observe and interpret body language. Because of this the players learned about the effect of finger pointing, and that they were doing it without realizing it… The debrief was interesting. Deb noted that at some point several players’ body language indicated they knew enough and were finished with the discussion.

Deborah observes body language of one group

From the players’ perspective that was partially true: some of the players were finished with the discussion, not because they were satisfied, but because they realized they had nothing to gain by the meeting, as their concerns went unheard (and unacted upon).

For those of you who asked me what Retrospective Hero was, and what it was about, I hope this cleared it up a bit. I welcome your questions and suggestions. For those of you who participated or observed, we’d love to know what you feel about the game after a few weeks.

In any case, we hope you join us at XP Days Benelux 2009 to experience the extended version

It has behooved the XP Days Benelux conference to allow playing of devious political games in its program. Join Emmanuel Gaillot and me on November 23 or 24 so that you can (re)find the (dirty?) politician in you.

“Cheney Satan ‘08″ by futureatlas.com

Photo found through Photo Suggest

(Well, you don’t have to get as dirty as the photo suggests, but you will have to put up a fight for your cause )

We will play politics – in a game you will represent a political faction that tries to get an alliance of agilists to spend money the way you prefer.  Convince others to vote for you so you can carry out your program, or choose another party to do what you want for you… Will you be trying to convince the voters to spend money on conference organization, advanced agile research, business 2 business schmoozing, or something else entirely?

After playing the game we will debrief our experiences and draw parallels with everyday work. It may be that you are already aware of the politics around you.  In that case the game can help you understand more about your behaviour.  It may be that you believe your work has nothing to do with politics.  Think again… it may be that you are a “spoiltician” – someone who has “delegated” that dirty politics to others (e.g. your boss . This game will show you how political many common project decisions are. Whether you care about corporate politics or not, they have an impact on your worklife. Regardless your status, be it an opinion leader, a reckless reformer or “just a programmer” in the silent crowd, this workshop is for you!

Benefits:

• Learn when politics happen
• Get a better grasp at why politics happen the way they happen
• Experience your own behaviour and that of others – it is the situation that is politically charged more than you
• Try out various political strategies and safely observe their possible outcomes
• Have fun!

In case we haven’t convinced you to join, maybe we can offer you a bribe or a kickback? (In case you are american, we may also have some pork available for projects in your home state, to be executed by the companies you love )

Agile Politics Workshop, November 23 or 24, XP Days Benelux, Mechelen

Xavier Quesada Allue tells me this will be mostly in Spanish. My Spanish stops around ‘donda esta el bano’ and ‘hola’, unfortunately. If yours goes further, this might be for you. Madrid as a location is attractive, and should be easy to reach. No doubt the organisation will be very good as well, and the event is for free!

electronic waterfall by curly_exp( l)osure

In the meantime, if you speak english, why not attend Agile Open Holland – my named cloud is bigger than yours, or is it?, September 10 & 11? Registrations are going fast. At last count we had over 50 participants, with space for about 80. As in previous years it’s looking to attract a good mix of old & new faces, all equally fanatical about uncovering better ways to develop software. It’s not free, but we kept registrations low enough – we hope the value for money makes it a no-brainer; the fee covers part of the costs, but its’ main purpose is to prevent no-shows, so that everybody who wants to attend, can attend. I hope to see you there!

Madrid scenes de rue by George Eastman House

We chose the theme ‘my method is bigger than yours… or is it?’ because it seems that as this agile software development thing goes mainstream more and more people lose sight of what we perceived was one of the underlying goals of the Agile Manifesto: get continuous experimentation and learning going by developing software and helping others do it across communities – hence the signing by people involved in all ‘lightweight’ methodologies at the time. We like the Named clouds meme and hope it spurs some discussions.

Even if this theme does not speak to you, come to Agile Open Holland anyway – anything goes, and new cloud formations are likely to form during the conference. Named ones in the sessions and the hallways, unnamed ones in the sky (we do hope the sun shines most of the time though..).

Maybe because of the delay (we skipped May eventually) we not only have more items, they are also longer. We try to keep the newsletter short, but the things we discussed at conferences and while making the product development training gave us some inspiration to explain some topics in more detail. If the topics pique your interest, you can read it online or subscribe.

I’ll process and post the rest of the photos when time permits – I decided not to do everything in a big batch this time (which sometimes means the batch never gets executed and photos are not published). Tomorrow Marc and I depart to Luzern, Switzerland for the first instance of our Agile Product Development training, so there is not much time left.

Willem and Marc introduce cultural patterns that can be found in software organizations. By understanding the cultural patterns then you can better adapt your practices.

The presentation starts off a bit slow, but picks up after the introduction. At the time we were incorporating some feedback about our presentations, most notably that we said too little about ourselves, so that the audience had difficulty understanding where we are coming from, and why we had to say something about the subject.

The videographer and editor did a good job at choosing the shots – shooting a pair presentation with one camera is challenging, especially since Marc and I are on opposite sides of the projected slide. The last part of the presentation was helped a lot by questions from the back of the room, I remember Keith Braithwaite and David Anderson (you can hear them faintly in the background) and there were one or two others. Next time I guess we could repeat more of the questions so they are more audible on the video.

A surprising thing we ran into was that Agile was not as mainstream as we thought – a surprising small number of participants put up their hands when we asked whether they were using (at least some) practices connected to Agile Software Development. Luckily, the patterns are independent of this, so we hope those who were/are doing something else get value from seeing various ways to organize development. It’s all about choosing an approach that fits and makes you more effective.

In hindsight the presentation became more graphical and less textual with each iteration. We’ve left the presentation alone for some time, and now have new ideas on presenting the material, as well as some new ideas on how to place various approaches to organize development. We’d love to hear from you about opportunities to perform new iterations…