Monday, April 06, 2009

TableNinja: Poker Consultant expert advice to Agile developers

Alex Sutherland graduated from Cal Tech a few years ago and continued into the doctoral program in math and econometrics. However, his online poker hobby was generating all the cash he needed and he noticed that the PokerStars user interface was not suitable for serious players with multiple simultaneous games running concurrently.

Teaming up with a partner in a Los Angeles software company doing Scrum, they decided to implement the best front end for experienced poker players in the business. TableNinja shipped their first Scrum product release a few months later.

Alex is a Certified ScrumMaster from a recent course in Beverly Hills and says Scrum has definitely helped him and his partner double productivity and that it works better remotely than it does colocated. When they are colocated they drift off focus. When they work via Skype video they stay focused. As a result they say their next hires will probably be outside the United States.

This observation is the same as the CTO of Xebia made in our paper at Agile 2008 last year. Teams half in the Netherlands and half in India work better in their environment than colocated teams so they do all their projects that way. Of course, you need to do really good Scrum to get this effect.

TableNinja does consulting for serious poker players all over the world and some of Alex's best students are in places like Tokyo outside the United States. He says his recommendations to wannabe Poker champions are the same that he makes to software developers.

Your game falls roughly into three categories:

A Game - all the big money is made in your A game. The typical player/developer is running at this level less than 10% of the time.

B Game - this is where you make small amounts of money, probably 40% of your time.

C Game - this is where you lose small (or perhaps big) amounts of money about 40% of the time.

Alex's goal as a coach is to increase your A game to 20% of your time and make your B game good enough to pay off your losses on your C game. If you do this, you can make as much money as you need (and maybe more) playing Poker.

The problem for Poker players and software developers is that they do not stay focused when in their A game and stop playing when they realize they are playing their C game. They are like a taxi driver that has a target of $300 a day. During a conference when they can cycle back and forth to the airport they make $300 in a hour and quit. The rest of the time they cruise for 12 hours a day until they get their $300 dollars. They don't get it that they should only work the day of the conference that week!

Alex's recommendation is to code like crazy when you are in the zone and quit immediately when you are tired or bored. I noticed this recommendation fit nicely with Tom Poppendieck's observation of an XP company that did an experiment with different hourly work weeks to see when XP teams that did intensive pair programming hit their maximum production of shippable software. In that company, 16 hour weeks delivered the most production ready software.

Tune in, turn on, and drop out of the rat race might be good advice for Agile developers. You can start by playing a little TableNinja to get a feel for it. Better yet, join us at Beverly Hills Scrum Certification training later this month and learn how to do this in software development.


agilebuddy said...

I am not so sure I buy the comment on the team being more focused when they're not colocated. While I buy the argument that one can achieve similar productivity on non-colocated teams if done properly (you have to work pretty hard at it as evidenced by some of Jeff's videos), I still believe colocation will always beat non-colocated teams given the same set of circumstance.

My 2 cents

Jeff Sutherland said...

The best paper on colocation randomly collocated teams within the same company and collocated teams had twice the velocity of distributed teams. This is the typical situation.

However, high performing Scrum teams typically implementing all XP practices within a Scrum and functioning in a hyperproductive state have found that they can distribute local velocity and quality to teams half in one location and half in another. To see how they do this requires reading the SirsiDynic or Xebia papers available on this site.

agilebuddy said...

Hi Jeff,

Thanks for responding. I most definitely did watch your video and read all the info on the SirsiDynic case study. That's why I was surprised to hear you say that non colocated teams are more focused. I totally buy the concept of linearly scaling teams across geographically dispersed teams but at best you'll get the same productivity as if the team was colocated no?

Jack Milunsky

Jeff Sutherland said...

The productivity and quality is the same collocated or distributed for these high performing teams. However, the delivery of the product backlog is not the same. For Xebia and TableNinja they get better focus on the backlog so the product gets delivered better. In TableNinja's case they say they are also more productive.