Don't be like Homer Simpson

"In times of trouble, go with what you know."
--Homer Simpson

Words of wisdom from a notoriously brainless cartoon character seem like an oxymoron -- and in fact that is the case. Unfortunately, Homer's prescription is something I experience over and over again with client organizations. In the midst of a difficult and challenging change, like moving the organization from a sequential development process to Scrum, there is strong temptation to fall back on old habits of mind. Whenever things get uncomfortable, whenever Scrum makes a long-standing problem unbearable, the knee-jerk reaction is to ditch the part of Scrum that "caused" the problem and revert to a previously learned behavior.

One example I have experienced repeatedly is the problems caused by a widely distributed Scrum team, that is, one with some team members in North America while others are in China or India. I recently ran across an issue in which the more experienced North American team members were attempting to work with freshly minted graduates in China who lacked even the slightest shred of domain knowledge. Since the time shift in this case was exactly 12 hours, it was impossible for the team members to work together closely. Not only were there twice-daily hand offs of code between team members in the different geographies, there was also the issue of the Chinese team members lack of experience in the domain.

The response from the domain-expert team members in North America was to clamp down process on their young Chinese peers. Over time, many gates had been constructed to prevent the Chinese team members from doing any damage to the code base. By the time I arrived on the scene, the gates were so restrictive that the Chinese side of the team -- and make no mistake, each geography had taken sides -- was unable to do any work at all. Even the simplest tasks were impossible to complete without involving the North American side because of the gating requirements.

A better solution, which the organization actually implemented, was to create separate North American and Chinese teams. While this by itself did not solve the bigger issue of domain knowledge being restricted to the North American team, it did allow both teams to work with a degree of independence and to finish the work they committed to each Sprint. The one major adjustment was to have the Chinese team work in one-week Sprints while the North American team worked in two-week Sprints. Shorter Sprints forced the Chinese team to break its work down into very small bites that the North American domain experts could then help with during the short window of overlapping availability each day. By limiting the range of variability -- implementing one-week Sprints -- the organization was able to move forward with new feature development much more quickly than had been the case with a distributed team and a multiplicity of gates for the Chinese team members' work to pass through. The organization also unknowingly implemented one of W. Edwards Deming's credos, that of changing the system to reduce variability. More on that topic in a later post....

All for now....

...-.-