Over on the ScrumDevelopment yahoo group, a ScrumMaster reported problems getting the Product Owner fully involved in the development process. Part of the problem is that the Product Owner isn’t co-located with the development team. The physical distance will certainly make participation more difficult, and less sure. That’s something to work on.

The Product Owner is not following the “rules” of Scrum, and this is frustrating the ScrumMaster. He’s likely right that playing the game by the rules will benefit everyone. He asks for advice on how to handle the situation.
One bit of advice the ScrumMaster received was to play hard-ball with the Product Owner.

1. Up front, you need to make it clear to the prospective PO that team collocation is REQUIRED. You WILL NOT ACCEPT THE PROJECT otherwise. …

2. Going forward, make it clear to the PO that their ongoing, active participation is REQUIRED. If they start out enthusiastically but begin to fade away after a few sprints, be prepared to WALK AWAY.

I have a very hard time supporting this advice. It seems unlikely to enhance collaboration with the Product Owner. Instead, it sets a negative, confrontational tone that will undermine trust. If it becomes necessary to walk away from the situation, and that’s always an option, what will be the result? Will it pass Weinberg’s Consulting Target? Will the Product Owner, or the company, be likely to try this “Agile” thing again? Or will the bad blood between people be a greater impediment than even a failed project?

I note the analysis of why the Product Owner is doing what he’s doing. I see the phrases “there seems to be,” “my gut feeling is,” “I think,” “I have a feeling that.” There’s nothing wrong with analyzing the situation in this way. But as Jerry Weinberg cautions, mind-reading is not a good practice for a consultant.^* It’s much better to ask.

A later post by the original ScrumMaster indicates that he has now asked, and “it seems that there may be confusion still with the scrum process and also operational priorities demanded his attention.” These are two very reasonable reasons. And these are two areas where further conversations will be needed.

• A series of conversations (probably a long series) about the process of steering agile software development from the business side, and
• A conversation to develop a strategy for handling future times when the Project Owner has too little time to respond.

These are problems that can be solved in many ways. And no one has to get upset or walk away.
^* I thought that this was in Secrets of Consulting or More Secrets of Consulting, but I can’t find the exact quote so I’ll just have to settle for this paraphrase.