The Swarm Template has been used for the past 6 months to kickstart projects by swarms. For a variety of reasons, swarms have not always kept the template up to date, resulting in missed important milestones, specifically Research and Specification. These milestones have often been skipped or overlooked before engineering implementation has begun.
Upon reflection on the types of work being done inside swarms, it can be concluded that a Swarm ITSELF shouldn’t be going through milestones. Rather, projects WITHIN Swarms should be the ones going through regular milestones. Having a single “Specification” or “Ideation” phase for an entire swarm should not allow for carte blanche development from then on. For example, the Keycard swarm should have multiple milestones for each of the sub-swarms (e.g. multi-account) rather than one milestone for the entire Keycard swarm. Therefore, Research/Specification milestones should be a semi-regular occurrence for all Swarms across multiple projects, not one-off events.
Request
For those interested in helping to contribute or give feedback on the existing process, feel free to discuss your thoughts below. Specifically, the following questions are top of mind for the Janitors:
What are ‘frictionless’ ways we can improve the Swarm process to ensure the Research and Specification milestones are completed?
Do you have examples of a review/gating mechanism being done effectively in similar organizations (e.g. similar size, distributed, web3, etc.)
It’s specifically written for non profits because “While you can debate weather the purpose of a business is to make a profit, without it there is no business”…“non profits don’t have the discipline of the bottom line”
In that sense some of the processes outlined in the book used by successful non-profits of all sizes and formations could be relevant for swarms.
I read this a few years ago but doing a quick refresh here are immediate ideas:
The swarm focus on the goal(s)
The goal should be front and center alongside the activities board (wrike, pivotal, jira, etc).
A standup should start with everyone stating what they did and how it helps move the goal forward.
A retrospective should be to done in order to abandon what is not working and strengthen what is.
If there is quick consensus on a decision it means nobody did their homework. The meeting should be postponed until everyone is caught up.
I don’t think every swarm should adopt these rules verbatim, but I think swarms can come up with their own processes that embodies the same spirit.