Escaping Scrum’s Build Trap: Integrating Learning Increments

Introduction: Scrum’s Shortfall in Discovery Work

Scrum, as an Agile framework for product development, emphasizes the creation of a usable?product increment?at the end of every sprint. In Scrum, a “usable product increment” refers to a working product that could potentially be released to users. While incredibly effective in standard development cycles, this concept may be short-sighted when applied to discovery work. It often leads teams to sprint to nowhere, caught in cycles of building without understanding the right customer and business outcomes. You may achieve high velocity but little value.

The drive to produce a working product in each sprint can give rise to “Sprint Myopia,” a tendency to focus too much on immediate, short-term deliverables. This shortsightedness can conflict with both problem and solution discovery phases, which often require iterative learning, testing, and refinement over several sprints, especially when those sprints are short. Concentrating on short-term gains can lead teams to overlook the bigger picture, resulting in challenges and misalignment with longer-term objectives. It’s important to recognize that the iterative nature of discovery may demand multiple sprints before a fully functional product can be achieved.

Challenges include:

1. Premature Solution Commitment:?The sprint-based pressure to deliver tangible outcomes can lead teams to settle on solutions too quickly, restricting deeper exploration. This can result in a high-velocity output of low-value items.
2. Difficulty Balancing Discovery and Incremental Development:?Activities like researching user needs or validating assumptions may not produce a ready-to-use product increment, causing tension as teams try to meet Scrum’s strict requirements while also fulfilling discovery objectives.
3. Overlooked Learning Processes:?The sprint’s outcome-focused nature can overshadow the need for essential learning and validation steps in discovery, jeopardizing alignment with actual user needs.

Incremental product delivery is crucial for empirically providing early value and testing solutions, yet, it shouldn’t be the only valid sprint outcome. Expanding the definition of successful outcomes to include discovery and learning outcomes can bridge this gap.

The Learning Increment: A Crucial Shift in Perspective?for Scrum

One way to alleviate the aforementioned challenges is to amend Scrum’s focus on a usable product increment and introduce the concept of a Learning Increment. A Learning Increment emphasizes learning, understanding, and alignment rather than producing a tangible product. By integrating this concept into Scrum’s framework, teams can become less locally optimized for building things and more focused on ensuring they build the right things. The feedback loops and rhythm of Scrum can help bring focus and ensure discovery does not go on forever.

This shift in perspective complements discovery activities and enables more focused exploration, especially when the environment and habitual practices do not prioritize learning. The Learning Increment becomes just as important as the Product Increment, guiding the three approaches discussed below to blend the advantages of Scrum with discovery.

Three Approaches to Blend Scrum with Discovery

1. Dual Track Scrum

In Dual Track Scrum, the process is divided into two parallel tracks: Discovery and Delivery. Unlike having separate teams, Dual Track involves a few team members from both tracks, such as the Product Owner (PO), User Experience (UX) designers, and an Engineer. They work simultaneously yet focus on different aspects. The other team members focus primarily on delivery.

• Discovery Track (Emphasis on Learning Increment):?Focused on exploration and learning, this track may involve prototyping, researching user needs, or validating assumptions. The Discovery Track has a separate backlog and ends in a Learning Increment.
• Delivery Track (Emphasis on Usable Product Increment):?Focused on building the actual product, this track ends with a focus on a product increment. While some learning may occur, it’s not the primary focus.

Pros:

• Enhanced Collaboration: Dual-track Scrum promotes better collaboration between the discovery and delivery teams, leading to a deeper understanding of customer needs and a smoother transition from concept to implementation.
• Faster Learning: With dedicated discovery and delivery tracks, teams can focus on their respective tasks, leading to quicker learning cycles. This iterative process enables teams to adjust their strategies based on real-time feedback.
• Risk Mitigation: By conducting continuous discovery and validating assumptions early in the process, dual-track Scrum reduces the risk of building products or features that might not meet user needs or business goals.
• Incremental Value: Separating the discovery and delivery tracks allows teams to deliver value incrementally. This means that even if a feature isn't fully developed, it can still be released if it provides value to users.

Cons:

• Complexity: Maintaining two separate tracks can introduce complexity, especially for larger teams. Coordinating efforts, managing dependencies, and aligning priorities between the two tracks can be challenging. This can become a high cognitive load, especially when discovery is not a shared habit or skill for all members.
• Team Allocation: Splitting team members between discovery and delivery tracks might lead to limitations in team availability. Finding the right balance to ensure both tracks progress smoothly can be difficult.
• Communication Overhead: Keeping all team members aligned and informed about progress, decisions, and changes across both tracks requires effective communication. Failure to do so could result in misunderstandings and mistakes.
• Potential for Misalignment: Without proper coordination, the priorities set in the discovery track might not align with the delivery track, leading to confusion and wasted effort.

For a deeper dive into Dual Track Scrum, you can visit?Jeff Patton’s article, which provides a more comprehensive look than my discussion here. It’s worth mentioning that some experts recommend using Kanban for the discovery track because of the work’s unpredictable nature. In my experience, sprints can also be highly effective for discovery. Both approaches have their merits.

2. Intermittent Discovery Sprints

Intermittent Discovery Sprints are dedicated sprints for discovery, breaking away from regular delivery sprints. Usually operating in a pre-determined cadence, such as every fourth Sprint is dedicated to discovery. These sprints have a separate discovery backlog, focusing on learning, prototyping, and understanding user needs. The discovery ends in a Learning Increment.? If you are familiar with Basecamp’s “Shape Up” process, it has some similarities to that, except that I encourage the whole team is involved in discovery and shaping the product in Intermittent Discovery Sprints. Note, think of the deliverables at the end as major and minor. For example, in a Discovery Sprnt, the major focus or Sprint Goal would be a Learning Increment and perhaps some decisions made. But, you could have a minor focus, which is to finish up the completion of a feature that was not completed last Sprint, which would be a Product Increment. Vice versa, for a Delivery Sprint, you can still learn about customer needs, but the major focus is delivering a small piece of working and usable product.

• Pros: Focused Effort: By designating specific sprints for discovery, teams can allocate undivided attention to exploration and learning without the pressure to deliver a product increment.
• Balanced Priorities: This approach helps prevent sprint myopia by setting aside time to focus on longer-term objectives and learning.
• Resource Allocation: With designated discovery sprints, teams can better plan and allocate the right resources and skills for discovery work.
• Risk Mitigation: Focusing solely on discovery can help identify and address potential risks early, leading to more informed decision-making in the delivery sprints.

Cons:

• Dilution of Focus: Separating discovery from delivery could still lead to uneven quality, particularly if the team isn’t adept at shifting gears between sprints.
• Cognitive Transitioning: Switching between discovery-focused and delivery-focused sprints may create cognitive load and require time for adjustment.
• Engagement: Some team members may prefer to stick to delivery tasks, potentially causing a skill and interest gap during discovery sprints.
• Upfront Learning Costs: Teams may need additional time and resources for skill development to conduct discovery effectively.
• Conflicting Priorities: Scheduling discovery and delivery tasks in separate sprints could result in disagreements about which tasks should be the immediate focus.
• Time Constraints: Designating entire sprints to discovery can pressure subsequent delivery sprints, potentially leading to rushed or incomplete work.

3. Holistic Scrum

Holistic Scrum unifies discovery and delivery tasks into a single product backlog, allowing for a more comprehensive approach. The team self-organizes to prioritize what’s most important for the upcoming sprint, selecting from a blend of discovery and delivery tasks. This self-organization extends to deciding who will carry out each task and how it will be executed, whether the focus is discovery or delivery.

Pros:

• Flexibility: With discovery and delivery in the same backlog, team members can more easily switch between tasks based on current needs.
• Continuous Alignment: Merging the discovery and delivery tracks encourages ongoing dialogue and alignment within the team, minimizing the risk of divergence between what’s being built and what’s actually needed.
• Simplified Prioritization: A unified backlog simplifies prioritization, allowing for a more streamlined decision-making process when preparing for each sprint.
• Adaptive Planning: The team can more readily adapt to new information or direction changes since discovery and delivery are part of the same sprint planning.
• Risk Mitigation: With both elements in the same backlog, it’s easier to gauge and address risks in real-time, whether related to market fit, technical feasibility, or other factors.
• Balanced Workload:?the load of discovery and delivery across all members, not just certain team members, which can overburden certain members and create bottlenecks.
• Lean/Just In Time: Discovery and delivery happen when needed.
• Flow:?It can create a smoother flow of work, mainly due to the decreased waste resulting from handoffs.

Cons:

• Dilution of Focus: Juggling both discovery and delivery tasks may compromise the quality of each, risking dilution in either learning or product increments.
• Cognitive Overload & Task Switching: The dual nature of tasks could lead to higher cognitive load, making frequently switching between discovery and delivery modes challenging.
• Unwilling Team Members: Not all team members may be interested or skilled in participating in discovery tasks, leading to potential imbalances in workload and expertise.
• Learning Investment: Teams may need to invest time and resources to acquire the skills needed for effective discovery, particularly in understanding user needs.
• Priority Conflicts: With discovery and delivery tasks vying for attention, disagreements or confusion over prioritization could arise.
• Time Management: Fitting both types of work into the limited timeframe of a sprint could result in rushed or incomplete tasks

Each method provides its blend of Scrum’s strengths with the crucial elements of discovery. By prioritizing Learning Increments and Usable Product Increments, teams can more effectively harmonize their efforts with the twin imperatives of discovery and delivery. While other strategies can also be effective, each has advantages and drawbacks. For instance, conducting an extensive initial customer discovery phase and then shifting to solution-building offers another route once the list of problems is clearly identified.

Conclusion: Evolving Scrum for Discovery

Scrum’s focus on rapid delivery has solved many challenges, but it can limit discovery work, resulting in products that do not solve real problems. Introducing a Learning Increment brings balance. Teams can choose from approaches like Dual Track Scrum, Intermittent Discovery Sprints, or Holistic Scrum to blend discovery into their Scrum practices. The aim is not just to deliver products but to solve problems effectively.

Anticipated Criticisms and My Response

Critique 1:?Scrum is intentionally incomplete, so you can add practices like discovery.?

Response 1:?Agreed. The issue isn’t Scrum’s incompleteness but its insistence on a usable product increment at the end of each Sprint, leading to the challenges mentioned.

Critique 2:?You should always be learning and discovering. Consider reading Teresa Torres’s?‘Continuous Discovery.’?

Response 2: While unceasing learning may seem appealing on paper, maintaining a constant state of discovery may not be practically feasible. The suggested approaches strive to seamlessly incorporate ongoing discovery within the framework of Scrum. The three options outlined in this article can leverage the concept of continuous discovery, particularly Dual Track Scrum and Holistic Scrum. It's worth noting that 'continuous' doesn't imply uninterrupted; rather, it signifies an ongoing process that revisits the concept. By this definition, Intermittent Discovery Sprints embody continuous discovery due to their repetitive nature.

Critique 3: A usable product increment could include valuable data or insights, making your argument moot.?

Response 3:?That’s stretching the definition. Scrum’s traditional focus is on delivering a functional product increment for potential release to users or customers every Sprint.

Critique 4:?Intermittent discovery disrupts flow, making it inefficient.

Response 4:?Balancing discovery and delivery isn’t like running a factory line. Piling both tasks together can be too mentally taxing for many teams, slowing down productivity. We must respect the team’s cognitive load to effectively get the right things done.

Critique 5: According to Scrum, you must deliver a usable product increment by the end of a sprint. If you don't, technically, you're not doing Scrum since it is immutable.

Response 5:?Okay, point taken, and this critique is not technically incorrect. But does it really matter? If all other aspects align with Scrum, I still call it Scrum. While this critique may be accurate, it doesn't offer much practical value. Technically, Scrum is Creative Commons and can be modified based on its license; it would have to be called something slightly different. So, I could call this Product Scrum or John's Scrum, but that would be silly.

Critique 6: John, if you're not delivering a usable product each sprint, you're not truly Agile. You're using waterfall methods within the framework of Sprints.

Response 6: That's all-or-nothing thinking. The Agile Manifesto itself says, "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." It doesn't mandate delivery every sprint. If I have four one-week sprints and two are focused on discovery and prototyping while the other two yield usable products, I'm still in line with Agile principles. A Scrum team should be able to focus on the 'next smallest right thing,' which isn't always a usable increment. It's about finding a balanced approach. Being fixated on delivery, each sprint can cause the problems I've mentioned in my article. A discovery sprint doesn't turn it into a waterfall, especially when considering Winston Royce's original description. Products like the iPhone (read Creative Selection to learn more), which underwent iterative design phases before creating usable increments that could be released, also prove that Agile isn't just about ticking boxes every sprint.

Learn More?

If you enjoy these posts, consider subscribing to my mailing list or taking a course with me. My signature Certified Scrum Product Owner course focuses on customer discovery, using methods like Jobs To Be Done for Outcome-Driven Product Management.

The original article is published on my website at https://agileclassrooms.com/escaping-scrums-build-trap-integrating-learning-increments