Agile methodologies empower self-organizing teams to focus on the customer, deliver incrementally, and utilize feedback to adjust priorities. The most common agile methodology is scrum, where small teams operate in sprints, usually one to four weeks in duration. Teams commit to a set amount of work for the sprint and aim to complete it.
The fundamentals of scrum are simple. A team reviews a backlog of prioritized user stories, commits to the work they can confidently complete during the sprint, and aims to achieve the “definition of done” documented in the user stories. Scrum ceremonies help teams collaborate; classically, they are conducted as recurring meetings scheduled by a product owner, tech lead, or scrum master.
Adapting scrum to different work settings
During the pandemic lockdown, scrum teams performed these ceremonies virtually using tools like Zoom and Microsoft Teams. The meeting mechanics evolved to support virtual participation and account for flexible work times.
The question for many organizations today is how to adjust scrum ceremonies to support a permanent shift to hybrid work. Some teammates may be collocated in one or more offices while others work remotely. Hybrid work represents a new opportunity for organizations and teams to revisit their agile ways of working.
Many agile teams are motivated to make hybrid work successful. In one recently completed study, 40% of respondents estimated that 50% of the workforce would continue to work remotely three or more days per week. In another survey, 75% of engineers said they would prefer to work remotely most of the time. Supporting hybrid work is key to hiring and retaining developers.
Engineers on agile teams who permanently want hybrid work options should help their organizations realign scrum ceremonies and review these additional hybrid team devops recommendations.
Start with sprint reviews
Let’s review the four primary scrum ceremonies most teams follow:
- Sprint planning: The team reviews the backlog of user stories, understands the requirements, and commits to the work they complete during the sprint.
- Daily standups: In short gatherings, the team reviews the status of the work to complete user stories and escalates any blocks, questions, or other impediments to completing them.
- Sprint reviews: At the end of the sprint, teams share and demo their accomplishments to the product owner, delivery managers, and stakeholders.
- Sprint retrospectives: The team reviews what went well during the sprint and where they can make improvements.
The sprint review impacts the most people, especially when agile teams invite stakeholders, demo the completed work, and capture feedback. Optimizing this meeting for hybrid work is important because it often involves multiple people and requires an efficiently managed dialog between the scrum team, product owner, and stakeholders.
Andrew Amann, CEO of NineTwoThree Digital Ventures, believes agile teams need to focus on feedback from stakeholders and adjust priorities. He says, “The most important aspect of hybrid work sprint reviews is ensuring that all the decision-makers are involved.
Amann shares these tips for hybrid sprint reviews. “Turn cameras on, and take writing pads out. We combine our sprint reviews with planning for the next sprint. Our teams explain what they completed and what is ready for the next sprint, so switching hats from reviewing to planning within the hour is vital.”
Tips for hybrid sprint reviews
Here are some other ways to improve sprint reviews with hybrid work teams:
- Document user stories from a customer’s or user’s perspective and guide what to demo.
- Assign user stories to team members during commitment and have them be responsible for demoing the story.
- Consider scheduling a rehearsal, especially if the team is less experienced, the features are complex to demo, or significant stakeholder feedback is expected.
- Let the product owner decide the sequence of user stories to demo and time box how long to spend on each one.
- Determine a best practice for how demos are shown in conference rooms and shared virtually to minimize disruptions when switching presenters.
- Decide on an approach for capturing feedback. For example, teams using Jira Software for their backlogs can ask stakeholders to vote for completed issues. Teams on Zoom can use the chat feature to ask questions, and the product owner can open breakout rooms after the demo if longer discussions are needed. Teams can also ask stakeholders to add comments to the user story for small feedback or use a Slack channel to capture general feedback.
- End sprint reviews on time. This is important. If a review is running late, consider closing the meeting and recording the remaining parts of the demo for people to watch when they have time.
- Always record the meeting so that teammates and stakeholders can watch them afterward.
The goal is to ensure that all participants find value in joining sprint reviews, and this requires facilitating an efficient hybrid meeting.
Discuss improvements in sprint retrospectives
Once there’s agreement on a format for conducting hybrid sprint reviews, teams should use their retrospectives to discuss improvements. This is critically important in larger organizations where a one-size-fits-all approach is unlikely to be optimal, but neither is leaving the responsibility entirely to scrum teams to learn best practices.
For example, if a review went too long or a story didn’t demo well, how can the team prepare and demo better in the future? If stakeholders aren’t providing sufficient feedback, what changes to communications, processes, or tools might offer improvements?
Retrospectives also provide an even more important opportunity to improve hybrid work practices, increase teammate happiness, and discuss work-life balance issues.
Ravs Kaur, CTO at Uplevel, says that scrum teams should expand their discussion scope at retrospectives. She says, “Looking at project health and technical achievements are generally at the forefront of most sprint retros, but success isn’t just about the product. To succeed in the long run, the people building the software need to be healthy too.”
Kaur offers these questions and recommendations. “Was the team burnt out during the sprint? Was there an unsustainable amount of context switching? The human cost of productivity should be a huge part of deciding if the sprint was a success or not. You may have met your sprint goals, but is your team satisfied?”
These are important questions for agile leaders to think about, especially those seeking hybrid work as the model for their organization.