In a previous blog post, I wrote about how to put in place a dual-track agile structure that allows you to validate ideas before spending the effort to build it.

In this blog post, I wanted to go one level deeper. This time I’ll cover how I run agile ceremonies within a dual-track agile structure.

For reference, this diagram covers a typical agile structure if you follow a 2-week cadence.

‘A classic sprint cycle’ an image by PagerDuty: https://www.pagerduty.com/eng/agile-scrum-ceremonies/

Standup

This is a 15-minute daily meeting for the team to discuss what they did yesterday, what they are working on today and whether there are any problems. Standups are short, snappy and get everyone on the same page. I like to talk to a visual board on JIRA or Trello, and move tickets if there are updates. Each person should speak for 2 minutes and if people start to drift, then gently remind them to take this out of standup.

When I run standups, I like to book a 30-minute slot. The first 15-minutes is for the traditional standup, the remaining time is to cover any blockers the team have identified. Anyone who needs to be involved in resolving the issue stays on, whereas the others not needed can jump off the call.

Show and tell / demo / sprint review

This is a 1-hour meeting where team members present their work. I invite senior stakeholders to see the team’s accomplishments. You can share what you’ve learned, discuss your plans for the next few weeks, and answer questions. It also allows other teams to understand how your work connects to theirs.

I’ve run demos differently based on the environment. For instance, with clients, I provide updates on key risks and the budget. At other times, I’ve combined presentations with teams in similar spaces to share lessons. Don’t shy away from sharing not so shiny things e.g. technical debt work. It’s important for stakeholders to understand why this work is important.

The consistent theme when running show and tells is to ask people to keep their presentations to 10-15 minutes to maintain interest. We visually show the work to build rapport with stakeholders. If you don’t have much to show, run a shorter demo.

Importantly, a show and tell doesn’t need to be polished. Don’t spend ages crafting perfect slide decks. It would be more interesting to show a prototype or run a live demo.

Here’s a typical structure:

1. Update on project health e.g. timelines, progress, risks, budget. [10 minutes]
2. Update on technical e.g. interesting development work, new functionality [10 minutes].
3. Update on design e.g. new design ideas to facilitate initial feedback [10 minutes]
4. Update on user research e.g. an update on user feedback [10 minutes]
5. Next steps e.g. an update on the plan for the next sprint [5 minutes]

‘Show and tell’ an image by Mikhail Nilov: https://www.pexels.com/photo/a-man-making-a-business-presentation-to-colleagues-9301257/

Retrospective

This is where your whole team talks about what’s going well, what is not and what can be done to improve things within the team. Retros can last up to 1 hour.

A typical structure I follow:

• Allow participants to write down what is working well and not working. [15 minutes]
• Dot vote on the post it notes people want to talk about most. Each person gets 3 votes. [5 minutes]
• Discuss how we might improve things and capture actions. Timebox your discussions so you can get through everything. [35 minutes]

In the past, to make retrospectives more interesting, we had different team members run it.

Planning

During planning meetings, the team decides their next tasks and how to approach them. These meetings usually last 1-2 hours and occur every 2 weeks.

Before I go into planning, I review and prioritise the backlog. Then, I hold a pre-planning session with the Technical Lead. We spend an hour looking through what we’ve achieved in the last sprint, what is outstanding, review the backlog and confirm the key technical stories for the next sprint.

Once, the Technical Lead and I are comfortable about what the sprint looks like, we run a planning session. This is a typical planning structure I like to follow with developers:

• Review the roadmap and capacity. [10 minutes]
• Review items on the board, assign points using dev days or story points using planning poker and then assign tasks to developers. [45 minutes]

In dual-track agile, I like to split planning so that we are always thinking about discovery. Typically attendees tend to be the design team rather than the technical team.

• Review the roadmap and capacity. [10 minutes]
• The design team captures what they think needs to happen in the next two weeks. [10 minutes]
• Discuss these items as a team and add these tickets to the board. [35 minutes]

At the end of planning, I put an update on Slack to ensure people understand the key priorities of the sprint.

Conclusion

Whilst I’ve tried to provide examples of how I run teams, it shouldn’t be how you necessarily run the team. Agile teams should be self organising, and it is up to the team on how to best run.