Full Stack Poker is a workshop I came up with to help facilitate a dialogue between stakeholders who need to collaborate with getting the right skills into teams in the right way.

Loosely based on the planning poker game, it's a highly interactive way for participants to collaboratively go through required capabilities and assign each of them a Team Collaboration Pattern.

Mentioned previously in this book, Team Collaboration Pattern are used to describe how a capability can be provided to teams. Full Stack poker provides a lightweight means for stakeholders to agree on an initial engagement model between support functions and other teams. The session tries to nudge people from the typical hand off oriented approach to one where people come to teams to help.

I have play tested the game with clients, practitioners, etc. and early results have been good. Full stack poker is a simpl(er) way to discuss what can be a complex topic.

If you like this article read more about other Agile Organizational Design in my latest book

Steps to playing full stack poker

1) Map the organizational context of the teams in question

We want to limit the session to a particular segment of the organization. A good starting point could be a product line or two and the teams dedicated to the dev and maintenance of them, or the collection of teams responsible for supporting a specific set of customers. We don't want to do the entire organization in one session as we will never get anywhere :). If the structure of your context is not well understood, then consider running an Organizational Mapping exercise prior to this session in order to understand the structure and scope of responsibility of edge, inner and outer core teams.

2) Make an inventory of the roles and skills teams need to deliver value.

These skills could be based on roles, systems, domains of knowledge, expertise in working with market actors, you name it. Create a backlog of the skills and capabilities your teams need and then prioritize this list in the order you want to tackle each skill. Here is an example skill list from stereotypical enterprise:

Sample Skills

Delivery

  • Story Analysis (by domain)
  • Story Testing
  • Delivery Leads

Engineering

  • Devops (often by platform)
  • Architecture (by system / domain)
  • SRE
  • Core Developers (by language)

Value

  • Product Expertise (by product)
  • UX
  • Bus SMEs
  • Marketing
  • Sales
  • Branding
  • Measure / Learn

Operations

  • Incident / Problem
  • Monitoring
  • Call Center
  • Op Readiness
  • Logistics (by proces)
  • Enterprise
  • Training
  • HR
  • Legal
  • Compliance
  • Finance

3) Give each player a deck of Full stack poker cards

Each card represents a different team collaboration pattern. Each card also has a score, this is the organizational complication that each card incurs if you choose to use this pattern. So providing a skill through a Full Time Team Member creates way less organizational complication than providing that same skill through a Service Center. We will be using this score to track total complication in our organization. More on this later.

4) Play Full Stack Poker going through each of the skills in priority order

  • Select a particular skill you want to discuss. Spend 1-2 minutes discussing the scope of the capability.
  • Everyone at the table drops a single card, representing how you want that skill to be provided to a team

5) Discuss the player's choice and try to get to a common decision

This is done "planning poker" style. The players with the highest and lowest rank start the discussion, answering why they chose the card they selected. If the table cannot come to a consensus than anyone can ask to run a re-vote.

6) Place the skill in an organizational zone and calculate the complexity score

Agree on where the person who has the skill is being staffed / resourced from, typically this is a well known team that exist in an edge, outer zone, or inner zone.

Once a skill is placed in an organizational zone the complexity score can be calculated by adding the complexity score of the zone to the complexity score of the pattern. The complexity score of an organizational zone can be calculated as follows; if the team is directly responsible for staffing the position give the zone a score of one, add one for every layer "away" from the the team.

The table can then move on to the next skill in the backlog, making sure to track of the total complexity score across all of the skills.

Once the table has voted on all the skills and placed them into an organizational zone, total organizational complexity across the skills can be discussed by the participants. Key topics to consider include:

  • How many skills are being provided by using the service center or traveller pattern? How can we move more of them into either the Full Time team Member or Enabler pattern?
  • How many skills are being provided by people staffed by inner core zones? Is there an opportunity to shift some of these skills closer to outer zones and even directly to the Edge?
  • Look at the overall complexity score, is it a lot higher than the total number of skills that were discussed? If so where are some areas where the score can be lowered?
  • What are some of the reasons behind having a high complexity score? What needs to change organizational before we can start to reduce this complexity?

Download a PDF of the cards here!

Download a one pager on instructions here!

If you like this article read more about other Agile Organizational Design in my latest book