There are many potential pitfalls when selecting the initial product owner. Some of the most common early-stage problems and what you can do to address them include
The product owner delegates decision making but then overrules the decision maker. To fit the new duties of the product owner into their schedules, some
product owners delegate decisions about specific parts of the product. Other
product owners enlist a business analyst to be a "feature owner" over some part
of the system. This can work well because the product owner has more time to
dedicate to areas that are not as easy to delegate.
Problems arise when the product owner says that decision-making authority has been delegated but then continues to approve or sometimes reverses decisions. Before delegating, product owners should be sure they are really willing to delegate without later second-guessing. Because of the pressure of the short, timeboxed sprints, Scrum teams often move much more quickly than they did before transitioning. It is inevitable that some decisions that the product owner delegates will turn out to be wrong, and these should be revisited. What we want to avoid, however, are situations where the product owner says,"Get your answers from Dave; he owns this part of the system," and then consistently overrules Dave's answers.
My advice to a new and overloaded product owner is to free some time by delegating just beyond the point at which you're comfortable. You may be pleasantly surprised and find no important decisions to reverse. But you'll occasionally find some decisions you would have made differently. Often the best thing to do in this case is the same thing we're all taught when learning to drive: If the car starts to slide, steer into the slide. Rather than pull against the decision (assuming it is not a horrendous one), allow that decision to persist through the end of the sprint; then decide if it should be changed. When the cost of reversing a decision is compared against all the other valuable work on the product backlog, you may find that the decision wasn't so bad after all.
The product owner pushes the team too hard. Product owners are often under pressure to deliver financial results to the company; more features delivered sooner is one way for them to achieve it. As I've said, I have no objection to a product owner who announces at the start of a project, "We need to build a product that is smaller, better-performing, and cheaper than our competitor's, and we need to do it in three months less than we spent on the last product." As long as a challenging goal like that is accompanied by appropriate freedom in how the goal is achieved, the team will do its best. The problems arise when the team is kept under constant and changing pressure from sprint to sprint. One difficult goal of "do this amazing thing in 6 months" is in many ways less stressful for the team than 13 successive two-week sprints of "I need more, more, more!" If you have product owners who are pushing teams this way, the ScrumMasters should first push back and then work with the product owners to set longer-term goals for the teams while ensuring teams have commensurate degrees of freedom in how those goals are achieved.
The product owner wants to cut quality. Cutting quality is an oh-so-tempting decision when trying to deliver a challenging set of features by a difficult date. It can lead to the short-term appearance of having met the objectives established at the start of the project. Eventually, however, the cost of having cut quality becomes apparent as more post-release bugs than usual are reported, the team's velocity decreases, and customers clamor for the product to behave as they thought it would.
Ken Schwaber has called quality a "corporate asset" (2006). As such, no one except the chief executive has the authority to sacrifice quality in exchange for achieving a short-term goal such as making a release date. A decision to cut quality may be the appropriate one; I can't tell you otherwise without knowing the full context of a situation. But, that decision is one that needs to be made sufficiently high up in the organization and with such openness that no one is surprised by the negative impacts that will almost certainly follow
Selecting product owners who understand this is sometimes challenging in organizations that are consistently focused on this quarter's numbers. Pushing back against attempts to reduce quality is the job of the ScrumMaster. The ScrumMaster does not need to prevail in these early disagreements. The ScrumMaster does, however, have to succeed in making the decision visible.
Time is on the ScrumMaster's side. If the ScrumMaster successfully raises the visibility of decisions to cut quality, he should eventually be able to win later arguments against reducing quality. "Remember on the Gouda project how I told you that cutting quality on version one would hurt us during version two?" the ScrumMaster can say. "Well, here are the graphs of velocity on the two projects. Note that version two had a lower velocity even though we added two experienced people. That was because we left bugs behind during version one (here's a graph showing that) and because the team didn't feel it had the time to do a good job of keeping its code clean. We even skipped the automated unit tests on a few modules. Here's a comparison of the number of defects found during the six months following release, broken down by whether the module had automated unit tests. It's up to you if we do this again on this project, but I think you know my opinion."
Our product owner is in a different city than the development team. With more projects being developed by remote teams, this is an increasingly common situation. Both the team and product owner in this situation should assume some of the burden of over communicating with the other. I have worked with many remote product owners, and it can work very successfully as long as the product owner does the following:
• Remains engaged in the project
• Establishes a rapport with the team
• Performs all usual duties of the role
• Is available to the team for phone calls for at least some part of the day, even if it is after the usual workday for the product owner
• Responds by e-mail or phone when not available in person
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
The product owner delegates decision making but then overrules the decision maker. To fit the new duties of the product owner into their schedules, some
product owners delegate decisions about specific parts of the product. Other
product owners enlist a business analyst to be a "feature owner" over some part
of the system. This can work well because the product owner has more time to
dedicate to areas that are not as easy to delegate.
Problems arise when the product owner says that decision-making authority has been delegated but then continues to approve or sometimes reverses decisions. Before delegating, product owners should be sure they are really willing to delegate without later second-guessing. Because of the pressure of the short, timeboxed sprints, Scrum teams often move much more quickly than they did before transitioning. It is inevitable that some decisions that the product owner delegates will turn out to be wrong, and these should be revisited. What we want to avoid, however, are situations where the product owner says,"Get your answers from Dave; he owns this part of the system," and then consistently overrules Dave's answers.
My advice to a new and overloaded product owner is to free some time by delegating just beyond the point at which you're comfortable. You may be pleasantly surprised and find no important decisions to reverse. But you'll occasionally find some decisions you would have made differently. Often the best thing to do in this case is the same thing we're all taught when learning to drive: If the car starts to slide, steer into the slide. Rather than pull against the decision (assuming it is not a horrendous one), allow that decision to persist through the end of the sprint; then decide if it should be changed. When the cost of reversing a decision is compared against all the other valuable work on the product backlog, you may find that the decision wasn't so bad after all.
The product owner pushes the team too hard. Product owners are often under pressure to deliver financial results to the company; more features delivered sooner is one way for them to achieve it. As I've said, I have no objection to a product owner who announces at the start of a project, "We need to build a product that is smaller, better-performing, and cheaper than our competitor's, and we need to do it in three months less than we spent on the last product." As long as a challenging goal like that is accompanied by appropriate freedom in how the goal is achieved, the team will do its best. The problems arise when the team is kept under constant and changing pressure from sprint to sprint. One difficult goal of "do this amazing thing in 6 months" is in many ways less stressful for the team than 13 successive two-week sprints of "I need more, more, more!" If you have product owners who are pushing teams this way, the ScrumMasters should first push back and then work with the product owners to set longer-term goals for the teams while ensuring teams have commensurate degrees of freedom in how those goals are achieved.
The product owner wants to cut quality. Cutting quality is an oh-so-tempting decision when trying to deliver a challenging set of features by a difficult date. It can lead to the short-term appearance of having met the objectives established at the start of the project. Eventually, however, the cost of having cut quality becomes apparent as more post-release bugs than usual are reported, the team's velocity decreases, and customers clamor for the product to behave as they thought it would.
Ken Schwaber has called quality a "corporate asset" (2006). As such, no one except the chief executive has the authority to sacrifice quality in exchange for achieving a short-term goal such as making a release date. A decision to cut quality may be the appropriate one; I can't tell you otherwise without knowing the full context of a situation. But, that decision is one that needs to be made sufficiently high up in the organization and with such openness that no one is surprised by the negative impacts that will almost certainly follow
Selecting product owners who understand this is sometimes challenging in organizations that are consistently focused on this quarter's numbers. Pushing back against attempts to reduce quality is the job of the ScrumMaster. The ScrumMaster does not need to prevail in these early disagreements. The ScrumMaster does, however, have to succeed in making the decision visible.
Time is on the ScrumMaster's side. If the ScrumMaster successfully raises the visibility of decisions to cut quality, he should eventually be able to win later arguments against reducing quality. "Remember on the Gouda project how I told you that cutting quality on version one would hurt us during version two?" the ScrumMaster can say. "Well, here are the graphs of velocity on the two projects. Note that version two had a lower velocity even though we added two experienced people. That was because we left bugs behind during version one (here's a graph showing that) and because the team didn't feel it had the time to do a good job of keeping its code clean. We even skipped the automated unit tests on a few modules. Here's a comparison of the number of defects found during the six months following release, broken down by whether the module had automated unit tests. It's up to you if we do this again on this project, but I think you know my opinion."
Our product owner is in a different city than the development team. With more projects being developed by remote teams, this is an increasingly common situation. Both the team and product owner in this situation should assume some of the burden of over communicating with the other. I have worked with many remote product owners, and it can work very successfully as long as the product owner does the following:
• Remains engaged in the project
• Establishes a rapport with the team
• Performs all usual duties of the role
• Is available to the team for phone calls for at least some part of the day, even if it is after the usual workday for the product owner
• Responds by e-mail or phone when not available in person
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
|
|
0 comments
Post a Comment