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, chchrispipierre 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