The Risk of Overemphasizing Risks
When I was in college I spent some time doing tech work with a theater group on campus. Occasionally, one of the members of the group who was a mechanical engineering student would comment that some poorly thought-out approach would not work, saying, “Physics is against you.” This often saved a fair amount of trial and inevitable error.
As developers and engineers who build software systems, we are trained to identify and evaluate risks. This sort of risk analysis prevents teams from making costly decisions that are unlikely to work, saving time and money and helping the team move forward to create value.
However, a risk-avoidance mindset can also stop progress. Successful agile teams embrace an approach that sees risks as ways of starting a conversation, rather than stopping it.
Planning meetings are one context where a risk-avoidance mindset can be particularly disruptive to an agile team. Consider a scenario where a product owner proposes a user story for which the team sees unintended consequences. One approach could be to raise the concern and stop. This prevents the team from potentially doing something costly, but it also stops progress.
Another option is to use the risk to explore the elements of the story. Perhaps the team does not have a good sense of the why behind the story. Or perhaps the story is too large and there is a smaller, lower-risk story that will allow the team to better evaluate the risk. It’s also possible that the team misunderstood the business scenario, and thus the risk. A user story is an invitation to a conversation, and it serves the project when the team tries to keep the conversation going.
Aside from the vague advice of keeping an open mind and an adaptive mindset, there are some concrete things to do to get past using potential problems as an excuse to stop the conversation. One approach is to keep the “yes, and” improv technique in mind. Rather than starting a response with “No, we can’t do that,” consider acknowledging the problem and proposing alternatives.
Focusing on solving the customer’s problem rather than the exact details of the user story can also help; often there is a gap between wants and needs, and it’s not uncommon for user stories to start with wants. Encourage experiments, because your analysis could be flawed, so you may learn something from the data the experiment yields. And when you raise a concern, try to clearly express what problems you foresee and why, as this will help the team understand your thoughts—and perhaps identify flaws in your reasoning.
While some problems are not easily overcome—because physics may well be against you—it is more effective to start with an approach that creates opportunities to explore possibilities and gather data, rather than to simply raise flags and move on. Walking into user story refinement and planning meetings with a mindset of wanting to create a useful solution rather than mitigate the risks you see can be difficult, but it will encourage an agile environment that creates value effectively.
