A Week of Learning Agile Development

Lamak Qaizar
Tech @ Careem
Published in
4 min readJan 3, 2021

Away from the hustle of production work, we organised a series of team activities to grow our agile development capabilities. Each full-day of activity was themed:

  • Day 1 — Refactoring
  • Day 2 — Code Smells
  • Day 3 — Testing Legacy Code
  • Day 4 — Simple Design
  • Day 5 — Mob Programming

We kicked off each day with a book reading activity. Reading was intertwined with discussion and was followed by a coding kata — an exercise that reinforced learning by practice.

A short retrospective meeting to gather reflections and learnings brought each activity to a close.

Learning Week was held remote-first on Zoom and all activities were group-based —i.e. reading and programming in either one large group or several smaller teams. For these smaller groups, we used Zoom’s breakout rooms feature.

Want to run these activities for your team?

If participants are not familiar with Pair Programming & TDD, consider including relevant introductions. Participants in our case were a budding XP-team with a year of practical experience.

Refactor cat. Photo by Zainab Jalali

Day 1 — Refactoring

  • Group-reading: Design II — Refactoring from Agile Technical Practices Distilled. While reading, participants discovered heuristics such as Object Calisthenics & duplication, and techniques to refactor (Safe Refactoring & Parallel Change).
  • Participants were introduced to 5 atomic refactors: (1) Rename, (2) Extract, (3) Inline, (4) Move, (5) Safe Delete. A look-up table was provided with keyboard shortcuts for reference.
  • Kata: Yatzy Refactoring Kata

A few thought-provoking excerpts from Chapter 2: Principles in Refactoring of Refactoring: Improving the Design of Existing Code were shared with participants through the day:

“But doesn’t the time I spend on refactoring reduce the speed of development?”
“How to tell a manager about refactoring?”
“Refactoring can be a fantastic tool to help understand a legacy system …”

Day 2 — Code Smells

Participants added Code Smells to their refactoring tool-kit.

  • Group-reading: Chapter 3: Bad Smells in Code from Refactoring: Improving the Design of Existing Code, followed by Design III — Code Smells from Agile Technical Practices Distilled. Participants discovered the catalogue of refactoring recipes in Martin Fowler’s book.
  • Kata: Smelly Tic-Tac-Toe — participants used the following commit convention: [code smell] message, for e.g. [primitive obsession] wrapped float as Amount.

Day 3 — Testing Legacy Code

Tests were already written for coding exercises on previous days. Day 3 asked the question: What if we don’t have tests?

  • Group-reading: Chapter 1: Changing Software and Chapter 2: Working with Feedback from Working Effectively with Legacy Code, followed by Testing Legacy Code from Agile Technical Practices Distilled.
  • Kata: Ugly Trivia Game — writing a Golden Master test.

Day 4 — Simple Design

Besides introducing the principles of Simple Design, we set out to build a habit of experimentation & improvement.

“After deleting and starting again enough times, I’ve often heard people say they have a feeling of freedom they’ve not experienced before.” — Corey Haines

  • Group-reading: Good design? and 4 Rules of Simple Design from Understanding The Four Rules of Simple Design, followed by Classic TDD I and Classic TDD II from Agile Technical Practices Distilled.
  • Kata: 4 sessions of Conway’s Game of Life, 45 minutes each. This followed the Code Retreat format: code was thrown away & pairing partners switched after each session.

Constraints

Participants were given a constraint in each session to break out of habitual code & design practices.

  • Session 1 — TDD, driver/navigator rotation in five minutes (or less)
  • Session 2 — ≤ 3 lines per method, no variable reassignment
  • Session 3 — Evil mute ping/pong. One person is a test-redder, and the other a test-greener. The test-greener does not care about requirements and will get tests to pass any which way. Partners cannot talk to each other.
  • Session 4 — No if/else, no loops, no getters (Tell, Don’t Ask principle)

We adapted constraints after each session based on progress. More constraints can be found on coderetreat.org, along with a facilitation guide.

Reflections

  • Cyber-Dojo allowed for a low overhead pair programming experience, i.e. no IDE quirks, no git commands and a simple way to throw away code by closing a browser tab. The downside was the lack of refactoring support. We switched to an IDE with git for our last session.
  • Groups may require a nudge to follow a constraint or discover an insight during sessions. We started with 1 facilitator and 4 pairs, before shifting to 2 mobs in the last session. The last session yielded better engagement between facilitator and groups.

Day 5 — Mob Programming

Participants chose what to do on the final day: refactoring the Ugly Trivia Game from Day 3.

A single mob formed with five to eight members throughout the day. Driver/navigator roles rotated every five minutes, with a primary-navigator selected to avoid overwhelming the driver. Drivers would be rotated into the primary-navigator role.

We experimented with mob.sh for quick handovers. It turned out to be a nifty tool: keeping time and managing the sequence of drivers.

Code changes were deleted at the end of each rotation if tests were not green, encouraging participants to use safe refactors.

Book references

--

--