Games of Incomplete Information

Agile Software Development as a hand of No Limit Texas Hold'em?
Ever since I started playing various forms of poker "seriously" about 5 years ago, it has struck me that there are definite similarities between these card games and agile software development. For the past couple of years I've been mulling this over and trying to see if the analogy works. If so, perhaps it would provide another mechanism to illustrate the value of iterative/incremental development. Here's what I've come up with:

In an agile software development project, the object of the exercise is to continuously deliver as much value as possible given the current conditions. After every iteration, the Product Owner can see the value created and make decisions on whether to continue (and in what direction) or cancel the project. In a hand of NLHE the object of the exercise is to continuously make decisions based upon incomplete information such that one can profit from the hand. After every street, the rounder can see the value accrued, assess the risk, and decide to continue (and in what direction) or fold the hand. All of these decisions are based on a myriad of inputs which affect the perceived value of proceeding. As we shall see, Agile projects are analogous to individual hands of poker.

Pre-flop (Release Planning) Action
Prior to seeing any community cards (streets), one must make a decision based on several things: hole card value, position, chip stack, and opponent characteristics. In order to proceed with the hand, one must wager at least the amount of the big blind. Of course there are other possible actions:

Limp: This is equivalent to simply paying the 'cost of doing business'. Enough information is present to justify starting the project. Based on what is known, while there are still significant uncertainties, there is some undetermined likelihood of success.

Raise: Enough clarity is present to warrant raising management expectations regarding the level of success that‘s possible.

Call a raise: While significant risk is apparent, there is enough information (hand value, relative position, participant characteristics) in place to warrant accepting the increased risk. On a project, the fact that we have a seasoned team, known technology and a known domain might cause us to call a raise.

Re-raise: This would occur only when the team believes that their estimation accuracy is sufficient to overcome most likely risks and is a signal of significant confidence.

(Re)Raise All-in: This translates to risking the entire project success on incomplete information regarding the hands of the opponents and the community cards. Committing to a specific combination of schedule, scope and resources at this time is analogous to raising all-in pre-flop. This is fairly common in 'waterfall-based' software development projects. While this action does occur in poker, it occurs only in specific circumstances involving calculated risk/reward ratios.

Fold: The project is canceled because the likelihood of receiving enough value from the project based on the starting information is extremely low. If you're playing poker correctly, this event happens much more often than in software development although sometimes I think we should fold much more than we do in software development.

Flop, Turn, and River (Iteration Planning) Action
After the flop, the majority (3/5) of the common cards have now been exposed. Some more information is now present for all to see and it is reasonably unambiguous. Every exposure of a community card is analogous to an iteration planning session. Whatever the plan was prior to the flop, turn or river, there may be need to adjust the plan based on the new information. As with most things there is always some amount of risk (unless you've hit a royal flush ... 20,000:1). The amount of risk is relative to hand value, position and chip stacks. Further, taking into account the information (bet amounts and other non-verbal inputs) gathered on prior streets complicates or simplifies the issue depending on your point of view. The options here are to check or bet in the face of no overt threats, or to call, raise or fold in the face of overt risk.

Check: Based on the newly presented information we are unsure of where we stand and may not be willing to invest more in the project if more adversity arises. We are certainly not bullish about our strength.

Bet: Based on the newly presented information we believe we are strong enough to invest more in the project given that no added adversity has arisen yet.

Call: Based on the newly presented information, and a new overt risk (someone else is representing strength) the team believes that it is worthwhile investing more in the project in the face of the new risk. In poker, this is actually usually deemed a sign of weakness. To some extent it is viewed as ignoring reality ... if you were really strong, wouldn't you re-raise?

Raise: Based on the newly presented information, and an overt risk (the previous bet), the team believes they are strong (confident enough in their knowledge of the situation, skills and domain) enough to overcome the risk.

Fold: Based on the newly presented information the team realizes that the risks far outweigh the likelihood of success.

The Showdown (Retrospective)
At the end of the hand, if we've seen it through, we have a clear indication of success or failure. In either case we are able to look back at the information taken in during the hand and learn something about people's patterns and communication styles. This can be very useful for future projects.

In the end, it's the experienced teams and card players that are able to raise their stakes and their games as they are able to continually adjust their plans mid-play.