Teaching developers agile software development methods is a pain for many managers and senior engineers. You can send them to an agile training course, they will get a certificate, but they likely won’t rethink the way they do their daily work from the ground up.
What you need is to make the agile training practical. Make it a game for your developer team, and turn training into an agile team-building experience.
Lean Poker may be the answer for you. This is a cool idea for your company hackathon.
It’s fun. Who doesn’t like poker?
It’s educational. Your developers get to use their coding skills, and they take pride in sharpening them.
It teaches them the agile way. Sure, you can send them to a workshop to learn, but this way, they get a chance to discover working with agile methods for themselves. Though it won’t hurt if they know the basic agile principles at least.
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.
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.
The black dots mark deploys.
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.
The simpler the better
Another key takeaway many teams learned by the end of the Lean Poker hackathon is that they did well with simple solutions. There wasn’t time to build a sophisticated poker bot, and there was no planning beforehand. Everything was thought out and implemented on the fly.
Simple solutions ruled our Lean Poker hackathon, but the complicated ones took too much time to perfect and debug. This is another key takeaway for your developers: keep it simple.
Simple solutions may be harder to come up with at times, but they are easier to maintain.
If you hold a Lean Poker hackathon, your developers will learn how to apply the agile mindset when working on a real project. They will get to the conclusion that using them is better on their own. The game is competitive, and everyone wants to win; you only need to look out to avoid making it toxic.
For the company, it’s a win, because you have a low-cost team-building exercise with all its benefits. On top of that, you get a gamified agile software development course, where you don’t need to push your developers to learn. They will push themselves and become better engineers.
What You Should Do Now
🚀 If you need developer help for your project then click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.