Boehm’s Theory W and the Anti Matter Principle
Rereading Boehm’s Value Based Software Engineering I have been reminded of his “Theory W”:
Enterprise Success Theorem: Your enterprise will succeed if and only if It makes winners of your success-critical stakeholders.
I can’t help but wonder if this is actually the same as The Antimatter Principle, the difference simply being a difference in language and perspective.
Attend to Folks Needs
Is attending to somebody’s needs the same as making them a winner?
If I provide a meal to somebody, attending to their hunger, have I made them a winner?
That doesn’t make sense.
If I get two hungry people to fight for the food then I would have a winner. It seems to me that the existence of a winner implies that there must also be a loser.
The idea of Win-Win tries to contradict this with the idea of everybody winning. The assertion that nobody wins unless everybody wins has been made many times, but it begs the question: why are we using the word ‘win’ then.
Is this one of those mindset problems that Marshall keeps warning us about? We talk about wining because the mindset of the zero-sum game, of battling for territory, or competing for scarce resources is so deeply engrained in our way of thinking. We all want to be winners, we cannot contemplate the option of not-winning. Nobody wants to be a loser.
If we look again at Theory W we see that there is an important adjective: “success-critical”. It isn’t necessary for everybody to win. We only need the important people to win. Those that don’t matter to us will be the losers, and we don’t care about them.
Is this a safe position? Boehm continues to prove that nobody wins unless everybody wins, or as he puts it “win-win becomes lose-lose.” He uses the example of an enterprise system with three stakeholders – customer, developer and user. What happens if two of those stakeholders become winners are the expense of the third?
|1. Quick, cheap, sloppy product.||Developer & Customer||User|
|2. Lots of “bells and whistles”||Developer & User||Customer|
|3. Driving too hard a bargain||Customer & User||Developer|
In Case 1, the customer and developer attempt to win at the expense of the user by skimping on effort and quality. When presented with the product, the user refuses to use it, leaving everyone a loser with respect to their expectations.
In Case 2, the developer and user attempt to win at the expense of the customer (usually on a cost-plus contract) by adding numerous low-value “bells and whistles” to the product. When the customer’s budget is exhausted without a resulting value-adding product, again everyone is a loser with respect to their expectations.
In Case 3, the user and customer compile an ambitious set of features to be developed and pressure competing developers to bid low or lose the competition. Once on contract, the surviving bidder will usually counterattack by colluding with the user or customer to convert the project into Case 2 (adding user bells and whistles with funded Engineering Change Proposals) or Case 1 (saying, for example, “The contract specifies user-friendly error messages. For my programmers, a memory dump is a user-friendly error message and thus is a contractually compliant deliverable”). Again, everyone is a loser with respect to their expectations.
What about the Operations staff who need to maintain this piece of enterprise software? Are they not a success-critical stakeholder? Is it OK for them to lose?
The above proof shows that failing to “make a winner” of just one success-criticial stakeholder leads to the eventually making losers of them all.
Is it safe to ignore any stakeholder who is deemed unimportant at the time? To do so is introducing the risk that they will prove to be important in the future.
So what is the alternative? Identifying all stakeholders and making them all winners?
This talk of winners seems like cognitive dissonance to me. It looks like conflict between the idea that we must all strive to be winners and the realisation that if anyone loses, we all lose. In an effort to square this circle we find ourselves tied up in paradoxical knots.
What is really needed is to change our mindset and end our dependancy upon conflict. Instead of thinking about making everybody winners we should think about attending to everybody’s needs. This leads to clearer, simpler thinking.
Rewording Boehm’s Win-Win Achievement Theorem is simple and leads to something clearer and easier to follow:
Antimatter Achievement Theorem: Attending to Folks Needs requires:
- Identifying those affected (Folk).
- Understanding what the Folk need.
- Collaborate with Folk to produce set of product and process plans that will satisfy their needs.
- Supporting progress toward Folk attending to each other’s needs, helping them adapt to future changes.
It seems clearer and, dare I say it, nicer.
Yet I appear to have been conditioned to reject anything that is clear and nice.
I read it and I think – ‘that is to good to be true.’
But if it can’t be true, what is the alternative?