Product Discovery and Delivery are higher collectively.
I’ve skilled an fascinating pattern within the Agile and Scrum area this 12 months. At first, it looks as if a step to get us nearer to our buyer’s wants. But as I peel again the onion, I’ve seen the way it can lead us down a treacherous path.
The pattern entails Product Discovery. Several firms have approached me with a request, reminiscent of:
“We want a Product Discovery coach to assist construct succesful Discovery Teams and enhance the consumption of backlog objects with Delivery Teams.”
At first, the notion of Product Discovery teaching sounds intriguing. Design Thinking, buyer analysis, and light-weight prototyping are partaking actions. Plus, exploring what clients want by partaking with them shouldn’t be commonplace in at present’s Scrum groups.
But my pleasure dissipates after I take up the remainder of the request: “…and enhance the consumption of backlog objects with Delivery Teams.”
This makes me notice the request for what it’s. The ask is to teach conventional conduct disguised with fancy, new terminology. Splitting Product Discovery and Delivery throughout two groups is a type of a purposeful silo.
In my expertise, splitting these important product improvement actions throughout groups is problematic.
The need to separate Discovery and Delivery stems from an unlucky misinterpretation. In error, we assume Scrum is just involved with creating working software program. So we type a separate Discovery Team to take a customer-focused view.
Often, it is a consequence of The Scrum Guide’s lack of steering on “how” to ship a precious product.
“Scrum: A framework inside which individuals can tackle advanced adaptive issues, whereas productively and creatively delivering merchandise of the very best potential worth.”
—The Scrum Guide
My teaching lately focuses on integrating Discovery and Delivery utilizing Scrum. I’ll get to this in a second. But first, let’s discover what can go incorrect in the event you determine to separate Discovery and Delivery.
Splitting Discovery and Delivery ends in two groups. One staff focuses on Discovery and one focuses on Delivery. Each staff is probably going utilizing the Scrum framework for its personal slim focus.
Often, a wall exists between the 2 groups. This is normally fortified via a digital Product Backlog.
Discovery consists of defining product technique, gaining buyer empathy, and designing the shopper expertise. Design considering, lean consumer expertise design, and excessive consumer engagement are the hallmarks of the Discovery Team’s strategy.
Delivery focuses on expertise design and improvement to type a working product. The Delivery Team’s understanding originates from documentation within the Product Backlog.
Unfortunately, Delivery Teams have minimal contact with the top buyer. And they’re typically disconnected from their Product’s function.
Each staff is, as a rule, adept at Scrum for its localized focus. But I’m positive your thoughts is already deducing the systemic pitfalls of this strategy. The issues fall into three classes.
Pitfall №1–Diminished Shared Understanding
Shared understanding is the lifeblood of a high-functioning product staff. To ship a product, you want each side of the coin—Discovery and Delivery. Splitting these actions between two groups segregates important information and experience. And it results in suboptimal and, typically, incorrect choices.
The following behaviors have a destructive impression on shared understanding:
- Over-reliance on documentation to speak between groups
- Each staff goals for a partial Definition of Done
- Disconnection of the Delivery Team from the shopper
- Formulation of options by the Discovery Team with out feasibility enter
- Turf-building and lack of a one-team mentality
Pitfall №2–Slow Feedback & Limited Learning
At its worst, Discovery occurs in a giant, upfront chunk earlier than handoff to the Delivery Team. At its greatest, the Discovery Team works just a few Sprints forward of the Delivery Team. Regardless, the suggestions loop diminishes between the Discovery and Delivery groups.
In the top, the timeline for gathering buyer suggestions on working options elongates. This delays studying from buyer findings and insights. So it takes longer to emerge the “Right” product whenever you separate Discovery and Delivery. This ends in an extended time to market and an elevated price of delay.
Pitfall №3–Increased Lead Time
Lead time is the time required to get from idea to money — from thought to consumer adoption and enterprise impression. Separation of Discovery and Delivery into two groups creates waste. In truth, you expertise every of the seven lean software program improvement wastes :
- Handoffs: The transition from Discovery to Delivery ends in misunderstandings and rework.
- Defects: Incorrect interpretation of buyer wants ensuing from batch handoff and communication hurdles.
- Extra Features: The Discovery Team designs with out Delivery Team validation. The Delivery Team creates an structure runway with pointless parts whereas ready on Discovery.
- Extra Processing: Keeping the 2 groups in sync requires additional coordination.
- Partially Done Work: Batches of incomplete work pile up from Discovery actions ready on Delivery.
- Delays & Waiting:. The Delivery Team waits on the Discovery Team’s output. The Discovery Team waits on the Delivery Team to catch up. And the shopper waits as a result of elevated waste within the course of. And if something wants to vary, the delays hold including up.
- Task Switching: Because Discovery and Delivery Teams don’t work on the identical factor on the identical time, they interrupt one another with considerations and questions.
The three perils of separating Discovery and Delivery now have your consideration. So let’s discuss concerning the answer. You will discover it to be easy.
Instead of a Discovery Team and a Delivery Team, we want one staff—a Product Team.
“Cross-functional groups have all competencies wanted to perform the work with out relying on others not a part of the staff.”
—The Scrum Guide
The Agile mindset focuses on the continual supply of worth to clients. To emerge worth, the Product Team should know its clients and its enterprise and the wants of every. And the staff will need to have fast and early iteration to reach on the “Right” product.
“Our highest precedence is to fulfill the shopper via early and steady supply of precious software program.”
—The First Principle of The Agile Manifesto
How does this work?
The mannequin is easy. You have one small, cross-functional Product Team, which focuses on Discovery and Delivery. The staff’s purpose is to emerge the best product for its clients and its enterprise.
During Discovery, the staff types an understanding of the aim of its product and the “why” behind it. The staff builds an understanding of the targets of its clients, its enterprise, and its personal staff members. And then, the staff defines the goal outcomes and impression of its product.
The Product Backlog ceases to function a communication layer between the groups. Instead, it turns into a repository of choices to strive for reaching the goal outcomes. And the staff evolves the choices from direct buyer engagement suggestions.
After the staff devises choices to satisfy the goal end result, Delivery commences. Here, the staff assesses which choice to strive subsequent and the training goals.
The staff will select to construct a light-weight experiment if the choice uncertainty is excessive. This may take the type of a questionnaire or a light-weight prototype. But if the staff is extra sure concerning the choice, it’ll ship releasable working software program.
In both case, the staff will collect direct buyer suggestions on what it builds. This permits them to realize important insights.
The insights from Delivery feed again into Discovery. The cycle continues till the “Right” product to launch emerges.
The perils of the separate staff strategy evaporate when you have got one Product Team centered on Discovery and Delivery. And there are notable enhancements with the Product staff strategy. These fall into three major areas.
Improvement №1–Seamless Shared Understanding & Purpose
Full staff participation in Discovery and Delivery ends in excessive shared understanding. Collaboration is wealthy, with high-bandwidth communication strategies. The staff members not depend on backlogs and documentation to speak.
An fascinating side-effect emerges when the staff focuses on all product improvement features. Empathy builds within the staff for its buyer and its enterprise. Its function turns into actual.
And the staff’s function supplies a guiding power for all the pieces it does. Team engagement will increase.
Improvement №2–An Enhanced Focus on Value
The Product Team has no exterior dependencies. It has full accountability for understanding its buyer and enterprise wants. This removes the seven wastes of the separate staff strategy.
Having management inside the staff builds staff autonomy. And this autonomy focuses the staff on delivering worth versus coping with the waste of the siloed strategy.
All staff members innovate to plan choices for assembly their goal outcomes. When this occurs, the “Right” product emerges quicker. Different views present the mandatory battle to provide higher concepts.
Improvement №3–Rapid Learning
Learning velocity will increase when Discovery and Delivery are inside one staff. This fast studying occurs throughout two dimensions.
First, the “Right” product emerges quicker via light-weight, cheap experimentation and iteration. The staff navigates utilizing proof gathered from a fast suggestions cycle. As a consequence, the staff validates concepts and choices earlier than investing in them totally.
Second, the staff discovers the “Right” technique to construct the product and so they be taught from one another. Team members proficient in Discovery and buyer expertise be taught Delivery expertise. Those with Delivery experience collect expertise in Discovery.
The greater studying velocity interprets into higher outcomes, higher impression, and higher groups.
We began this publish on the pattern to separate product Discovery and Delivery into two groups. And we reviewed why that is problematic. While well-intentioned, it will get in the best way of the efficient pursuit of the “Right” product.
But there’s a higher different. One Product Team centered on each Discovery and Delivery results in nice outcomes. You will expertise:
- Higher staff engagement
- Improved supply of merchandise your clients want
- Better achievement of your online business impacts
So lately, when requested for Product Discovery teaching, I encourage Product Team teaching as an alternative. It is a greater, holistic strategy. Try it for your self and expertise the ability and ease of the Product Team.
Also revealed in Serious Scrum on Medium.
Related Posts
Read extra on the associated posts under:
References
- Implementing Lean Software Development — From Concept to Cash, Mary and Tom Poppendieck — Sept 7, 2006 ↩
About the Author
Todd Lankford helps organizations simplify their Agile journey by constructing cultures that emerge higher merchandise. Todd Lankford is an skilled Enterprise Agile Transformation Coach and Product Strategy Facilitator. His teaching is concentrated on making Agile easy once more. You can join with him on LinkedIn.
On Medium, Todd is the Editor and Writer of Serious Scrum and Simply Agile, Writer for The Startup, Writer for Illumination, and a Top Writer in Leadership and Productivity
Subscribe to his YouTube Channel.
Sign up to get Agile ideas delivered to your mailbox.