This past few days, I lived through two more examples of the need for my Conversational Meta-MethodologyTM ;-) as an essential adjunct to Agile methodology. While hashing out a design problem with the team (details not relevant to my point), I got hung up on interpretation of an issue that had (in my mind) significant performance implications. My way was the best way, of course, and others involved in the discussion were wearing blinders.
It turns out the other members of the team were on the right track, and the aspect of their view of the design with which I had a beef was necessary. The reason I was so recalcitrant, it turns out, is simple: I was thinking in Oracle, but the project is adhering to SQL-92 because its raison d'être is to federate heterogeneous data bases hosted on diverse platforms. Although I myself use the term "SQL-92" on just about a daily basis on the project, I was assuming a key portion of the algorithm was implemented using Oracle-specific SQL constructs related to generating XML result sets. Duh! XML didn't exist in 1992!
My mental model of the algorithm had a built-in tacit assumption based on my own past experience, an assumption that led to an erroneous viewpoint with respect to the problem at hand. Only through conversation did this come to light -- probably a longer conversation than necessary due to my having had only five hours of sleep the night before and a fairly stressful Pilates class before work, but that's another story.
The other situation was, on the surface at least, more serious. We committed as a team to a deliverable in the last iteration, the responsibility for which fell on one person's shoulders, as it happened. Our customer considered that we failed to deliver, as did most of our team. The nominally responsible party was off on a long weekend while the team got a severe oral beating for the missed deliverable.
It turns out that the problem was, once again, a divergence between the mental model of the responsible party on the one hand, and on the other hand the apparent consensus of mental models among the customer and other team members. In retrospect it was a legitimate difference in definition of terms based on prior experience of all the participants. The failure was systemic -- as a team, we were not defining clearly enough the requirements for that deliverable. The user story could be read in two ways, depending on whether it was read from the viewpoint of a sysadmin or application developer or consumer. The work was completed, for good reason, just barely in time for the party to leave on vacation, so there was no time for a "mini-iteration" prior to the milestone deadline.
More lessons given to us in the school of hard knocks -- time will tell if they are lessons learned for the team. I think they will be lessons learned.
Comments