Saturday, July 30, 2016

Strong Pairing, Mobbing, and Woody's Workshop

First - some background.

I don't program computers for a living and haven't in a long time.  I am interested in programming techniques, languages, and approaches though; I could code my way out of paper bag if my life depended on it.

For a long time I have been a proponent of XP practices like pair programming, TDD, small stories, frequent delivery, etc. 

At my last company I had started to sit with developers while they worked and talk with them about some of the issues they faced.  General problem solving, simplifying, and helping to focus on one thing at a time.  This would be very weak pairing as I would be conversant but not fluent in the tools.

At the same company, two of the teams had started to do a lot of group sessions where they would work through problems and solutions together in an informal way that allowed people to join and leave as they needed to while the group continued to make progress.  We didn't have a name for it but it seemed to work well.  This had grown out of our hiring process where all available members would participate in interviews and technical challenges that required collaboration, resourcefulness, and the courage to ask questions and sometimes say "I don't know."

A few months ago on the Slack board, somebody mentioned Mob Programming which I had not heard of.  I was very interested though based on the previous good experience with group sessions, and intrigued by some of the details such as frequent driver changes.

I watched the video, bought the Mob Programming book and reached out to Woody on Twitter.  We had a phone call one Sunday afternoon and I decided I needed to learn as much as possible about this way of working.

Cut to #Agile2016 and an available Mob Programming workshop in Atlanta after the conference. While walking around and talking to a large number of interesting people, I noticed there was a Mob in session working on a Refactoring Kata for a simple Tennis Scoring program.

I walked over and sat down to observe.  In the space of less than 10 minutes, several approaches to refactoring the ugly If block were coded.  All of them worked but left one or another team member dissatisfied because they were clever, or confusing, or ugly, finally - still in the 10 minutes or so - somebody suggested a clean, simple, and elegant solution.  The tests passed and it was over.

Llewellyn Falco mentioned that they would be doing another Kata as a Mob the next morning.  Well the next morning the projector had disappeared and there had been a party the previous night so only Llewellyn and I showed up.  He offered to do a Strong Style Pairing session with me.  Strong Pairing is where any coding idea must go through somebody else's hand on the keyboard.  I was a bit nervous, we would be coding in C# - a language I have not used or even looked at - and with just the two of us there would be no cover for my ignorance.  It turned out that Llewellyn was very patient, we came to a nice refactoring solution in a about 40 minutes with some good conversation and advice thrown in.

Shortly after that, I realized I was a train ride and car drive away from Woody's Mob Programming workshop.  I arrived a few minutes late and Woody was still covering stuff that's in his book - whew!

Woody walked 4 volunteers through the rotation process while the rest of us tried not to interject and learned to feel what that is like.

In no time, we broke into groups of 4-5 - each with our own computer setup - and strict directions that only the current navigator could suggest what to code and only the current driver could type stuff in.  

This was hard.  As the navigator, I really wanted to consult with the team.  As an observer, I really wanted to help the navigator.  As the driver - all my recently learned keyboard shortcuts were useless because we were using a different IDE from what Llewellyn and I had used.

After satisfying a couple of requirements, we were allowed to call for a consult at any time and talk as group but with hands off the keyboard.  This was a lot better, but we found it easy to spend too much time evaluating different ideas without putting them to code.  A couple of times when we wanted to refactor because the code was getting ugly, we couldn't agree on an approach right away so we just made the test go green and put refactoring on the back burner.  I did mention that we were doing TDD - right?

A quick word about TDD.  With the group it was easy to write the test for each new requirement first. We quickly grew comfortable with this approach and it made refactoring attempts really easy and stress free.  One time we made too many changes and turned about half our tests red.  Woody had us revert until all the tests were green and try again.  His view - which I now share - is that you should only start a refactoring when all your tests are green, and that you should never be more than a couple of edits between passing all tests.

Finally, as we continued to knock out requirements more and more quickly, and Woody - our product owner - was busy with other teams, we started to use the gaps to review our approach and identify refactoring opportunities that would make us happier with our code.  Better names, cleaner tests, etc.

The last stage as a team was to be in full Mob mode - anybody could make a suggestion at any time while remaining Kind, Considerate, and Respectful.  This was a lot of fun and we already felt like a team after something like 1 hour of working together.

When we started only one person on the team was an actual C# programmer.  This was scary but turned out to not matter. Almost any problem is going to require only a small set of language features and you learn the ones you need pretty fast.  A nice side effect is that everybody learns them.

I also thought that the frequent Driver Rotation would be disruptive - we were using 4 minutes.  It was not a problem and seemed to have the effect of time-boxing our work.  We would think about how we could go green in the space of a rotation - whether it was a new requirement or a refactoring.

I want to do a lot more of this and find a really good way to Mob Remotely.  I highly recommend that you get Woody to do a Workshop for your teams and give this a solid try.  The concepts are simple but I think your chances of success and adoption go up with the workshop.

No comments: