Product Owner Must Be’s
We often talk about what the Product Owner Must "Do" - they must own the Product Backlog, they must manage the product backlog and the priorities, they must refine the backlog, they must answer the team's questions.
We very rarely talk about what the Product Owner must "Be".
During this session I will highlight what I have learned from my experience as a Product Owner and a Product Owner coach, what I believe are the main Must "Be's" for a Product Owner.
Outline/structure of the Session
Following is outline of my talk:
- Opening and Introduction
- Review what a Product Owner is
- Overview of a Product Owner's characteristics or "Being"
- Overview of the 3 hybrid elements
- Compensating for the missing elements: a few examples
An Innovative Product Owner is a:
- Vision Keeper
- Story Teller
- Single Source of Truth
The best Product Owners have several key characteristics in common that help them become great Innovative Product Owners.
- Part of the team
What’s more, certain characteristics combinations yield hybrid characteristics, much like an eloquent speaker endowed with charisma can make a powerful politician.
- Engagement + Availability = Trust
- Decisiveness + Empowerment = Leadership
- Knowledge + Foresight = Vision
- Understanding a Product owner
- Characteristics that are in a great Product Owner’s DNA
- Impact of entangling these characteristics
- Stories and examples on how to counteract the lack of these elements.
Product Owners, ScrumMasters, Transformation Teams, Scrum Teams
schedule Submitted 1 year ago
People who liked this proposal, also liked:
Build Measure Learn - Designing your MVP
We all know that a Minimum Viable Product is a lean startup technique designed to test and validate if a solution actually solves a customer problem. It is an endeavor to go forth and learn to then, iterate or pivot as you better understand the problem and solution. To be successful, it is not only about learning what the people want but also being able understand the most painful aspects of that problem to then define what is the minimum amount of work you can do to generate early value to them. But how do we figure that out? In this 45-minute workshop, you will learn what is an MVP; why it matters; what makes a good MVP experiment; and how to get started on designing your own. By the end of this 45-minute workshop, you will have:
- Created a problem statement, or hypothesis for an MVP
- Turned your hypothesis into a list of possible experiments
- Collaborated with agilists who will help you formulate your MVP concept and experimentation ideas
Shit Agile Coaches Say
"Language does not just describe reality. Language creates the reality it describes." - Desmond Tutu
The agile community has evolved into a group of highly enthusiastic proponents who bring a high level of excitement to everything they say and do. Agilists speak a strange sort of insider jargon in which plain English words have very unusual, and often counterintuitive meanings.
They may describe your multi-billion-dollar enterprise as "dysfunctional" and on the verge of "failure." They may suggest your teams "sprint" to get work done, and yet do so at a "sustainable pace." They may tell your management that agile helps teams "go faster" while assuring your teams that agile isn't about "going faster." They may insist that agile is more about culture and mindset than about practices, and then measure your progress in terms of how faithfully you follow a prescribed set of practices.
There are many more examples of this odd insider jargon, starting with the seminal buzzword itself, "agile." Over the years, the way agilists speak has confused and turned off many who might otherwise have benefited from applying agile values and principles. The presenter will share several stories of the unintended effects of agile-speak, and will invite you to share your own tales of woe and amusement.
The value of diversity in an agile environment
There is much talk about diversity in the software development field and in the tech industry in general, and yet most teams and organizations comprise mostly a single cultural group. The dominant group may be 20- and 30-something white males, as is common in Silicon Valley, or some other culturally homogenous group, such as H1B holders from the same country, as is common in large corporations.
When nearly everyone in an organization has the same general worldview, problem-solving approach, educational background, life experience, and so forth, the organization tends to suffer from groupthink - they can only conceive of a single approach to achieving a goal or solving a problem. When faced with a unique challenge or an unexpected change in circumstances, such an organization often has great difficulty.
In contrast, a diverse organization can bring to bear a variety of perspectives, experiences, collaboration styles, and problem-solving approaches. The rich blend of differences enables the organization to adapt to change and to overcome unexpected challenges creatively and flexibly. How can we build a more diverse workforce in the software development field?
Automated Testing and TDD for Mainframe Applications
Mainframe systems continue to play an important role in large IT operations. Contemporary software solutions often comprise components that run on multiple platforms, from smart phones and tablets to Windows, OSX, and *nix systems, and mainframes.
Is it feasible to extend modern software engineering practices like continuous integration; automated deployment; automated unit, component, and functional testing; and test-driven development to this venerable platform? It turns out to be quite feasible. There are several practical approaches to the problem, including commercial products from IBM and third parties; off-platform test drivers such as Cucumber, Concordion, and FitNesse; service virtualization products; on-platform approaches such as Java on zOS Unix System Services; hand-rolled mocking of CICS, DB2, and MQSeries resources; using IBM utilities to isolate and test individual steps from batch jobstreams; and isolated off-platform solutions based on hand-rolled test frameworks running under S390 emulation or mainframe-compatible compilers.
This session provides a summary of several of these approaches. Unfortunately, it isn't feasible to run working examples on an actual mainframe in the context of the conference. We can show code that works and walk through it to illustrate approaches to test automation that are in use in real mainframe environments, and we can demonstrate the emulation-based solutions that don't require a connection to a real mainframe.
To wrap up, we can have a group discussion about the specific testing and automation issues you have in your organization and how you might introduce test automation on your mainframe systems. Better yet, you can share your own stories of how you have solved this problem.