Downloaded 16 times
![18
Avoid problems from the start
§ Write “good” user stories
• Clear
• Follow some principles of BDD
• Define Acceptance Criteria
• Review them with the team, always
upon sprint planning and later on
• in order to avoid misunderstandings, you can
explain them again as people start working
on them
As a [role]
I want [feature]
So that [benefit
As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank
is closed](https://image.slidesharecdn.com/agileconnectaveiro20181212v2-181213093427/75/From-Software-Developer-to-Proud-Product-Owner-Agile-Connect-Aveiro-Meetup-20-18-2048.jpg)
More Related Content
Similar to From Software Developer to Proud Product Owner (Agile Connect Aveiro Meetup #20)
From Software Developer to Proud Product Owner (Agile Connect Aveiro Meetup #20)
- 1. Sérgio Freire Proud ProductOwner Product Manager @darktelecom From Software Developer to Proud Product Owner: challenges in Waterfall and Agile contexts
- 2. 2 Today’s menu • Starters •Background • Main dishes • Software Developer • Team Leader • Product Owner • Dessert • Product Manager • Coffee & Digestive • Other topics • Open discussion
- 3.
- 4. In a nutshell Whois this guy? • PT Inovação • Developer • Team Leader • Technology Consultant (processes, tools, methodology) • Runtime Revolution • Team Leader & Senior Developer • Xpand IT • Product Owner & Product Manager
- 5. 5 Side Projects Stupid thingsI’ve done • Codebits (3rd, 5th and 6th prizes) • Nagalhães • Truz Truz – knock knock to unlock • remote control Meo with Chocolate Milk Boxes (no award) • The Grid (first version) • The Grid, as a product (guess the revenue I made?)
- 6. 6 What makes me excited ThinksI like • Get Things Done (even if I have to make them J) • Learning • Discover • Try • Improving • Being helpful, so others can improve themselves • Challenges • Creativity • Innovation
- 7.
- 8.
- 9. 9 Being a SoftwareDeveloper § Waterfall • You hope the BA did their work • You do what you’re told (e.g. by the TL) § Some few problems • You make something that is not exactly what customer needs • Too many hierarchical layers => information turns into noise • Problem vs Solution space If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions. - unknown
- 10. 10 Being a SoftwareDeveloper § Agile • You iterate and discuss with the team and the PO, on a daily basis • Customer may act as the Product Owner § Some few problems • Doing things iteratively has some challenges to the architecture design • It is a complete different mindset than starting with a full spec • Sometimes it’s hard to get the customer always available as a PO
- 11.
- 12. 12 Team Leader vsScrum Master § Team Leader • Manages Team • Defines tech architecture • Accountable • Senior (in theory) • Sometimes you earn a leading role • COOL!? Maybe not really https://mozaicworks.com/blog/team-leaders-and-scrum-masters/ https://www.scrum.org/forum/scrum-forum/7630/team-lead-role-sign-bad-scrum
- 13. 13 Team Leader vsScrum Master § Scrum Master • Servant leadership • Guard & coach the Scrum Team • Remove impediments for the Team • Facilitate the various Scrum Events • Ensure efficient communication between Team and the Product Owner • Doesn’t tell the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
- 14.
- 15. 15 Product Owner § Responsibilities •Build and manage the product backlog • Closely partner with the business and the team to ensure everyone understands the work items in the product backlog • Give the team clear guidance on which features to deliver next, on the upcoming sprints • Release Management https://www.scrum-institute.org/Scrum_Product_Owner.php https://www.atlassian.com/agile/scrum
- 16. 16 Clarifications on ProductOwner Role “The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.” “For the Product Owner to succeed, the entire organization must respect his or her decisions.” To me, a “Product Owner” is someone who not only has the power to modify its features, but they have sufficient power to kill the product they own. If they don’t have that level of power, then they are not really the product owner, and someone else really owns it. - Alan Cooper
- 17. 17 Beware with theProxy Product Owner § What is that? • Someone else owns the product • Product vision and features managed by someone else Which leads to... • Unclear ownership • Unable to take the necessary decisions whenever they’re needed • Unable to control the necessary budget/resources • Not fully accountable https://www.scrum.org/resources/blog/what-proxy-product-owner-why-it-found-so-often https://dzone.com/articles/pattern-of-the-month-proxy-product-ownership
- 18. 18 Avoid problems fromthe start § Write “good” user stories • Clear • Follow some principles of BDD • Define Acceptance Criteria • Review them with the team, always upon sprint planning and later on • in order to avoid misunderstandings, you can explain them again as people start working on them As a [role] I want [feature] So that [benefit As an Account Holder I want to withdraw cash from an ATM So that I can get money when the bank is closed
- 19. 19 Product Owner § Sourceof problems • Maintaining multiple versions at the same time • Does your product depend on others? • Do you have to support multiple versions of that product? • New versions rise unexpectedly and may break your product • Customers will get upset and demand a fix ASAP • Bye bye planning Þ plan for the unknown: allocate people on advance out of Sprint context Þ bugfixes managed using Kanban => released ASAP
- 20. How to dealwith >3000 customers?
- 21. 21 Product Owner Tactics yourcustomers/stakeholders will use • Pressure (email, phone, don’t renew/purchase, etc) • They will find ways • Massive voting • Keep annoying you and your support team
- 22. 22 Product Owner • Recommendations •You’ll need the PM role, sooner or later... • Be transparent • Say no => not every customer is a customer that you want • Don’t commit to fixed dates => always mention that you work with estimations • Be clear about your Release Policy and how you manage your releases • Have a public roadmap • Beware that you’re dealing with people => they’ll be smarter than you (votes example) • Beware with sponsoring features!!
- 23. 23 Handling your backlog §What you can do and some limitations • apply “labels”, use “components” or other filters to properly tag issues • having a well defined list of values may help later on • Don’t use vote amount as-is or you will get garbage • up to 1 vote per each customer • not easy/effective to manage the backlog by multiple criteria • “Comala Agile Ranking” for Jira can assist ranking backlog items by Importance/Risk => not perfect; how to deal with multiple value proposition?
- 24. 24 Things that canaffect your Sprints § Things that will happen • Team not being focused • Team working on side projects • Unplanned events/activities • HR, visits, etc • Support issues • Investigation of problems, optimizations, compatibilities => very hard to estimate "If we knew what we were doing, it wouldn't be called research.” – Albert Einstein ??
- 25. 25 Things that canaffect your Sprints • Avoid side projects • Do them in-between Sprints or with someone working outside the Sprint • Unplanned events/activities • Talk with your stakeholders in order to be aware of them in advance • Support issues • Several levels, first ones handled by the Support team (if you have it) • 1 person allocated each week (i.e. 1 person on average out of Sprint timeframe) • TL as a backup • Investigation of problems, optimizations, compatibilities • Very high-level of uncertainty => do outside of Sprint but keep the communication going on
- 26. 26 Common Scrum Traps §You’ll see this often • Mini-waterfall • Testing only done at the end => Shift-left your testing, up to the release planning • Estimation 1 Story Point = x Hours • you may use this at start but you have to change your mindset! • Have a Release Date and a pre-defined Scope, for that date => you have to choose one • Unclear or not adequate Definition of Done • code implemented and review != Done • Ownership / accountability!
- 27.
- 28.
- 29.
- 30. 30 Product Management Product managementis an organizational function that guides every step of a product’s lifecycle: from development, to positioning and pricing, by focusing on the product and its customers first and foremost. To build the best possible product, product managers advocate for customers within the organization and make sure the voice of the market is heard and heeded. (Atlassian)
- 31. 31 Product Owner vsProduct Manager Product Owner is a role you play on a Scrum team. Product Manager is the job. Melissa Perri (Product Manager Competence can be summarized as).... deep knowledge of your users and customers; deep knowledge of the data that’s generated about your product; deep knowledge of your industry; and deep knowledge of how your business works. Marty Cagan There comes a point when growing businesses benefit from having two product roles — externally focused product managers and internally focused product owners. And the people are happier too. @johnpeltier
- 32. 32 Product Manager The messyou may get involved with • Team • Engagement/Happiness/Growth • Improve processes • Communication • Webinars, blog posts, articles, presentations on events, videos • Customers • Demos, pre-sales, Q&A/clarifications, recommendations, discussion of new features, assistance • Partners • Q&A/clarifications, recommendations, assistance • Product development • Prototyping, UI/UX, tech documentation • Competition analysis • Exploring • Support • Roadmap
- 33. 33 Rian Van DerMerwe @RianVDM http://bit.ly/2BYx05R
- 34. 34 Agile Product Management • Havethe Agile Manifesto and its principles in mind • Listen to the customer frequently (meet them on person, discuss with them) • Make frequent releases and gather feedback / involve customers • Be open to changes, prototype them and discuss them with other customers • Use analytics to have a better understanding on people use your product • Don’t overcomplicate attending to every single request; make things simple yet useful for most of your customers • Your roadmap is not static; let you customers be an active part of it
- 35. 35 What matters foryour Product? What matters for your Product?
- 36.
- 37.
- 38.
- 39.
- 40. 40 All the extrasyou can get
- 41. 41 Don’t forget that... §Your product is like an holographic paper • Take into account the different value proposition of your product • It would be great to map and prioritize stories for each value proposition and from there prioritize the backlog
- 42. 42 Facts • People seeyour product differently • People will value your product differently • People will have your product even if they didn’t asked for it • People will always get unsatisfied with something • You can get real ambassadors
- 43. 43 Know your differentuser personas • What are the different kind of users that user your product? • What do they intend to use it for.. • And how? Notes: • the same persona can perform quite different scenarios • different personas may have similar needs, yet slightly different (e.g. reporting)
- 44. 44 Keep your audience pleased •Don’t forget to... • Address needs for the different personas and for their different usage scenarios • DON’T do it all at the same time, or you’ll loose focus on each release • Give workarounds for things you don’t want to do (or want to do on the short term)
- 45. 45 Mapping this toreleases § Tips • Make small, focused and frequent releases • Use semantic versioning (i.e. major.minor.fix – 3.1.2) • Go over your backlog and check long waiting or painful stuff • Having in mind the different personas and the things most relevant for them
- 46. 46 Don’t forget § Thisis not secondary stuff • Technical debt • Performance • Usability & UX • Ways of easing support activities
- 47.
- 48. 48 “Multiple” Teams • Devteam • Support team • Marketing team • Partners team • Sales team • Customer Success team • Design team
- 49. 49 Challenges with growth §Source of problems • Many requests from “multiple” teams at same time • Many customer requests/support => unable to handle it • “Improvements and bugs” created on the” backlog” Þ don’t allow customers to create improvements/bugs directly; make them through the support Þ Problem Space vs Solution Space Þ support may create issues in the project; not on the “backlog” itself; use a specific “Backlog” version
- 50.
- 51. 51 What your userslove § Tips 1. It’s not your product 2. And it’s not you J 3. And it’s also not what they do with the product by itself It’s all about turning their pains into pleasures (i.e. fulfilling their needs in seamless and pleasant ways) And give them the opportunity to shine...
- 52.
- 53. Cover with justtitle How we work
- 54. 54 Team setup • ProjectManager • CMMI and other certifications compliance, processes optimization, HR needs, top alignment • Team Leader (acts also as the Scrum Master) • coordinates Team and that processes are met, including CMMI related activities • Helps on support, namely on more critical issues • Interview new members for the Team • Developers • Implement stories (including documentation) • Review code of others in Pull Requests • Fix bugs • Help on support • Testers • Involved in Pull Requests • Support • frontline for customer issues • coordinates with dev team and PO • PO/PM
- 55. Cover with justtitle Product vs Services
- 56. 56 Working in Productvs Services § Product • your deadlines are more or less flexible (kind of) § Consulting / Services • Hard to “sell” Agile/Scrum/Kanban • People don’t valorize testing • Time & Materials • Hard to estimate • Fixed-price • Risky; try to avoid it
- 57. 57 Do some thingsupfront • Do a Design Sprint or some sessions with customer to algin scope and expectations • you can then give a better estimate (reduce uncertainty) for Fixed-Price contracts • See: https://thoughtbot.com/playbook/product-design-sprint/introduction • Prioritize features together with customer => quite helpful for Scrum iterations • Make some rough mockups • better alignment; always good to have! • Fixed contracts • do visual design ASAP • MVP => follows some Agile principles
- 58. Thank you! sergio.freire atgmail.com @darktelecom Challenges are timeless. Your biggest challenge? Yourself. How can you overcome it? As a Team.