Stevens oferece 4 coisas para buscar como sinais de aviso que o relacionamento do time com seu Product Owner pode precisar de melhorias:
"O Teste da Galinha": se o time está tratando o Product Owner como se ele não fosse um membro do time, então há uma alta probabilidade que exista algo sobre o comportamento do P.O que está deixando o time desconfortável.
"Sprints que falharam, impossibilidade de soltar um release": é possível que problemas com stories da iteração tenham causado isto e elas podem ser rastreadas de volta para os problemas em colaboração com o Product Owner.
"Quem é o responsável?": Problemas causados por um time recebendo sinais misturados ou em direções ambíguas de múltiplos Product Owners.
"Seu time está desmotivado": a falta de um tempo adequado face-a-face com seu Product Owner causando a perda de motivação do time.
O principal do post de Stevens vem na forma de 3 dicas para o Product Owners (ou Cliente XP) para melhor comunicação e report com seus times.
Participe totalmente de todos os rituais do Scrum, incluindo o Scrum diário e as retrospectivas. Assista o scrum diário e a retrospectiva do sprint como um participante normal. Responda as mesmas questões que todos os outros. Escute. Não use a oportunidade para jogar seu "peso" nos rituais. Talvez você deva se oferecer para ficar em silêncio por um sprint ou dois para construir a confiança. Isto vai ajudar você entender seu time e o que eles necessitam para serem bem sucedidos. Eles também vão entender seus problemas e desafios melhor.
Você faz um acordo com o time em todo planejamento do sprint. Mantenha seu lado da barganha. Não venha para o seu time com trabalho extra durante a sprint. Não mude sua opinião caprochosamente - ser ágil não é a mesma coisa que ter falta de visão. Proteja seu time da interferência de qualquer um na companhia. Sim, este é trabalho do Scrum Master, mas assuntos serão escalados para você.
Venha para reuniões no horário marcado e esteja por toda a duração. Reserve o suficiente de sua capacidade para atendet as necessidades de seu time. Se seu tempo é limitado, então ache qual o impacto que sua ausência está causando no projeto. Planeje releases em torno de datas que não são alteradas, como férias, feiras de negócio e outros eventos importantes, para que você possa estar presente em fases críticas do projeto.
Para não ser repetitivo, mas vale estressar que enquanto Stevens apresenta sua mensagem em termos Scrum, este conselho é igualmente aplicável para aqueles em ambientes não-Scrum. Se você está praticando XP, por exemplo, então este conselho é para o "Cliente" e seu "sprint" é sua "iteração", etc.