This is part of an ongoing series. It continues from Evaluating a Root Cause. Visit Walking, Peanuts, and Systems if you’d like to start at the beginning.
Recap
Project management is hard because of uncertainty. Current solutions provide minimal support to address the difficulty of uncertainty. The problem of uncertainty is obvious, so I should expect current solutions to address it. If smart people have not addressed it, there must be some core conflict that keeps the problem from being addressed.
Searching For a Conflict
My tool for conflict is the Evaporating Cloud (also called a Conflict Resolution Diagram) from the TOC thinking processes.
The first step is to find two seemingly contradictory solutions that people suggest. Anytime someone suggests a necessary balance that no one can ever seem to find, there’s possibly a conflict.
Thinking about software development from the engineer side, a regular complaint is that requirements change throughout a project. Stated another way, there is uncertainty about the requirements. There are two extreme positions to take:
- Lock down requirements such that they can’t change
- Accept that requirements can change at any time
Those meet the definition of a conflict in that you can’t do both at the same time. For the sake of my goal, the following should be true about these positions:
- Clearly visible in software development
- People oscillate between the two, trying to find the balance
These two positions are so ingrained in software development that they have easily recognizable names: Waterfall and Agile.
People oscillate between the two. Each position is caricatured by the opposite side. There are lots of no true scotsman articles about Agile, arguments about Waterfall being misrepresented, and critiques that Agile does no planning while Waterfall does too much planning.
Filling in my Evaporating Cloud, I can see a conflict around how we should handle uncertainty. We can’t remove uncertainty while also ignoring uncertainty. (I’m using the word “ignore” to capture the idea of not worrying about future changes. It’s more pejorative than I’d like if I was primarily trying to communicate with someone else, but it works for me.)
The premise behind the Evaporating Cloud is that there are no conflicts in reality. Apparent conflicts exist because we have at least one invalid assumption in our solution. With my cloud, I can start searching for the invalid assumption.
My starting questions:
- Are the only options for uncertainty to remove it or ignore it?
- Is removing uncertainty the only way to be predictable?
- Is ignoring uncertainty the only way to be flexible?
Thoughts:
- We ignore lots of uncertainty all the time because it isn’t relevant.
- Unknown unknowns represent different uncertainty than known unknowns.
Hypothesis for invalid assumption:
We assume uncertainty is binary. We know nothing, or we know everything.
Is That Reasonable?
I can think of a few examples that encourage this line of thinking:
- Jira ticket assignment – it’s either assigned to someone, or anyone can be assigned to it. There’s no way to say, “Someone from this subgroup will work it.”
- Jira delivery date – either pick a date or it can be literally any date. There’s no way to say, “Around Feb 8th.”
- Waterfall – require all specs before moving forward. No way to scope certain specs within a range that will be finalized later.
- Agile – only immediate specs before moving forward. No way to make decisions about the future unless everything can be decided now.
To reiterate, it may be possible to do those things in Jira, but they are not obvious and not first class concepts. Waterfall and Agile are presented as the extreme, but people do struggle to figure out the balance between the two.
Uncertainty is regularly only visible as negative space: I’m uncertain about something, and the only way you know that is that I didn’t add any certainty.
To summarize, uncertainty is what we don’t know. We treat uncertainty as binary, as if it’s something to squash (Waterfall) or put off (Agile). The incorrect assumption that uncertainty is binary is the assumption I should address when designing a solution.