Marco Polo And Software Development

The game of Marco Polo comes back to me from my childhood. I remember being blindfolded and reliant on auditory cues to catch another player. I’d run around shouting “Marco” and then chase the obligatory “Polo”. Given enough time I’d catch someone and they would take their turn being Marco. The game is entertaining because everyone is constantly moving, by the time Marco gets anywhere close to the source of the original “Polo”, the target has moved.

This reminds me of what frequently happens with software development. Regardless of organizations using the stricture of waterfall or the versatility of agile methods, the result is all too often like a game of Marco Polo: chasing perpetually moving targets.

Why? Because organizations rarely ever share the purpose of the software they’re creating with the engineers creating it. Instead, players (engineers) are blindfolded by layers of management micromanaging every single task (put a green button here, show a table of data there, and put this in the footer). Even with the leanest approach, players can’t find out that what they were told to do is irrelevant until they finish their tasks and call out “Marco”, only to find the resulting “Polo” has moved. Development becomes a game of chasing moving targets. Compound this with the likelihood that no one has scrutinized the purpose and therefore it’s likely a moving target as well.

Fortunately, avoiding this is rather simple. We need to clearly define the purpose of the software and make that the target. Purpose is the impact on our customers, not a task or a feature. We need to leverage the expertise of everyone to scrutinize the purpose. We may not get the target exactly right, but we’ll be pretty darn close if we’re not blindfolded. Since we’ve liberated our senses, we can continuously make small course corrections and be much more likely to hit a valuable target.