Agile Project Management Lessons Learned From Texas Hold'em

Over the holidays, CIO.com columnist David Taber spent way too much time discovering eternal truths while playing online poker. Take a look at what he learned along the way about agile project management.

By David Taber
Mon, January 13, 2014

CIO — I can hear you sighing — and I'm not surprised. I had always considered Texas Hold'em Poker to be a game dominated by blind luck, bluffing and testosterone poisoning. What could be more different from the cold rationality of IT project management?

Actually play the game, though, and you'll see that skill is definitely involved — and there are clear right and wrong responses to most situations. You'll also notice several weird parallels with software projects:

  • At the outset, you have surprisingly little concrete, actionable information. What you do have is a lot of hope and supposition; you can make decisions based only on general probabilities.
  • Most of the time, making an irreversible commitment early in the project is about as effective as going all-in before the cards are dealt.
  • As things evolve, prior decisions are sometimes invalidated by subsequent information. Significant changes in strategy may be required, including cancelling part of the work.
  • In certain situations, winning will mean spending more than you originally budgeted.
  • The biggest costs often come at the end, even though the chances of a great result haven't gotten that much better.
  • Being stubborn really costs you. Alacrity and flexibility pay off over time.

Now, these observations aren't exactly another revelation on par with the Mythical Man-Month, but there are still some interesting corollaries for software project management in the enterprise.

You Only Think You Know What It Takes to Win

In software projects, the impulse is to create a detailed requirements document to guide the project team before anything starts. In the extreme case, that requirements document, rather than business value, is the basis for the business case. That can work for software products, but with business systems — particularly customer-facing ones or CRM software — producing a thorough requirements document is a fool's errand.

[ Commentary: Top 10 Ways to Blow Up an Agile Project ]
[ More: 5 Ways to Send a Custom Software Project Off the Rails]

Why? Even before the ink is dry, requirements documents just aren't accurate enough. During the requirements writing, one group or another won't be able to put its "A Players" on the job long enough. There will always be something more important to do than this busywork assignment — so the document will have invisible gaps, wild assumptions and incorrect priorities.

That's not all. The "requirements tome" approach is based on two assumptions that, all too often, prove to be false in CRM projects. One it that it's possible to specify exactly what's needed before the project begins. The other is that a successful project delivers exactly what's specified, but only what's specified.

OK, then. What are the odds of the following?

  • Your users will state their requirements with such thoroughness and precision that you won't misunderstand them.
  • You understand your business processes, data quality and cross-system integration issues so well that there won't be any surprises.
  • Users won't change their minds about details and priorities during the course of the project.
  • There won't be a reorganization that changes priorities or even nullifies some of the requirements.
  • Your product or service offerings won't change in substantial, relevant ways.
  • Your channels and competitive environment won't change during the life of the project?
  • You're able to foresee all the government regulations, customer contractual stipulations and internal standards you'll need to comply with.

In the immortal words of Clint Eastwood's Dirty Harry, "Are you feeling lucky?"

Continue Reading

Our Commenting Policies