Dealing With Complexity
Like the customers a product serves, software development is complex. This is due to a number of factors. To start with, it’s often difficult to be certain of cause and effect when offering a new feature or service. If a customer likes the simplicity of our product, but we interpret their satisfaction to reflect the options we’ve offered, we risk driving them away with increasingly involved features.
Unfortunately, customers don’t always know what appeals to them either. I’ve worked with organizations that replaced existing product versions only to have long-complaining users bemoan the change. Determining why a product does – or doesn't – fill particular needs can be challenging.
We also must remember that each change we make has the potential of introducing myriad other changes, needs, and preferences. When the first smart phones made hand-held computers available to the general public, few expected that navigation, weather, social media, and transportation apps would become ubiquitous. In turn, each of these apps introduced other services and applications now commonly sought after.
As a result, our approach to addressing the needs of customers should incorporate our understanding of complexity. For example, rather than launching into large, elaborate projects, it’s best to first probe for solutions to customer problems, sense responses to our probing, and then adapt to those responses. This increases the likelihood of keeping pace with perpetual change.
Sometimes, the easiest way to appreciate the intricacy of human beings is to try serving their needs. For example, it would be difficult to overestimate the complexity presented by child rearing. Parents of several children will find unique challenges with each of them. When a new child is added to a brood, the impacts on the child as well as their siblings are innumerable and often difficult to adequately understand, anticipate, or control.
When we choose an approach for a given child, it might be met with playful engagement, outright defiance, or some moderation between the these extremes. This experience could be the result of the child’s personality, the residual effects of some past experience, or any number of combinations of these influences. It is often impossible to determine what has caused a response to even the most mundane requests or directions given a child.
Software development can be similar largely because it involves an attempt to satisfy the needs of software users or customers. When we create a solution to a user’s problem, for example, it’s often difficult to understand if the user finds the greatest value in the solution’s simplicity, completeness, novelty, some other aspect, or a combination of any of these. Responses to a product can also be influenced by past experiences, biases, and expectations. For this reason, determining the value of a product with many users and uses becomes increasingly difficult.
Unlike raising a child, users and customers are generally able to express themselves. While this doesn’t eliminate the potential for confusion or unexpected outcomes, it does validate the Agile principle of working closely with customers on a daily basis; the more closely we engage with customers, the more opportunity we have to understand what they need.
This is an excerpt from my book Speaking of Agile.
