Delivering often in small increments with Scrum
Agile software development, particularly using Scrum, has revolutionized the way software is built and delivered.
At its core, Agile embraces iterative and incremental development, a stark contrast to traditional “waterfall” methodologies.
The primary objective is to deliver working software frequently and in small increments, ensuring continuous feedback, adaptability, and rapid value delivery.
However, we know from experience that this is not always the case, and if you have worked long enough in the software development industry, you know that usually, it is not the case.
I wrote before about this and the articles were well read (on LinkedIn), but I still see the need to summarize those articles:
Key principles and practices
In order to frequently deliver small-increment you need to implement several key principles and practices:
Decomposition and User Stories
Break down large features or requirements into smaller, manageable user stories.
A well-formed user story describes a desired functionality from the perspective of an end-user, following the format: “As a [type of user], I want [some goal] so that [some reason].”
These stories are then estimated and prioritized.
Time-boxed Sprints
Scrum operates in short, fixed-length iterations called “sprints,” typically 2-4 weeks long.
Each sprint has a specific goal and a defined set of user stories to be completed.
The time-box ensures a consistent rhythm of delivery and prevents scope creep within an iteration.
Definition of Done (DoD)
A clear and shared “Definition of Done” is crucial.
This defines the criteria that a user story must meet to be considered complete, including coding, testing, documentation, and integration.
This ensures quality and prevents partially finished work from accumulating.
Cross-functional Teams
Scrum teams are self-organizing and cross-functional, meaning they possess all the skills necessary to take a user story from conception to delivery.
This reduces dependencies and streamlines the development process.
Frequent Feedback Loops
Scrum incorporates several built-in feedback loops:
- Daily Scrums: Short daily meetings where the team synchronizes, discusses progress, and identifies impediments.
- Sprint Demo: At the end of each sprint, the team demonstrates the “potentially shippable increment” to stakeholders, gathering feedback for future sprints.
- Sprint Retrospectives: The team reflects on the past sprint to identify what went well, what could be improved, and creates actionable plans for the next sprint.
Prioritization and Backlog Refinement
The Product Owner is responsible for maintaining and prioritizing the Product Backlog, a living list of all desired features.
Regular “backlog refinement” sessions ensure that upcoming user stories are well-understood, estimated, and ready for development.
Now, if you think that by doing this solves all your problems, well, you are not entirely wrong, but also not entirely right. 
As with any methodology, there are challenges.
Challenges and Solutions
Large, Undifferentiated Requirements
Stakeholders often present high-level, monolithic requirements that are difficult to break down into small, shippable increments. This can lead to long development cycles and delayed feedback.
Solutions
- Invest in User Story Mapping: Collaboratively map out the user’s journey and identify smaller, deliverable “slices” of functionality.
- Employ techniques like “Splitting User Stories”: Learn patterns and techniques to effectively break down large stories into smaller, valuable pieces (e.g., by workflow steps, by data type, by role).
- Product Owner Focus: The Product Owner plays a critical role in collaborating with stakeholders to refine and decompose requirements, ensuring they are “INVEST” (Independent, Negotiable, Valuable, Estimable, Small, Testable)
Technical Debt and Integration Issues
Rapid delivery can sometimes lead to accumulating technical debt (shortcuts taken for speed) and integration headaches if not managed carefully.
This can slow down future development and make small increments harder to achieve.
Solutions
- Prioritize Technical Excellence: Bake in time for refactoring, code quality, and automated testing within each sprint. The Definition of Done should include these aspects.
- Continuous Integration and Continuous Delivery (CI/CD): Implement robust CI/CD pipelines to automate builds, tests, and deployments, ensuring that the software is always in a releasable state.
- Pair Programming and Code Reviews: collaborative development and peer review usually catch issues early and maintain code quality, but they also slow down delivery. Use with care.
Lack of Clear Prioritization
Without a clear and stable Product Backlog and a Product Owner empowered to make decisions, teams can struggle with shifting priorities, leading to wasted effort and delayed delivery.
Solutions
- Empower the Product Owner: Ensure the Product Owner has the authority and understanding to prioritize the Product Backlog effectively, balancing business value, risk, and dependencies.
- Regular Backlog Refinement: Conduct frequent and collaborative backlog refinement sessions to ensure upcoming stories are well-understood and ready for development.
- Transparency: Make the Product Backlog visible and accessible to everyone, fostering understanding and aligning expectations.
External Dependencies and Silos
In larger organizations, external dependencies (e.g., other teams, external vendors, compliance departments) or internal silos can hinder a team’s ability to deliver independently and frequently.
Solutions
- Active Stakeholder Management: The Product Owner and Scrum Master should proactively identify and manage external dependencies, facilitating communication and coordination.
- Cross-team Collaboration: Encourage regular communication and collaboration between teams, potentially through “Scrum of Scrums” or other scaling frameworks if applicable.
- Shift to a “Value Stream” Mindset: Focus on optimizing the flow of value across the entire organization, identifying and removing bottlenecks that span multiple teams or departments.
The post Delivering often in small increments with Scrum first appeared on Sorin Mustaca’s blog.
