Have you ever found yourself in a situation that you are building software systems/applications but don't know the long-term vision yet ? Or you are asking Product to lay down the roadmap, but they are in the same boat as you because there are too many moving parts ?
Apparently this happens a lot, and there is a formal name for such kind of situations (which I recently found out about, and hence this article) - VUCA.
VUCA has been around for a while, since 1980s. It is an acronym coined by U.S. Army to describe a volatile, uncertain, complex and ambiguous multilateral world. Since then, this idea has since found its way in business world to describe situations; its drivers and effects. Taking a deeper look:
- Volatility - means while the situation is unexpected, it can be predicted and we can also identify its driving factors if it happens. Volatility usually refers to the rate and nature of change. For e.g.: an application may get impacted due to unexpectedly high number of simultaneous defects/bugs. It is expected that software will have bugs, but an unusual high number of bugs may require sudden re-routing of time and bandwidth.
- Uncertainty - A potential surprise; lack of clarity about current situation - unpredictability. This usually leads to increased analysis and effectively delaying action, thereby creating a catch-up mode for the affected system and people to deal with the situation.
- Complexity - The situation is complex because of several moving parts which have multi-factor interdependencies and relationships. For e.g.: A software application serving a business need which has too many variations per country, per segment or per use-case; such that every variation demands its own product discovery.
- Ambiguity - unknown unknowns. We have no understanding of situation, and nor it can be predicted. For e.g.: while we have view of what product view is present today, the future of an application/system is unknown and it depends on acceptance by customers.
Harvard Business Review published an article with a great summary view of VUCA.
Credits: HBR January–February 2014
Dealing with VUCA (in context of software development)
By now, we can probably correlate one or more above-mentioned descriptors to real-life situation at work. Here are some ways to counter VUCA:
- Counter Volatility with Vision - The vision refers to having foresight to deal with volatility. In this case, depending of nature of volatility the action may vary. If it is sudden demand in capacity and effort because of surge in defects, then we could route some help from other parts of development; or try to establish if there is a common root-cause to seemingly unlinked problems. It is also a good idea to foresee issues during development lifecycle and build necessary buffer.
- Tackle Uncertainty with Understanding - Look at industry architecture and references for inspiration and recommendations. Also keep a close keep a close eye on competition. In case if an uncertain situation arises, and we must react - then it is also important to segregate must-haves from nice-to-haves, and then formulate a winning strategy.
- React Complexity with Clarity - Build close partnership with Product so that one assumes as less as possible (design assumptions are the kryptonite of software development). Also, take a modular approach in building complex systems which can be moved around and glued differently if some assumptions change with lesser cost.
- Fight Ambiguity with Agility - Opt for iterative development by creating thin slices of deliverables. Also, keep the system agile by making it config-driven so that newer implementation strategies can be embedded easily.
It may appear that these strategies are overlapping, and it is okay for one strategy to fit multiple situations.
One does not need to be a doomsday prepper, but our world is increasingly complex and volatile, some of these practices will help in creating platforms/applications that have longer shelf life.
