Squad handbook

Summary

  • Squads last an entire 5 week development cycle
  • New squads are formed at the start of each cycle, with a clear mission to deliver either a big-batch project or a number of small-batch projects in one or more SWAT-TEAM squads.
  • Squads are formed of at least 2 developers and 1 designer
  • Between development cycles we have either a 1 week or a 2 week "regroup" period. During this period, people may take time to submit pitches, fix bugs, work on internal pet projects, address debt, tooling, and planning for the following cycle.
  • For work to be considered for a pitch, a  pitch  needs to be created. Anyone can submit a pitch, and are encouraged to do so.
  • Between cycles, during the regroup period, chchris pipierre and mimike will review all the pitches and allocate which ones will be picked up in the next cycle or even future cycles to allow for some slightly longer-term planning.
  • At the end of each cycle, we get together for Show And Tell, where each Squad demonstrates their achievements and functionality. This should also include process achievements, as all Squads are autonomous, choose how to work and share what works well and what didn't work well with other Squads.


Squad details

  • Each squad has a Squad Captain. The captain of the squad is somewhat similar to a Scrum Master. They are not the sole decision maker, not the sole accountable person for the output of the squad. The captain is, however, responsible for organising the squad. This should include having clean Slite documentation, making sure the squad's ClickUp tasks are up to date, running any meetings and ensuring the squad communicate effectively.
  • Each squad is autonomous and should share best practices, what worked and what didn't with the rest of the team.
  • Squads are encouraged to perform some of the following initiatives:
  • Kick Off - Division of work, ClickUp tasks and setting objectives and milestones
  • Standups - Either realtime, or asynchronously, perhaps daily, or every other day to reduce Too Many Meetings
  • Clarity and good communication
  • Big-batch squads are encouraged to ship often and deliver small pieces of functional work and not to only ship at the end of a 5-week cycle. Remember, shipping can be behind feature flags and internally.
  • Squad tooling
  • Slite: Each squad has a dedicated channel in Slite with 1 collection per task or per cycle
  • Slack: We have 1 channel per squad per cycle
  • Task management: We use 1 list/board per cycle


Pitch Details

  • Squads are there to give ownership to everyone at Slite. In this logic we want everyone to feel empowered and able to bring ideas to the table and changes to the product.
  • A pitch is not a fully formed specification
  • A pitch should have enough information to estimate it's sizing into Small, Medium and Large blocks.
  • Small = 2-5 days
  • Medium = 1-2 weeks
  • Large = 3-5 weeks
  • A pitch should try to include some form of UX/UI illustration, but may not be the final implementation.
  • A pitch should engage other people in the company to comment and provide feedback. Ping others in the early stages of a pitch to get input. If you feel at the early stage that the pitch is not well received, don't be afraid to abandon it and return to the idea at a later date.
  • To do so anyone can pitch an idea to the rest of the team, by using the #product channel and the  Pitch template 


Further Details & Questions



Regroup weeks / 1-2 weeks cycles

These shorter cycles are about cleaning and bugfix. We need to start larger features with an clear mind and so we clean things up before starting.
Regroup week are also the times to prepare for next block. Squads gather & go through data, productboard and pitches to define their tasks for the next block


Documentation

The end of a cycle is the right time for the squad to document things in the appropriate channel (dev, design, product, support,...).


Why this process

We launched squads after we talked about our core processes issues at the end of September 2018 to adjust things.


September 2018 - What was broken?

  • 2 weeks bring pressure, hard to achieve goals and hardly finished features
  • Sliters lacked of autonomy and impact
  • We were losing a huge amount of time because of our ceremonies
  • We didn't know how to well integrate bugs & quality in our sprints


July 2018 - What was broken?

  • People were organized around domain, not features (#dev #design)
  • Communication on each feature were team-wide causing a lot of spams & reduced exchanges
  • This created loneliness for developers while developing large feature
  • Product/design/dev was supposed to be done in sequence which avoided the back & forthes, created frictions and reduced the interaction between all positions