Our goal as software developers is to sustainably deliver value for our organisations. It's not enough to know and follow the best practices, it is also important to be able to harness the power in them. Our mission at Lean Poker is to provide a safe environment where developers can learn how to help their organizations to stay ahead of competition .

During the course of the day participants self-organize into teams and compete in delivering the right features at the right time. We use robots playing Texas hold'em as a metaphor for startups entering the same market and trying to take hold of as much of it as they can. Texas hold'em rules are easy to learn, yet it is a game of skill that allows for incremental development of strategies that evolve from simple to complex.

The robots start playing even before the teams had a chance to make a single change to the basic folding player provided. The robots play all day long and the teams can deploy new versions at any time. To win at a Lean Poker event, the team needs to be consistently better than other teams throughout the day.

Event structure

Lean Poker has a very similar structure to coderetreats. Events take about 8 hours and usually start in the morning at around 9am. After the introduction and forming the teams there are 5 or 6 coding sessions each followed by a retrospective and a break. The day ends with a closing circle before announcing the winner.

During retrospectives and breaks the robots are not playing and participants are not allowed to code. The only exception to this rule is the last retrospective and the closing circle during which the robots keep playing. The primary purpose here is to make sure that changes pushed in the last few minutes still have some effect on the final results.


The day starts with a short introduction that explains why Lean Poker was created and what to expect during the day.

Forming the teams

The facilitator gathers participants into a large standing circle. Supported languages are called out one by one and people who would like to work with that particular language put their hands up and look around for possible teammates. Finally participants are asked to self-organize into teams and get comfortable around a table as a team.

Coding sessions

Durring these hour-long sessions the robots play rounds (sit'n'gos) of Texas hold'em every few seconds, and the team with the robot who won will receive 5 points. The second comer collects 3 points. The team can make changes to the git repository provided by the platform. When new code is pushed into this repository it will be automatically deployed into production.


After each coding session the facilitator gathers the participants into a large standing circle and the previous round is discussed. What was interesting, surprising? What kind of problems were the teams facing, and how did they handle the situation? This is also a great opportunity for the facilitator to point out some Agile or Lean principles that might apply or could have helped the team in solving their problem. Each retrospective is followed by a short break.

Closing circle

At the end of the day, after the last retrospective it's important to step back and reflect on the entire day. The purpose of the closing circle is to make people think about what is it that they are taking away. During the closing circle each participant is asked to answer the following three questions: What if anything surprised you today? What if anything did you learn today? What if anything are you going to do differently in the future?


There are not many rules, but please keep them in mind. All rules of no limit Texas hold'em apply.

Lean poker - although it has a competitive feel to it - is not a competition. The emphasis should be on practice. Because of that any prize more valuable than a few dollars should not be promised to the winner.

Fair play is also important: no one should try to exploit weaknesses of the framework or deliberately inject backdoors into its source code. Also - with some notable exceptions listed below - no team should use any pre-written code.

We would like to avoid a situation where one team has a huge advantage over the others due to a library that solves some part of the problem. For that reason the rule of thumb is that only the language's standard library, and open source libraries are allowed. Similarly only open source data files can be used. Proprietary libraries and files are banned under all conditions.

Also note that repositories are public, but we count on participants not to look at each others code during the event. Please do not try to make your repository private in an effort to hide your code from others, since that will break the deployment pipeline.

If you still have questions, head over to the frequently asked questions section.