How does a Scrum Master "manage" an out of control Product Owner?

Question

I new to Scrum and while I understand the team concept behind the Sprints, I imagine there still needs to be a guardian for the team who minimizes the interference from Product Owners who are not conversant in software development. What are your successes, and what horror stories have you lived through?

Update:

I am looking for the balance between coding to implement business process vs creating the appropriate architecture for a client. If the product owner is from the business unit there has to be guidance as to what amount of time should be spent on data model, etc.

Definition:

By "out of control" product owner I mean typically some one from the business unit who aggressively sets time frames while having no real technical ability to create that estimate. Typically this person will say: "I need those screens before the next meeting with the Operating Committee next week, so prioritize those work products first. We'll tackle the database after we talk to Operations."

Great answers everyone. Thanks for the good input.

Answer 1

I've used Agile at two different shops, both times it works well. I don't see how an out of control anything can ruin the system. Before the sprint, you plan all the tasks you will do and guesstimate how long they will take (always round up). Then you can figure out approximately how much work can be done during your sprint.

Most shops use 4 week sprints, and 6.5hrs of workable time a day. When a sprint has been set, you don't introduce new tasks and only unplanned work that creeps into a sprint is fixing bugs in the features you are adding, of course that is suppose to be included in your guesstimate time.

If you want a more specific answer, you need to define what you mean by an "out of control" product owner.

Answer 2

I have two things to say.

You probably have some kind of R&D manager (that is not necessarily scrum master) and that is not a product owner).

This guy can and should (I think) "protect" developers. We were in situation when we had such a guy, and it worked pretty well. He helped us with getting non-functional stuff in the backlog for instance.

Now we don't have this guy. Our manager is scrum master. And he does pretty good job protecting us as well. Though...the problem here is that generic scrum master has no official power, so he cannot say "you are not going to press them this much", but he of course can and should talk if he sees that teem needs help.

The team itself and product owner also evolve with time so that they start to care more of each other. Product owner understands when the team just does not commit to more or says "we need some time for non-functional stuff now".

But then - again - it's nice of course if there's a separate R&D manager whose main responsibility is taking care of developers...then it will be more balanced I think..

We also have support department which borrows developers for support tasks. Sometimes it is difficult to agree what is going or is not going to be done for this or that customer (because support wants it all). For this case R&D manager - a very good idea too..

Ideally, I like the idea going completely lean so that developers don't need a manager or shield...but I don't know whether and how it works...:)

Answer 3

"there has to be guidance as to what amount of time should be spent on data model, etc."

Right. That's what prioritization is all about. You define the work, you prioritize. You work according to the priorities.

What can get out of control?

1. Redefining the work before anything gets done?

2. Redefining the priorities before the work gets done?

The solution is the same. Break the work into smaller pieces so something gets done before there's an opportunity to make a change.

If you have short (2-week) sprints, it's not possible to be out of control. If you go for slightly more practical 4-week sprints, then you have a small chance of getting into trouble.

Answer 4

I agree with S. Lott. Short sprints are better. Short user stories can help to. We try to limit our user stories to 2 - 4 days max.

1. Make sure that all your user stories are well defined and that the owner in agreement with them.

2. Once a sprint has started, insist that new tasks cannot be added to the current sprint, but they can be high priority in the next sprint. Shorter sprints make this much easier.

3. Also, in order to remove the imposition of artificial deadlines, you really shouldn't deliver items from the current sprint until the beginning of the next sprint when possible.

The hardest part about agile development is discipline. Once you have a disciplined team and scrum master, the users get used to it and things move much smoother. I'm not sure if you use any software for project management, but take a look at Rally. They have made some major improvements over the past year or so.

Answer 5

The responsibilities are very clearly defined in Scrum - the Product Owner defines backlog items and prioritizes them, the developers commit on how much they can do in a Sprint.

So, a Product Owner simply has no authority at all to set estimates. Of course he can still say that he needs something to a specific point in time - that simply happens. But it's still the developers who will say whether it can be done. And if it can't, they have to work out together on how to change the scope or whatever else can be done to get the needs of the PO fulfilled as best as possible.

Now, how exactly the SM should act in a situation where this doesn't work smoothly depends a lot on the specific situation. I'd rather see him facilitate a good relationship and communication culture between the PO and the team than have him shield the team from the PO, though.

Answer 6

The product owner is supposed to be the one that shields you from ambiguous or varying customer requirements.

The product owner must not give the estimates.

Answer 7

The iteration (Sprint in Scrum) scope should not be changed during the iteration. That's why only one iteration is planned at a time. As S. Lott pointed out, the shorter the iteration, the sooner the Product Owner will be able to get new things planned.

The Scrum Master role is to isolate the Team from such pressure and shall say to the Product Owner that new requests have to wait for the next iteration.

Now the Product Owner role is to maximize the value of the work the Team produces, so if there is a new top-priority item, which could not wait for the end of the current iteration, it is still possible to replace items with similar estimate and that have not been started. This should be the exception, not the rule.

Answer 8

Stick with the clearly defined rules of engagement then you(SM) can rather spend the time leading your team.

Answer 9

I don't think it's a question of "out of control".

"I need those screens before the next meeting with the Operating Committee next week, so prioritize those work products first. We'll tackle the database after we talk to Operations."

There is nothing inherently wrong with that statement by itself. If your app is properly abstracted, then your DB is separate anyway. The main problem with UI first is more psychological: The non-devs will assume that most of the work is done if they see screens and go bonkers when things "slow down". However, here's what I think your real problem could be:

The person you have flagged as a Product Owner is not owning the product, and so isn't taking on enough responsibility.

The product is the whole thing, not just the "functional requirements" (to borrow terminology). Your SM needs to have a sit down and be adamant that the PO needs to not try to push off understanding the scope of the behind the scenes work that needs to be accomplished. Once you're PO starts to look at the entire scope, then they can actually be your representative to the broader stakeholder community.

Ultimately, your SM is the one in charge of enforcing process. They should act like it.