 |
| photo credit |
I'm looking at you Product Owners, time to step up your game, understand your role and help take the team to the next level. Here's 6 things that you should know about owning the product:
1) Trust is key:
Particularly early in development for a new product there will be a lot of Product Backlog items which may or may not be understandable without development experience. At this early stage you'll be relying on your Scrum Master and in particular the development team to explain the need for these things so that you can properly prioritize them. My suggestion is to build a good relationship with the Scrum Master and at least one (preferably all) of the developers who can act as a guide for some of the more esoteric work that may need to be done in the sprint.
Likewise, that trust will be needed both ways. If the team knows you well enough to suggest some changes to the product that you may not have thought of or understand (refactoring comes to mind) then take some time to listen. More often than not these types of technical changes will ultimately make development much easier in the long run rather allowing for faster feature development, more reliable code and better performance in the long run. You'll find that this type of really valuable feedback will simply disappear if you don't take the time to earn your team's trust.
2) Your job is to serve the team:
The ultimate goal is to ship great software, that's why you're there, that's why the team is there and in a roundabout way that's why the Scrum Master is there. That being said, which role in a Scrum organization is most likely to get blocked, thus preventing the shipping of said software? If you answered the Scrum Team then you are correct. While it's not something that you can prevent altogether it's definitely not a problem that you should contribute to.
Let's imagine a scenario where the development team is working on various aspects of your product. One by one, (or even all at once) they need some feedback from the product owner so they call you and it takes you day (8 productive hours) to get back to them. One day turn around time isn't so bad right?
By applying the power of math, assuming a 14 day sprint and the loss of one day due to the product owner waiting to get back to the team, that's slightly more than 7% of the sprint lost to the product owner turnaround time which is likely a wide enough margin to cause sprint failure. Part of the whole point of having a product owner is to provide a single dedicated source of feedback for the team since the actual customers are usually off doing other things (which usually don't include software development).
My thought on the matter is that the Product Owner (and the Scrum Master) should adopt a helpdesk mentality when the Scrum Team requests some feedback. That request should be turned around in a matter of hours, minutes preferably. If at all possible, try to position yourself in the office WITH the Scrum Team and make them feel comfortable walking into your office (or cube, or whatever) to ask questions and get feedback when they need it.
3) It's your job to understand our customers:
Q: What do developers know really really well?
A: How to make software.
Q: What is unlikely for a developer to know really well?
A: How to work a warehouse, file insurance paperwork or anything else that your stakeholders will use the final product for.
Ideally you actually are one of the customers and bring a ton of domain knowledge to the party but if you're not (or even if you are) you need to spend whatever time you can understanding the end users who's needs may encompass more than what you're familiar with.
This means contacting customers who provide feedback personally, spending time with customers who actually use the product and/or a legacy solution to find out what they like/don't like. Being an active part of the online community (if there is one) for the business area and just generally getting into the head of the folks who will ultimately use your product.
This also means putting your ego aside in many cases to allow some backlog items you may really like to take a backseat to functionality that may be important to the customer base as a whole.
4) The Team occasionally fails
Each sprint adds value to the final product but that doesn't mean that the Scrum team will always deliver exactly what they committed to. Some sprints may see them over-deliver while other sprints that fail to implement everything. Neither Scenario is good or bad, it simply means that software development (at the team level) is unpredictable at best.
Think of it this way, if the team maintains a planned velocity of 100 hours per sprint but delivers the first sprint with an actual velocity of 90 and the second sprint with 110, what's the average?
The point here is that sprint success or failure isn't necessarily important to the Product Owner so much as the team delivering value to the product so don't sweat the details here and use some of the trust we talked about earlier. The team occasionally fails because they're trying new techniques, setting ambitious goals for themselves and is generally looking to improve every sprint, this results in the occasional failure but will generally trend towards a faster more efficient team over the length of the entire release.
5) You are not a Project Manager:
This part is actually a bit tricky but ultimately, it's your neck on the line as the Product Owner if the Product ends up sucking. But that doesn't mean that you set the schedule for the team, worry about how the allocates the work or god forbid, plan the sprint backlog. It's your job to set the teams priorities at the backlog item level and to provide valuable feedback for the team. If you attempt to control any aspects of development past these levels then frustration and team unhappiness will result.
Here's why, planning the day to day details of development with the individual tasks or even the backlog items reveals a wealth of complexity such as the expertise of the individual developers, dependencies at the task level, individual schedules, sick days, vacation time and various other aspects that have given project managers headaches for decades using the waterfall method. These things don't magically go away using Scrum but we absorb them at the team level which makes life for everyone much easier.
You see the team understands the technical intricacies involved with their work because their the ones doing it, they (should) know each others strengths and weaknesses and even each others schedules better than any Project Manager, Scrum Master or even Product Owner ever could which makes the team the most logical place to hammer out those details. This is the primary reason why the team decides on the amount of work to pull into the sprint backlog rather than any other role.
6) The Sprint Review is not a dog and pony show:
The sprint review is one of the few aspects about Scrum that should be done behind closed doors. The purpose here isn't to celebrate new features, berate the team for missing functionality or anything of the kind. As a product owner, it's your job to see what the product looks like at the current iteration, provide critical feedback, make some tweaks to the backlog and/or stamp the product ready for release. When the Sprint Review becomes a public meeting that instant feedback becomes much harder to give, details get lost, that part of the interface that crashes isn't clicked on. In essence the Sprint Review (while great for morale) becomes much less useful as a feedback mechanism.
Final Thoughts:
I could go on for hours about any one of these six points and you may see more detailed posts about them in the future. The truth is that a strong Product Owner is often the secret sauce that separates a great software development team that amazes customers from a mediocre one that simply pushes out a release every now and then.
No comments:
Post a Comment