Facilitators guide

This guide will provide you with the necessary details of organizing an event. However before reading it please first read the participants guide.

Preparing for public events

For a really successful public event the host (not necessarily the same person as the facilitator) needs to make sure that enough people turn up for the event, and once they turn up they have everything they need for a great event.

Before even starting to organize a public event it is worth making sure that you can get at least 9 people interested within your immediate professional network. If you already have a meetup group or similar user group that should not be an issue. If you are a company owner looking to use Lean Poker as an employer branding opportunity, ask your employees if they would be willing to come and bring some of their friends from other companies. Market this as an opportunity to them to show off the company as a great place to work at. Most companies provide referee bonuses, so this may give them incentive to bring more people in for the event. Once you have a critical mass you can use a meetup group to further advertise the event.

Once you have gotten enough people interested, you will need to set up some kind of a registration page. We usually use either meetup.com or eventbrite.com for that purpose. You can use a previous event as an example of what should be included. Finally log in to Lean Poker Live and create the event.

As for preparing the location for the event, follow this checklist:

• Make sure you have decent wifi participants can use. It should be capable of handling the load for up to 30 devices.
• Make sure there are enough power outlets for the laptops of participants.
• Make sure you have enough seats and tables. The best arrangement for Lean Poker events is 6 table islands (typically two tables turned face to face with each other) and 5 seats for each of them.
• Buy about 10 liters of soft drinks.
• Agree with a nearby restaurant to provide a lunch menu for your event, or be prepared to order takeout food. Make sure that you can scale the amount of food to the actual number of attendees, since the turnout for public events may vary.

The facilitators role during the event

The primary role of the facilitator is to make sure that the event runs smoothly and participants have a good learning experience. To achieve this the facilitator should take care of administering the event, answer questions of participants as they arise during the event, facilitate the retros and the closing circle to maximize knowledge sharing, and finally give expert advice to the teams to guide them in learning about continuous deployment, devops culture and the agile/lean values, principles and practices.

Welcoming participants at public events

In case of public events the facilitator should welcome participants as they arrive. Usually there are a few early birds, so sitting down and chatting with them is a nice gesture. As more people arrive involve them in the discussion to build a critical mass for networking. Once more people arrive the facilitator may leave the discussion to take care of other duties.

Usually it is a good idea to wait about 15 minutes after the announced start of the event before the introduction. A few people may turn up a bit late and those who were on time can use the time for getting to know each other. Note that the time you should wait may vary based on local culture. It's up to the facilitator to decide when it is suitable to start the introduction.

Just before kicking off with the introduction it is usually worth to see if there are any people on the street who didn't find how to get to the venue. This is optional, but many events are held in offices and getting in may not always be as obvious as it might seem at first.

Introduction

During the introduction the facilitator sets the stage for the rest of the day. Here are the topics I usually talk about:

Motivation

I usually kick off by talking about Coderetreats, and point out that the primary goal of them is to provide a safe environment void of time pressure where participants can experiment with best practices they didn't have time to try on the job. While Coderetreats are a tremendously good way of learning the basics of these practices they have an implicit message that you either do things right, or finish on time. I do not buy into that since I believe that the very purpose of a good practice is to make us more effective.

Lean Poker was designed with this message in mind: no serious project is ever finished, but we can make sure to deliver value faster than our competition and good practices help us in doing just that. If we can deliver just a bit more value within a given period of time than our competition we have done our job well.

At Lean Poker we are not trying to go fast, but instead aim at making steady progress in the right direction by small incremental changes. We do not aim at completeness or perfection, we aim at beating others to the market with the next improvement. We aim to learn fast and adopt to an ever changing environment.

Lean Poker in practice

During the Lean Poker event teams will compete in building poker bots that play against each other. The bots start playing immediately once the teams are registered, practically before anyone had a chance to write a single line of code. Every few seconds there is going to be a sit'n'go of Texas Hold'em poker, and the bot that wins gets 5 points, the runner up gets 3 points. Every team can deploy at any time to change the bot's behavior in production.

I usually mention Etsy at this point. Roughly speaking Etsy is eBay for people creating handcrafted products. At Etsy every single commit that is pushed to the git repository triggers the build pipeline. If a particular commit passes all of the automated tests it is immediately deployed to production.

At Lean Poker we have a similar rule - except by default no tests run - that the pushed commit is deployed no matter what.

When registering each team will get a scaffold that contains a source file named player. The team should edit the bet function in this file. This function receives a game_state data structure as described in the player API documentation. The bot should return a non-negative integer representing the amount of chips the bot is willing to commit to the pot at any given time. If the function throws an exception or the returned value is not a non-negative integer, the player will be banned from the sit'n'go.

Structure of the day and rules

Next I talk about the structure of the day as explained on the about page as well as the rules described on the same page.

Team creation

After the introduction it's time to self-organize into teams. I usually ask participants to gather into a large standing circle and as I shout out the supported languages (you can find a list on the Lean Poker website) I ask them to raise their hands if they would like to use that particular language, and look around to see who else they could team up with. Participants can indicate their enthusiasm about the language by putting their hands up lower or higher.

After all the languages have been listed ask the participants to self-organize into teams. The rule is: whoever does not have a team should remain standing and look for teammates. Whoever has a team should find a table to sit down with the team. Each team should be between 2 to 5 people, there should be at most 6 and at least 3 teams. On public events I also ask participants to try and form teams with people who work at other companies. On private events I ask them to work with people they don't know or are at least involved in other projects.

If there are people who could not find a team for themselves, try to assist them.

Once all the teams are complete, go to your event on Lean Poker Live and open it. Once the event is opened teams will be able to register. Tell teams to visit live.leanpoker.org and open your event. Once they have done that, one person from the team should register by specifying a team name and language. After that team members can join teams individually, and the team owner can approve them. Team members will be added as contributors to the git repository, so that they can push code without creating a pull request.

After each team has registered, you can start the event. Note that once the event is started it is not possible to add more teams.

At this point teams can clone their repositories and start working.

Coaching through the rest of the day

The rest of the day is a sequence of 1 hour long coding sessions, short retros and 15 minute breaks repeated a number of times. During the retros and breaks the event should be paused, and resumed for the next coding session. The only exception is the last retrospective and the closing circle during which the event should keep running. The reason we do that is to make sure that it's still worth for teams to deploy during the last few minutes of the last coding session.

Coding sessions

Walk around between teams, and talk to them. Try to understand the problems they are facing and answer their questions if they have any. Bellow is a list of things you might want to look for during the coding sessions.

Retros

After every hour of coding gather the teams into a large standing circle. Teams should group together. Ask each team to talk about the problems they were facing, how they solved them or plan to solve them. They should also talk about how they distribute work amongst themselves. Make sure you explain that the purpose of the event is primarily to learn from each other so they should be as open as possible. I also encourage them to talk about their current strategies, since they will soon change it anyway, but don't push that too hard. Most of the time teams like to keep their exact strategy to themselves.

Closing circle

Before the last coding session remind participants that after the last session the event will keep running for about 30 minutes during which they will not be able to make changes to the code anymore. After the last session follow up with the usual retro, but after that we do a second round. This time everyone should reflect one-by-one on the entire day. This last round is the closing circle. For the closing circle I usually write the following three questions on a piece of paper that I pass around the group, and ask them to answer them one-by-one:

• What if anything surprised you today?
• What if anything did you learn today?
• What if anything will you do differently from now on?

The purpose of the closing circle is to reflect on the day and make sure that participants are taking away at least one thing at the end of the day, and they are conscious about it.

After the closing circle thank participants for coming, and urge them to return for future events. In case of public events also make sure to say thank you for the company sponsoring the day.

Things you can look for during the day

No or very few commits during the first session

Some teams start by overengineering the problem. This usually leads to the team falling behind during the first session. During the retro call their attention to the fact, that they need to be consistently better than other teams not just at the end of the day. Try to get them to try and deliver as small of an improvement as possible. Some teams may say that they were setting up their environments, or making sure that their tests were running etc... If that comes up, it's worth pointing out that at first they may be able to deliver more value by postponing these efforts just until they have at least something marginally more intelligent running than the fold strategy.

One team gaining large lead over others in the first session

This is pretty much the opposite of the previous. This usually happens when a team realizes that by changing the return 0 to return 10000 they can turn the fold strategy to an all-in strategy, which is very effective against passive players. Point out that this is a very good strategy. The minimum viable product - as defined by Lean Startup - is almost always less than we would think, in this case just four extra digits in the code. If you see both the issue above in one team, and another team getting ahead with the all-in strategy you can contrast the two.

Frequent but short deep dives

When teams do not write any tests they can easily end up deploying versions that are crashing. When this happens the croupier bans them from the sit'n'go, which means the team can not collect points at all. Teams usually try to rush ahead in situations like this. When you observe that kind of behavior bring it up during the retrospective. It's a great opportunity to talk about the importance of at least a simple smoke test. (Even if it's just a bash script that sends a request to the bot, and makes sure that it returns a non-negative integer.)

In some cases the team may also point out, that they had returned something other than a non-negative integer, or they have thrown exceptions. If that happens, you can mention that it is a good idea to have a fallback response when something unexpected happens. This can make a system more resilient and can allow other services to handle the failure gracefully. In this particular case adding a try catch around the function body and returning 0 in the catch part is a good fallback. Also when the result is not an integer or it is negative, falling back to 0 is a good safety mechanism.

Errors going unnoticed due to the fallback mechanism

The danger of introducing a fallback mechanism is that there won't be an obvious sign of the failure anymore. The bot will just be on fold strategy. When a team runs into this issue, call their attention to the importance of logging an monitoring. When the code runs into a fallback it should log a warning, and the team should set up some kind of an alert for that. This is possible by setting up Logentries or Papertrail for the bot, and using it to send emails when a particular line of log appears.

Long deep dive with no commits

Sometimes a team may deploy a faulty version into production, and move on to implementing the next feature without checking the results. This is another opportunity to talk about the importance of logs, monitoring and alerts.

Long deep dive with lots of commits

This usually occurs as a consequence of the previous issue. When the team realizes that there is a problem, they try to rush ahead and instead of rolling back to a previous working version, they go into a fixing frenzy and deploy every single small change they think might fix the problem. If this happens bring it up, and talk about the importance of staying calm during crisis situations and having a good rollback mechanism as a contingency plan. When a faulty version is deployed, a roll back should be the first step and investigation should only start after that.

Premature post-flop strategy

During Lean Poker events the distinction between a pre-flop and a post-flop strategy is very important. Implementing a fairly decent push-fold strategy that only concentrates on the pocket cards is much easier than having a good post-flop strategy. During the first 3-4 sessions the pre-flop strategy is much-much more important than the post-flop.

Many teams do not realize that, and start working on post-flop strategies fairly early on. I usually wait for the first teams to make that move, and during the subsequent retrospective I explain the difference between a pre-flop and a post-flop strategy, and challenge teams to examine which of the two plays a more important role during the sit'n'gos.

Some teams will actually either abandon their post-flop strategy after this information is revealed, or at least scale down on their efforts in favor of working on a sturdier pre-flop strategy. Other teams will be so much caught up with their original concept, that they will pursue it nonetheless. When that happens and they keep losing, you can talk about the importance of letting go of our ideas in favor of early pivots based on feedback. It's all about judgement and pragmatism.

Usage of Rainman

Rainman was intended as a trap deliberately set up to teach people a lesson about the importance of properly examining a technology before investing into it. Some teams actually do get it working, and can build winning strategies on it, but most of the time it's a waste of time to try and integrate Rainman.

There are multiple reasons for that. First of all Rainman only works with 5 or more cards, so it's useless for pre-flop strategies which is way more important than post-flop. Even if the team is rightfully working on a post-flop strategy, Rainman only tells them what they have and not what they could have once more cards are revealed, neither does it say anything about how it compares to other possible hands competitors could have.

When teams fall into this trap I usually explain that using new technologies is a good thing as long as that new technology actually solves a problem that we have. However it is way too easy to get caught up in our passion for introducing new technologies and losing sight of the original problem we set out to solve in the first place.

Specialization within teams

With teams of at least 4 people specialization is almost inevitable to be effective as a team. Usually not more than 3 people code, and the rest of the team will be analysing the results. You may see the following roles within a team:

• Developers: They write code and may even deliver part of the domain knowledge to the team.
• Team lead / Project manager: Sometimes there is a person who takes matters into their own hands and makes sure that the team can work smoothly.
• Automated quality assurance engineer: In some teams one person may be assigned for a short while to solving the problem of automated testing or monitoring.
• Analyst: Looks at recent games and tries to find out where and why the bot won or lost big.
• Data analyst: Same as the analyst, but instead of looking at the Lean Poker Live dashboard and game viewer, the data analyst will download the JSON data structures and analyse them with scripts that detect certain patterns.
• Product manager: The product manager is usually doing domain research on Google, mostly looking for easy to implement poker strategies. Works closely with the analyst to find out what problems need to be addressed by the next strategy.

All of the above roles may appear separately or in some combination. Sometimes the same person may take multiple roles or roles may be traded between team members during the course of the day. What you should look for is which team starts to develop such specialisation first, and make sure that they talk about it during the retro. When a strong product manager or analyst role is present, you may want to point out how useful that is for a team to have one.

Silos within a team

This happens rarely, but when it does it can be pretty interesting. With larger teams it happens sometimes that they struggle working together, and instead work in isolated silos. These teams usually underperform. Sometimes it's already visible in how they arrange themselves around their table. A team that has silos will usually sit at a larger distance from each other, than other teams that are communicating more. I usually take a few photos of the team that has high cohesion, and the team that has silos, then I show it to the team with silos and ask them if they can spot the difference.

Team getting ahead, while being consistently second

After the first session players usually get overly aggressive. That amounts to short games where players lose their stacks pretty quickly. When that happens a team may realize that going back to a more conservative strategy can ensure they make it to at least second place every single round. Since gathering 3 points every round is much better than gathering 5 points every second round this strategy works really well against a set of aggressive bots. The only drawback is that by the time they get to the heads up (when there are only 2 players left) they end up being short stacked against their opponent. Still being on fold strategy (or a very conservative strategy) until the heads up, and then becoming bit more aggressive is a strategy that handed the trophy to many teams in the past.