Início Notícias Trabalhando com pessoas resistentes no Scrum
25 nov 2010 3 min(s) de Leitura
Como você trabalhar com pessoas difíceis e que não cooperam? Pessoas que são combativas e não profissionais? Pessoas que parecem mobilizadas contra as decisões do dia?
Will Jessup notou que desenvolvedores tender a ser pessoas altamente inteligentes e que frequentemente não farão algumas coisas simplesmente porque nós dizemos. Ele sugere um diálogo:
"ok nós vamos fazer as estimativas para estes cartões"
"por que? eu odeio fazer estimativas"
"Você tem alguma idéia melhor sobre como obter a informação para o cliente sobre nossa melhor estimativa para quanto tempo demoraremos para terminar este projeto? sem isso nós não podemos ter o orçamento aprovado e ninguém vai receber"
"hrm... não"
"então se nós fizermos estas estimativas nós teremos nosso bs completo, uma completa hipótese, um cronograma estimado com base em um monte de coisas que mudarão - mas pelo menos é alguma coisa"
Kevin Shine sugere que nós devemos para de vender idéias e fazer com que eles comprem-as por vontade própria: "Existe uma grande mudança de pensamento entre estas duas maneira de pensar. Uma é colaborativa e cooperativa e a outra é mais comandada e controlada." Ele sugere fornecer suporte e apoio, deixando o time chegar a suas próprias conclusões. Ele finaliza dizendo: "Você não pode forçar a mudança nas pessoas. Em vez disso, mostre a elas como o futuro pode ser e ajude-as a participar da criação dele."
Gustavo Cebrian Garcia:
Fazer uma questão como "por que não?" - em vez de tentar justificar sua abordagem perguntando para eles porque ela não funcionaria.
Transforme o problema do confronto para nós, talvez pedindo que reconheça o problema e em seguida, descubra qual é o problema. Isso frequentemente requer muitas questões para encontrar a raiz.
Faça referências à autoridade externa.
Bachan Anand questiona se o time está mesmo ciente do problema(s), dizendo que eles não podem melhorar se eles não perceberam um problema. Além disso, ele ressalta que um novo Scrum Master precisa de tempo para ganhar o respeito e a confiança dos membros da equipe.
AAshish Mahajan, nos lembra que o Scrum é apenas uma ferramenta e não um objetivo. Na falta de um sentido claro e convincente e um senso de urgência o time não se empenha. Ashish sugere um coaching 1-1, análise da raiz do problema e um rigoroso uso de retrospectivas para ajudar os membros do time a descobrirem seus próprios problemas.
George Dinwiddie, sugere olhar para o problema do ponto de vista das outras pessoas. Por que elas estão reagindo desta maneira? O que eles acreditam que explicaria seus próprios comportamentos? Ele recomenda "Resistente como um Recurso" de Dale Emery, e qualquer coisa de Esther Derby sobre feedback. George também indica uma bibliografia de artigos de feedback.
Este repórter observa que é difícil se não impossível vender idéias para pessoas, em vez disso é melhor ouví-las. Tire suas dúvidas de pessoas que busquem entender os problemas que elas tem, não os problemas delas com o Scrum, mas seus maiores problemas. Use o Scrum para ajudá-las a solucionar estes problemas e elas descobrirão o seu valor mais rápido. Além disso este repórter sugere:
"Por que" é uma pergunta potencialmente perigosa, há uma grande probabilidade de colocar a pessoa que está sendo perguntada na defensiva. Fazendo questões O que/Quando/Onde nos ajuda a alcançar os mesmos fins sem uma reação defensiva. Em vez de "Por que não", tente "O que você pensa que não funcionará se usarmos planning pokker" ou "Pode me dizer o que você acha que este problema é". Nós mudamos o foco da pessoa para o problema.
by Valdemar Júnior /
Muito bom artigo. Tenho ainda dificuldades de aceitação do SCRUM por parte da equipe que trabalho, mas com essas dicas, quem sabe pode melhorar.