Working on ‘Ways of Working’
I am about to introduce a new agile software development methodology that we will be implementing on our current project at Parliament Digital Service. It’s called ‘Cycles’, and it takes inspiration from the Shape-Up method at Basecamp.
One of the main goals of Cycles is to break down silos and facilitate better collaboration between the dev team and all the other disciplines. To do this, we have made a number of changes to the traditional sprint structure.
First and foremost, we have a Cycle at the length of 8 weeks. Each Cycle contains 4 Phases that last 2 weeks each. This allows for a cadence with existing agile models and is minimally disruptive, which I believe will help us be more agile and responsive to change.
We have also implemented automatic check-ins using slack bots. This means that at a set time each day (e.g. 9:30 am), team members will receive a message asking them to complete a short daily write-up. This write-up should include information on what they will be working on, any blocks they are facing, and any other relevant updates. This replaces the need for a stand-up, which can be time-consuming and not always productive.
Another key aspect of Cycles is the Retro bucket’. Rather than having a retro at the end of every sprint, we will only have one if the ‘Retro bucket’ overflows. The retro bucket is a virtual container that holds all the items that would normally be discussed in a retro. If the number of items in the bucket reaches a certain threshold (e.g. 30 items), we will have a retro to discuss and address them. If there are fewer items, we will wait until the end of the cycle to have a retro. This approach allows us to have fewer, more focused retros that are more likely to lead to meaningful change.
The planning phase of a cycle has also been modified. It is now split into four phases: planning, refinement, 3amigos, and cooling off. In the planning phase, team members pick their appetite for the whole cycle and discuss features and epics rather than assigning specific tickets. This allows for more flexibility and encourages a focus on the bigger picture. In the refinement phase, work is refined into more specific tickets, and in the 3amigos phase, tickets are reviewed and any that are deemed untenable are denied and archived. The final phase, cooling off, is a time for resolving any remaining tickets and includes a show and tell, stakeholder engagement, and a retro.
We are using a simple KanBan board with only six buckets: To do, Blocked, In Progress, Review Pending, Ready to Test/UR and Done. This is also split to 2 swimlanes Dev sits on top and Design / Research at the bottom. This allows us to streamline our workflow and avoid unnecessary meetings. The flow is left to right and bottom up.
Finally, we have instituted some strict rules for meetings. All meetings must have a clear agenda, and they must be time-bound and recorded. They should also have published outcomes, and there should be no more than three people in attendance (except for cycle meetings). By following these guidelines, we hope to make our meetings more efficient and productive, and everyone’s calendars less of a Tetris screen.
I am confident that the Cycles methodology will help us break down silos and improve collaboration within the team. I believe in long uninterrupted focused work time and this is what the Cycles are trying to achieve. Culture is not your vision and mission statements, but what you do every day, how you work and how you respond to change. I look forward to seeing the positive impact it has on our project at Parliament Digital Service, and most importantly for a spread to other teams an wholesale adoption.
What a Cycles calendar should look like
