A coding dojo story

It was 2008, and I was at the CITCON conference in Amsterdam. I’d only started going to conferences that year, and was feeling as intimidated as I was inspired by the depth of experience in the people I was meeting. It seemed like everyone at CITCON had written a book, their own mocking framework, or both.

I found myself in a session on refactoring legacy code. The session used a format that was new to me, and to most of the people in the room: a coding dojo.

Our objective, I think, was to take some very ugly, coupled code, add tests to it, and then refactor it into a better design. We had a room full of experts in TDD, refactoring, and code design. What could possibly go wrong?

One thing I learned in that session is the importance of the “no heckling on red” rule. I watched as Experienced Agile Consultant after Experienced Agile Consultant cracked under the pressure of criticism from the baying crowd of Other Experienced Agile Consultants. With so many egos in the room, everyone had an opinion about the right way to approach the problem, and nobody was shy of sharing his opinion. It was chaos!

We got almost nowhere. As each pair switched, the code lurched back and forth between different ideas for the direction it should take. When my turn came around, I tried to shut out the noise from the room, control my quivering fingers, and focus on what my pair was saying. We worked in small steps, inching towards a goal that was being ridiculed by the crowd as we worked.

The experience taught me how much coding dojo is about collaboration. The rules about when to critique code and when to stay quiet help to keep a coding dojo fun and satisfying, but they teach you bigger lessons about working with each other day to day.

Agile / Lean Software Development

Comments (0)


Thinking outside the shu box

I just got back from the fantastic Lean Agile Scotland conference, where I spoke about why agile fails. I’ve been doing a lot of travelling this year since The Cucumber Book came out, consulting and training different companies in BDD. A pattern I keep seeing are companies who adopted agile a few years ago but have hit a glass ceiling. This talk was a chance for me to reflect on why that happens.

One point I made in the talk was about cargo cults. The term ‘cargo cult agile’ is used to laugh at teams who go through the same ceremonies – daily stand-up meetings, planning poker meetings, story points, velocity etc. – yet in some very fundamental ways, they just don’t seem to be succeeding the same way as organisations who get it. I see this frequently, but I don’t think it’s particularly funny. I think it’s a sad waste of human potential.

I’m curious to understand why it happens.

There are various models for how we learn things, and one of my favourites is Shu-Ha-Ri. This model comes from Japanese martial arts and says that in order to really master something, we need to progress through three stages. The first stage, shu, is about learning the basics. Here’s a quote from Aikido master Seishiro Endo:

In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forbearers created. We remain faithful to the forms with no deviation.

That’s shu: absorbing the basic mechanics by repetition, without really understanding why.

The next stage is ha:

In the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded.

Imagine that? Broken and discarded! This is the point where we start to ask why; where we start to understand the value of the practices we’ve been using and have enough experience to make decisions about when they’re actually valuable, and when they could be getting in our way.

The final stage, ri is transcendence:

Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.

I think that sounds like fun.

Anyway, my point is that cargo-culting is just what happens when your team is stuck in the shu stage. If you’ve been on some basic agile training, you might have been led to believe that’s all there is too it; unless you’re aware that the other stages of learning exist, how could you aspire to reach them?

This morning I was asked a great question about the talk: How would I help a team that’s stuck in a cargo cult shu learning stage? I felt like it deserved a blog post, and that’s why we’re here.

My first step with that team is to understand how well they’d really learned the basics. Have the team been given enough support to really get to grips with the tougher agile practices like retrospectives, TDD, or pair programming? What problems are they suffering from and how can they be traced back to core agile practices that the team need more expertise in?

Then it’s time to help them learn and practice those basic techniques. Coding dojos are a great way to practice TDD in a fun environment, for example. Coaching willing members of the team how to facilitate effective retrospectives and helping make sure that actions coming out of those retrospectives are followed up helps to start building the culture of empowerment the team need to become confident enough to move beyond the shu learning stage.

It’s also important to have conversations with management to ensure that the team are being given the space to learn. I often see teams who are driven so hard by the demand to deliver features that they simply don’t have the time to invest in self-improvement. Once a product owner is made aware of this situation, and the benefits of having a higher-functioning team, they’re usually keen to make this investment.

Agile / Lean Software Development

Comments (1)


Seven Truths Exercise

Recently, I played a game with a team I was training which I called “Seven Truths of Test Automation”.

I got each “truth” and wrote it on an index card and put it in a (blank) envelope. I got to the training room early and hid them around the room, not very well, so that they were quite easy to find.

We did some other stuff first, and people were looking at all these little envelopes sticking out from behind whiteboards and under cushions, wondering what was going to happen.

Then I told them that we were going to play a game. I told them that there are seven truths of test automation, and they were about to discover them. I split them into 6 small groups. I then told them they would each go out and discover a truth. When they found it, they had to ask themselves the following questions:

  • Do we agree with this?
  • What are the implications of acting on this truth?
  • What are we going to do now?

I wrote those questions on a flip-chart. We then played the game out as a group on a single truth to make sure everyone got it. I made sure that we had a full and frank discussion about whether we agreed with the truth or not. We thought through the implications (good and bad) and listed them out. We then talked about some concrete steps we could take. When they offered vague intents “We’ll start getting better at reducing duplication” I urged them to say exactly what they were going to do next week to get better at reducing duplication.

Then they split off and each did their own. They wrote up a poster and we did a gallery at the end of the session where they had a chance to share their learning with the group.

It worked really well, generated great energy and used up a good couple of hours.

For the record, I think the truths I used with this group were:

  • test automation is software development (this is the one I picked to do with the whole group)*
  • duplication destroys maintainability*
  • incidental details destroy maintainability*
  • know when it’s OK to cheat
  • some things just aren’t worth testing
  • work with developers to make their systems testable
  • don’t test other people’s code

It felt a bit egotistical handing them down My Seven Truths, so I made the point that they were just my truths, and they would discover their own as they learned to become better testers. You could obviously vary the truths depending on what you think the that group needs to hear / discuss, and those truths could be about anything, not just test automation.

Agile / Lean Software Development

Comments (3)


XP Day 2008: Debugging Pair Programming

At XP Day 2008 I proposed an open-space session on pair programming. Specifically, I wanted to explore the reasons why programmers might not want to pair, or find it such an unpleasant experience that they’re put off doing it again.

Judging by the great number of people who turned up and stayed for the session, it’s clear I’m not the only one who is struggling with these issues, adding more weight to my suspicion that pair programming is the hardest of all the XP practices to master.

I worked with Laura Plonka to devise and run the session. Laura is researching her PhD thesis on pair programming, using video footage to analyse pair programming sessions, then running a retrospective where the pair get to debrief and share their experiences of the session.

Despite the huge contribution from everyone present, at the end of the hour, I felt as though we had only started to scratch the surface of the problems we’d identified. It seems as though too many teams, even at organisations who are ostensibly keen to embrace ‘agile values’, suffer from some toxic cocktail on this menu of dysfunction:

  • an agile-zealous leadership which forces people into unwilling or poorly-chosen pairs
  • a culture that, at some level, values heroics over craftsmanship, such that programmers may feel a subtle or unconscious reluctance to chose to pair on a task unless it looks utterly daunting, and there could be no shame in being seen to ‘ask for help’.
  • a team that disagrees on the types of tasks that should be done as a pair
  • team members who are far enough along the autistic spectrum (as Joseph Pelrine and Ben Fuchs pointed out, we have a higher proportion of these than many other professions) that they find the level of inter-personal communication required for pairing difficult or impossible.
  • ‘Experts’ on the team who feel that pairing with less experienced members of the team will slow them down too much
  • ‘Newbies’ on the team who are afraid to ask for help, or feel the work they’re doing is too mundane to need to be done in a pair

There were masses more issues brought up – these are just the main few that I can remember now. Hopefully more people will write up their sections on the session’s page on the XP Day wiki, or maybe comment on this blog post.

I spent the latter half of the session in a small group discussion the influence management can have on the adoption and enjoyment of pair programming. Paul Field and I enumerated the benefits that teams who embrace pair programming and create a culture where it works, can enjoy:

  • Better system knowledge across the team (higher truck number)
  • Skills transfer between team members (free training)
  • Team bonding
  • More defects found & found earlier
  • Better solutions/designs
  • More fun (better staff retention & morale)
  • Better focus (less time wasted in email / facebook)

It’s worth holding onto this list, and thinking about it when experimenting with pair programming within your team. Not all these benefits will be immediately apparent, so it’s worth being patient and trying to figure out ways to measure them to give you feedback as to the success of your experiment.

Another great idea I heard for teams that want to try pairing but are unsure as to which tasks are appropriate: try doing every task in a pair for at least five minutes. If, after that time you both agree that it’s a waste of time to do it as a pair, you can split up.

I still feel like there’s huge amount of work to be done to collect and disseminate the patterns and anti-patterns around pair programming, but I’m glad to have at least stirred up the pot a little. Thanks to everyone who turned up and contributed so much, and thanks especially to Joseph and Ben for organising a follow-up session later in the day where we had the opportunity to drill down into those psychological barriers a little bit more. Great stuff.

Agile / Lean Software Development

Comments (6)