The scrum framework is often celebrated because it enforces a kind of closed loop: a team is able to rotate methodically between process, iteration, and reflection with few outside interruptions. It’s everyone’s dream.
Process is a ceremony that mitigates unpredictability and disorganization.
Iteration means that devs can release features incrementally to meet a business need faster, and park or break up complex features into multiple deliverables.
Reflection, in the form of reviews and retrospectives, ensures that the team is committed to the value of the project, and keeps the process honest.
However, there is an important consideration that is often overlooked when employing scrum: whether the team feels engaged with the process.
Fortunately, there are quite a few signs that an experienced scrum team might be feeling disconnected: maybe velocity has been stifled by late-sprint changes, maybe the sprint retro seems like an opportunity to cross-work for them, maybe the standups feel like Groundhog Day. Any level of disengagement or frustration can have negative long-term effects on the team and the product. If you or the scrum team are experiencing social friction, or if it is starting to feel like the team isn’t working well together, then it may be time to refine some of your best practices.
Here are some suggestions for enhancing team engagement:
Scrum frameworks are partly successful because they give the team a predictable structure, thus more time to focus on delivery. For two-week sprints starting on a Wednesday or Thursday, try optimizing sprint planning and backlog refinement to take place on the same day/time, alternating weeks. This sets a precedent for balancing development work with ceremonial engagements and reduces the negative impact of context shifting.
It’s seldom the case that the development team will completely understand a feature/user story during your refinement sessions. Instead of putting pressure in a moment to commit to understanding the feature, prep the feature in advance and create timeboxes in your sprint to allow the development team to review, formulate a hypothesis or question, and be ready to speak to their proposed approach and time commitment (or story point estimate) during a backlog refinement.
Because there is a bit of uncertainty during a development sprint—maybe a feature takes longer than anticipated or an API is not quite what the developer thought it would be—it may be tempting to simply extend the sprint by a day or two. This kind of disruption to the timeline is not recommended. There is a knock-on effect to extensions: future sprint dates would either need to be shortened or extended, ceremonies rescheduled, and release dates bumped. These disruptions may earn customer favor, but they send a message that you’re putting development second and are willing to undermine the process. By rolling tickets to the next (or a future) sprint, you're defending the timeline, honoring the workflow, and ensuring that the team has the necessary stability to target their velocity and remain committed to their objectives.
Making measured improvements to your process is not only encouraged, but expected.
Retrospectives are a key part of the feedback loop. If you’re finding that there are long pauses or lack of engagement during your retrospective, it may be that an alternative approach could help enliven the conversation. Try breaking the retro into parts—requirements through review—and ask targeted questions that put the team back into the specifics of the story. If your team is not into it, then it might be time to host a project-wide retrospective or start measuring agile maturity. This will allow you to look at adjustments to the program overall.
On many scrum teams, the role of product owner is underutilized; often folks serving in this role feel that they should share the responsibility with another team member, don’t have time to commit to the responsibilities required of them, or are concerned with working in a silo. Product owners are a key part of the scrum framework. If a responsibility doesn't have a singular owner—someone overseeing user stories and priorities and signing off during reviews—then the team becomes imbalanced. Slow velocity, rework, frustration, and even technical debt may become an issue because a key owner is missing from the relationship. Protecting the product owner role and defending its necessity on the team ensures that there is close engagement between the scrum team and the business.
Standups are often used as an opportunity to “report-out” progress towards a specific ticket. If it feels like your dev team is waiting for you to call on them and reciting their update as if it were scripted, then it may not be the best use of everyone’s time. Instead, remind the team that the standup is for their benefit: Who needs to know that a ticket is coming their way in the workflow? Who are you planning to reach out to after the meeting to troubleshoot an issue? Who needs to know that you’re too swamped to review a pending PR? If your scrum lead needs basic information (like ticket numbers) to make the conversation valuable to them, then ask that of the process. Otherwise, let the dev team decide what’s important to cover.
Setting a sprint objective (or goal) requires leadership from the dev team and buy-in from the product owner, and it is as much of a task as it is a measurement of engagement. At a fundamental level, the sprint objective is an opportunity for the dev team and the business to align on the intended outcome of implementation. If new feature tickets do not tie into the objective, then consider revisiting the priorities to optimize delivery. Gaining consensus with the sprint objective allows the entire team visibility of the product goals: you’ll find that that devs begin making connections with previously refined or delivered tickets, and even make enhancement suggestions for the backlog that are value focused.
Engagement is important to the success of any team, and, ideally, it should be recognized beyond showing up, producing quality work when assigned, and revisiting “what went well,” etc. week-after-week. You’re doing the right thing to encourage changes among the team. Keep in mind that another core characteristic of a scrum is agility: making measured improvements to your process is not only encouraged, but expected. Ensuring that engagement runs deep within a team should improve team fulfillment and product quality.