When you hear that your software service provider follows a Scrum process, you may be concerned about all the meetings that go along with that. Scrum, which is the Agile framework we apply to software development, advises five different meeting types per Sprint.
You may have doubts that your project costs will be kept down. Meetings can hinder productivity, prevent you from getting your ‘real’ work done, and create distractions and delays.
Believe me, I hear you. As a Project Manager for a range of medium and large web development projects, I spend much of my day in Scrum meetings of one kind or another. Along the way, though, I’ve come to appreciate that when done right, these meetings actually save time and money.
Meetings get a bad rap
Part of the problem is that meetings get a bad rap. Stakeholders can quickly come to devalue Scrum meetings. Especially if they don’t participate or prioritize them. We hear the following kinds of excuses:
- “I just don’t have time.”
- “It doesn’t really feel like I’m needed.”
- “Overseeing this project isn’t my main job, so it’s not a priority for me.”
- “You’re the experts, you make the decisions.”
- “I’m not sure what’s expected of me.”
The fact is, Scrum meetings provide a chance for client stakeholders to engage with their project. In a client-vendor relationship, we can’t force stakeholders to come to the meetings, but when they stop coming, they lose a valuable way to be a part of the process and have a say in the outcome. Potentially, they run the risk of missing important deadlines. This can happen if they don’t weigh in on requirements and decisions that are finalized as the project progresses.
The following are a few real-life examples of what can go wrong when stakeholders don’t attend Scrum meetings:
- The client doesn’t provide approvals or input in time, which causes a deadline to be missed
- The client doesn’t feel like part of the team, doesn’t feel comfortable asking questions or participating, and their overall experience with the project suffers as a result
- The wrong work is queued up for development because the client’s priorities or requirements have changed and haven’t been communicated to the Project Manager
What makes Scrum meetings so important?
Client engagement in meetings can help to avoid all of those issues. Let’s look at why each meeting is essential to keeping a project on track and how Scrum meetings can save time and money in the long run.
1. Sprint Planning (Once per Sprint)
Sprint Planning is conducted at the start of a Sprint, and establishes the plan for the Sprint as well as kicks off work. Before this meeting, the Product Owner (usually the Project Manager) will ensure stories are lined up and groomed. It often immediately follows the prior Sprint’s Retrospective (more on Sprint Retro below).
Why it’s important: We ask client stakeholders to attend this meeting to ensure they are comfortable with the plan for the Sprint. The Sprint should reflect the client’s current priorities. They can chime in with any recently changed priorities and influence which stories are included in the Sprint. They can ask questions about the planned development approach for any story and ensure they understand the team’s commitment for the Sprint. By the end of this meeting, all stakeholders should know just what to expect for deliverables out of the Sprint.
2. Stand-up (Daily)
This is when all team members report in on their progress since the prior day’s Stand-up. In a typical Scrum setting, participants of Stand-up meetings literally stand up for the entire meeting. This helps keep the updates (and therefore the meeting) short and sweet.
Stand-up occurs daily to:
- Ensure that stories do not stay with a single team member for longer than necessary
- Enable prompt response and resolution to any blockages reported
- Keep transparency across the project high – any team member is aware day by day what the other members are working on and any unique challenges being faced
Why it’s important: We ask client stakeholders to attend this meeting because it gives them a sense of how the Sprint is progressing. In this setting they also hear about obstacles encountered, if any, and whether there are any the client can help remove. They also stay current with their trajectory in the Sprint, and identify any issues that need attention. This is the best chance to monitor the team’s progress.
3. Backlog Grooming (Once per week)
This meeting’s purpose is to review stories in the backlog (outside the current Sprint). Stories have to be groomed before they can be included in a Sprint. This meeting provides the chance for team members to ask questions and discuss potential implementation approaches. The goal is to establish clarity on issues or dependencies of each story, and the level of effort to complete each one.
Why it’s important: It’s critical that stakeholders attend this meeting to contribute to discussions about what the team is trying to achieve with each story. Frequently, questions come up about the client’s preferences in how the team could go about delivering an outcome. Additionally, the team may identify an alternative feature or a potential improvement that the client should consider.
4. Sprint Review (Once per Sprint)
In any project, it’s extremely valuable to demonstrate progress frequently. The Sprint Review (also called Sprint Demo) provides a forum to keep stakeholders up to date, and gives the development team fast and frequent feedback. We need a chance to ask, “Does this look and act as you expected it to? and, does this meet your needs?” The client then has an opportunity to ask questions about the feature or raise issues if the work done does not meet their expectations.
Why it’s important: I don’t need to espouse the importance of the client getting to observe and ask questions about the outcome of the team’s work. But further, this is an important meeting in Scrum because iterative development builds on code developed in prior Sprints. Frequent and formalized check-ins ensure the team doesn’t go too far down the wrong path before correction. If key stakeholders miss Reviews, it can mean time-consuming and costly rework and missed deadlines.
5. Sprint Retrospective (Once per Sprint)
Following each Sprint, the entire team takes an opportunity to evaluate the Sprint. Specifically the team is asked to answer two questions:
- “What went well?”
- “What could have gone better?”
Focusing on what went well is crucial for team morale, as it draws attention to the strengths of the team and any improvements they’ve made in recent weeks. The things that didn’t go well should have some action associated with them so there will be movement towards resolving or mitigating them.
Why it’s important: It’s common for developers and testers to be heads-down working through their assignments during the Sprint with blocks removed speedily, which is just what you want as a client stakeholder. However, with each Sprint it is invaluable to pause and consider what might have caused any issues and whether proactive measures could prevent them from recurring. The only thing better than resolving an issue quickly, is to not encounter it again in the future.
One note about client participation in Retrospectives – teams should decide whether the client relationship makes that particular client suitable to participate in their Retros; some teams may feel the sensitive nature of what may be discussed warrants more caution and privacy before exposing the client to that information while others feel comfortable with the client stakeholders hearing and participating in this discussion directly.
As you can imagine, client participation is particularly crucial for these last two meetings. But we all know that sometimes missing a meeting is unavoidable. Mike Cohn, founder of Mountain Goat Software and a leading Scrum trainer, says that “in most cases, everything should roll forward as planned” if someone can’t attend, since momentum has its own value. Still, even he would consider cancelling a Sprint Review if a key client stakeholder can’t participate. There’s just too much at stake.
Conclusion
Admittedly, the meeting burden is not trivial on a Scrum project – up to 15 potential meetings across a two-week Sprint. However, ScrumMasters assist in maintaining meeting focus and discipline, and nothing runs a minute longer than it needs to. They also take care of all scheduling, preparation, and facilitation.
As I’ve found, Scrum meetings help to address issues before they become issues. When stakeholders attend and prioritize these meetings, we can minimize lingering obstacles, out-of-date priorities, and unpleasant surprises.
In return, we reach the desired outcomes:
- The client has the chance to provide input and approvals in time for the team to meet their deadlines
- The client becomes a real part of the team, can comfortably ask questions and actively participate, and has an overall pleasant experience working with their Scrum team
- The appropriate work is assigned for development in accordance with the client’s priorities
Ideally the client and the team should work together like a well-oiled machine. The communication during meetings is what provides the lubrication to keep that machine running smoothly. The lack of communication can bring it – and the project – to a grinding halt.
Contact GovWebworks to find out more about using Scrum to keep your next software project running smoothly.
Author bio
During the past decade as a project manager, Sarah Crossman has worked with software requirements design, vendor evaluation and implementation, and web development. At GovWebworks, she brings a smile and efficient attitude to every meeting.
