Degrees of uncertainty
After introducing the concept of uncertainty as the unifying main driver of rethinking IT, I discussed the basic approach how to act under uncertainty in the previous post.
In this post, I will discuss that not everything is equally affected by uncertainty and how we need to respond differently to different levels of certainty and uncertainty.
From certainty to uncertainty
As I wrote before: Uncertainty is the unifying driver of rethinking IT and we need to rethink basically everything that we became used to in the last 50+ years in IT – and we often hold dear.
But before I will dive deeper into the rethinking IT in future posts, in this post I want to make clear:
Not everything is uncertain.
Yes, uncertainty is or will become predominant in many places inside and outside of IT and we must be able to respond to it adequately to survive as a company. Yet, we also need to realize:
- Certainty still exists and the approaches that are great to address uncertainty usually do not work very well in environments dominated by certainty.
- Uncertainty comes in many shades. Things can be a tad uncertain, quite a bit uncertain or even massively uncertain.
I wrote about industrial markets, post-industrial markets and the startup working mode before. All of them bear different levels of uncertainty. Still, it is important to understand that these markets and corresponding modes are not mutually exclusive but rather define a spectrum. 1
I also mentioned in prior posts that sometimes markets are kept inefficient artificially (via regulation, high entry barriers, monopolism, lobbying, etc.). Thus, even if a market generally has post-industrial properties, it can present itself differently sometimes – again in varying degrees.
Additionally, different projects inside the same company can exhibit very different characteristics, just depending on the mission of the project. It is important to understand the degree of uncertainty associated with a project. Otherwise, very likely we will address it in the wrong way.
To illustrate the problem, let us have a brief look at a few example projects:
- Implement a new legal regulation into the existing systems (e.g., a new customer documentation law in banking).
- Replace a system that has reached its EOL (end of lifecycle).
- Extend or improve an established business offering (e.g., a new tariff plan generation in telecommunications).
- Create a new digital interaction point for an established business offering (e.g., a subcontractor self-service app in logistics).
- Grow a successfully launched new business offering (e.g., the “lifeworld” initiatives that many insurance companies started lately).
- Explore a potential new business offering (e.g., what many companies try to do in their “innovation labs” and alike).
- Create potential new business offerings (e.g., coming up with potential business offerings based on the vision “create a better world for our children”).
All these types of projects could occur in a single company, and there are quite some companies where all those project types actually occur. All those projects face different degrees of uncertainty, ranging from not containing any uncertainty at all (#1) 2 to being extremely uncertain in many ways (#7).
Unfortunately, quite often companies have a single software development process, and all software development projects need to adhere to that process. No matter if they use a traditional process framework or some flavor of “Agile”, it is a one-size-fits-all approach for all their projects, no matter what uncertainty properties they exhibit.
Different value maximization approaches
It should be obvious that it does not make sense to address all the listed example projects the same way if you want to achieve a good effort-value ratio.
If you have a completely certain project it does not make any sense to tackle it using an approach that is optimized for addressing uncertainty. Instead, we should focus on maximizing efficiency. We know for many years how to do this best: Extensive planning upfront. Creating a detailed plan. Then executing the plan step by step. A rigorous controlling to detect and readjust unwanted deviations from the plan.
I often surprise agile hardliners with the statement “It is perfectly fine to use waterfall (if the context fits)”. Waterfall 3 is based on the assumption of complete certainty: Everything necessary for planning is known upfront and requirements do not change in the course of the project. In such a setting, waterfall is the most efficient and thus most valuable approach existing.
Still, such a perfectly certain context rarely exists. Most contexts bear more uncertainty. Either requirements remain unknown upfront no matter how hard we try to discover them and can only be detected in the course of the project using internal feedback loops 4. Or you can only learn from external feedback loops, collecting the (unpredictable) user responses to your ideas (hypotheses), based on repeatedly deployed versions of your solution 5. Depending on your task you may be affected more or less by both types of uncertainty and need to respond to it.
Moving from project example #1 to #7, you need to give up more and more of the certainty-driven, plan-based approach and utilize more and more of the uncertainty-driven approach as I introduced it in the previous post: treating requirements as hypotheses, take small steps and collect external feedback often to learn and adapt early in order to avoid bigger misinvestments.
Software development approaches
If we break down this general observation to concrete software development approaches, we can arrange them along the certainty-uncertainty axis.
Here I use a rather simple and coarse-grained schema to arrange the different approaches. The intention is to illustrate the basic idea, not to create a perfect schema that takes all particularities of all approaches into account. This would require a much more complicated picture that would obscure the underlying idea. Thus, if you should feel like putting an approach more to the left or to the right, that’s okay. Again, it is about the illustration of an idea, not about a perfect arrangement of software development approaches.
On the left hand I start with approaches that work well under certainty. Usually, their focus is on optimizing costs, i.e., to implement a given fixed set of requirements as cost-efficiently as possible. In some other contexts, their focus is on repeatability (which obviously only makes sense under certainty). Typical representatives of this class of approaches are the aforementioned Waterfall model, the V-model or SAFe 6.
The enterprise “Agile” approaches accept a bit of uncertainty. As I stated in footnote #5, their typical implementations only focus (more or less) on the problem of unknown requirements, but neglect the uncertainty introduced by dynamic markets 7. Typically, they have a strong focus on optimizing costs while allowing a bit of uncertainty regarding requirements. The latter usually is addressed by over-the-time requirements refinement and a few internal feedback loops. Typical representatives of this class of approaches are Scrum or LeSS.
The next class of approaches support quite some uncertainty regarding implementation. The general goal of the project is clear-cut, but there are lots of external unknowns regarding the concrete measures, i.e., features and their implementations, to reach the goal. They must be explored in a sequence of small steps with lots of feedback from the market.
From a software development perspective this means a focus on flow. The goal is to minimize the time from asking customers a question until they can answer it – which is needed to test hypotheses (see the previous post for more details). The time from question to answer includes the time the accompanying software implementation needs to move through the IT value chain.
Hence, minimizing the time from question to answer requires minimizing the time through the IT value chain – which means a focus on flow. Typical representatives of this class of approaches are DevOps or Lean.
While the previous class of approaches tries to achieve short cycle times without compromising quality, there are contexts where fast learning via very fast feedback is king while quality has a subordinate role. Often you find these conditions in startup contexts where finding a product-market fit before the funding runs out is the single most important goal.
In such a context, there is not only a lot of uncertainty regarding the features and their implementations. You even do not know if your general goal is viable. Approaches like Developer Anarchy as described by Fred George that focus on extreme short external feedback loops can be useful in such settings.
Finally, on the very right side of the axis you do not even have a clear goal but are still looking for it. In terms of uncertainty this is the highest level of uncertainty. You usually have a vision like in the example project #7 but everything else is still undefined and thus uncertain. If you are in this place you should abstain from developing software and focus on finding a goal that is worth testing. This is the domain of innovation approaches, not software development approaches.
Picking the right approach
As you can see, the project context changes drastically while moving from the left to the right and obviously there is not an one-size-fits-all software development approach to handle all those contexts. Instead, to address a given project the right way, you need to understand its degree of uncertainty first and then choose a fitting software development approach. I.e., the software development approach follows the project characteristics, not the other way round.
Unfortunately, many companies still try to impose their single one-size-fits-all software development approach to all their projects, no matter if it fits the project characteristics or not. 8
The key is to understand where you are in terms of uncertainty and then pick an approach that suits your needs. No approach fits everywhere. Each one has its sweet spots and its weaknesses. Thus, know a set of different software development approaches and where they fit best, be receptive for the project context, especially its level of uncertainty, and then choose the approach that fits best.
In this post I discussed that not everything is equally affected by uncertainty and how we need to respond differently to different levels of certainty and uncertainty.
I provided a few project examples to illustrate the range from certainty to uncertainty – from projects that bear no uncertainty at all to projects that bear so much uncertainty that it does not make sense to start implementing software yet. By looking at these examples we saw that certainty and uncertainty are not a strict dichotomy but rather form a spectrum.
Therefore, it does not make sense to go with an one-size-fits-all software development approach as we see in many places. Instead we need to understand the degree of uncertainty of our project and then pick the software development approach that meets our needs best.
There is no one-size-fits-all, but only a fit-for-purpose.
With this post, I would like to finish my initial introduction of the concept of uncertainty. I started with introducing the concept of uncertainty, continued with the basic approach how to act under uncertainty and ended here, extending the picture to a range from certainty to uncertainty with many grades between them.
I will come back to uncertainty and its consequences many more times on the future. But for the moment, I would like to leave it here and hope that these posts gave you some new ideas to ponder …
On a conceptual level it is important to clearly distinguish the different markets and working modes to understand their disparate characteristics better. As I wrote when I discussed the power of models, such a clear abstraction helps to reason better and find better solutions for given problems. Yet, as I also wrote in that post, it is important to realize that reality is never as selective as a model. Reality always comes with more variants and blurrier boundaries. ↩︎
Some people claim that also projects like the one described here (implementing a new legal regulation into existing systems) would contain a lot of uncertainty because people would not know the existing systems (due to poor documentation, knowledge drain, etc.). This is not uncertainty. This is just homework not done. Uncertainty is something that is not under the control of the affected party (here: a company). It is a result of external forces that cannot be influenced. Not understanding the existing systems can be addressed easily by doing the required work. This is perfectly under the control of the company. Often companies are not willing to fund that work – but that is a different story and has nothing to do with uncertainty. ↩︎
Usually the waterfall process is attributed to Winston W. Royce based on his paper “Managing the development of large software systems”. Interestingly, Royce did not introduce the waterfall approach in this paper, but just sketched it briefly and then discussed why it often does not work and what to do instead. Yet, as it seems most people did not read beyond the image of the process. ↩︎
There are still (too) many people out there who are convinced that an IT system can be fully defined upfront, just given enough diligence. This conviction has been proven wrong a long time ago. Peter Wegner from Brown University established the Lemma (known as “Wegner’s Lemma”): “It is impossible to fully specify or test an interactive system designed to respond to external inputs.” in his paper “Why Interaction is more powerful than algorithms,” CACM 40(5):80-91, 1997 (you can download a draft version of the paper on his home page; if you just want a quick summary, you can, e.g., read this post). Watts Humphrey, a pioneer in software engineering and sometimes called the “father of software quality”, supports this reasoning in his book A Discipline for Software Engineering where he establishes an uncertainty principle, often called the “Humphrey’s Requirements Uncertainty Principle”: “For a new software system, the requirements will not be completely known until after the users have used it.” (for a brief explanation of his reasoning you may, e.g., read this blog post). There are several other more or less scientific proofs of these observation, but all of them agree that it is impossible to fully specify an interactive system (which most enterprise systems are) upfront. ↩︎
Side note: While most agile implementations address more or less the problem of unknown requirements, most of them still completely neglect the uncertainty introduced by dynamic markets. ↩︎
If you ask yourself why I sorted SAFe under certainty: While SAFe may have a value for some companies, it does not address uncertainty. As I already wrote in a footnote of my post The different flavors of IT – Part 1: SAFe in its core is a traditional incremental-iterative process framework like RUP, just disguised behind agile terminology. It builds on the assumption that the value of what you are doing is certain. Maybe I will discuss this topic in more detail in a future post. ↩︎
Theoretically, the enterprise “Agile” approaches would be able to respond to market-induced uncertainty quite well. Yet, in practice we can observe that the existing implementations do not take market-induced uncertainty into account. Market response is still considered predictable by most companies, i.e., an industrial market is assumed. This practical observation made me placing these approaches so far to the certainty side, even though they could address uncertainty a lot better in theory. ↩︎
Side note: This one-size-fits-all habit extends to the software development practices used in the project. E.g., in a startup product-market fit context it does not make a lot of sense to insist on rigorous “clean coding” or extensive unit testing. In such a context cycle times are everything. Thus, you will always focus on the least effort possible to get feedback from the customer. Most of the code will be thrown away a few days after writing it anyway (when the underlying hypothesis failed). Still, many software engineers insist on a single “right” way to do software development and try to push it through vehemently instead of reflecting the context first and then choosing the fitting practices. Often, these people have worked on the same level of uncertainty level all the time and are not aware that of other uncertainty levels. Thus, if someone comes to you and tells you that you lack to do the “right” practices, first check the context the person comes from. Often, you will learn that the person relates to a completely different context. ↩︎