Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Disseminando conhecimento e inovação em desenvolvimento de software corporativo
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Postado por Mike Bria , traduzido por Douglas Masson em 13 Jan 2009
Nos últimos dias houve um debate muito ativo no Grupo Scrum Development do Yahoo Grupos sobre o que fazer quando uma pessoa da sua equipe está tendo "baixo desempenho". Na thread de mais de 130 respostas, Rotten Apple in Scrum Team, a discussão variou de conselhos até a questão principal, falar sobre a moral da equipe e quem a gerencia, até o debate clássico da medição de indivíduos, para distinguir se uma equipe é realmente uma "equipe"e mais.
Marko Majkic iniciou o debate descrevendo um membro da sua equipe que ele parece estar com problemas de "baixo desempenho" e pedindo conselhos sobre como lidar com isso (citação derivada do post original e de uma resposta posterior):
A contribuição média por desenvolvedor é de 38 usp (user story points, ou pontos de história do usuário). Um dos membros fez apenas 19 ups - duas vezes menos do que os outros.
...
Eu não acho que esta pessoa é preguiçosa ou maliciosa. Parece-me que ele tem a mente ausente no trabalho e/ou tem falta de concentração
...
Devo levar isso a a reunião de review Scrum ou devo falar com esta pessoa em particular? O que vocês fariam?
A partir desta declaração muitos tópicos foram lançados, um dos quais sendo um debate em torno da primeira questão do Marko sobre como lidar com o individuo de baixo desempenho. Muitas dessas respostas retornam para uma base de sugestão que a ação mais crucial é fazer uma nova, avaliação do objetivo do que está realmente acontecendo. Paul Hudson resume:
Como outros já disseram, talvez você precise voltar um passo atrás aqui. Me parece, baseado no que você disse que você assumiu que o individuo deve ser responsabilizado pela baixa produtividade, ao invés de procurar solucionar algumas questões subjacentes.
...
Eu acho que eu (e vários outros) estamos encorajando você a utilizar outros pontos de vista. Não existe fórmula mágica. Você precisa descobrir quais problemas a pessoa em questão possa ter e discuti-las com ele.
...
Então as sugestões (concretas) foram:
a) Verificar se o problema realmente é um problema e se é o que você acha que é
b) Obtenha mais informações sobre os problemas que a pessoa possa enfrentar
c) Levante e discuta o problema a nível de equipe ou individuo
Mais conselhos sobre como agir em relação às coisas citadas nas sugestões de alto nível do Paul, incluem coisas como:
Interessantemente, uma discussão mais adiante revelou que a preocupação do Marko não foi tanto sobre a produção real do individuo por si só, mas sim um receio de que o resto da equipe pode em breve reagir negativamente ao individuo, talvez trazendo isto para uma retrospectiva. Como seria de esperar, muitas respostas foram rápidas de salientar que este é um resultado desejado, e não deve ser temido. qComo declarado por Ilja Pruess:
Eu realmente preocuparia muito mais sobre o que *não* falar faria com a atmosfera da equipe.
...
Então se eu senti que havia maus sentimentos sobre este "baixo desempenho" na equipe, eu veria isto como minha responsabilidade como um facilitador, *encorajar* os membros da equipe a falarem e ajudá-los a solucionar graciosamente o problema.
A partir deste veio também um debate em torno do tema da "moral da equipe". Particularmente notáveis foram as respostas para a questão de quem "é responsável (pela manutenção da moral da equipe)?". Respostas dadas por Alistair Cockburn, Dan Rawsthorne, Michael Wollin, Paul Hudson e outros debatem se este é o papel principal do Scrum Master, gestor de projeto, Product Owner, a própria equipe, CEO, outros e/ou todos citados acima. Também, uma referência de informativa sobre como melhorar a moral foi apresentada no meio da discussão.
Também a partir da declaração inicial do Marko rescucitou o debate em torno da medição de desempenho individual (re: Marko utiliza "pontos por pessoa"), ressaltado pelo lembrente do Ron Jeffries de que não deveria haver tal coisa como "pontos completados por individuo " se a equipe está realmente funcionando como uma "equipe". Uma discussão relacionada apresentou a idéia que a medição de desempenho das pessoas (objetivamente) pode não ser necessariamente errada, mas deve ser usada apenas como uma entrada de muitas para suas avaliações subjetivas de um individuo (ex: registro do Eric Deslauriers).
Para mais informações sobre este assunto, veja um post popular da InfoQ sobre "análises de performance", bem como dois posts de blog recentes por George Dinwiddie em química da equipe, julgamento de desempenho e também um do Mark Levison.
Finalmente, lembre-se, até esta data houve 130 respostas no Scrum Development Yahoo Group discussion, portanto entenda que este post da InfoQ ésimplesmente uma visão geral light de alguns dos temas centrais. Confira a thread você mesmo para entender tudo que foi resumido aqui e é claro não se esqueça de adicionar sua opinião tanto lá e/ou quanto aqui.
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.
Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.
Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.
O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.
Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.
Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.
Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.
Nenhum comentário
Acompanhar Discussão Responder