2 keys to a successful Sprint outcome

There is no shortage of theory on how agile teams or the Scrum framework can improve, especially as it relates to achieving a successful sprint. Interestingly, most of these articles do not focus on what defines a successful sprint outcome.

Is it possible to know how to get somewhere if we don’t know where we are going?

Rather than make assumptions or create a general list of what makes a successful sprint, I focus on two ways that we at Forte Group define success along with our two key ingredients.

Ready? Let’s go!

Ingredient #1: Revisit the Story Often

Peter Drucker brought the world’s attention to the fact that what is done is very different than how it is done. As engineers, we typically focus on precision and different ways to solve a problem or meet a requirement. However, when we begin working with clients, we often instantly notice that three basic questions were never asked:

• Why are we doing that something in the first place?
• Who is the audience?
• How does it meet the value proposition?

The biggest issue we see when working with IT organizations is that the delivery team doesn’t question the “why”–they want to do it well. However, we find that the more business perspective a team has, the more accurate its assumptions/implementation decisions.

Perspective and understanding of value lead to creativity and innovation because they provide a goal–a lighthouse on the horizon. The goal serves to guide the team to a solution without prescribing how.

The first key ingredient is to revisit the story often with the Product Owner.

Great life drawing artists know this concept well. They spend a majority of their time inspecting and rediscovering their scene versus focusing on drawing the picture. Artists do this because they understand that the mind’s interpretation of an image is inherently flawed because it skews the actual image the instant the artists cease to look at it. Overinterpretation results in under-alignment with the real picture.

This same challenge occurs with a delivery team that is sprinting. The correction is to increase the frequency of revisiting the story with the Product Owner to reassert the “what.”

Ingredient #2: Minimize the Solution

W. Edwards Deming said, “Slow is smooth and smooth is fast.” Theoretically speaking, Deming is pointing out that practicing slowly (until you achieve precision) will lead to speed. In the case of sprints, the quote also nicely describes the importance of accurate estimations and accountability in delivering on a commitment; regardless of how fast the work is done.

Most clients express their need as software that is “better and delivered faster.” This is not an unreasonable expression. However, we ask if it is “quality and timeliness of delivery” that they look for instead.

The subtlety here is that while working with our stakeholders and end users, we find that assuming high quality, a valuable outcome, delivered at the right time is good enough.

This simple agreement is powerful because it allows us to meet our stakeholders’ objectives, while also implementing a solution that results in higher quality. Higher quality is possible because the goal is no longer speed, which, as we know, is the enemy of quality.

The second key ingredient is to minimize the solution by knowing your code.

Knowing the code is not easy, especially walking into an organization with a legacy platform. However, knowing the code is important nonetheless. The secret to predictably delivering in a timely way is to find the smallest solution that ALSO hits the value proposition of the story.

When asked to provide a solutions roadmap that outlines what we will deliver each sprint, we always ask for a discovery sprint. During the discovery sprint, and depending on the needs of the client, we typically perform one of three exercises to familiarize ourselves with the code:

• Defect fixing
• Test case automation
• Integrated prototyping

The discovery sprint is important to us because we can isolate problem areas and uncover ways to work with the code more efficiently. We look for different types of technical debt, such as overly complicated code, anti-patterns, tight couplings, dependency proliferation, poor code commentary, and the amount of unit test coverage. When you know the pitfalls in the code you are changing; you minimize the ultimate solution.