Traffic in India

I recently spent a week Mumbai. While stuck in traffic during a tour of some of the incredible sights, our guide stated that in Mumbai there were three certainties, death, taxes and traffic. With the sound of auto and truck horns ringing in my ear, that statement rang true.  On reflection, I would add change to the list of certainties, whether in Mumbai or as a general attribute of all human endeavors.  Software development and maintenance are no different. Over the past few weeks, this blog has extolled and then pilloried the virtues of both big bang and incremental change approaches (and by inference everything in-between). In the end, there is no perfect approach that fits all scenarios. How can we decide which end of the change approach spectrum will work in any given scenario?  The answer is not as straightforward as a checklist or decision tree, rather three interrelated concepts must be weighed when deciding on a change approach. The three are the organization’s propensity to fall prey to change fatigue, the possibility of tunnel vision and the tolerance for dealing with Watts Humphrey’s requirements uncertainty principle.

Change fatigue occurs when the combination of a high pace of change and a negative perception the value or success of change, collide. One of the mantras of the software development industry is that the pace of technological change is fast and getting faster. One form of evidence of the pace of change is that nearly every person has to reinvent themselves at least once, and often many times.  This constant change churn sets the stage for the propensity for change fatigue to pop up at a moment’s notice if they feel they are working toward change don’t they see as successful or valuable (either to themselves directly or to their organization). In organizations with this smoldering change fatigue lurking below the surface, slowing down the rate of change by consolidating smaller (more incremental) changes can be a useful strategy.

Tunnel vision is a singular focus on one thing to the absolute exclusion of everything else. In medical terms, tunnel vision is not considered a positive.  In the business and IT environment, the medical definition is often confused with the more sought after the concept of focus. While it is easy to see a relationship, they are not the same. When focus crosses the line and causes an organization to neglect or ignore other important priorities, focus becomes as destructive tunnel vision. One of the attributes of a big bang change program is that it is often too big to fail.  When an organization develops tunnel vision and begins to ignore feedback, they have entered the danger zone. An organization’s culture can be a powerful tool to predict whether tunnel vision is a major risk.  Organizations that have an extreme fear of failure or pride themselves for persevering at all odds are apt to fall prey to tunnel vision.  Early in my career, I worked for a firm that proudly stated that if any of their projects got into trouble they would “darken the skies with engineers.” This almost always busted the budget and was career limiting. The two competing cultural components tended to cause leaders to block out negative feedback.  The culture fostered tunnel vision.  In those cases having a focus had became tunnel vision. The managers and stakeholder put blinders on and ignored feedback until it was too late to correct their course. If an organization is at higher risk for tunnel vision due to its culture, incremental change approaches are a tool to create a mechanism to break the focus and challenge the vision and to generate and interpret feedback.

Watts Humphrey, the founder of the Software Engineering Institute and contributor of some of the most significant thought leadership to the software development over his lifetime, established the principle of requirements uncertainty.  In its very simplest form, the principle can be stated as “they won’t completely know it until they see it.”  The amount of uncertainty establishes how far into the future a project team or organization will comfortably commit to a direction.  The more uncertainty the shorter amount time into the future a team can commitment.  This requirement uncertainty principle screams incrementalism.  As Todd Field suggested, “a short commitment cycle (incrementalism) does not preclude a longer term vision” (watch the tunnel vision).  Several frameworks for scaling Agile build this risk mitigation cycle into their methods.  For example, the Scaled Agile Framework Enterprise (SAFe) is built around a process that recognizes uncertainty. SAFe includes a long-term roadmap for each product.  The roadmap becomes less specific the further it extends into the future reflecting uncertainty. Specific program increments (PI) define what will be delivered over a 90 (ish) day window reflecting more certainty that comes from a short, fixed time horizon. In a further attempt to reduce uncertainty, the PI evolves based on the feedback and results from short sprints or iterations. SAFe represents a hybrid approach that mixes big bang and incremental concepts. The process provides organizations a way to define what they intend to deliver in the future while accepting that real life creates situations that need to be addressed.  The more uncertainty a change program faces the shorter the increment of commitment should be.

The state and culture of the organization or team has or can have a large impact on whether a Big Bang approach or an incremental approach makes sense.  I think the most succinct answer I got when I asked which change approach made the most sense was from Lee Copeland, Talent Scout at TechWell, Lee answered with one word, “depends.”