Here’s the puzzle:

https://gist.github.com/912504

Can you solve it?

The idea behind the session is to simulate the life of a start-up software company. In the early rounds of the tournament, the priority for each team is to get a robot, any robot, out there an playing matches. As the tournament progresses, quality becomes more important as you need to adapt your robot to make it a better competitor.

This ability to adapt your approach to the work to the context you’re doing it in is, I think, really important for the true craftsperson to grasp. If you’ve been reading Kent Beck’s posts about start-ups and design, you’ll be familiar with this subject. It’s wonderful to be able to patiently produce a beautifully-worked piece of furniture, but what if the building is burning down and you just need a ladder to escape, right now? Can you rip up some floorboards and knock something together from the materials to hand and save your family?

There’s a great skill in understanding and working to the appropriate level of quality for the context you’re currently in, and I hope this session gives people a little insight into that.

You can watch my screencast audition for the session here. Please leave any feedback or comments here.

Narrative Journey Maps

• Duncan Prefers the term Usage-Centred Design to User-Centric Design. There was a book reference here but I missed it.
• Narrative Journey Maps (NJM) are a way to model and visualise the steps a user has to follow as they try to achieve a goal.
• Each Step is decorated with:
• Comments
• Questions
• Ideas
• An Emotional Barometer is draw across the top which highlights pain-points where the user may be particularly frustrated with the process.
• NJMs are usually created from a Contextual Study where users are quietly observed trying to reach the goal.
• They are a way to record the current state of play, and a place to start thinking about how things could change.

Personas

• Alan Cooper 1985
• Based on real data: capture and use direct observations of real experience
• Group and merge those observations to form personas
• Personas have:
• Motivations
• Goals
• Frustrations
• Behaviours

It seemed that what had worked for the presenters was to focus on just one persona at a time, when it became obvious who their core user was, and work at satisfying their needs. Once they’d started to make significant inroads into this, it became clearer and more worthwhile to look for other personas.

To Read

Luke Hohman’s Innovation Games Mr Squiggle (seed drawings for workshop excercises) Consensus:

• Quaker Business Method
• Sociocracy
• Formal Consensus (CT Butler)
• “Participatory Decision Making” – Sam Kaner

“The Logical Thinking Process” – H William Dettner. A book on conflict clouds. “Round the Bend” – Neville Chute. Like Zen and The Art of Motorcycle Maintenance but English

Other Conferences

Keith Braithwaite was heading out to ‘Next Generation Testing’ and said he was really looking forward to it. He said it was quite easy to stand out from the crowd of big vendors, and that if you have something original to say you’ll likely be asked back. He also mentioned ‘Test Expo’ as being another conference in this vein.

Really interesting it taking the Cucumber message to these conferences.

Remote Pairing and Wolf-pack programming

I met several people who are making use of or would like to make use of this more. Many of them were using Ubuntu so don’t have access to iChat, and were struggling with slow VNC connections. I suggested screen + emacs/vim to a few people (not that I’ve used it myself, but I’ve heard good things). People mentioned plug-ins for eclipse, and my old favourite SubEthaEdit came up. It does feel like there’s product missing here.

Some guys did a BoF trying out a crazy contraption they had using a smalltalk environment that allowed a dozen people all edit the same code at the same time, on their own workstations. It sounded pretty amazing.

My Session

I ran a session, Robot Tournament at the conference. Despite what I had considered thorough preparation, I had some rather exciting moments when the tournament engine spluttered and needed some running repairs. Overall though the feedback I got was positive. Some observations:

• The (accidental) downtime gave people an opportunity to make build scripts and so on. I wonder whether this could be engineered deliberately another time.
• More logging and visibility of exactly what’s going on when a player runs would be useful to help participants with debugging.
• The warm-up should include calling a robot with a command-line argument so that any teething problems with reading the input can be resolved at a relaxed pace.
• A better explanation (role play?) of how the tournament works would help.
• Need to limit the number of players to 1 per team. Although it was worth experimenting with allowing more than one, there were a couple of disadvantages that seemed to outweigh the advantages:
• when people realised they could write scripts to add several robots, this really slowed down the time to run a round due to the number of permutations of matches. I guess here you could deal with this by using a league system, but for now the simplest thing seems to be to just limit the number of players.
• there is a strategy (which the winning team used) where you use a patsy player which can recognise a game against another player from the same team and throw the game, thus giving that player an advantage. By releasing several patsy players you leverage that advantage.
• I was surprised (and a bit disappointed) at how conservative most of the language choices were. I think we had 3 Ruby robots, 2 Java ones and one Haskell robot. Sadly I couldn’t get smalltalk working for the guy who wanted to use that. It seemed clear that rather than one language being particularly better than another for the problem at hand, teams who used a language they were familiar with did best.
• It was hard for people to see what was going on when they were getting their robots running. More visibility how exactly what it looks like when their program is run on the server environment would be helpful.
• Also more functionality on the UI to slice the results and look at just how your own robot had performed.
• The problem was so small that tests were hardly needed. Pivoting, changing the rules of the game half-way through the tournament might have helped here.
• I would also be interested in trying out variable-length iterations – some long ones, some short ones.
• Shipping simple solutions early was definitely a strategy that had worked for everyone.
• People enjoyed the fact that the goal – getting points – was clear, so that rather than it being about writing clean code or writing tests, it was more realistic to a business context.
• Trying a more open game where you could learn more about your opponent might be interesting
• Getting teams to swap code might also be interesting
• Doing a code show & tell wasn’t in my plan but worked really well

The session format ended up being something like this:

• 10 minutes introduction
• 25 minutes warm-up
• 30-45 minutes faffing around fixing the engine while people started to build their real robots break
• 7 x 7 = 50 minutes tournament rounds
• 25 minutes code show & tell
• 15 retrospective looking at what we’d learned and any insights

Here’s some more details about the conference:

Friday 14th May 2010 – UCLan, Preston

Price held at £95 per person – be there to learn, share, take part and enjoy

Details on www.agilenorth.org

Mind if I run a couple of things past you?

I’m going to use personas in the session as a tool to help people discuss the anti-patterns that I think cause teams to struggle with pair programming. You’ll hopefully recognise yourself or people you’ve worked with in the past in these personas. What do you think? Have I missed any? Are they too obvious?

Goran, Architect

“For most tasks, pair programming just slows me down. When you pair with me, it’s not pair programming, it’s mentoring”

Goran has been programming professionally for over 15 years and draws on that experience to write clean expressive code. He can code fluently in C++, C#, Python and is handy in numerous other languages. He knows all the common design patterns and when to apply them, as well as numerous refactoring strategies.

Goran has tried pairing a few times, but doesn’t really see the benefit. He feels that his level of experience makes for rather uneven and therefore pointless pairing sessions.

Bart, Obsessive

“I just hate having to share the keyboard”

Bart is really gifted programmer who gets a huge amount done with few mistakes, but his team-mates often find it hard to understand and change his code. He’ll often use jokey or sarcastic names for variables and methods and has a tendency to write long, complex, methods. Bart drinks a lot of coffee and works long hours, often getting quite obsessed about finishing a particular piece of work.

Bart doesn’t really like the idea of pair programming. Although he understands the benefit of ‘no code ownership’ in theory, in practice he feels quite possessive about his code, and finds himself quickly becoming aggressive when discussing design decisions with other members the team. He often seems to upset his team-mates when he just thinks he’s being honest with them.

Moira, Anxious Project Manager

“My team doesn’t have time to work in pairs, we have too many bugs to fix”

Moira used to be a programmer back in the day, working on COBOL mainframe systems, so she knows the ropes. As everyone sticks to the plan, she sees no reason why things should go wrong. Right now her team are in the ‘testing phase’ of another project, and as usual there’s a frenzy of activity as bugs are uncovered by the testers and passed to the developers to be fixed.

Moira just can’t see how halving the number of bugs being worked on by adopting pair programming can help her team meet their deadline. To her, pair programming just seems like a fad that helps programmers have a better time at work.

John, Contractor

“I’m scared people will realise I don’t know what I’m doing half the time”

John is a contractor, a hired gun. He’s paid at least twice as much as most of his team-mates who are salaried. He’s experienced and highly competent, but secretly frets that he isn’t really worth the extortionate daily rate that he’s paid, and feels guilty when he gets stuck or has to ask his team-mates for help.

John has never tried pair programming but he worries how his team-mates will feel when they realise he sometimes needs to spend 20 minutes reading around blog posts and mailing list archives, or writing throw-away code to figure out how to use a library he’s never used before. Won’t they end up resenting him for wasting time?

Sarah, Wallflower

“I’m just used to programming on my own”

Sarah has been programming since her early teens and got top grades studying Artificial Intelligence at University. Sarah is naturally shy, and has always found comfort in programming as a place where she can express herself and her ideas without having to talk to people face-to-face, which she finds awkward and embarrassing. She contributes to a couple of open-source libraries and can often be found on IRC channels and mailing lists supporting the users of those libraries with friendly and eloquent responses.

For Sarah, programming has always been a solitary activity. She finds the idea of pair programming strange and quite intimidating, since she doesn’t think she’s very good with people.

Gary, Once Bitten

“Pair Programming is a load of old bollocks”

Gary has worked on a project before where the team claimed to be ‘agile’. They used Scrum and user-stories for planning their work, and the scrum-master encouraged them to use pair programming. In fact, the scrum-master forced the team to work in pairs, by picking pairs at the start of each 2-week iteration, and making sure the developers stuck to those pairs for the entire duration of the iteration.

By the end of each iteration, most of the pairs were so sick of working with each other that they would barely speak for several days afterwards. Gary found he would come in earlier and earlier so that he could get some time hacking on ideas he’d had but didn’t have the chance to play with during the main working day. He found pairing to be a drudge and a chore.

Rod, Whacky Races

“Every time I pair with someone new, I have to learn their bloody keyboard shortcuts”

Rod has just joined a new team who are using UNIX text editors to do their development in Perl. Rod is used to using the Eclipse IDE and has never really used these text editors before so he feels awkward and clumsy when he gets the keyboard. This is compounded by the fact that his team are using a mixture of editors and operating systems, with some people staunch EMACS users, others using VIM and yet more using Textmate on the Mac.

Rod likes the collaborative aspect of pairing, but feels hampered by the variety of development environments that his team uses. What can he do?

All thoughts and comments appreciated. If you’re in London tomorrow night, why not come along to the session and let us all know what you think?

Come to my talk if you want to hear my experiences of breaking a team out of the Scrum mould and doing some exciting stuff with value stream maps, Kanban boards and other techniques from the school of Lean Thinking. Come along if you want to hear about a world without task cards, exhausting planning days, and maybe even a world without estimates. Sorry Jason, but there may be some mention of coloured bits of card.

I’m actually one of only a few people with a scheduled talk, as the organisers have decided to use an open-space format this year. Which means you also have a chance to get up on stage and lead some discussion. After my last experience with an open space, I’d say it’s well worth doing your homework and really thinking about what you’d like to discuss at the conference beforehand so that you get the most out of it.

If you’re interested in building software as well as you can, XP Day is a great place to meet like-minded people, share experiences and develop ideas. It’s only small, so register soon!

Let me know in the comments if you’re coming, and what you’d like to talk about when you get there.

There’s a mixed crowd – some die-hard extreme programmers, quite a few self-styled (and self-promoting!) ‘coaches’ and a few newbies.

The atmosphere was really friendly – you would quite often find yourself sat in one session right next to the person who had been leading the previous one, so that and the often fun and interactive sessions broke the ice pretty quickly.

The first day was a bit flat for me, but after a night on the free beer courtesy of the sponsors, the second day picked up and really made it worth it. I wish I’d had time to stay for another session in the pub on Tuesday evening.

Key things I took from this conference, more detail on these later if you’re lucky:

• There’s a fairly serious backlash going on against scrum (I heard more than one person drop the ‘r’, although I think one of those was accidental!), certainly within the London / UK agile scene.
• There’s tension, which as I see it is between the coaching community and the programmer / creator community, who disagree about how much it’s OK to compromise on the original agile manifesto values and XP practices. I heard the phrase ‘valuing pragmatism over orthodoxy’ which summed it up rather well.
• Nobody, but nobody, works for ThoughtWorks anymore, not even Fred George
• You probably need to be working in Java if you want to get decent XP gigs, especially for a bank, and there’s quite a few people working for banks – particularly front office.
• Kanban is where it’s at, baby.