Thursday, March 9, 2017

Last Week's Lessons On Pairing, Mobbing and Collaboration

Last week I experienced three great examples of collaboration. Although quite different, all of those proved insightful and fun.

Performance Spike

Our application is currently performing poorly, to the point that we get complaints from our users. Although we had been aware of the situation slowly getting worse, there simply had been more value in working on other topics with higher priority. Now we have to pay the debt for this decision. To identify the major root causes, we agreed on doing a spike with the whole team, having everybody work on the performance topic for two days.

After an initial brainstorming of potential root causes, we split up to investigate the areas where we suspected the highest improvement potentials. Some people started working on their own, some in pairs. I happened to pair up with a programmer, profiling the application as well as implementing and testing quick wins. I really enjoyed this quite rare experience to pair up on doing hands-on stuff. Normally we only pair up on demand, when clarifying questions, discussing tests, or reproducing an issue. This time we could instantly share knowledge on how we approach problems, how we use tools, where we suspect which kind of issues. Sitting together and directly improving the product was great and just felt right. The other pair also heavily appreciated the joint effort as they could share knowledge and experience and help each other grow.

My personal lesson learned: Pair up more often in the team; the programmers among themselves, but also I as a tester together with a programmer.

Coding Dojo

As one of my colleagues put it: "You're all over the place, right?" Well, at least I try to get my hands on as much knowledge as I possibly could. Last week I finally took the chance to attend a coding dojo for the very first time. I always shied away from this kind of experience, considering my programming skills still being on beginner level. However, one of my resolutions is to get out of my comfort zone more often to give myself more learning opportunities. So I contacted the meetup organizers, asked if they would have a beginner and was welcomed to join.

At first I felt a bit strange among all those developers, but quickly learned I was not the only one without strong programming skills. We split up in groups of four people. The organizers explained the rules and approach. We were supposed to do strong-style pairing, taking turns every 5 minutes. The navigator should give the directions of what to do to the driver at the keyboard, with the other two people listening and preparing for their turn. We were instructed to write our tests first and to only switch when tests are green; so if the timebox was over and the implemented solution caused a test to fail, it had to be reverted.
setup practice session at http://cyber-dojo.org
My group had a rough start. None of us was used to this style of working and we really had to discipline ourselves to keep the driver from coding away without the rest of us following. As a navigator, we faced the challenge how to express our intentions well enough that the driver knew what to do. For example, not all of us were familiar with the chosen programming language and IDE. It also required us to structure our thoughts first to provide clear directions. Another thing was team dynamics. One of our group resisted to take over the keyboard at first, getting upset with the format as he had come to the dojo with quite different expectations in mind. We could convince him to give it a try and managed to find a way to collaborate. But this incident taught us how important it is to have buy-in from the whole group.

Everybody was really patient with each other. After the first struggles, we quickly found a kind of routine and were able to solve all given katas. It was a fun experience and we could share and learn a lot during the whole exercise. As we have been a group instead of just a pair, I realized that this actually had been my very first mobbing experience. I loved it and I'm eager to try this with my own product team.

FlixTech Hackrday

My company declared every first Friday of the month as hackrday. Everyone can bring up ideas, pitch them to have others join, implement them and then demonstrate the results at the end of the day.

Last hackrday I was a bit upset that some of my teammates did not join. This time I was even happier that one of those not only joined but pitched his own idea! He came across Gource, a tool enabling you to visualize the history of your git repository. A great thing to show everyone what we do all day! To take it further and learn about stuff we're normally not getting our hands on, we decided to use an Amazon Echo device to trigger the visualization by providing the parameters via voice input.

Beginning of the day, we started with only three people on the team. We first discussed the planned architecture and split the work into three independent areas to work on separately, with each one triggering the next one. We wanted to get a very minimal product done as soon as possible to be able to get early feedback. I volunteered to investigate how the voice input can be configured and how to define parametrized "utterances". Meanwhile a colleague from Berlin announced to join us, so I spontaneously paired up with him remotely. The next programmer managed to jump in as well and paired up with another one working on an AWS lambda function to take the voice input parameters and send the corresponding messages to Amazon SQS. As the voice input part was ready to go quite soon, the Berlin colleague and I teamed up with the other two to get both parts integrated. Two pairs together made four. Having finalized the integration, we joined our fifth colleague working on the crawler application polling on SQS and triggering the visualization according to the provided parameters. And suddenly we were all working on the same topic at the same time. Like an emerged informal mob. Testing, fixing found issues right away, testing again, and doing anything else together.

And guess what: We had so much fun learning on our way, testing our implementation, and building a first minimal solution to demonstrate the endless possibilities when talking to Alexa. Together.

Any Conclusions?

Product development is all about the people. Pair often to share knowledge and bake quality in. Give strong-style mobbing a try and find your ways and routines. And go with the flow if you find yourself pairing up with more and more others until you happen to work together as the whole team. Many good things emerge of close real-time collaboration.