Department Kata: The Good and the Bad


As a department we decided to organize a “Team learning Kata“.
We would work on the ‘Game of Life‘ which is  is a cellular automaton game. The game is a zero-player game, meaning that its evolution is determined by its initial state, requiring no further input. One interacts with the Game of Life by creating an initial configuration and observing how it evolves, or, for advanced “players,” by creating patterns with particular properties. ¹

  • Work in Mobs (with Mob Timer )
  • Team up with co-workers you do not interact/work with often
  • TDD
  • Strict Navigation
  • 2 Languages ( JavaScript & TypeScript )
  • Work for 1 hr , then rotate to new team, new language and start all over
Expected Outcome

Some of the main focus for this exercise  were:

  • Navigation
  • Team communication
  • Articulate intentions
  • Common Understanding
  • Sharing expertise

To be honest I was not excited to participate since we have done this exercise last year. But after  reviewing what we accomplished and the obstacles we had to overcome I was reminded of some practices we try to implement as a Software Department such as stop the cross talk, no estimates and communication.

Group 01

Stop the cross talk

To start, I guess we were all just excited to begin and face the problem. We all began to navigate and try to implement our own method. After 3 driver rotations we decided to stick with strict navigation, because it was confusing for the driver what to implement. We continued to discuss and ask questions as to  what the navigator  decided to implement and to keep everyone engaged.

Personally I dislike strict navigation where one person is allowed to talk and make the decisions because that is not what we do in our working mob. We discuss the issue and agree on a solution and continue with one Navigator, as we did in Group 01.

Will talk more about strict navigation later……

After we decide to implement “strict navigation”, everything went smoothly. Slow and steady, we continued working.


When time was up, we were assigned to a new team. As I gathered my stuff I reviewed what we accomplished and what obstacles we encountered. As I moved to my new mobbing station I (forgive me Woody for I have sinned) estimated we would accomplish more in Group 02, boy was I wrong.

Group 02

Estimate Continued…..

I thought we would accomplish more in Group 02. I mean we did work on this already, we know what to do, what could possibly go wrong *in a sarcastic voice*. Well it seemed that some of our members never worked in JavaScript before and this slowed us down. We also had different ideas to handle the issue. Even though we worked on a similar (or even the same) problem, we do not know the unknowns and cannot use previous experience to estimate.

STRICT! Navigation…..Yuck

Once we settled in our new mobbing station we began to face the same problem but in a new language. I was first to navigate and decided to ask a question.

“How do we want to implement this…..”

I explained how we implemented in my previous team and also asked if they had a better way than mine. I wanted to review and get ideas from the rest of my team. But Mobber X said:

“I don’t know, your the one navigating.”

At first I wanted to explain why I wanted to review. But I was tired, it was Friday, there was only an hour left of work so I played along. So I continued with strict navigation and started to implement the same way as my previous mob.

After each rotation, the next driver always asked:

“What was your thought behind this,”

The previous navigator would explain, the new navigator would take time to understand, then (with the little time left in the rotation) continued to implement…… then repeat. We decided to add a retro into the rotation, and when the time arrived our Senior Engineer asked:

“Any comments or concerns of what we did”

And Mobber X said:

“I feel like we all have different ideas, and it is confusing to see what we are trying to implement….”

Now I’m not saying strict navigation is not helpful, there are benefits in using it such as trying to stop the cross talk (Group01) or help someone learn from other mobbers (Group02).

Since one of the main focus of this  exercise was communication, I believe using STRICT navigation (where only one person talks and make the decisions) is not the way to go. As we saw in Group 02, Mobber X  enforced STRICT navigation then had trouble to understand what the other mobbers were trying to implement.


This department learning session reminded of principles we practice in our department. Even though I felt like I was not going to learn anything, it made me realize why we try to implement these practices as a Software Department.