Cherish The Performer
Work in software development consists of 2 essential parts: planning and performing. This stands true for any methodology — agile, lean, Scrum, waterfall, or any other variety thereof. The theory of project management has it that ~10–20% of work time goes into planning, tracking, adjusting trajectory, wiping the binoculars, etc. The percentage varies depending on the project’s complexity and uncertainty. There’s some research that suggests the 20–33% bracket could be perfectly normal, too. How do we know, then, when too much planning is too much? And, more importantly, why do we need to be mindful about the activities that fall into the category of “planning”? The said activities usually include meetings, discussions, re-adjustments, more discussions, and on.
There appears to be just 2 modes of existence for planning, or, rather, for any activities that are non-related to performing:
Option #1: the oversized “talk-plan-remake-do it again” cycle is a given.
Option #2: over-indulgence with talking & planning is a waste.
The hardest job is to distinguish whether we are dealing with option #1 or option #2. If option #2 guises itself as option #1, the performers would roll their eyes at any attempt to entice them into more of talking and planning.
The unwelcome “talk-plan-remake-do it again” cycles might occur if/when performers want to get down to work, but still have to linger in meetings and discussions for reasons that appear irrelevant to them. I’m not going into what those possible reasons might be, for now, but apparently even a single pair of the rolled eyes means that the team has to check if they are on the same page about planning and discussions. Some people are naturally more inclined to performing solo, and their philosophy is: “I care only for what I have to ship, and I’d rather stay away from excessive talking.” And, this is completely understandable.
There’s nothing as fulfilling as a happy experience of a well-accomplished performance, and performers find delight as they ship something on any given day. The deliverable can be a piece of code, or those few milliseconds of faster load times, or a finished design element, or an HTML-coded web-page. If planning and discussions stand in the way of the collective desire to perform, your team might be in trouble. This feel might signal that the whole act of planning is somehow misinterpreted, and is seen as a thing-in-itself that lives in an isolated reality, unrelated to a shippable outcome. If that’s what’s happening at your organization, remember that the best talkers or planners may not be the best performers. The catch here is that with time some sort of an organizational blindness might develop, as talkers and planners appear to come across as performers. Beware that optical illusion.
