When people think of Scrum, they imagine various teams working in sprints, attending daily stand-up meetings, and regularly performing sprint planning meetings. They might even be familiar with the sprint retrospective and sprint review events. However, if you execute these meetings with your team and think you’re doing Scrum, you miss Scrum’s actual benefits.

Putting too much emphasis on the events that Scrum outlines is far too familiar. Instead, we need to focus on why we choose this process in the first place. Scrum is the idea that we learn best by trying out an idea, measuring the impact, refining the concept, or abandoning it. We repeatedly execute this cycle while gathering insights to determine what works and doesn’t.

The important part of Scrum is not the events or even the artifacts that following Scrum practices produce; it is the pillars of the empirical process itself. Transparency, inspection and adaptation. When these three concepts are genuinely understood and employed across all aspects of the team’s culture, you’ll obtain far more than just a releasable product.

Transparency

The Scrum Guide has this to say about transparency:

“The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk.”

https://scrumguides.org/scrum-guide.html#transparency

The Scrum Guide promotes all interested parties’ visibility into the Product Backlog, the Sprint Backlog, and the Product increment.

The Product Backlog is a prioritized list of all planned improvements for the product. At a minimum, this should always be available for everyone across the organization to view. In addition, depending on your targeted user base, this backlog could be visible to people outside the organization. When a product’s future roadmap is known, it helps provide more context about what to expect regarding the near-term changes. In addition, it can be a valuable reference for stakeholders to see where the features they are most interested in sit on the priority list. While individuals constantly challenge the chosen priority, setting these expectations sooner will mitigate unwanted assumptions.

The Sprint Backlog is all the work the team has chosen to perform for the current increment. Leadership, stakeholders, and other teams or departments should know how to see what work is currently in progress. These people can look for themselves about in-flight items anytime they wish instead of asking the Development Team or Product Owner. A correctly planned sprint with the status of each work item up to date is a highly effective communication tool.

The Product Increment, the outcome of each Sprint, must be available for all to see. Even if sprint reviews/demos occur with stakeholders invited, they should be able to get their own hands on the product anytime. Allow them to review it in their own time and at their chosen level of detail. If the Sales team wants to update their pitch deck or the Customer Success team needs to create additional training material, ensuring they have access to the updated product enables them to execute their responsibilities effectively.

Inspection

Without the ability of a team to regularly review their output and how they work, there is minimal opportunity to improve. The five different Scrum events help define a regular tempo to inspect the work.

“The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems.”

https://scrumguides.org/scrum-guide.html#inspection

The Sprint is the defined period that enables a team to focus on a task set. To facilitate the review of the required work, Sprint Planning allows the team to build a plan for the duration of the Sprint. In addition, Daily Scrum enables the team to examine their progress day-to-day and discuss any issues they each may have encountered when executing their chosen tasks. Therefore, when planning is detailed and the proper discussions happen at stand-ups, the entire team can inspect their progress frequently, allowing them to seek answers or alternative solutions when blockers inevitably occur.

Sprint Review is the opportunity for the stakeholders to get eyes on the team’s progress. Whether the results of the Sprint include UI/UX changes for the Product team to review, technical improvements to show off for the senior engineers or some documentation for the end-user that Customer Success can utilize, this is the chance for all interested parties to provide input. When the team is transparent about the challenges and decisions made during the Sprint, everyone can have constructive conversations about the next steps.

The Sprint Retrospective is arguably the most critical yet underrated event in the Scrum framework. This event permits examining how the group worked. A well-performing team should allow themselves to reflect on how well they worked together honestly. Discuss any of the many possible topics such as; communication, collaboration, process improvements, and knowledge sharing. Naturally, an individual’s emotions under certain circumstances are also fair game. For example, if a teammate feels frustrated or unsupported, these situations are critical to discuss. There is always room for improvement, but we must be honest before identifying what to change.

Adaptation

The idea that ‘businesses need to adapt to change’ is not new. We’ve been hearing it for decades. Scrum’s third pillar not only prescribes constant change but seeks it out early and often.

“If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.”

https://scrumguides.org/scrum-guide.html#adaptation

Changing course will occur in most projects, whether a minor correction or a significant deviation. The first opportunity to steer back on track is the Daily Scrum event. When teams communicate issues or blockers regularly, the opportunity to correct course occurs about as early as possible. Perhaps a team member is spinning their wheels on finding a solution to their assigned task. A job with some unknown risks might have produced some unforeseen obstacle. Even in some cases, a new set of requirements or an essential change in priority demands the team to switch gears entirely. Regardless of the case, the team needs to identify the issues and pivot quickly. A daily review of the ongoing work is the first opportunity to adapt to change.

The Sprint Review is the event that enabled the team and all interested stakeholders to look at the team’s output and decide where to go from that point. Occasionally a concept that sounded good on paper doesn’t turn out to be feasible once implemented. So this is the opportunity for everyone to discuss what options are available and decide to continue to move ahead with the feature or abandon it. Perhaps produced documentation wasn’t found to be helpful by the intended audience. What if a component dramatically changed how an end-user interacted with the product? Although it might not result in any shift for the development team, the Customer Success team has an opportunity to change their material in how they reach out to users. Sometimes a change in one area, like a product feature, requires a change in another team or department. This event allows transparency and inspection to enable adaptation across the organization.

The event with the most significant opportunity to impact the team and the organization is the Sprint Retrospective. The required work for the product is what it is. Sometimes the direction is well defined, and sometimes it is more exploratory. Regardless, there is always room to improve how the team works together. Therefore, a compelling retrospective will only include discussions of the work where task execution is the immediate context.

Were there communication problems? Which is likely very common for newer groups still in the forming or norming stages. Were they internal or external to the team? If it is internal, maybe it is the method you are using or a personal conflict. If it is external, perhaps someone should be appointed as a point of contact for the team. Try to focus on the root of the problem and brainstorm a way to improve it.

Did the current process fail? Of course, no strategy is perfect, but it should account for most of your team’s common paths. If you are continually coming across the same problems – change them. Even if the process works fine, teams shouldn’t be afraid to try new ideas.

Were there persistent interruptions? When a feature-filled release has recently occurred, responding to production issues isn’t out of the ordinary. But action should be taken when the team has to regularly handle tasks that were not part of the original plan. Perhaps change needs to happen by setting expectations with external influencers. Then, the group can provide a more predictable and reliable manner for others to ask for work to be undertaken.

There are many other opportunities to change how the team operates. If a team can identify the most persistent or impactful challenge it is facing; then they should attempt a solution in the next Sprint. Prioritize at least one process improvement throughout the next iteration.

When you can focus less on the tangible aspect of Scrum and more on the theory and values it prescribes, the answer to what is most important becomes clear. You don’t need to follow every single ‘rule’ in the Scrum Guide to succeed; you only need to establish a culture of transparency, inspection and adaptation.