I’ve know Woody for a few years. He invited me to a free (yes, I said free, as in I don’t pay a dime) workshop to learn Mob Programming. After a couple of tries, I was able to attend what might be the last free workshop on February 25, 2017. It was free because Hunter Industries paid for Woody’s time, let us use their facility & equipment, provided our lunch, and volunteered their time to coordinate all the activities. Nice people.
This is my blog entry on my experience at the workshop.
The warm-up exercise, which was attributed to Tim Ottinger, seemed to be a learning experience about the problem with estimating (aka #noestimates). It didn’t feel like a mob programming exercise, per se. I support the concept of no estimates, I enjoyed the activity, I got my mind working a little, and started to interact with the other participants (of whom, I didn’t know any of them) so I it felt appropriate enough.
Next, the process of mob programming was explained to us, starting with how it started. I had heard descriptions of it before, including on the Watir Podcast which I host. Woody described the coding dojo and the retrospectives. The explanation in the workshop, unencumbered by time, was much clearer because Woody was able to explain the whole process.
Then we split into teams to work on a fictitious problem requiring us to write software in C#. I won’t describe that problem because it isn’t important. It was sufficiently complex enough that we needed to work together to solve it, but not so complex that beginner programmers could not contribute to the work.
The idea is for one person to navigate the direction of the software development. That person is typically standing. A second person is driving the software development through typing on the keyboard and clicking the mouse. The others are contributors that support the navigator and driver through providing additional information, suggestions, etc. The team would switch in a clock-wise fashion every four-seven minutes so that eventually everybody had turns as navigator and driver. I am OK that I am under-describing the process – there are smarter people to do that.
The other important instruction was to use red-green-refactor as the process. Every new line of code started with a new unit test. That was followed by the minimum code to satisfy the new test (without creating failures in the previously satisfied tests). Finally, we could refactor the code to make it better (remove code smells) without breaking the tests (they must pass).
We knew that we would run three sessions. Between sessions we would reflect and determine how we could alter the work-behavior rules. Woody would come by to give us requirements – they would be spoon fed, one at a time. We would do the minimum to satisfy each requirement, then ask Woody for more.
We only knew the details of the first session which would be orthodox: the instructions for our behavior and interactions was strict and clear. We would switch positions every 4 minutes. It felt like the shu phase for me. I spent my time in the ‘other role’ pretending to be polite and quiet while I planned my time as the navigator. The navigation time is short so I felt it must be well-spent if I was going to get us going in the right direction. By the end of the session, I felt that I could fulfill the role in each part (though I violated the rules at least once by speaking when I shouldn’t).
In the next session, we were given permission to raise our hands to provide input as “others”. As navigator, we were to listen to those inputs (or request a moment to complete another idea first). This would be more generous, less orthodox. The requirements were making the software more complex. We began to refactor, and soon things started to get messy. We couldn’t complete anything before we would switch to the next position. Woody came by to see how our team was doing. He could see that we had lost our way in the red-green-refactor loop because we had several tests failing. We stopped switching so we could discuss the situation, the design, and the possibilities. I felt that we had entered the ha phase, only we were finding many failures.
I felt frustrated, and the others did too. What was going on here? As I’ve hated retrospectives after a bad sprint, I didn’t want to go to the reflection session. In it, I started to cool down. As we talked, I could start to see how success wasn’t possible without all of the team working well together. I had been spending more time wanting to fix them than work with them.
Finally, we started the third session. This time anybody could respectfully provide their ideas. The navigator would still be the person deciding on the direction, and we would still take turns. This time, things started to go much more smoothly. Three things made that happen: respect for each other so we talked it out; using the r-g-r framework to write tests and get them to pass; walking through the code (through discussion, not the debugger) to figure out what was going wrong. We made much more progress than the first two sessions, and the comradery grew quickly. This felt like the ri phase. I had learned to stop pretending the respect for the others. I felt that respect, only gained by allowing them to be themselves. There was balance in orthodoxy and generosity. It became group magic.
What did I learn? I learned that I thought I knew unit-testing and TDD, but I was breaking many of the principles. I also learned that the phases associated with each of the sessions were required for the breakthrough of my learning what mob programming was about. And I learned a little C# (did I mention that I had never used it before?).
What are my take-aways? First, that any team could do this. My team had a new programmer, a non-programmer, an experienced programmer, and me (software tester who is self-taught in programming – aka not great at it). Everybody contributed. Everybody was valuable. We all listened, and all had a voice.
Second, the code we wrote on our team was very high quality. I spoke with members of the sponsoring ‘Hunter team’ who had been using mob programming for about five years – they had zero defects in the field. None!
Third is I could probably relay some of the things I learned. I bet we could run a dojo at lunch to learn to code better. I bet we could work on our team code in groups. But with a short one day workshop, I would prefer to get professional help in getting started.
Special thanks to Hunter and Woody for bring me there and spending their time with me. It was so worth it, and would have been worth a considerable fee.