Examining the Product Owner Role
As with everything else related to agile, the nature of the Product Owner role, and whether it is needed or all, depends a great deal on context. As teams discover this, it leads to some common questions:
- What do Product Owners Really Do?
- Do we even need Product Owners?
Join Kent to examine the Product Owner role and attempt to answer the above questions. He’ll share his experiences and give you a chance to share your perspectives with each other. By the end of the session, you'll have more insight into the Product Owner role and how it applies (or not) to your situation. After all, the only consistent answer to the above questions is “it depends”.
Outline/structure of the Session
Note: I referenced my Slide Share account below. I'll post slides for this talk that I am giving at Lean Agile KC after November 9.
A Brief History: Brief Overview of the Product Owner role - point out where it originated & some common misconceptions
What Do Product Owners Do: Ask attendees to get into small groups and create a list of what they think Product Owners do. Hang on to lists for later reference. I then cover three main things that I think Product Owners are responsible for: Outcome over Output, Building a Shared Understanding & Making Decisions.
Where Do Product Owners Fit: Show three common models for Product Owners in organizations and share a brief case study for each model. Following discussion of the three models, ask attendees to revisit their lists to see if anything changed and to identify what model they are currently working in. Discussion at this point.
Do We Need Product Owners: Wrap up discussion on the question "Do We Need Product Owners? Wrap up with the point that the activity of Product Ownership is more important that the role Product Owner.
- Identify common organizational models for product owners
- Determine appropriate product ownership responsibilities and practices
- Share product ownership experiences with other attendees
Product Owners, business analysts, people who work frequently with product owners or want to be a product owner
schedule Submitted 6 months ago
People who liked this proposal, also liked:
Dynamic Reteaming: The Art and Wisdom of Changing TeamsHeidi Helfand
schedule 7 months agoSold Out!
Who says you need "stable" teams in order to build a successful software company? While the addition or removal of one person from a team means you have a "new team", there is a myth out there about "stable" teams. When your team compositions change it doesn't mean you're doing it wrong - it could be the secret to your success. Different companies have thrived through reteaming - the act of moving people around teams in different ways. In this talk I'll go over the what, why and how of reteaming and will share stories from different companies who are living this reality.
'Tis Better to Be Effective Than EfficientKent McDonald
schedule 6 months agoSold Out!
Better. Faster. Cheaper. Many IT organizations are constantly seeking the "best" practices that will deliver those characteristics, and the fact that they continue to search indicates they haven’t found them yet.
It could be they are looking in the wrong place. Most efforts around achieving better, faster, cheaper center around becoming ultra efficient.
Effectiveness may just be the better target.
Join Kent McDonald to explore the difference between efficiency and effectiveness and learn three simple, yet powerful, techniques that he has found can help teams be more effective. You’ll learn how to:
- Build a shared understanding of the problem you are trying to solve
- Establish clear guard rails for distributed decision making
- Measure progress based on outcome, not output
Along the way he’ll share stories about how he has used these techniques and help you figure out when these techniques may work in your situation.
You may be able to get faster and cheaper with efficiency, but in order to get better outcomes, you need to be effective. Come to this session to learn how.
Making Sense of Sense-Making
The world as we know it is growing more complex. As we automate away those things that can be easily repeated, we leave ourselves with ever more challenging work. The way we’ve worked in the past won’t necessarily work for today’s problems… or will it? Join Diane and Doc as they explore dimensions of complexity in software development and look at how teams and leaders might adjust their behaviors (and the software they create) based on the complexity of the problem at hand.
This hands-on, interactive workshop will provide a practical introduction to Cynefin (a sense-making framework for complexity) and show how it applies to the work we do every day as creators of software. You’ll map your own work to Cynefin and learn about applicable management styles and optimal team interactions for each of the Cynefin contexts.
How Agile Helped a BA Discover Her Real ValueDiane Zajac-Woodie
schedule 6 months agoSold Out!
As companies introduce agile practices, the Business Analyst role is often left by the wayside. The title does not even exist in Scrum or other specific agile implementations, leaving many Business Analysts wondering where they fit in. But fear not! The skills of a good BA are even more valuable in an agile environment!
Join Diane Zajac-Woodie as she tells the tale of a new agile team, struggling with no formal training, a resistant corporate culture and unwilling team members. She shares how this team benefited from the communication, collaboration & facilitation skills of an experienced BA. She then highlights specific shifts that Business Analysts can make in order to help their own team’s transition. These include using story maps and writing executable requirements, just in time.
Embracing their new roles, BAs can also encourage team members to cross role boundaries. This leads to new skill acquisition and a more cohesive team, which ultimately leads to higher quality software.
Explore Your Customers' Needs with Empathy MappingDiane Zajac-Woodie
schedule 6 months agoSold Out!
“Success is not delivering a feature; success is learning how to solve a customer’s problem.” ~ Scott Cook, founder of Intuit*
If this is true, then the next question is: what is your customer’s problem? Unfortunately there’s no magic trick to figure out what customers need. But there is a simple technique that can help you gain insights and build empathy for them.
Empathy mapping is a simple activity that you can facilitate with stakeholders (or anyone responsible for delivering products and services) to build empathy for your end users. It allows you to explore what your customers see, hear, say & do, as well as consider what they think and feel. This leads to insights about their pain and potential wants.
Because this is done collaboratively, using silent brainstorming, everyone on the team contributes to a shared understanding of the customer. So not only do you build empathy, but you also create alignment within the team and among stakeholders. And that can only help you be more successful.
*as quoted in The Lean Startup, page 66