Lean Poker: Agile Training Molded Into Team Building

What is Lean Poker?

The idea of Lean Poker is to build poker bots that continuously play Texas hold ‘em against each other and gain points in every round. Whichever bot has the most points by the end is the winner.

You put teams together and each gets a poker bot, and they start working on it. By default, all the bots just fold, so teams need to hurry up to ship a working first version of their own.

The Lean Poker framework has the potential to work with just about any language. A wide range of them is supported already, and more can be implemented.

Put your teams together

The teams should have 2-7 developers, and you can add non-coders on top to include the most people into the fun. They may not write code, but they may have valuable insights into poker and its strategies, and they can play a part in analyzing how the team’s bot does against the rest.

We constructed teams by assigning one non-coder to every team, and we had them randomly draw 1-2 senior developers and 3-4 medior and junior developers each. So, we ended up with 6-people teams; in each one, a senior engineer took on the role of team lead and started working from there.

It’s also a good idea to assign the teams beforehand and to make sure you mix people who don’t usually interact with each other. We went with the random draw for an extra game element, and it did the trick.

How to run it

The idea is to do 60-minute sprints, then hold a retrospective meeting with all teams present, and take a short break. During the retrospectives and the breaks, no one is allowed to code, and the bots stop playing. The last session is different insofar as the bots keep playing during the retrospective and a half an hour after that, so last-minute commits can influence the final result.

The retrospectives are for the teams to share with the others what they did wrong or what worked out for them. It’s a competitive game, but the atmosphere didn’t get toxic when we did it. We offered no rewards other than bragging rights.

Ideally, you’d dedicate a full 8-hour day to this. We did it on the last workday of the year, so we took time to reflect on the past year and started a couple hours later. You can do 5-6 sessions in a day; this time, we stopped at 4.

The developers can use anything they want, except for copying pre-written code, looking at each other’s code or trying to build backdoors into the framework. You can’t stop them, but it’s cheating, so you should ask them not to do it, and count on them to be mature enough to listen.

The teams can deploy an update any time, and as time passes, the bots play more frequently. So, an early lead certainly won’t decide the final outcome, and you can always find your way back to the top.

Learn how Monzo has built and keeps up its renowned engineering culture! [Podcast + Blog post]

What have we learned?

Building a Texas hold ‘em bot is a competitive mini project that you certainly can’t make sophisticated enough in a day. All teams have plenty of work to do all day, and with the games happening more frequently, there are more points to gain as the game progresses, so no team can stop development and still win.

This drives the teams to want to win and to do the best work they can. They learn about making their code work in production, and this shows them the advantages of the agile methods in practice.

Sure, you'll also learn a lot about Texas hold 'em as well.

Tests are essential

Developers don’t like tests. It’s a fact.

At Lean Poker they get a chance to skip testing. All our teams took the chance to build the bots as quickly as possible. Every team ended up breaking them eventually, losing out on a lot of points.

All our teams decided by themselves that testing is necessary.

Developers, especially juniors, often feel like tests are forced on them, and they’d be fine without them. Lean Poker is the best environment possible to let them make that decision, to push bad code to production, and to deal with the consequences. That teaches them how important testing is.

Some teams didn’t break the bot in the first sprint, but they did later, and they lost out on more points by the time they had fixed it. Another team’s bot actually started doing worse once they implemented tests and fixed the bugs. But everyone unanimously agreed that the bot should do what it’s built to do.

Splitting up tasks makes the team efficient

Breaking the groups down into smaller units and dividing the different tasks between them worked more effectively than centralizing the work, and having one developer implement everything.

The developer team that ended up winning our Lean Poker hackathon worked with a split where the team lead handled sending the code to production and writing the basic mechanics of the bot. He had help from two other engineers analyzing the games, identifying the weaknesses of their bot compared to the others. Another two developers were working on the logic of the poker bot, recognizing different sets of cards.

Another team worked with a more centralized method, with one person writing most of the code and everyone else brainstorming ideas. After the competition, this centralized method was the biggest source of complaints from the members of that team.

The team leader would have preferred to split the tasks up and take less on himself. He took the lesson to communicate the way he wants to run the project clearly and as early as possible.

Deploy or die!

The lesson to deploy fresh code to production often is embedded into the rules of Lean Poker. You gain points continuously, so you want to have the best poker bot you can at any given moment. Pushing every small upgrade to production as soon as possible is a given.

Small deploys make reverting to an earlier version and debugging easier. It’s a valuable lesson to learn, and to see it work in practice.

All our teams handled this well, but each with a different style. The team that ended up winning started out slowly, waiting for the first logic features to be built. Eventually, they started gaining points, and by the end, they actually stopped deploying features but kept building them, only pushing new code once the bot started losing.

But most teams pushed new code as soon as it was ready and had been properly tested. As mentioned above, a broken bot is worse than an imperfect one.

So, Lean Poker may somewhat distort this aspect, but it still teaches the lesson: quick deploys make your life easier.

React quickly, stay agile

The teams are not supposed to look at each other’s codes, but they need to develop the poker bots to beat each other’s. Our winning team had two people analyzing the bots’ behaviours in the games.

But the lesson isn’t to analyze.

The lesson is in the constant change of requirements, priorities and tasks. Whatever you may be developing, if another team starts beating you consistently, you better have an answer to that. So, you need to figure out a solution and build it quickly.

This is the very idea behind agile software development. You need to be flexible and quick at switching tasks and priorities. Juniors often need time to make this way of thinking their own.