Hardening Sprints: Quality Cram Sessions

Hardening sprints are the software development equivalent of an all-night study session—necessary if you’ve neglected the material but not a habit to cultivate.

What Is Sprint Hardening

Sprint hardening involves dedicating a Sprint solely to improving software stability and performance. This practice can sometimes mask deeper problems in development processes.

Is It Normal To Have a Hardening Sprint

It is not uncommon for agile teams to include a hardening sprint at the end of a fixed number of Sprints to ensure quality standards. However, its regular use might reflect a deeper problem with the process.

“Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.”

— Scrum Guide

Given that the Scrum Guide states that increments should be thoroughly verified and usable, it’s hard to see how a Sprint dedicated to ensuring that previously completed work meets this definition could possibly be in line with the expectations set by the Scrum framework.

The truth is that many organizations (especially the larger ones with siloed teams) have not equipped their teams to meet Scrum’s quality and integration standards.

The common response to this recurring problem is to enact hardening sprints. The problem is that what should be a temporary solution becomes the norm, and we stop looking for ways to fix the root cause of the issue.

This response exactly meets Wikipedia’s definition of Anti-pattern:

“…a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.”

The Sprint Hardening Anti-pattern

Sprint hardening deviates from ideal Scrum practices by designating a separate Sprint solely for fixing issues and finalizing product details right before a release. This practice disrupts the continuous integration and feedback loops central to agile approaches.

Hardening sprints are detrimental because they delay problem-solving and feedback, which can lead to accumulating technical debt and unresolved issues. This delay impacts the product quality and hinders the team’s ability to respond quickly to changes.

The evolution of the hardening sprint anti-pattern typically stems from a lack of emphasis on maintaining consistent quality and integration. Often driven by deadlines and feature delivery pressures, teams might skip thorough quality checks during regular Sprints. This oversight leads to the need for a concentrated effort before a big release to resolve these accumulated issues, hence the birth of the hardening sprint. This pattern can also arise from a misunderstanding of agile practices, where teams mistakenly see hardening sprints as a necessary phase of quality assurance rather than an indication of process inefficiencies.

Recognizing the Hardening Sprint Anti-pattern

It should be fairly obvious if your team is currently engaging in hardening or release sprints.

Several warning signs, or “smells,” can indicate that your team may be veering toward a reliance on hardening sprints. Recognizing these symptoms early is crucial to prevent slipping further into this anti-pattern.

1. Craftsmanship Apathy

This symptom involves a diminishing focus on code quality and robust development practices, often emerging as teams prioritize speedy deliverables over meticulous craftsmanship.

2. Bugalanche

A bugalanche occurs when a significant number of bugs accumulate, typically uncovered only during the hardening sprint. This overwhelming influx results from previously unaddressed or unnoticed issues that surface late, overwhelming teams and complicating the release process.

3. Unsustainable Pace

High-pressure environments often force teams into a development tempo that is not sustainable in the long run. Hardening sprints aim to rectify numerous issues in a condensed timeframe, leading to burnout and a decline in overall product quality. Such a pace is unsustainable, pushing teams beyond their limits without adequate recovery or reflection time.

4. QA-Dev Segregation

In environments with hardening sprints, it’s also common to see a clear divide between quality assurance and development teams, particularly because these sprints often involve handing off completed features to QA teams only at the end. This segregation leads to larger batches of work, delayed feedback, and a lack of cohesive collaboration, which can impede timely and effective issue resolution.

5. Divergent Expectations

This symptom arises from varying interpretations among team members about what constitutes a completed Product Backlog Item. Hardening sprints exacerbate this issue as the rush to finalize can lead to rushed decisions and unclear communication about expectations, ultimately resulting in deliverables that may not meet all stakeholders’ standards.

6. Delayed User Feedback

Typically associated with hardening sprints, this symptom involves receiving user feedback only after the product’s release. This delay in obtaining critical insights can lead to missed opportunities for improvement and user dissatisfaction, as we’ve not iteratively refined the product with direct user input throughout its development.

How Would You Avoid the Hardening Sprint Scrum Anti Pattern

To avoid hardening sprints, teams need to elevate their commitment to quality. While that might seem straightforward, it’s a substantial undertaking, and many teams may feel uncertain about how to start.

It’s similar to advising a college student on how to avoid last-minute cram sessions before exams. You’d suggest spreading their study sessions out over the weeks leading up to the exam, studying in small, manageable increments. Regular self-testing can help them gradually identify and address gaps in their understanding, ensuring a deeper and more lasting grasp of the material.

With our Scrum team, we’re focusing on integrating quality into every Sprint. This approach aims to progressively reduce our reliance on late-night cram sessions—or hardening sprints—until we can phase them out completely.

I find that there are four mindset shifts that we must cultivate to help us with this transformation:

• from excessive technical debt to prudent maintenance
• from feature quantity to feature quality
• from delayed quality to prioritized excellence
• from a ‘works on my machine’ mentality to rigorously enforcing the Definition of Done

Four Guiding Principles to Avoid Hardening Sprints

1. Prudent Maintenance

This principle revolves around the idea of “Prevention vs. Crisis.” It emphasizes proactive maintenance and improvement of the product throughout the development process rather than waiting for problems to escalate into crises. To embody this principle, teams need to shift from reactive troubleshooting to continuous, proactive enhancements. This mindset shift ensures stability and reduces the need for emergency interventions.

2. Feature Quality

Quality vs Quantity” is at the heart of this principle, advocating for a focus on the quality of features rather than the sheer number of features. Adopting this principle requires a shift from prioritizing output to valuing the impact and usability of each feature. Teams should deliver well-thought-out, thoroughly tested features that add significant value rather than rushing to include more features that might compromise the product’s integrity.

3. Prioritized Excellence

The mindset of “Now vs. Later” underpins this principle, which stresses the importance of achieving excellence in every Sprint. Adopting this principle requires a shift from putting off quality and refinement for future Sprints to integrating high standards from the start. Teams need to commit to delivering their best work in the present, ensuring that each Increment is as close to perfect as possible rather than deferring refinement to later stages.

4. Rigorous Definition of Done

Centered on “Alignment vs. Assumption,” this principle establishes clear, shared understandings of what ‘done’ means for each Product Backlog Item. The shift to this mindset moves away from individual assumptions about task completion to a shared agreement that aligns everyone’s efforts and expectations. Doing so ensures that all aspects of a task are thoroughly completed according to collective standards before being considered done, thus eliminating ambiguity and enhancing team coherence.

Applying these guiding principles might seem like a challenge, so the following four sections will provide three actionable steps for each principle, giving you a clear starting point to steer your efforts in the right direction.

Three Ways to Implement Prudent Maintenance

1. The Boy Scout Rule

The Boy Scout Rule encourages developers to always leave the codebase better than they found it. By incrementally improving frequently used code sections, teams can achieve continuous improvement, ensuring the code remains clean and manageable.

2. Strategic Debt Reduction

Strategic debt reduction involves prioritizing the resolution of technical debt based on the frequency of code use, its importance, and its impact on the business. This targeted approach helps ensure that teams concentrate efforts where they will provide the most benefit, reducing the risk of future crises.

3. Debt Prevention

Debt prevention requires strategic consideration of the trade-offs between the immediate benefits of quick fixes and the long-term drawbacks they might entail. By carefully evaluating these decisions, teams can prevent unnecessary technical debt, aligning with the proactive nature of Prudent Maintenance to avoid future complications.

Uncle Bob likens this to making sure you can afford the payments before you buy a house.

Three Ways to Improve Feature Quality

1. Built-in Quality

Built-in Quality emphasizes prioritizing quality from the outset by integrating it into every development process step rather than treating it as an add-on. This change ensures that each feature is developed with high standards from the ground up.

2. Refactor

The practice of refactoring urges developers to continuously refine and optimize the code as they progress. This ongoing effort helps maintain high code quality and prevents the accumulation of technical debt, supporting the overall principle of prioritizing feature excellence.

3. Stakeholder Feedback

Stakeholder Feedback involves engaging with stakeholders early and often, collecting their insights to ensure the development aligns with their needs and expectations. Based on this feedback, implementing changes in small, manageable increments helps refine features iteratively and enhances their quality and relevance.

Three Ways to Prioritize Excellence

1. Shift-Left Testing

Shift-Left Testing advocates for moving the testing phase as early as possible in the development process. By having quality assurance (QA) collaborate with developers even before they write the first line of code, teams can detect potential issues early, reducing the need for extensive revisions later.

2. Reserve Technical Capacity

Reserving Technical Capacity means setting aside a dedicated portion of each Sprint to enhance technical excellence. This practice ensures that continuous improvement of the codebase is not just an ideal but a scheduled part of the development cycle, supporting sustained excellence.

3. Automated Testing

Automated Testing involves investing in and implementing automated systems to handle routine testing tasks. This strategic move streamlines the quality assurance process and frees up team members to focus on more complex quality challenges.

Three Ways To Ensure Rigor in Your Definition of Done

1. Establish the DoD

First, Establishing the Definition of Done (DoD) is crucial. It sets a clear, joint standard for quality across the team, ensuring everyone knows what ‘done’ truly means. This shared understanding prevents discrepancies in quality and helps maintain consistency in deliverables.

2. Reference the DoD

Regularly Referencing the DoD during the development process keeps these standards in mind for all team members. It acts as a continuous reminder and guideline, ensuring that every Product Backlog Item adheres to the agreed-upon criteria before being considered complete.

The Definition of Done (DoD) is more than just a document; its power lies in your team’s ongoing commitment to and utilization of its guidelines. Don’t make the mistake of putting in the effort to establish a DoD only to ignore it after that. Its effectiveness is realized through persistent application.

3. Update the DoD

Updating the DoD is an essential practice. As teams evolve and projects grow, common quality issues that were not initially apparent may arise. Updating the DoD to reflect these new insights ensures that the standards remain relevant and robust, tackling quality concerns proactively.

TLDR

Just as cramming for an exam at the last minute leads to subpar results and heightened stress, relying on hardening sprints reflects similar shortcomings in software development.

By adopting the principles of Prudent Maintenance, Feature Quality, Prioritize Excellence, and a Rigorous Definition of Done, teams can integrate quality into every phase, reducing the need for frantic, last-minute fixes.

Key actions like establishing and regularly updating the Definition of Done, embracing Shift-Left Testing, and dedicating capacity for technical excellence ensure ongoing improvement. Steer clear of the “exam cram” approach by embedding quality deeply and consistently across your projects.

Works Consulted

• Wikipedia on Antipattern
• Correct Use of a Release Sprint
• Definition of Done in Agile: Ensure Consistency
• Definition of Done: Anti-Patterns
• Technical Debt Quadrant
• Technical Debt
• We must ship now and deal with consequences
• SAFe: Built-In Quality
• Hardening Sprints: good or bad?
• Hardening sprint: why we did it, and why you shouldn’t
• 28 + 2 Sprint Anti-patterns Holding Back Scrum Teams