It’s Monday! 🚀 Developer Experience Kickoff
This was the title of a blocker in the calendars of members of the DevEx team at BRYTER, spanning from 9:00 CET to 12:00 CET every Monday. Three hours. Quite some time for a meeting. Unless: This was not a meeting, as you may know it.
This was one of the highlights for us, every week. Not a mandatory meeting prescribed by our agile framework (we did not use one) or a meeting called by a manager (our managers understood their role in supporting rather than demanding things).
The weekly kickoff was one of many results our team got from constantly adapting and improving our ways of working. Long, long time ago, we realised that it can feel quite lonely to start the week without seeing your colleagues, when you are working as a remote team. Sure, smaller groups would meet and collaborate, but that is not the same.
Furthermore, it can be quite hard to get back into work after a weekend, when you are on your own, need to start a new task or figure out, what you were doing last week. The weekly kickoff solved all these topics for us and gave us space to reconnect, reflect, adapt, collaborate and kickstart. It put us in a productive mood that lasted throughout the week.
Structure of the Weekly Kickoff
The weekly kickoff is not a planning meeting. Planning is a small part, but not the main focus. It combines spending quality time, recapitulating the last week, making plans for the week and collaboration. The Weekly Kickoff is about spending time together in the most meaningful way.
Therefore, the agenda varies a bit from week to week, but some elements were there most of the time:
- Extended Checkin
- About Last Week
- About This Week
- Writing our weekly update
- Discussing Collaboration Topics
- Checkout
- Collaboration Time
In our Developer Experience Team, we used a Mural board to visualise our reaction circle, the agenda, and notes we wanted to take during the session. It helped us to have some structure while still having the flexibility that we wanted.
1. Extended Checkin
We started the kickoff with an extended checkin. At BRYTER, almost every meeting started with a short checkin that helped people to arrive in the meeting, share their state of mind and allowed for personal connection and empathy. This can be difficult in a remote context otherwise. Usually during a checkin, every attendee would say how they arrived and (maybe) what they expected from the session.
The extended checkin followed a similar approach, only that we made it much longer, shared events from the weekend, topics on our minds (personally or work) and other things we wanted to share. This typically took 10 to 30 minutes, and we intentionally gave it a big time box to not rush into work but prioritise connection.
“People first!” is an important principle to build great and trustful relationships with each other.
2. About Last Week
After the checkin, we reflected on topics from the previous week. We checked, if there were any open merge requests (MRs) and discussed their state. Furthermore, we looked into close and ongoing tasks on our GitLab board. Last, but not least, we checked if there were any other ongoing topics that were neither reflected in MRs nor tickets and made sure that we made those visible, if necessary.
Usually, already during the checkin, team members would share things they were still working on, or they were working on last week, but this wasn’t a requirement.
Reflecting about last week was neat. It made visible what we had accomplished as a team and also remembered us about topics that were still open and that we would likely continue this week.
After having recovered our memories about the previous week, we naturally progressed into discussing the topics for the current week.
3. About This Week
Of course, we had a board and, in theory, everybody could just pick the top item from the up-next column. However, checkin in together helped to make sure that the board really reflected our current state. Furthermore, we ensured that we collaborated on the most important topics that were ongoing, rather than being quick to jump onto the next topic alone.
Therefore, we checked that the board contained all the necessary information for the next tickets and discussed how and if we can collaborate on ongoing tasks before pulling something new. This already gave some good ideas on what we could work during our collaboration time, which usually was about 2 hours of the 3-hour kickoff.
4. Writing our Weekly Update
As a platform- and enabling team, it was quite relevant for other teams what new features our platform (tooling, technologies, libraries, …) had to offer and what they could expect from the upcoming week.
Therefore, every Monday, we have published a summary as a Slack post. Having reflected on the last week und the main priorities for the current week refreshed our memories enough to write a short summary while focussing on what was important for other teams. We focussed on achievements and changes rather than what we did.
We wrote the weekly update collaboratively in Notion within 3–5 minutes during our Kickoff. The facilitator would then publish this summary after our kickoff as a Slack post.
5. Discussing Collaboration Topics
Until this point, we usually had identified 2–3 topics that we would like to collaborate on in various constellations. We briefly discussed who would collaborate with whom and opened some breakout rooms in Zoom to meet in smaller groups.
Occasionally, we have decided to collaborate on a single topic with the entire team. This was typically the case when the topic was more complex, highly cross-functional or a topic with plenty of unknowns where we wanted to build up more knowledge with the entire team.
After deciding what topics to collaborate on, we closed the big round with a checkout if we continued in breakout rooms.
6. Checkout
Typically, at BRYTER, most sessions would end with a checkout. In a checkout, participants would state how they liked the meeting, what they take away or what could be improved next time.
Due to the open-ended nature of our weekly kickoff, we have realised, at some point, that we missed a checkout round and that it felt odd just to leave into the breakout rooms. Thus, we decided to put a formal checkout before splitting up. This allowed us the space to thank the facilitator and other people, summarise our highlights, and mention potential improvements and ideas for the next kickoff.
At this point, we would usually do a 5-10 minute bio-/coffee-break before starting the collaboration time.
7. Collaboration Time
Typically, the collaboration time took around 2 hours of the entire 3-hour blocker. During this time, we would pair- or ensemble-program or collaborate on other topics such as investigating bugs, experimenting with new technologies, researching or even jumping on calls with other teams and helping them with their current challenges.
We had two other blockers (one on Tuesday and one on Thursday) for collaboration, and would also jump into collaboration times any time one of us found it usable.
Rotating the facilitation
The normal dynamic of meeting/session facilitations is, that one person happens to be the facilitator. Depending on the team you are working on, this could be a Scrum Master, a coach, a team lead or some other lead (tech/product). It could also be the person arriving at first on the call, talk first or be quickest to open the Mural board.
Not having any coaches or team leads when we started to have the weekly kickoff back in 2021, it was me, the tech lead, who was prone to become the default facilitator.
I did not want that. Sure, I am more than happy to facilitate any kind of session with any kind of group of any size and have done so thousands of times in my career, but I never liked the idea of a default facilitator. The reasons:
- If the facilitator is absent for whatever reason, usually nobody else feels equally comfortable to facilitate.
- Having always the same person facilitating robs the others from bringing in their ideas for the facilitation and prevents cross-pollinating each other’s facilitation styles.
- Facilitation often comes with the burden of not being able to fully participate in discussions. Great facilitators should stay objective and hold the space for others. Having always the same person on the team, doing this, is unfair.
- Being able to facilitate meetings is a great skill to have and something that I recommend everybody working on a team to do occasionally.
However, as a self-organising team, we also did not really see the need for external facilitation for this kind of meeting. — Thus, it had to be a team member who took this role.
Thus, I suggested that we rotate this responsibility along with many others. At the end of every weekly, we would find another person to facilitate the weekly next week. This person would also be one of two people in our Slack support handle and to take care of handling requests from other teams in our channels.
At the beginning, some people on the team were more shy to step up and volunteer to take this role for a week. However, after some time, everybody was able and felt comfortable enough to do this, and we inspired each other with our facilitation styles.
We also followed a similar approach with my team at PAYONE and I saw similar benefits and can highly recommend trying this kind of rotation with your team to liberate structures within the team.
Conclusion
The weekly kickoff is a fantastic way to start your week as a team together.
- You check in and reconnect with each other,
- naturally bring back memories from the last week,
- discover what the priorities are right now,
- and kick-start the week in a fun, human, efficient and effective way.
For our team, this was probably the most important event of the week, and we loved it. It allowed us enough structure and flexibility to satisfy our needs and to set us up for a productive and successful week.
What kind of rituals is your team using? And how are they working for you?
