The Scrum Pillars at Sophilabs: Inspection

Our teams are committed to practicing Scrum, organizing their work in two-week sprints. However, we're well aware that it's not enough to simply impose the structure that Scrum provides and expect improved agility, stronger ownership, more efficient development, and increased customer satisfaction. In order for Scrum to truly be effective, we must actively strengthen the pillars of this framework–transparency, inspection, and adaptation–and live the Scrum values of commitment, courage, focus, openness, and respect.

In our previous post, we discussed how we strive to maintain transparency. In this second installment of our Scrum Pillars series, we'll look at how we practice inspection in every sprint.

What does inspection look like in Scrum?

According to the Scrum Guide, "Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work." ¹ While this prescription for inspection is straightforward, it also speaks in general terms, leaving room to think critically about how inspection actually works in the day-to-day.

As a lightweight framework and not a fully-fledged methodology, Scrum allows for flexibility in lower-level practices within the provided structure. If a team has specific ways they like to discuss things, estimate work, review items, or get feedback, there's room for that as long as the team is reaping the benefits of Scrum. Our teams adhere to Scrum while also plugging in a few specific practices that help us attain the value that the Scrum framework offers. This is certainly the case in the way we do inspection. Below we'll take a look at inspection at sophilabs, from the instances of inspection that are already baked in to Scrum to our specific practices that align with the purpose of this Agile framework.

Inspecting Artifacts

First off, we'll get into how we inspect Scrum artifacts and the underlying value of inspecting artifacts regularly.

The Product Backlog

The Scrum Guide describes the Product Backlog as a "living artifact" that can and should change based on customer feedback and an evolving business landscape. The Guide recommends ongoing refinement to add "detail, estimates, and order" to the stories near the top of the backlog. However, Scrum doesn't provide a specific process for backlog refinement. It simply advises that the Scrum team should decide "how and when refinement is done." ²

At sophilabs, we hold product backlog grooming sessions to refine stories for the next one or two sprints; any stories beyond that are too susceptible to change to be worth investing time in refinement. Unlike Scrum ceremonies, there is no fixed schedule for grooming sessions; they can happen as often as necessary. However, the Scrum Guide recommends not exceeding 10% of the team's capacity on backlog refinement, as spending too much time on grooming can cause this form of inspection to "get in the way of the work." ³

During backlog grooming sessions at sophilabs, the Product Owner gets together with stakeholders to reprioritize stories and gather more detailed requirements. Sometimes the development team also participates in the session and does some estimation. Grooming sessions are an opportunity to capture feedback, make sure requirements are clear, and do some housekeeping. They allow us to have quicker and more effective sprint planning sessions because we are able to knock out a significant amount of work in advance. Regularly inspecting the product backlog in this way enhances the efficiency of the development process.

The Scrum Board

An important visual tool for transparency, the Scrum board undergoes inspection during every daily scrum. Actively inspecting and updating the Scrum board ensures that this artifact maintains its usefulness as a measure of progress during the sprint. Inspections also uphold the effectiveness of the Scrum board as a way to encourage accountability and ownership among individual team members. An up-to-date Scrum board promotes the Scrum values, keeping the team committed to and focused on the sprint goals.

Inspecting Progress

Inspection goes beyond examining and updating the aforementioned artifacts, however. Below we'll get into how we consistently inspect progress.

Daily Scrum

The daily scrum is possibly the most important instance of inspection that happens in Scrum. Inspection is at the heart of this ceremony's purpose. During each daily scrum, the team must measure their progress and determine where they are in relation to the goals they set out to accomplish by the end of the sprint. This often involves thinking critically to identify key blockers and brainstorm solutions together. While it isn't always practical to discuss solutions in their entirety during this brief meeting, it does keep everyone aligned regarding the issues the team needs to address.

The inspections that occur during daily scrums ensure that the team tackles problems together and as soon as possible, contributing to the quality of the software increment and the efficiency of the development process. At sophilabs, we value the power of people-centric practices like daily scrums and the way they enable teams to self-organize and do their best work.

Sprint Retrospective

The sprint retrospective gives teams a regular opportunity to inspect itself and the way team members work together. The progress that's measured in the retro is not necessarily related to the sprint goals, which should have already been reviewed by this time in the sprint. The main focus of inspection here is the team's efficiency and its ability to communicate and collaborate effectively. By deeply examining these aspects of the team's performance, the team can identify problems or inefficiencies in their processes that they can remedy through adaptation (we'll explore this third pillar of Scrum in our next installment). Honest reflection and inspection during retrospectives gives the team the knowledge it needs in order to continuously improve.

There are many effective techniques for getting the most out of a sprint retrospective, and Scrum teams have the freedom to conduct their retros using whatever lower-level practices work best for them. At sophilabs, we typically structure our retros into five stages: staging the retro, gathering data, fostering insights, making decisions & mapping future actions, and closing the retro. Our retrospectives can last anywhere from less than an hour to a full ninety minutes, depending on how much we need to discuss. The specific techniques we use to guide our retrospectives heavily depend on the team's maturity and particular dynamics.

Our favorite techniques for staging retros include the tried-and-true check-in questions: What was your biggest accomplishment during this sprint? What would you change about this sprint if you could? This simple opening is a very effective way of getting individual team members to start thinking critically about how things went during the last sprint. Satisfaction gauges are another reliable staging strategy to measure how the team feels about how they are working together and the results of the last iteration. Likewise, a "weather report" activity in which team members determine where they are on a scale of stormy, rainy, cloudy, or sunny provides a quick visual means of assessing where everyone stands regarding the sprint.

To gather data on the sprint, we often utilize a straightforward chart to collect input on what was good, what could have been better, and ideas. We sometimes employ other versions of this technique, such as Mad/Sad/Glad, in which team members share specific instances during the sprint that made them feel mad, sad or glad. Similarly, applying the 4Ls technique requires team members to identify what they loved, learned, lacked (or loathed) and longed for. Another strategy, Lean Coffee, uses voting and time limits to help teams prioritize what to talk about.

When it comes to the fostering insights stage, we focus on helping pain points come to the surface and determining what caused these problems. We find 5 Whys, a root cause analysis technique first developed in Japan at Toyota Motor Corporation, an especially effective way to identify the sources of issues we're experiencing. 5 Whys involves asking why an issue occurred, and then taking the answer to that question and asking why that happened. The team continues this pattern of questioning five times, which usually unveils what set the negative chain of events going. Another great technique for generating insights, Perfection Game, asks team members to describe a perfect sprint. We then pin down the key differences between the perfect sprint and how the sprint actually played out.

The fourth stage of our sprint retrospectives, making decisions & mapping future actions, starts to delve into adaptation territory, so we'll cover this more in depth in our final installment of this series. For now, we'll simply state that the main goals in this phase are to reach a consensus through voting, make sure we have a clear plan, and ensure that every team member has realistic action items to work on during the next sprint. During the closing stage, we focus on recognizing teammates' contributions and encouraging each other to tackle future challenges. ⁴

An Integral Part of Scrum

Practicing inspection helps make sure that Scrum works the way it's supposed to, allowing both the client and the development team to get the maximum value out of this framework. While inspection is already built into regular events like the daily scrum, teams also have the freedom to add smaller practices and techniques as they see fit, provided that they're still receiving all the benefits of Scrum.

At sophilabs, we consider inspection fundamental to our development process and strive to uphold this pillar of Scrum. When inspection is done right, it results in productive teams and high-quality software. In our next and final installment of this series of blog posts, we'll take a look at how adaptation works. You can also check out our Playbook if you want to learn more about how we work.