Three Rules of Coaching Engagement

Last year software crafter and Kotlin enthusiast Oleksii Fedorov asked me about technical coaching. He was going to work with a small team and focus on technical enablement. He would do so by pair and mob programming with them for some time and later support them remotely if needed. During that time there would be no pressure or deadline to deliver new features so they could focus on improving.

Oleksii is a like-minded peer. I met him on several occasions in the past. He is fun to work with and considers teaching an integral part of pair programming. I did not expect any problems. He kept pushing me and made me think about my principles. In the end I came up with three points I like to make clear right from the beginning, i.e. set the ground rules of the engagement.

1. Manage expectations
Managing expectations is crucial. I learnt that the hard way during my Pair Programming Tour. Whenever I run a session, e.g. pair or mob programming and often also prepared workshops, I start with a discussion to collect expectations. For longer contracts I recommend to start with a dedicated meeting to do so. Usually expectations are fuzzy, like "I want to learn something", so keep pushing with questions like "How will you know it was worth it? How will you measure that you learned something?" and so on. In the end I want the team to come up with ways to measure their learning and define their own success metrics.

2. Learning is their responsibility
Oleksii planned for two weeks. In two weeks people will not change (much). Such a coaching engagement does not last long enough for much impact, rather it is a start of a (maybe even life long) journey of learning and improving. This is true from day one and during the initial meeting I make it clear that I am not a teacher. I will not push knowledge onto them to be forgotten the next day. To get something from working together, people have to participate, to engage, to invest time and effort into the topic. They will only get so much from it what they have put into it themselves. Learning is their responsibility.

3. Treat them as strangers
After removing the responsibility to teach anything - because learning is their responsibility - I feel less stressed. As coach I am still responsible for creating a safe space, providing content, managing exercises and a lot of other things. If someone does not want to participate or feels like doing something else, I have to be OK with that. Even being paid for "teaching" should not change that. My advice here is to treat the team members as "strangers", like we treat new visitors of a Coding Dojo. As a facilitator I try to help, but I will not oppose or coerce.

Feedback
Oleksii started the job soon afterwards. I was sure everything would work out fine. When we met again he told me that my three rules had helped him. 1. He collected expectations in the beginning and managed them while moving forward. 2. People understood that they had to invest and some participants even showed up for sessions during their free time. 3. People where entering and leaving sessions all the time, still he stayed relaxed.

Journeyman Pairing Sessions

This is the third and last part of my series about my Journeyman Tour two years ago. In how to Journeyman Tour I summed up all facts and advice regarding planning such a tour. Then I described what I learned by going on a Journeyman Tour. Today I want to share more about the actual pair programming sessions. During the tour I already summarised some findings, e.g. I wrote about discussing expectations with your pairing partner up front and bringing a keyboard for all languages used in the area.

The Very First Session
When I started my tour I did not know how it would work out. I was uncertain how others would react and afraid to screw up. It helped me that the very first session took place in my usual environment. Raphael and I met in a co-working space I had been before. I knew the place and how to get there. Also we worked in Java, the language I had been using almost exclusively until my tour. By using my main language I was not bothered by the language and its tools. Third we started a new project from scratch, starting with a detailed introductory discussion. There was no old code I had to understand. And finally Raphael and I shared the same mindset. It was clear from the beginning that we would do TDD and create high quality code that he needed for his games. The only thing that was new for me during our pair programming was being on tour and pairing with a stranger. It was the perfect start. Probably I was just lucky, but I recommend starting your tour like that. Look for someone you know, working in a place you know, using a programming language you know. This might be a colleague from a previous engagement or someone from your favourite meetup community who agrees with you on most things.

Warm-up
When pairing with a stranger for the first time, I needed some time to establish a rapport. During my tour it took between a few pomodoros (two hours) up to the while day (eight hours) to get in sync with my partner and understand the domain to an extend that I was able to contribute. On the second day we usually worked much better. Due to this warm-up I recommend sessions of at least two full days with each person - assuming that you are looking for real pair programming during your tour.

Interruptions
Most of my pairing partners had blocked their calendar and made sure they were available the whole day without interruptions. Many did not even check their email all day. Some had even organised a meeting room so we could work on our own. Unfortunately not all people I visited knew how to "behave well". Working with heavy task switchers was really difficult. As the guest I did not complain about task switches, but when the interruptions became too many or too long, I went back discussing our expectations of the pairing. Few young developers had to be reminded to stay focused on the task at hand.


Tasks
In the introduction of my Code Cop Tour I explained my conditions as following: The only condition is that we will pair program. It should be a quiet time without meetings where you plan development activities on the mainline of delivery, e.g. writing code, writing tests or improve your build system. Obviously not all kinds of work, even on the mainline of delivery, were useful to me. For example researching or spiking, where we both had no clue how to continue, did not work well. And I hated spending two days of my tour looking for a single bug, tracing execution through auditing records in the database. While I believe that pair programming might be useful for debugging in general, I did not have the relevant experience to help my pair here. I recommend rejecting such work for your visit, or at least discuss the problems with your pairing partner up front.

Taking Notes
I brought a large notebook with me to record all interesting things. I wrote down the full names of my pairing partners, their expectations and any learnings during the sessions. I kept notes of each session retrospective and a kind of personal diary. I glued in business cards, Post-it notes and all stickers I collected during my tour. In the beginning I used a cheap pen, which made my hand hurt after some time. I had not practised my hand writing for almost 20 years. I fall back to my fountain-pen, which created a mess of ink now and then, but was a better writing device by far. I wrote a total of 55 pages A4, two pages per pair programming session on average. For road thoughts I used the standard voice recorder of my mobile phone. While it worked I do not recommend using it during driving, especially when going fast on the highway.

Known Or Unknown Pairing Partners
In the previous blog posts I quoted some other Journeymen and named their advice according their names. While these rules make sense for me, you may chose to ignore them. The last of these "rules" is Samir's rule: If I do not know you, I will not pair with you. What Samir meant was to meet before the session, to get to know the partner and make sure that both get something out of pairing. This is definitely a way to reduce uncertainty and avoid surprises. Checking future pairing partners helps aligning your expectations with potential learnings. On the other hand - depending on your learning goal (see Daniel's rule, you need a learning goal) - you might want to pair only with people you do not know because it gives you more coverage.

That ends my notes. If you plan to go on tour yourself and have some questions I did not discuss, do not hesitate to contact me. And when you have been on tour, I would love to talk about how it went and compare our experiences. Please get in touch with me!

Teaching using Mob Programming

Since some time I am training young developers. I meet with different teams and we discuss topics like Pair Programming or I run hands-on workshops in the Coding Dojo format. Occasionally I pair program with single team members on difficult tasks as mentoring on steroids.

The first session
Last November one team I work with grew tired of Coding Dojo examples and wanted to work on real code while keeping the good atmosphere of our sessions. I envisioned sort-of a dojo in Randori style with everybody of the team pairing with me one after another. It ended with me being busy driving and all others navigating in different directions at the same time. Additionally, as teacher, I had to think about the proper action for the code and discuss the different proposals of navigators. It was difficult and showed many opportunities for improvement.

Enter Mob Programming
At the same time I learned about Mob Programming. Mob Programming is defined as all the brilliant people working at the same time, in the same space, at the same computer, on the same thing. That means that most of the mob's work is done sitting together in a group work area. All the necessary skills are present together in the same room, so there is no waiting time. If you have never heard of it, I recommend watching this presentation by Woody Zuill about Mob Programming, presented at the Oredev conference last year. Woody's team is using this technique since some time for all production work.

My Sessions
Inspired by Mob Programming I applied some of its concepts to my sessions. For example I never drive and I also do not navigate. Instead I try to meta-navigate the team of navigators. (Or sometimes I simply dominate everybody and tell the driver exactly which keyboard short-cuts to type. ;-) In the following sessions we refactored some code and created unit tests. All these sessions worked out well. Now, after running more than ten Mob Programming sessions with various teams during the last year, here are some things I noticed:

Communication
Mob Programming enables communication. In one of the first sessions, the architect of the team saw something in the source he did not like. He mentioned it to be an architecture violation but the other team members did not know this aspect of the architecture. It was amazing to see them talk. Although being on the same team they had not talked about it before. It is known that regular pair programming spreads the knowledge throughout the team and Mob Programming does even more so.

Participation
"Mob learning" differs from regular "mob work". Some people like learning sessions less than "the real thing" Also as in any team and any team activity some are more interested in the session than others. But usually participants are engaged, probably due the good communication. One major factor for active participation is the team size. Sessions with too many people do not work out well. Larger groups split into subgroups with their own agendas. I recommend group sizes of ten or less people.

The teams I work with are mixed teams with members of different experience and skill. It happens that some junior members cannot follow a high level discussion and zone out. I believe this is a symptom of the group needing more knowledge sharing and communication in general. I guess this does not happen to experienced "mobs" but I do not know. As moderator I try to get all people engaged and ask the seniors to explain the problem to the whole team because "the team needs to know". I also move forward very slowly so everyone is able to get along. This is even more important in the end of the session as people get tired and zone out more easily.

Exhaustion
Due to their active nature "mob sessions" are quite exhaustive. Ten minutes of break each 50 minutes of work help to keep people fresh. Also regular rooms run out of fresh air quickly, so I open windows as much as possible during these breaks. Most meeting rooms I have been to have the projector on the shorter side of the room, so almost all people have to sit with their heads turned. This is uncomfortable and tiring when sitting like that for several hours. While there are no dedicated work areas for mobs, internal training rooms are better because they are usually arranged like classrooms. But I have yet to find the perfect mob working area in the enterprise.

Topics
In my Mob Programming sessions I want to show the team certain techniques, e.g. splitting a large class. The session needs a defined, explicit goal and everybody needs to be clear about his or her expectations. The format works well for showing a work-flow from end to end. Also people like sessions with big structural changes, e.g. refactoring towards a pattern. On the other hand they do not like extracting small structures, discussing names and other clean code related activities. People do not feel progress there. This might be a drawback of working with real code, the urge to make progress is higher than in a dojo. Maybe these sessions are only appropriate after the participants have gained a certain level of competence by attending Coding Dojos. Even with successful mob sessions I mix in a Coding Dojo every third time at least. In the dojo people work on the details and practise the basics. In some way mob sessions are orthogonal to dojos and as such a great addition to our learning tools.

Driving
I rotate drivers every ten to 15 minutes, as proposed by the Mob Programming guide to keep people active. Usually there are participants who do not want to type. These include junior team members, who probably are afraid to get criticised in front of the team, and on many occasions female developers. If someone does not want to drive, I ask why, but till now did not get any clear answer. I guess some people do not want to type because they are slow. Once a senior guy refused but then did drive. He was horribly slow and used no short-cuts at all. He even did not find the rename refactoring in the Eclipse menu. It was embarrassing.

Moderation
These kind of work is more demanding for me than dojos or even theory sessions. I rehearse my theory presentations and experiment with the planned kata before a dojo, but it is impossible to prepare fully for such a mob session. I ask the team to send me the code we will work with a few days before and then work through it in detail. Knowing the code up front makes me feel more secure and saves time because I do not have to read the code during the session. Such a session is team work and I do not have a strict outline except the defined goal. In fact I can never be sure about the right thing to do because it is not my code. I have no idea about its requirements, history and constraints. This is stressful because as mentor I am asked for guidance which I might not be able to give. It happens that I have to say that I do not know, which is not a problem but still makes me feel that I failed.

Conclusion
I am facilitating Mob Programming sessions since almost a year with different teams in different companies. Some worked out great, some did not. Some were fun, some were just exhausting. Should you try it? Maybe, I do not know. Do I recommend it? No, I stick with Woody's style of "not recommending", No I do not recommend it, I am just sharing because people have been asking about it. But I am genuinely interested in this mode of working and will continue to experiment with it. Unfortunately I never participated in a real session, working on production code. That would be another kind of experience. (Hint, hint! All you mobs out there, I am open for your invitations ;-)

Awesome Week 6

Journeyman Tip: Plan for some space each month
I try to keep the pairing sessions of my Journeyman tour free of any appointments. If we spend only two or three days I do not feel comfortable in coming late or leaving early, there is just not enough time. My calendar was blocked by pairing sessions entirely until my first "free" day last week. It was a busy day, and I used it to prepare a few things for our upcoming Eclipse DemoCamp in Vienna. And I had a job interview. (The position looked cool but in the end it turned out the vacancy was not for a developer but for a Unix sys-admin guru, someone who compiles his own kernel for fun now and then.) They day was too full, I had packed too much into it. So I recommend leaving one or two days without any pairing session each month, to catch up with all the things that need to be done. Corey did the same thing, splitting his journey into tours of up to four weeks, and also Daniel Temme ended his Journeyman weeks after four weeks.

Week Number Six
The remaining days of the last week I visited SIB Visions, a company focusing on the simplification of the software landscape used to support business processes. The backbone of their application stack is the JVx Enterprise Application Framework which was open source right from the start. If you need to build a typical business application to edit data in table- or master-detail-style, this is the framework you want to use. Check it out!

First I paired with René Jahn, SIB Visions' Head of R&D. He had a list of things he wanted to discuss with me. We started with the build. I complained that it was too slow, running longer than a hour, and that there were failing tests. We immediately started fixing them. Then René showed me the framework and I was impressed. The JVx code-base is following a strict standard defined by René, covering documentation, naming and much more. While I did not agree to some of his conventions I did admire the consistency in the code base. I believe that consistency is crucial for quality of a code base, some time ago I even declared it the First Law of Code Quality. Well done JVx team, I like that ;-)

Then I worked with Martin Handsteiner, CTO of SIB Visions, on a particular tricky problem. A main class of JVx' data model had grown larger than 5000 lines and needed to be split. Due to performance optimizations it worked with plain object arrays internally, following the Flyweight Design Pattern, which did not make it easier to understand. We fought the beast for two days and were able to split away a few hundred lines of code. It was hard work, but just the beginning of a longer rework Martin had estimated to take two weeks. It should never have become that large and entangled in the first place. Martin had always wished for a keyboarder/keyboardist and a "mouser" and thus stayed in the navigator role for most of the time. While it was unusual for me to be the driver for extended periods of time, it worked out well because Martin knew the concept of his model and I was moving forward relentlessly.

Just yesterday I received mail from René telling me that his build now takes nine minutes, 900% faster than last week and that all tests are green. I was delighted. For the first time one of my hosts had taken my ramblings serious and immediately fixed the issues. Awesome, that is the right spirit. Keep up the good work!

Remote Pair Programming
Even more awesomeness happened at the weekend. My friend Thomas Sundberg asked me for help with his presentation on (Remote) Pair Programming at 33rd Degree for charity in Kraków, Poland. He needed a remote pairing partner for a small demo. We frequently do remote pair programming katas since more than a year and were sure we could pull it off. During lunch break we tested connectivity and the audio equipment of the conference venue, to make sure that everybody would hear me. During the demo we did a few cycles of TDD, discussing names and refactoring the code in ping-pong style as usual. I was sitting at home, still contributing to a conference talk - it was awesome!

Remote Pair Practice

Deep in my notes of past conferences I keep a quote that says Writing code together is the only true way that programmers communicate. Even if you do not agree, pair programming is still a great way to share with one another. Whenever I program in a pair, I learn a lot. Unfortunately I have a very little opportunity to do so as my team is distributed around the globe. After attending a Test Driven Development workshop at this year's GeeCON I decided to do something about it.

Schedule
I plan for a pair coding activity each week. This seems like a good target to aim for. To free one or two hours each week for deliberate practice should be possible for everybody. Unfortunately I do not reach my target because I might be busy, might still look for a pair or my pair might be busy as well. In the past I only managed to participate in a pairing session twice a month. By writing this post I hope to save time on explaining and to improve the frequency of my pair programming. I found it better to schedule throughout the day instead of the evening. It also seems easier to find a suitable time at work days instead of weekends. Keeping away from evenings and weekends helps because there are still people with some private life ;-). An appointment at a fixed day and time is an option when pairing with the same person again and again, but to meet with different people, one has to be flexible. I do not care for the time as long as it is somewhere in my (European) time zone. To find suitable times in advance I use Doodle.

Pair Programming
A lot of people are afraid of pair programming because they never did it. To get started you should read James Shore's description of Pair Programming from his book The Art of Agile Development. There is even a short summary consisting of 99 words for the people who do not have time to read. In the end the rules how to behave during pair programming, are about practising everyday civility, because all I really need to know about pair programming I learned in Kindergarten. So be especially courteous. Pair programming teaches us to collaborate. I recommend watching Angela Harms' presentation about the (social) anti patterns in pair programming, Does pair programming have to suck? Note that pair programming may be difficult and uncomfortable for the first few times.

Get-Together
Obviously we have to meet in order to pair. In the past I managed a few times to meet during lunch breaks and have a short pairing session, much like Code & Coffee. Now I always bring my laptop when I meet my friends for lunch, maybe he is interested in a spontaneous pairing session while eating?

Remote Setup
Meeting in person is preferable but not always possible. Remote pairing is mainly about the additional tooling and all rules from regular pairing apply as well. My friend Thomas wrote a good post about Pair Programing from which I took all the material of this section. We use Skype to talk and TeamViewer to share our screens. It helps to have Skype contacts exchanged in advance so one can start the remote session by sending a chat message to the other one. As soon as the line is established we discuss who will host the session. A good headset is recommended, otherwise the voice quality is poor.

Then the host starts his TeamViewer and sends his TeamViewer id in Skype. I never had any problems with TeamViewer and it works great, even when connecting Windows and Mac machines. TeamViewer is a commercial tool but free for non-commercial use. A pairing session is definitely for educational purposes, so I do not see any problems with the license. After connecting I recommend changing the resolution of the host machine to the maximum resolution supported by the client. As a client I use TeamViewer's options View > Original and and View > Full Screen to get rid of all these scroll bars. If I have an additional screen I put the Skype window and a browser window there, if I want to look something up quickly. This setup is much like Level Four Pair-adise, except that it is remote.

It happens that I would like to scribble something on a white board. There is a nice Web Whiteboard, which allows drawing and shared editing. It is as simple as a real white board. If you need something more advanced, create a new Scribble in Google Docs which allows shared editing as well. All these and even more advanced topics of remote pairing are discussed by Joe Moore in his excellent talk about Remote Pair Programming: People and Technology.

Code Kata
An educational pairing session looks much like a Coderetreat. We might do a code kata or whatever coding problem seems adequate to work on. A code kata is an exercise in programming which helps a programmer improve his or her skills through practice and repetition. When I meet someone new, I do not impose any special rules. We would just work on a kata, preferably one that we both know, using ping-pong styled Test Driven Development. Todd Sedano compiled a list of code katas sorted by how easy it is to apply TDD. Fizz Buzz and Prime Factors are too short, but all other katas beginning with String Calculator are suitable. In fact the size of the kata does not matter, because it is not about finishing, it is about improving.

The choice of programming language is not important to me. Although my primary language is Java, I have done katas in Ruby, Scala, JavaScript and C# as well as some other, less common languages. After choosing the kata, the language and the development environment to use, we need to agree on the focus of the training session. There are some variations of katas possible, e.g. to use a more functional programming style or not to us any primitives or conditionals, up to the (at least for me) extremely difficult TDD as if you meant it.

With Tomatoes
It happened that we would lose track of the time while focusing on the problem. Later, for example after working on the kata for two hours, we would "wake" up and be totally exhausted. To prevent this, and to create some space for chit-chat, I use the Pomodoro Technique. There is a break of 5 minutes every 25 minutes. I just watch out to stop the Pomodoro with a failing test, so we know where to continue after the break.

Conclusion
As shown my remote pair practice contains everything that is good and holy: pair programming, cool tools like video conferencing and screen sharing, coding, TDD, code katas and Pomodoros. Can you resist?