Last December 14th we gathered in Quito to have a code retreat, where the big winners were TDD and Pair Programming. How did we get to this conclusion? Well, by using retrospectives to ask people what they liked and what should be changed for the next session. Here is the sequence of fun retrospectives we used at the GDCR13.
Lucky for us that Paulo Caroli was visiting the TW Ecuador office, and helped to plan the sequence of fun retrospectives we should use to improve the subsequent sessions and to gather new ideas for the next year. The “planning session” included energizing people at the start of the day, checking after every session what was working and what wasn’t, and, getting ideas for the next year along with feedback on the organization.
I got your back buddy
The way one kicks off the first session is crucial to setting the tone for the day and to get everyone’s energy levels up. Encouraging “pairing” is an important part of the GDCR and so we picked an appropriate energizer – “got your back”.
This energizer consists of finding a partner, sitting down on the floor and working together to stand up. Very simple, yet fun. It helps to break the ice and gets people to be comfortable with each other quickly.
Gathering data from every session
As the format of the GDCR goes, we then had a few sessions of programming one after the other. This provided us a great chance to take action based on the retrospecting right away, and thus make every session a bit better than the previous one. So we picked an activity that was focused on gathering feedback and simple enough to finish it in 30 minutes or less — WWW: Worked Well, Kinda Worked, Didn’t Work.
This retrospective allowed us to see how some topics that started as a “problem”, changed to be the very things that people liked at the end of the day. It also demonstrated that as technical problems disappear, people started to focus on the domain problems at hand.
The first round resulted in people focusing on the time available to solve the problem and they found TDD (Test Driven Development) a bit difficult to follow. However, people who had already practiced TDD found it to be a concept that worked.
After the second round TDD disappeared from the “didn’t Work” column and had more voters in the “Worked well”. We also noticed that the acceptance of TDD was closely related to Pair Programming.
The time for each session was still felt as too short and not knowing the programming language started to show up as an issue.
A parenthesis to organize the pairs.
As most of the people agreed that pairing is working well, we had to devise a way to make sure partners were not repeated, so a pairs’ matrix came in handy.
While building this matrix we realized something: we didn’t know everyone’s’ name. Best way to solve this was to have a Zip Zap Zoom energizing activity!
Last round for improvement
By the end of the third round, the programming language, which was changing often till then, was the one every pair felt the most comfortable with. The rules of the game showed up in the “didn’t work” column, this showing that focus has moved from learning syntax of a new language to solving the problem. And to solve it, TDD and pair programming proved to be of most help – a very happy ending.
Helpful Tip: Maintain color-coding for the posts and keep it consistent, so as to easily relate the results from one session with another when you put the pictures together for analysis.
Time for new ideas
When the time to leave had come, we had the chance to review the whole day and find new ideas for the next time. A good retrospective technique with this goal in mind was the thumbs up, thumbs down, new ideas and recognition.
It was good to learn that people liked the food, liked learning TDD and sharing some lines of code with people they didn’t know before. On the down side the feedback was that we needed more assistants and that 45 minute sessions with unknown programming languages work against getting the problem finished.
For the next year, the main suggestion was to go big on publicity: several emails, tweets, likes, posters in schools and the like. Also, introduction to new languages before putting them into practice was recommended.
Finally, before going home, we wanted to know if spending 8 hours of your Saturday coding was worth it. This is asked in five minutes with Feedback and ROI.
Good thing it was 🙂
Thank you for enjoying programming with us as much as we enjoyed pairing with you all!
See you all next year.