New products require rapid learning by the whole team
The “New” Product — A Story
If you coach every team to treat each product the same, you are missing an opportunity. Each team’s product context is unique, and as such, they each need coaching within that context.
To show the importance of product context, I will continue the tale of the Cloud data team from the prior post.
This team is now starting to build a new product. Real events form the thread of this story, but I have fictionalized it to protect the innocent. Post story, I present a coaching strategy for a team with a new product, such as the one described.
Part 1: Jira is All We Need
“The last six weeks have been a thrill ride,” said David, the Scrum Master of the new Eagles team.
The Eagles team formed from a subset of the Cloud data team and merged with new members to fill in capability gaps. This team is now a cross-functional feature team. They have also met all the other pre-conditions for Agile team success.
“The team is so excited to get started on the new product. When can you coach the Product Owner to put our stories in Jira on time so we are not sitting idle?”
Here we go again with the feature factory mentality. My “spidey” sense immediately turns on. Teams seem eager to gravitate to the Product Owner being some type of all knowing figure. This person sits in a white room and develops perfect ideas to solve customer needs. Once the Product Owner chisels these ideas into stone tablets, he or she throws them over a wall to a team. Then, like robots, the team produces feature-after-feature for the Product Owner.
“Have you scheduled a backlog refinement session with the Product Owner and the rest of the team?” I ask.
“I scheduled a session between the Product Owner and me, but I didn’t know the rest of the team should be there,” said David.
“They need to be there to gain understanding and provide their ideas to solve customer needs.”
“What do you mean by customer needs? Oh, wait! Paul, the project sponsor, gave us the list of features to build last week. I guess those are the requirements for the customer.”
I tried to steady myself. There is some work we need to do on gaining customer empathy.
Part 2: The Product Owner’s Delimma
The next morning I head first thing to my meeting with Tracy, the Product Owner. After my conversation with David yesterday, I reached out to Tracy to get her perspective. I was hopeful Tracy would calm my concerns. Maybe I was a bit too hopeful.
“Good morning, Tracy.”
“Hi, Todd. Can we make this quick? I need to get these stories entered into Jira. This tool is so frustrating.”
There it is again, rearing its head—Jira. That first value in the Agile Manifesto gets left behind too quick these days. You would think it read, Processes and Tools over Individuals and Interactions.
“What are you entering into Jira?”
“Well, I got these requirements from Paul. He said we have to build them this quarter. We have a big customer conference at the beginning of next quarter, and he wants to show off what the product can do.”
”Who came up with these requirements?” I consider how the use of the word “requirements” implies certainty and finality.
“Paul did. He told me that he spent all weekend brainstorming the features. He said he and the rest of the board would like to see them in the product to make it stand out in the market.”
I start to wonder if anyone has spoken with the customer at this point. “Tracy, have you met with your customers yet?”
“Ha, you are funny! When is there any time for that? We have to move fast to build these features or we will never be ready for the conference.”
“Will you be at the backlog refinement session that David scheduled?” I ask.
“I doubt it. Between Jira and the requests coming from Paul, I have my hands full.”
I smile and tell Tracy I will let her get back to work. The focus on building every generated idea with no customer input is all too common these days. It might be a different story if they knew their customer, and the product was more established. That is not the case here. They are only starting to explore what the product could be. There is vast uncertainty. They don’t know their customer.
Part 3: Team Boundaries
The next morning after the Eagles standup, I asked the team if I could have a quick word. I was not surprised that Tracy was not at the standup. It was easy to guess what she might be busy with.
I asked the team if they understood the reasons why they were working on their Stories this sprint.
“Because these were the top priority Stories in Jira when we did Sprint Planning,” Gwen said. You could sense she was proud of her answer.
“Do you guys talk to Tracy about the Stories before Sprint Planning?”
“There is no reason to do that,” Ty said. “She adds all the details about what we need to do to the Story in Jira. See.” Ty pointed to a Story on his monitor.
I watched with dread as Ty scrolled and scrolled through the description of what needed to be built. The detail was overwhelming. Plus, there was no mention of which user would need this feature and no mention of why a user would care.
“Who is this Story for?” I ask.
“No brainer. It is for Tracy. Tracy is the one voice. She is the user representative. It’s just like we heard in the Scrum training,” another team member said.
My “spidey” sense was in overdrive at this point. This is a classic case of Scrum misinterpreted. All the pressure was on the Product Owner to make decisions. The team was not engaged in product decisions. No end user was in sight. Every idea was being built as fast the team could build the features the product owner put into Jira.
I will need to intervene before these behaviors became habits.
Product Stages
As Kent Beck discusses in his new work on 3X1, there are three stages for a product. These stages are Explore, Expand, and Extract as shown in Figure A.
Explore
When your team forms a product idea, it enters the Explore stage.
You and your team have a concept, but uncertainty is high. The value is uncertain. Exactly what you should build is unclear. Your team does not have high confidence the end user will find the idea useful.
Your goal in this stage is rapid learning. You will best achieve this through small, low-fidelity experiments and rapid customer feedback loops. Enterprise scalable, working software is not the goal in this stage. You can tolerate higher technical debt here; it will vanish when you discard low yield idea experiments.
In the Explore stage, close customer engagement and fast learning are key. This will guide you to the “right” product to build.
Expand
As your idea gains momentum with your customer, the demand drives the product into the Expand stage. In this stage, your team must reduce variances and constraints to meet the demand.
For example, as your users increase, performance of the system might become a constraint. Your focus will shift to solving this.
It may be that manual testing ceases to provide fast feedback. The manual overhead lengthens the timeline for assessing how new features impact system integrity. You need automation testing to remove the constraint.
Perhaps dependencies on other teams are slowing you down. You must break these dependencies to meet the demand.
In Expand, the success of the product is dependent on removal of your constraints. Large scale adoption depends on it.
Extract
When your product enters the Extract stage, you have met the demand growth of the Expand stage. The product has wide adoption.
The growth of the product is slow and steady. You and your team have a solid understanding of the product and the customer needs. Your handle on the technology is solid. You and your team have stability and increased confidence.
Uncertainty has reduced. As a result, you don’t have to test every idea with your customer before you build working software. You don’t have to perform Spikes to figure out how the technology works. Your team has an improved ability to estimate the value and effort of ideas.
Economies of scale become important. For example, you may need to improve maintainability. You may need to refactor to remove duplication in the code and create common components.
Extract focuses on steady growth and support of the existing user base. It is a less volatile time for you and your team.
Story Analysis and Coaching Strategy
In the story above, the Eagles team is in the Explore stage. Yet, they are acting like they are in a much more certain situation.
During the Explore stage, we want many minds to contribute. You need a whole team approach. Your goal is to generate varied ideas and test those ideas in a rapid, low-cost manner. This will help the team gain empathy for the user and understand user needs. The “right” product will emerge.
This is not the behavior pattern of the Eagles team. They experience the following obstacles to Explore stage desired behavior:
- Product ideation does not involve the team
- Stakeholders send feature ideas as fixed requirements to the Product Owner
- The Product Owner focuses on the conference date rather than customer outcomes
- Ideas immediately flow into development of working software without customer research
- The team does not understand the customer or if the customer needs the features
- The Product Owner does not understand the customer, but the team sees Tracy as the “voice of the customer”
- The Scrum Master does not enable whole team engagement in achieving product value
- The Product Owner takes stakeholder requirements without question
- The team does not feel collective ownership for the product
- The Product Owner focuses more on Jira than interacting with the team
- Jira is being treated as a requirements specification
- The Product Owner does not operate as a member of the team
- The value of the feature is not clear to the team
- The Product Owner describes stories to the team through heavy documentation
- The team focuses only on output of feature-after-feature
- The Product Owner is unavailable to the team during development
The Eagles team requires coaching to intervene before these habits harden.
Coaching Strategy
The Eagles coaching strategy should focus on creating collective product ownership. This will engage the team in all aspects of the product as depicted in Figure B.
Team Community
There is no reason for the Product Owner to have to engage with the product community alone.
Relationships with stakeholders, users, and other subject matter experts are critical. These relationships should expand beyond the realm of the Product Owner. This should be an activity for the entire team.
Team awareness of purpose increases by forming direct product community connections. Whole team involvement when engaging with the product community is essential. It removes silos and ensures rapid alignment.
Three Perspectives
Better ideas form from more than one perspective. Valuable, feasible, and usable are three lenses that enhance ideas.
Idea generation is a whole team activity rather than for a select few. The team includes User Experience experts, Development Team members, and the Product Owner. Each capability should exist on the team. Every team member plays a part generating idea options.
As a result, diverse perspectives increase the chances of meeting desired customer outcomes and business impact.
Parallel Power
Discovery, delivery, and user testing are not performed in serialized phases. They are not performed by different groups.
Rather, the entire team performs all three activities in parallel. This includes User Experience experts, Development Team members, and the Product Owner. The team engages with end users in each activity.
Focusing on all three activities amplifies learning. It also shifts the team’s focus from outputs to customer outcomes and business impact.
Coaching Game Plan
The Toyota Improvement Kata2 is an effective, targeted improvement technique. Teams can use it to meet a challenge, such as building a collective product ownership mindset.
In the case of the Eagles, this technique would focus first on collective product ownership concept education. The learning focus will be on defining the concepts and why they are important.
Then, the coach will co-create a improvement approach with the team and management. The approach will aim to achieve the challenge of collective product ownership. The team will meet the challenge through a scientific method of incremental improvement. Figure C shows this method applied to the Eagles team.
Improvement Kata Formation and Coaching
First, the coach asks the team if they want to set the challenge. If the team does not agree, the coach stops the process. A team must desire to take on a challenge; imposing it does no good. Yet, if they agree to set the challenge, the process continues.
Second, the coach asks the team to self-reflect where they currently stand. It is key to engage the team in reflecting on their current condition. This will allow the team to self-assess their primary needs. Resist the urge as a coach to provide your own observations.
Third, the coach and team set the first target state towards the challenge. For example, the first step in collective product ownership is for the team to gain understanding of its user.
Fourth, the coach collaborates with the team to outline the first experiment. The team provides their own ideas. The coach suggests options from his or her experience. It is important for the team to select the experiment they will try first. In our example, the team decides to meet with the customer to attempt to understand needs.
With a team starting on its journey, the coach needs to have a high touch approach. This allows the coach to correct the team during experiment execution. By correcting in the moment, the coach helps the team avoid the seep-in of old habits. The coach is able to provide expert guidance on the correct implementation of the new habit. This results in faster formation of the correct new behavior habits.
The co-creation of an improvement strategy produces buy-in. The experimental approach introduces small changes, which allows learning patterns time and space to form. This approach helps the team achieve tough challenges and to practice using the scientific method.
Wrap up
The context of a team’s product stage is key to the coaching strategy you select. It is tempting to treat every team the same and start applying standardized patterns. Yet, the more prudent approach customizes coaching to the team’s product context.
Collective product ownership is great for the initial Explore product stage. It continues to add value for the entire product life cycle. How will you and your team embrace collective product ownership today?
The next post in the series finds the Eagles in the midst of their Technology learning journey. Stay tuned.
Other Posts in the Series
- Customizing Agile Coaching to a Team’s Context—An Introduction
- Customizing Agile Coaching to a Team’s Social Context – New Teams
- Customizing Agile Coaching to a Team’s Technology Context – New Technology
Related Posts
- Agile Leader Pattern 4 for Building Awesome Teams: Enable Face-to-Face Interaction
- Agile Leader Pattern 6 for Building Awesome Teams: Serve the Team
- Limit What You Start to Go Faster: Priorities and Simplicity
- Remove Date Driven Behavior to Achieve Agility—Commit to Value, Not Dates
- Remove Date Driven Behavior to Achieve Agility—Focus on “Done”
- Gain Control By Breaking Dependencies: Between Organizational Entities
References
- Product Development Triathlon blog post by Kent Beck July 2016
- The Toyota Kata by Mike Rother (2010)
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.