TL;DR Due to software's innate complexity & its ephemeral character it may not be easy to assess the "level of its completeness" (/readiness) - it's not only that opinions on that may vary, people are also reluctant to give final statements (due to high degree of uncertainty). In the end of X participants you may hear X different statements, not just misaligned, but sometimes even contradictory. This effect (similar to key plot construct in japanese movie classic - "Rashomon") can be combated in quite a simple way: by promoting radical transparency and consistently stressing for making clear distinction between facts & opinions.
I guess you all know the pleasant sensation that happens while you're participating in a discussion & what others say perfectly matches your own practical experience (/observation). Especially when they are able to name it more accurately, provide a more striking metaphor (or more accureately depicting) or just frame it conceptually in more clear manner (than you did before). I love this feeling as well. I had it during recent DDD Europe while discussing so-called "Rashomon Effect".
If you didn't heard about it (& didn't bother to follow the link I've provided ...), it's an interesting psychological effect that happens when several people (/groups of people) who are exposed to the same event / occurence / phenomenon, interpret & report it in a different & frequently fundamentally contradicting way. This effect usually happens when all the participants have some stake in the event - they are either (at least partially) responsible or just play a more or less active role. This fact encourages the excessive simplification of this phenomenon's interpretation - we too eagerly assume people are just CYAing to secure their own interest, while in fact - it's a bit more complex.
I guess you've already figured it out, so I'll just briefly point out that this phenomenon takes its name from famous (& absolutely brilliant) movie "Rashomon" by Akira Kurosawa - this effect was something whole plot of the movie was built upon.
Moving in a fog
What does it have in common with building software? Oh, quite a lot.
One of the hardest challenges in building software is ... finding out where you are at particular moment (some would call it "delivery governance"). Ofc there are companies with an actual ability of Continuous Deployment/Delivery who measure the progress with actual working software available for users on production (so they always know exactly where they are ...), but these are still a fraction in context of whole industry, so let's focus on vast majority who's not there yet.
By "where you are" I mean:
- what is already "done" (with a clear & pragmatic definition of "done")?
- are we fine with (will we still meet ...) commitments we've set upon us?
- when will we be (realistically) ready ("done") with current feature bundle?
- if there's a plan - are we behind the schedule or ahead of it?
- are all the necessary qualities (product's abilities, properties & elements) in place & on par with expectations?
"Liars, you all LIE!"
Unsurprisingly, whoever you'll ask, there will be a different answer - developers have their own opinions (various specialties / teams can have DIFFERENT ones), so do testers, business stakeholders, managers, analysts ... Additionally, these opinions tend to (if not "put under appropriate level of scrutiny") be far from tangible (/measureable in objective units):
- "we're good" / "team is doing great"
- "OUR part of work is ALMOST done"
- "it's developed, now it's ONLY the tests"
- "this is 90% done, well maybe 85%"
- etc.
What makes whole topic more tricky - if various groups' opinions vary, it doesn't necessarily mean that (almost?) everone is lying, in many cases everyone involved is fully convinced their perspective is the most truthy (& justified) one.
So why does this ("Rashomon effect") happen?
There's plethora of reasons that may seem very different:
- individual people have there bias that skew their judgements
- their individual experience level does vary as well - e.g. for the more junior ones one month may seem like an indefinite amount of time, sufficient to deliver whole brand new OS
- in majority of cases they stick (subconsciously) to their own ("local") comfort zone & success criteria - unofficial, coined by them around areas & topics they feel they control (e.g. excluding all dependencies like cross-team integrations); ofc that may be very far from production-ready end-to-end product, but their priority is not to take the blame for someone elses (or edge - hence ambiguous) problems
- there may be (at least partial) conflict of interest (or even small misalignment) - especially if some of the guys work for a different companies (e.g. fixed price vendor projects)
- cultural differences may be a factor as well - if culture is a factor, "no != no" and "yes != yes"
- actual questions used while probing for "the current state of things" may not be "laser-sharp" (e.g. "is everything OK?" -> "Sure, everything's OK" (which still doesn't mean we can make it on time ...); "do you think we can make it?" -> "yes, definitely we can make it" (but the chance is 5% only ...))
- at last but not least - yes, sometimes people (for whatever reasons) are trying to intentionally sneak out of their own mistakes - by "distorting the reality" or plain, old bullshit ;>
As you can see, all of the points above can be generalized to one, root cause -> they are based on opinions -> subjective, susceptible to bias, somehow fuzzy OPINIONS (yes, estimation is also an opinion!). Everyone has one, these rarely do match & the justifications are individual (& usually quite hard to rely upon objectively).
Way of a samurai
Opinions are not that bad & can be turned into something accountable as long as one is fully independent & does not rely on external factors. Sadly it's rarely the case. So in practice all the governance has to rely on facts, instead of opinions.
What are the typical facts you can base your governance upon then?
- past time metrics - not hand-crafted (/ estimated), but taken directly from various side-effects of actual work taking place (e.g. cycle time = difference between the moment of backlog item's first appearance & its actual deployment on production)
- hard (work-)system constraints - e.g. unmovable deadlines (legislative ones, etc.)
- verified bottlenecks (it doesn't make much sense to measure / optimize for anything that is NOT on the critical path)
- actual work - visualised & published according to the principles of radical transparency; teams who follow this concept actually treat being pro-actively open about their work as their priority number one
But is it (real-time governance) that important? Well, actual work does have to happen anyway, so maybe the point is not to overthink it, huh?
According to all I know about this business, the initial plans & estimations are important, but what really matters is what you learn (& how you react in response to that) on the way - adaptation to ever-changing conditions. If you can't properly assess the situation, what do you want to adapt to? It is a serious problem, because:
- trust once lost (due to differences in perception, detected never too soon) is very hard to gain back
- decisions based on false perception are far from optimal
- attempts to fix the situation that may have been escalated far earlier may have to be far more painful for the whole team (crunch-time, crippled product, feeling of being cheated/lied to)
What's probably even worse, Rashomon effects leads to the permanent state of desynchronisation where (once things start getting really nasty & it's more than clear for everyone that project / product is completely derailed) ...
- ... no-one feels responsible for whatever's wrong
- ... everyone has a feeling of being cheated / treated unfair
- ... everyone feels that (s)he was fully honest or at least fully justified in messages/opinions expressed
- ... everyone claims that the actual fault was somewhere out of her/his control
- ... in case of misunderstanding / miscommunication everyone assumes the other parties were lying / hiding the truth (while in fact it was - again - a matter of perception & wrong questions asked)
P.S. If you haven't yet, I encourage you to watch "Rashomon" just for fun - this movie is almost 70 yrs old, but still pleasure to watch. You can watch it for free here.
