How to run a Design System team ceremony or workshop
This document details the principles, tools and resources we use when planning and running a ceremony or workshop on the Design System team.
Facilitation principles
There are some principles that are important to remember when planning and facilitating a ceremony or workshop on the Design System team:
- consider if there are asynchronous methods you can use to get the information you need. With remote working it is easy to experience video call fatigue.
- share an agenda and session details ahead of time (including links to slide decks and collaboration tools). This helps participants prepare for the session and frame their thoughts - it can be difficult to think on the spot.
- consider the accessibility of the tools used in the session - we prefer to use Trello or Padlet.
- make use of the ‘optional’ invite for those who don’t need to be there.
- if it’s an open workshop, consider adding the meeting to the Design System team events calendar which can be seen by all. Ask a delivery manager for a link to the calendar.
- avoid booking over the lunch period (12-2pm). We generally avoid that period for meetings to give everyone an opportunity to have lunch and get away from their desks.
- things always take longer than you think they will! Scope your session carefully and ensure it ends on time.
Ceremonies
All team ceremonies live in the Design System team events calendar. This is to ensure multiple people can access the calendar entries to make amendments if the facilitator / owner is absent.
Each squad has its own stand up, sprint planning, mid-sprint review and retro. The only combined ceremony is show & tell.
Stand up
The team currently hold separate stand ups for each squad on the team. We have a different facilitator at each Google Meet stand up.
Design System squad
The Design System squad has a Google Meet stand up each day at 10am except on no-meeting days. It is up to the facilitator to decide the format of the stand up. From August 2023 the squad are trialling using the GitHub sprint board at every stand up.
There are a couple of formats that can be used:
- looking at the ‘Needs review’ column only and identifying who is needed to review something and when they can do it
- reviewing the ‘Blocked’ column and asking the team what’s needed to unblock something
- running through the ‘In progress’ column and asking for updates
- reviewing the ‘Sprint backlog’ and asking if anything can move into ‘In progress’
- focusing on just one epic and reviewing all cards in all columns related to that epic
Frontend squad
The Frontend squad has a Google Meet stand up each day at 10am except on no-meeting days. It is up to the facilitator to decide the format of the stand up.
Keeping stand up focused
Do your best to ensure stand up keeps to 15 mins but this can be tricky when conversation starts flowing! Encourage the team to take detailed conversations offline.
Show & tell
Show and tell occurs every other Tuesday. The facilitator will take a copy of the previous slide deck and prepare it ready for sharing. The team is prompted on the no-meeting Friday before to prepare slides.
We expect to hear from every epic in play at each show & tell. Show & tells help us to:
- document projects, key decisions and activities
- communicate across the team
- share knowledge, understanding and ideas
- stop covering old ground in meetings
- get feedback on hypotheses, scrappy prototypes or conundrums
There are multiple slots available with 5 mins presenting time and 2 mins for questions (7 mins in total).
When facilitating show & tell keeping time is probably the most important thing as it’s very easy to run over. Communicating clearly at the beginning of the session that each talk has 15 mins and you will intervene if it runs over helps with timekeeping.
Start the recording. Introduce each of the speakers and their topics, and encourage questions afterwards.
At the end of the session, share the slide deck and file the recording in the Recordings folder in our team drive.
Sprint planning
Sprint planning occurs for the Design System squad every other Tuesday.
In these sessions, the squad decides what will be delivered in the next two weeks. Because of this, it’s important that the whole squad attends.
It’s useful to prepare sprint goals before the ceremony so conversations are focused during planning. Before the session, the facilitator should pre-populate slides with any notable events in the coming sprint eg leave, conferences, etc.
This is another session where it’s useful to share your screen if facilitating so everyone is looking at the same card at the same time.
Start by reviewing the previous sprint goals, moving any completed goals to “Done” on the sprint board. Then talk through other events happening in the upcoming sprint which may impact the goals the team set.
The majority of the sprint planning session should be focused on agreeing goals. Ensure the goals are actionable, measurable, and realistic. Avoid goals such as “Start doing x”.
It can sometimes be difficult to articulate the goal if you do not have all the context. Ask the team to edit the goal either during the session or afterwards. There are prompts to follow within the GitHub issue template to achieve a well articulated goal.
It’s important to ensure each goal has an assignee(s) who will work on the goal. Do this during the session.
At the end of the session, ensure all goals are in the “Sprint backlog” ready to be worked on and assigned to the correct “Iteration” on the board (eg Q2 22/23 Sprint 2).
Backlog gardening
Backlog gardening occurs for the Frontend squad within the team every other Tuesday.
The purpose of this session is to make sure that the backlog has all the right work in it, that the work is well described, and that it’s ordered well. It’s a fancy way of saying backlog refinement.
Think ahead over the next 4 weeks and consider which epics – or tasks in epics – the team is likely to start working on soon. Ensure that the outcomes are clear and any dependencies are noted: the goal is to make sure that an issue is well described and that someone could pick it up independently. For example, if it’s a spike that should result in a team workshop or learning session, make sure that’s a part of the issue or epic.
This is also an opportunity to think about any pre-work or knowledge sharing that needs to happen. For example, if a piece of delivery work needs scoping, you’ll probably want to arrange a team workshop to help, like MoSCoW prioritisation or getting feedback from service teams.
Where a piece of work can help someone meet their professional development objectives, highlight that they might want to work on it – or assign it to them and let others on the team know they’ll be tackling it.
Note: This ceremony is fairly organic and has suited the team OK so far, but we have identified a need to increase collaboration and pairing on the team. So it should probably be amended / adapted as we tweak our processes to meet the needs of the team.
Mid-sprint review
A mid-sprint review is a checkpoint halfway through a sprint. The session usually lasts 30 mins and checks progress against sprint goals, providing the opportunity to pivot if needed.
In a mid-sprint review, the squad asks the following questions of the sprint goals:
- have any risks or dependencies emerged?
- how can blockers be resolved?
- has the scope changed?
- has it been deprioritised? If so, why?
- has a new goal emerged?
Update the sprint board as a result of the discussion.
Retrospectives
Retros occur every other Tuesday for each squad. The purpose of retro is to reflect on the previous two weeks and identify ways the team can improve its processes going forward. Therefore it’s useful if the whole team attends so we collectively agree to actions.
When planning or facilitating a retro, there are a few things to remember:
- retros are more engaging if there is a different format each week. You can get format ideas from websites such as Fun Retrospectives or 40 ideas to spice up your retrospective, and check previous retro formats in the historical notes folder. Or freestyle!
- use a private Trello board for the retro. If the previous retro notes are cards are still there, kindly ask the previous facilitator to document them and clear the board
- share the retro board ahead of time (preferably the day before) as some folk find it useful to think of contributions ahead of the session
- it’s good practice to begin a retro by reading out the prime directive
- allow plenty of time for discussion and agreeing actions so consider setting time limits to the card contribution stage
- agreeing actions is generally the most challenging part of a retro. It can be easy to agree on actions such as “we should get better at x”. Actions should be specific and actionable, making them easier to achieve
- each agreed action must have at least one owner. You should not assign actions to individuals who are not participating in the retro as you do not have their agreement
- write the notes up after the session and save in this folder. You can use a previous doc as a template.
Other team meetings
Design System & Prototype dev catch up
This is a meeting between developers across the Design System and Prototype teams, to make sure we’re all aware of what everyone is working on. It happens twice a week (Mon at 10am and Thurs at 10:30am currently). Discussions are informal and relaxed, no need for prepared presentations.
This catch-up gives developers time to:
- update other developers on what they’re currently working on
- flag anything they’re working on that may affect other squads/teams
- get help and advice for anything they’re stuck on
- discuss tech debt and technical issues
Facilitating this meeting is very light-touch. On a Monday, start by going around the group and asking each person for their update. If there is time, look through the agenda items. Start with anything listed under ‘related to work in progress / support / time critical’, before moving on to ‘non-urgent’ agenda items.
On a Thursday, reverse the order by starting with agenda items first, and then going to updates if there’s time.
When facilitating this catch-up, there are a few things to remember:
- make sure someone else is happy to note-take (rolling meeting notes here). It’s difficult to facilitate and note-take at the same time!
- try and make sure discussions come back around to actions, even if they’re not things we will be picking up straight away
- if someone is asking for help with a problem, try and make sure they at least have some avenues to explore by the time the call has ended. If not, discuss how to best help them (and who will do that) outside of the catch-up.
Team L&D session
These happen every other Monday and are currently being used to support the team coaching workshops with Stefan Powell. The team has paired up to support reflection exercises.
The agenda of the session currently looks like this:
- Intro
- Complete reflection worksheets
- Pair up and share in breakout rooms, asking the following questions:
1. What have you scored the highest and why?
2. What have you scored the lowest and why?
3. What have you chosen to work on?
- What opportunities are there to work on goals in the next two weeks?
- Update worksheets
- Pair up and share in breakout rooms and ask each other the following questions:
1. What will you do?
2. What support do you need to do this?
3. How will you get that support?
- Close