Dr Seuss Product Owner
•Download as PPTX, PDF•
1 like•945 views
The document discusses the role of the product owner using analogies from Dr. Seuss books. It describes different "types" of product owners based on characters from books like "Red Fish Blue Fish" and "Green Eggs and Ham". It also provides tips for product owners on visioning, backlog refinement, collaboration with the team, and developing minimum viable products. The overall message is that product owners play a key role in guiding development through an understanding of the market and close collaboration with their scrum team.
More Related Content
Viewers also liked
Viewers also liked (19)
Similar to Dr Seuss Product Owner
Similar to Dr Seuss Product Owner (20)
More from Joshua A. Jack
Dr Seuss Product Owner
- 1. Dr. Seuss, Product Owner “Unless someone like you cares a whole awful lot, nothing is going to get better. It’s not.” - Dr. Seuss
- 2. Why Pick on the Poor Ole Product Owners? Value Champion Single Ringable Neck Customer or close to the customer Drives the market Subject Matter Expert 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 2
- 3. Just a couple more things. . . Not just for the product owner to “get it right” Teamwork is essential! ScrumMaster coaches to do better Resource managers to help “retrospect” 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 3
- 4. Seussian Product Owners Explained! “From there to here, and here to there, funny things are everywhere.” - Dr. Seuss 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 4
- 5. “Red Fish, Blue Fish” Product Owner One fish Two fish Red fish Blue fish. Black fish Blue fish Old fish New fish. This one has a little star. This one has a little car. Say!What a lot Of fish there are. 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 5 Characteristics: ExtremelyVisionary Knows the market In Demand
- 6. “O.T.T.Y.C. T” Product Owner Think left and think right And think low and think high. Oh, the thinks you can think up if only you try! 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 6 Characteristics: Hands On Thorough Successful
- 7. Characteristics: CriticalThinker Protective Risk Mitigator “Green Eggs and Ham” Product Owner Team: Would you like them in a house? Would you like them with a mouse? ProductOwner: I do not like them in a house. I do not like them with a mouse. I do not like them here or there. I do not like them anywhere. I do not like green eggs and ham. I do not like them, Sam-I-Am. 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 7
- 8. “If I Ran The Circus” Product Owner “Now a fellow like me,” said young Morris McGurk “Could get rid of this junk with a half hour’s work. I could yank up those weeds. And chop down the dead tree. And haul off those old cars. There are just two or three. And then the whole place would be ready, you see. . .” 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 8 Characteristics: Self-Driven Doer Zealous
- 9. Characteristics: Listener Niche Maker Entrepreneurial “Horton Hears a Who” Product Owner “Believe me,” said Horton. “I tell you sincerely, my ears are quite keen and I heard him quite clearly. I know there’s a person down there.And, what’s more, quite likely there’s two. Even three. Even four. Quite likely… 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 9
- 10. Ideas for Improvement “The more that you read, the more things you will know. The more that you learn, the more places you'll go.” Dr. Seuss 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 10
- 11. Four Stages of Competen ce Unconscious Incompetence Conscious Incompetence Conscious Competence Unconscious Competence 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 11 Four Stages of Competence Unconscious Incompetence Conscious Incompetence Conscious Competence Unconscious Competence
- 12. Vision Boarding and Business Value Modeling NoVision = Flaming Ball of Death Increasing levels of granularity “Order” the vision and roadmap as well “Maximizing the work not done” is truly an art form “Net realizable value (NRV)” 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 12
- 13. What Does it Look Like? Valuable Vision Reactive Vision Team Understands Direction Optimized Work Value Driven Vision, Release, Sprint 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 13 Vision Boarding and Business Value Modeling
- 14. Fully Engaged Backlog Refinemen t Backlog Refinement is a behavior, not a meeting Discover the best solution to do the least amount of work It’s time to purge 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 14
- 15. What Does it Look Like? Better Backlog Backlog Refinement Meeting Allocation of time, not meeting Improved Team Work Faster, Stronger, Better Solutions 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 15 Fully Engaged Backlog Refinement
- 16. Negotiatio n We are all on the same side of the table Implies two-way communication and two-way ideas Scrum exposes deeper issues 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 16
- 17. What Does it Look Like? Better Backlog Priority is Order Team Negotiation Order- Driven Success Feature- driven value releases 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 17 Negotiation
- 18. Minimum Viable Products It is not only possible, it is must A piece of a larger puzzle Increases trust between customer and team 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 18
- 19. What Does it Look Like? Release Like a Boss Stable Releases MVP’s Macro and Micro Evolutionary Feedback and “Feed- forward” 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 19 M.V.P.
- 20. In Person Teamwork and Collaboratio n Should be a regular fixture in the team room A Product Manager is not the same thing as a product owner Product Owner Retrospective Really getting tired of seeing “do away with the product owner” Guard Dog 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 20
- 21. What Does it Look Like? Collaborate P.O. is available P.O. is active Morph from Chicken to Pig Team 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 21 Collaboration
- 22. Final Thoughts from Theodor Seuss Geisel March 2, 1904 – September 24, 1991 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 22
- 23. Thank You! 6/24/2015 Dr. Seuss, Product Owner - Presented to Atlanta Scrum Users Group 23
Editor's Notes
- How many of you in the audience are product owners? All of you are here today because you care a whole awful lot about getting better.
- Why pick on the poor ‘ole product owners? Well, first I am not picking on them Because they are extremely important to the delivery of a working product! Just as the team and the scrum master play invaluable roles in delivery, the Product Owner is: Value Champion not only champions the value to the team, but also continues to champion this value throughout each release to the stakeholders Single Ringable Neck they own the good as well as the “not so good” they own the user stories (new features) and the technical debt and bugs. Customer or close to the customer in a perfect society, the product owner would be the customer, but if not, they are in the least a customer advocate Drives the market the features that a product owner gets delivered become the competition to someone else they drive the market and the technology Subject Matter Expert they take the chances because they know the risks
- This is more than just a rebuke of “P.O.’s – get it right” This is about creating a team and working as a team toward results. While most of what I am going to talk about focuses on the Product Owner, it must be backed up by the team ScrumMasters! Coach your Product Owners! Resource Managers – if you are still doing yearly performance evaluations and not retrospectives, you are doing your staff a disservice!
- On top of the symptoms, cleverly identified by Dr. Seuss, these Product Owners have amazing qualities that need to be latched onto by the team in order to be successful We are not saying all Product Owners should be the same!
- The Red Fish, Blue Fish Product Owner. This product owner can be credited with either providing conflicting acceptance criteria, unclear acceptance criteria, OR so much information that the user story is inestimable They are really good with the “as a, I want, because” for the reason that they are very good at seeing everything around them! That being said, the meat of the story is difficult to get to in conversation because they are always in demand across the organization because of the visionary leading to the aforementioned a/c issues
- And we also have the Oh the Thinks You Can Think or “O.T.T.Y.C.T.” Product Owner. Where the Red Fish, Blue Fish Product Owner’s Achilles heel is acceptance criteria, the O.T.T.Y.C.T. (Oh the Thinks You Can Think) Product suffers from the dreaded “I’ll never have the teams attention again, so we must ask for everything and the kitchen sink” syndrome. This Product Owner could have the backlog populated with everything from Gufs to Schlopps; Might even be expecting all of it to be released in a single release or sprint! They are always in the team room, even being vocal in the Daily Stand Up. Might be a successful former Project Manager/Program Manager Always looking for “status updates.”
- Green Eggs and Ham Product Owner My favorite Product Owner has to be the Green Eggs and Ham Product Owner. Not just because this book was my first Dr. Seuss, but because they know what they are trying to gain in value; they just have a hard time explaining it even after seeing what they do not want. Every time a feature is released, they say, “no, no, I meant xyz” or, “this is nice, but I really wanted to do this” Suffer from the dreaded, “it’s not perfect” syndrome This means that they generally build too much into a product and defeat the “art of work not done” because of trying to mitigate risk
- If I Ran the Circus Product Owner I have to say that I haven’t run across this one very much. . . But I have been this one. As product owners go, they can be extremely invaluable because of their subject matter expertise in the system/technology as well as the usage However, it can also be their detriment. Because they “know” the technology, they also think they know what it will take for everyone else to do what they are asking for. They tend to love to “estimate” with the team and use words like, “that is just. . .” or, “that’s a piece of cake to develop.”
- Horton Hears a Who! Product Owner This product owner has the admirable characteristic of listening to all customers. In that, they have created some of the most unique features and enhancements known to man. Unfortunately, they are based on edge cases. I actually know a wonderful user turned product owner that is like this. She is extremely thorough but is focused on the entirety of the possibilities in the product, not the stuff that will absolutely be used all the time. Like the Green Eggs and Ham Product Owner, they tend to overbuild the product. This creates complexity that is difficult to continually innovate Always looking for the next “penny stock”
- Empirical meets social experiment meets psychology meets behavior
- Initially described as “Four Stages for Learning Any New Skill” The theory was developed at the Gordon Training International by its employee Noel Burch in the 1970s. It has since been frequently attributed to Abraham Maslow, although the model does not appear in his major works. Most see this as a 4-step process. I would suggest this is cyclical with the restart of the cycle being from new or change in variables (drivers, information, better practices, environment, knowledge, etc.)
- Without a vision, teams/projects/initiatives die in a flaming ball of death Does your product or organization have a vision? How do you know what to aim for if you never aim? Orienteering example: Use the compass to find a visible point far enough away so that you can maintain course, but not so far as that you lose sight. Increasing levels of granularity, starting with the business vision Business Value Modeling by Pascal Van Cauwenberghe Decide the business values or benefits (vision/goals) that we want to achieve Find the benefits that provide tangible value Then support these benefits with portfolio items/epics/user stories “Order” the vision and roadmap as well If we stick with the idea of increasing level of granularity along with ordering, why would we not order the vision and roadmap goals/benefits as well? Allows us to get as close to the release as possible before digging into to solutioning, allowing agility “Maximizing the work not done” is truly an art form Vision boarding, business value modeling, and the like allow us to take a pragmatic view of our backlogs This means that we can see what will bring the most “bang for the buck” to the customer Value is great, but what is your product’s “Net realizable value (NRV)” I have also found that when most say value they often omit the cost How can we state that something has intrinsic value if we do not figure in how much it will cost us to create the feature? Net realizable value is basically what the value is minus what it will cost to create
- Baseline is that there is a reactive vision This means that the product owner and team respond and react well to change This means that the team is also reactive It also means that not much is being planned to meet enterprise/executive vision Teams understand where we are going. This is a powerful tool It shows that the Product Owner is able to both cast and maintain the vision Keeps team energy up because it indicates that everyone is behind the product owner Optimized and ordered work based on value Product owner has created an optimized product vision, roadmap, and backlog (along with the team) according to an actual value Products that add to the bottom line incrementally and consistently while also allowing for change
- While Backlog Refinement isn’t considered an event or ceremony in agile, continuously refining and improving the list of backlog items, but more importantly the content of the backlog items, is one of the most important actions we can take. As a full team, ask yourselves: Is our backlog refinement always the Product Owner reading the story and the team yelling out an estimate or is it a two way conversation in which more and more detail around what is expected and what can be done is identified to meet business need? Are we sometimes prototyping or doing team research to find the best solution to a story? Has backlog refinement become just another meeting or is a cultural way of working that finds high value solutions? A refined backlog item should be clear and create the correct conversation, driving the solution toward the most valuable implementation. A refined backlog does not include “everything and the kitchen sink” Refinement might be prototyping (writing code that could be used in a final product), research, etc.
- That all being said, a backlog refinement meeting is better than nothing (and should also be weighted heavily as needed This changes to allocating time to solution out the backlog which turns to improved team work to focus on definition of ready. While this sounds counterintuitive, making sure that our ducks are in a row to begin work (even if it means prototyping) should be considered. This leads to faster, stronger, better product backlog and product!
- One of the challenges of transitioning organizations (especially staunchly hierarchical ones) to Agile is teaching teams and leadership that negotiation is not just accepted, but required! The team - along with the Product Owner - are in this together; trying to achieve the same goal, and that they have a say in delivered work! This is where leadership and the scrum master encourage negotiation as a positive technique to improve the user stories, the backlog, and even the viability of the product.
- Priority is the order is the basic “agile” negotiation. The Product Owner is the one setting the priority and that is what works. Then the team starts to look for ways to speed up and they realize that actually #1, 4, 5, 8 sort of fit together and wouldn’t take as long to do. They negotiate, somewhat begrudgingly, with the PO. This leads to the realization that the team has valuable information (not invaluable) that could drive success. Finally, the concept of just delivering stories and goals morphs into micro-features delivery that provide value to the business model on a small scale
- In some of our more traditional methodologies, a final ‘big-ole’ product was the end state of the project. Everyone worked for year(s) to provide a single releasable behemoth. Changes after the fact were not accepted, or were discouraged to the point where it created a behavioral paradigm in which “it had to be perfect the first time.” Agreeing to a minimum viable product (MVP) can be a conversation that helps accelerate the trust factor. How, you say? It allows us to get a product into the customers’ hands quickly, ensuring that the team can delivery a valuable product quickly and with good quality Think of the original iPod touch: Released September 5, 2007 iTunes, Safari, and that was about it No calendar, mail, etc. No speaker Just an iPod with a touch interface – a true MVP The conversation should center on the value that the initial release of software can provide along with the fact that feedback from the customers/stakeholders can help drive the overall success of the product up. Using business value negotiation and full engagement refinement as tools can improve the MVP solution as well as the successive releases and features. The concept of an MVP also allows for a greater value – that of product adoption/acceptance – be identified which can bolster the continued development effort!
- Stable Releases all teams need to start here. Maybe some will end here. Many organizations’ customers cannot consume multiple releases per year much less one every 2-3 weeks. Also, some organizations cannot physically handle quick releases themselves. MVP’s is when we start to get good. Releasable frequently with the idea the team and P.O. can be flexible enough to create a releasable product. Macro and Micro Evolutionary are your releases both incremental improvements and flash-forward feature balanced? Finding the right balance of fixing and features is key. Feedback and “Feed-forward” many teams I know have gotten to the point where they are able to consume feedback and, within a release, provide features that address this feedback. But few teams are able to be forward looking, anticipate market forecast and move on new features. This is grail.
- One of the challenges facing product owners is that of where do they live in the organization. The challenge is that they are (read: should) be as close to the customer as possible meaning in large organizations (that are not development), they are generally a person who represents several departments to one product. They also might have a “real job.” Anyone heard this before? I have also seen product managers instead of product owners become more prevalent
- Horton Hears a Who! "Don't give up! I believe in you all. A person's a person, no matter how small! I Can Read With My Eyes Shut! The more that you read, The more things you will know. The more that you learn, The more places you’ll go. Oh, the Places You'll Go! When things start to happen, don't worry, don't stew. Just go right along, you'll start happening too! You have brains in your head. You have feet in your shoes. You can steer yourself any direction you choose. With your head full of brains, and your shoes full of feet, You're too smart to go down any not-so-good-street. Out there things can happen, and frequently do, To people as brainy and footsy as you. And when things start to happen, don't worry, don't stew. Just go right along, you'll start happening too! You're off to great places. Today is your day! Your mountain is waiting. So... get on your way.