Optimistic versus pessimistic protocols
Pessimstic means assuming things will go wrong;
Optimistic means assuming things will go right.
Jim and Michele McCarthy introduce a number of “protocols” (ways for people to interact) in their book Software for Your Head.
Most of those are “pessimistic” protocols. To go faster, you can use “optimistic” protocols.
What are those, and what do they mean in real life?
Optimistic versus Pessimistic Protocols
In the olden days, communication lines were noisy, computers went down a lot, and generally, information packets between computers got lost or screwed up a lot. And so, the designers arranged for there to be a lot of checking … “Did you get that packet? OK, then, here’s the next.” ... and so on. It was slow, but it worked.
Sometime in the 1980s, lines got reliable, and so did computers (except the one on your desk that hangs for no known reason). Researchers started to complain about the slowness of the computer protocols and design ones that would go faster.
Except, some bright person got the idea that maybe the old protocols would work just fine, if only one made the assumption that packets wouldn’t get lost or corrupted. Namely, ... “Here are 1,000 packets. Did you get all 1,000 OK? Great, here are the next 1,000.” ... Of course, if the answer was “No”, then 1,000 packets had to be resent, but that didn’t happen very often with the new communication lines.
All of a sudden, with no change in protocols, everything ran much faster, and there was no need for new (incompatible) protocols.
The former protocols made pessimistic assumptions about the players and the environment. They were safe but slow. The latter protocols made optimistic assumptions about the players and the environment. They were generally faster (when the assumptions held) but potentially slower when the assumptions didn’t hold.
Of course, a smart programmer would implement the system so that the computers might start with a pessimistic variation; if there weren’t many errors, generally ramp up to the optimistic version, and then, if errors started showing up, ramp back down to the pessimistic version, and so on, going faster when possible, going slower when necessary.
How does this map to ordinary life?
You can apply this idea in many places in ordinary and working life. The basic idea is
- Start slow, checking your assumptions often.
- If you are making good assumptions with few errors, find more efficient ways to work, checking assumptions more rarely .
- If you find your assumptions aren’t so accurate, slow down again and check in more often.
Here are some examples of it in use.
Agile development in hostile versus friendly territory
Agile planning techniques such as XP’s "Planning Game" and Scrum “sprint commitment” are based on “hostile” assumptions, that the parties are antagonistic toward each other.
Here’s the Planning Game in hostile territory. See also its description in “Agile Software Development: The Cooperative Game”
Planning Game, Hostile / Pessimistic Version
- The customer writes what he/she wants on cards .
- The programmer says, “That one’s stupid, it’ll cost way too much.”
- The customer says, “Shut up, that’s what I want. Estimate it.”
- The programmer estimates it, the customer says, “Don’t be ridiculous – it can’t possibly take that long.”
- The programmer says, “Shut up, that’s my estimate. Reprioritize it if you want.”
- The customer reprioritizes.
The Planning Game actually works when played in hostile territory with the pessimistic version. You can see it’s not optimal.
Planning Game, Friendly / Optimistic Version
- The customer writes what he/she wants on cards .
- The programmer says, “That one’s going to be expensive – I’m not sure you really want it that way at that cost.”
- The customer says, “What can you suggest?”
- The programmer says, “Could you get away with this? … It’s much cheaper to implement and might have the same effect.”
- The customer says, “Sure, that’s fine. I didn’t mean the other one had to be that way, it’s just how I was thinking about it.”
You can see that the friendly version works much better.
You might think that the second version is always available, but oddly, it is surprisingly often not. I was in a setting once with a professional facilitator, and he was so worried about people possibly harassing each other that he set up the meeting so that there was never any direct dialog between the participants. It was, as you can guess, slow and agonizing.
Hostile / Pessimistic Version of Scrum Sprint Planning
Basic Scrum relies on a deal between the project sponsors and the development team. The team commits to what they’ll do in the next month (or sprint), in exchange for the sponsors promising not to add or change any requests during that time period. In other words, the sprint backlog is locked for the duration of the sprint.
The good news is that the team has peace and quiet for the duration of the sprint to do their work. The bad news is that if something interesting or urgent comes up, the sponsors can’t get it any attention until the next sprint.
Friendly / Optimistic Version of Scrum Sprint Planning
If both parties are well-behaved, the team doesn’t commit to what they’ll do in the next month – they estimate what they’re likely to get through. During the month, if there are changes in priority, the sponsors come by and discuss the ramifications of the changes with the team, and they jointly decide whether to keep going, or to add / remove / change the backlog.
You can see that with this version, the team can respond to changes much faster and generally optimize their work.
However, as with the business with the communication protocols in the beginning of this article, things can get out of hand. The team starts off well, but then one of two things happen:
- The sponsors turn out, at the end of the sprint, not to “remember” that it was all estimates and best-guess and collaborative negotiation, and start to blame the dev team, or,
- In a surprising twist, the dev team and sponsor are too friendly, and end up changing their minds so often that they actually get less done than if they’d simply stuck with the original version of the backlog.
In both of these cases, the best thing to do is to revert back to the “pessimistic” version, and make sure the communications between the parties are in order before making the next foray into the more efficient but more hazardous optimistic version.
Perfection Game and Decider Protocol
Jim and Michele McCarthy have a set of excellent team protocols in Software For Your Head. One of the most used is the "Perfection Game" (see that PPT file or of course Jim and Michele’s book for more complete instructions). The protocols are remarkably “safe”, meaning designed so people’s egos don’t get bruised. To do this, they are “pessimistic” in the sense that they miss opportunities for faster progress.
Perfection Game
In the standard Perfection Game, person A presents something; the review group is not allowed to criticize it or mentioning what they don’t like (that’s the pessimistic part), but only to say what they like and “what it would take to get a 10.”
I attended Jim and Michele’s “Bootcamp” some years ago, and found:
- One of the people in the group was so terrified of criticism that even after 4 days, when he asked me to evaluate something, with actual terror on his face as I started to mull on his item, he said, “Please use the Perfection Game.”
- At the same time, several of the rest of us had gotten impatient with not being able to say what we didn’t like, and found we could move faster if we just blurted out what we didn’t like. We found that we sometimes know what’s bothering us but not how to fix it. If (and notice the “if” in the sentence, marking the presence of optimistic assumptions) … if we are comfortable enough with each other to know that “what’s bothering me about this” or “I don’t like that” isn’t personal but is just pointing to a place needing work, then we move faster.
As with communication protocols and sprint planning, we can dial this forward and back. Start with the optimistic or pessimistic version, review feelings and assumptions and either ramp up to the optimistic version or back to the pessimistic version.
Decider Protocol
Their Decider Protocol (see p. 394) has the same properties. In the Decider Protocol, anyone can dissent or veto a proposed decision; the rest of the group are not allowed to quiz the person about what’s bothering them – they can only ask “What would it take to get you in?”.
As with the other examples, a group of people can start with the Decider Protocol, and after they feel safe with each other, can move to a faster, more “dangerous”, more dialog-oriented protocol; and if that gets to hurting people’s feelings, move back to the Decider Protocol.
Personal Relationships and Marriage
When people just meet or are courting, they tend to be extremely polite to each other. Then they get comfortable with each other and just blurt things out. In some cases that is fine, and they go on being very effective and direct with each other. In some cases, they get into a pattern of being direct but feeling hurt. In some cases, they go back to being very polite to each other even after they know each well, with the assumption that being polite reduces potential for damage even though it costs a few more syllables and motions.
Using the Crystal 3-Step Model (discussion: Re: The three steps of Crystal)
I have been describing optimistic versus pessimistic protocols using the Crystal 3-Step Model (discussion: Re: The three steps of Crystal). First, I gave the theory, then I gave examples of practice. Now it is time to close the cycle by applying “self-awareness.”
Self-awareness is the step in which we find personal priorities, personal values, personalities, and reflection. This top step has several implications and applications. For the current discussion, what it means is that when and where the group decides to use an optimistic or a pessimistic protocol will depend on their personal characteristics.
It is not that “optimistic protocols are best”. This is because optimistic protocols are also more dangerous (feelings are more likely to get hurt, the failures are bigger). What is best for the group depends on the individual people’s personal accommodation for danger and hurt.
And, to shift from one protocol variation to another requires the people to be willing to investigate their sense of security and ambition, and work out what level of optimism/pessimism best suits them.
End Notes
Look around you and spot where you see Optimistic protocols in place – either working well because the assumptions are holding, or not working so well because the assumptions are not holding (and, therefore, feelings are getting hurt).
When you spot an Optimistic protocol in place, dig out the assumptions being made, and see whether they hold.
Similarly, look around you and spot where you see Pessimistic protocols in place. I’ll guess they’re working. However, check to see whether some people are frustrated by the slow pace of progress because they’d like to cut some corners in the protocol.
When you spot a Pessimistic protocol in place, dig out the assumptions being made about what’s likely to go wrong and what bad things will happen when they do. Check whether those assumptions really hold, or whether a (more) Optimistic protocol might work, trading safety for speed.
If you can, take a look at the individual people’s sense of safety and tolerance for danger, and see if you can spot – or help them find – a better place on the scale to operate.
Write to me or comment below if you see any interesting examples.
Discussion
I have never used those protocols formally, but I did read Software for your Head a few years back (and rate it as influential, looking back). I fully agree that friendly negotiations are preferable. I believe it’s one of the great way to deliver tons of value to customers without huge budgets. However, I think that both protocols you mentioned go that way.
By being pessimistic, they encourage creativity and require constructive criticism. It’s easy to sit back and say “I don’t like that.” It’s much harder to go one step further and say what you would like to see instead and propose something, which may not be perfect, but will open up to additional discussions. If you just stop at what you don’t like, you better well hope the person in front of you has a creative mind to propose something along those lines rather than stop the discussion and walk away (which is the worst possible outcome).
For sure, a group who has worked together can cut on formality, but only because they know that the other will react correctly.
-by Louis-Philippe Huberdeau on 5/26/2010 at 2:59 PM
609
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
