Assim como na dinâmica anterior, o objetivo do Feedback Canvas é promover uma autoavaliação da equipe, onde todos os membros levantam pontos sobre os demais. Essa forma de feedback foi criada por Matheus Haddad e, assim como outras atividades que utilizam um Canvas, ela consegue se beneficiar deste artefato, já que ele direciona e deixar bastante visual exatamente sobre quais aspectos uma determinada pessoa deve ser avaliada. O resultado desta avaliação permite que cada um ouça dos seus colegas como está o seu trabalho, além de levantarem juntos ações que podem ajudar a melhorar comportamentos considerados negativos por todos. Sendo assim, cria-se uma atmosfera onde todos colocam as cartas na mesa com o objetivo de ajudar uns aos outros a desenvolver competências e melhorar, por consequência, a qualidade do trabalho da equipe.

Falando um pouco mais sobre o funcionamento do Feedback Canvas, a ideia é que cada membro da equipe escolha sobre qual competência ele deseja ser avaliado. Feito isso, toda a equipe elenca as atividades consideradas mais importantes para aquela competência e será em relação a essas atividades que a pessoa receberá seu feedback. O mais interessante desta estratégia é que cada pessoa será avaliada em relação àquilo que a equipe realmente julga ser importante e não em relação à conceitos e/ou atividades “pré-moldadas”, que às vezes podem não traduzir exatamente o desempenho de cada um dentro da equipe. Isso reforça ainda mais a ideia de receber feedback dos colegas e permite que o desenvolvimento de competências seja ainda mais focado para o trabalho que está sendo realizado.

Como podemos visualizar no Canvas, a competência escolhida será avaliada por todos de acordo com a escala ali apresentada. Todos os membros da equipe, incluindo o avaliado, colocarão sua opinião sobre em que ponto da escala a competência do avaliado se encontra e, feito isso, conversarão sobre os motivos de essa ser a percepção geral. Essa escala de avaliação pode ser a definida pelo criador do método, com base em outros métodos, ou pode ser definida pela própria equipe. No primeiro caso, o significado de cada número se encontra descrito abaixo.

A discussão sobre pontos positivos, negativos e ações de melhoria finalizam a dinâmica e completam o Canvas. Após esses últimos passos, a pessoa avaliada consegue ter um quadro onde estão mapeadas as principais atividades relacionadas à competência que deseja desenvolver, a visão da equipe sobre o trabalho realizado e quais são as atitudes que ele deve tomar para continuar se desenvolvendo.

E você? Já experimentou o Feedback Canvas na sua empresa?

Em um próximo post aqui no blog falaremos um pouco sobre a nossa experiência ao utilizar o Feedback Canvas com uma de nossas equipes. Conte para nós também como foi sua experiência e fique ligado no próximo post desta série, quando começaremos a tratar sobre feedback de fora da equipe para dentro. Até lá!

Referências: http://gestao30.matheus.eti.br/palavra-chave/feedback-canvas/

The post Feedbacks, motivação e desenvolvimento de competências – Parte 3 appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

No primeiro post desta série vimos que, apesar de às vezes não ser o mais buscado, o feedback dos demais membros da equipe de desenvolvimento é um dos mais valorizados por todos. Isso se explica pelo fato das pessoas acharem mais importante saber a opinião daqueles que estão diariamente com a mão na massa, como eles, do que daqueles que estão um pouco mais distantes. Isso não significa que os demais feedbacks sejam menos importantes, não mesmo. A questão é só que os próprios membros da equipe são mais capazes de identificar pontos de melhoria e de auxiliar os outros a enxergar formas de melhorar e aprender outras formas de desempenhar o trabalho em questão.

Visando promover esse tipo de feedback, há um tempo atrás fiz uma atividade na reunião de Retrospectiva em que o objetivo era justamente fazer com que todos falassem de todos. A ideia é que cada membro da equipe, inclusive o Scrum Master, indicasse uma característica positiva e uma negativa sobre todos os outros membros presentes. No caso, nossas Retrospectivas não contam com a presença do Product Owner.

Para tentar avaliar se havia alguma resistência, fiz a atividade Safety Check que comentei no post “Feedback, Motivação e Desenvolvimento de Competências – Parte 1” e sim, havia resistência. Então, comentei que de repente seria melhor deixarmos para outro momento, mas a equipe teve uma atitude legal de conversar sobre o assunto e resolvemos seguir em frente. A atividade foi bem legal e o mais importante foi ver que todos entenderam o objetivo principal daquele momento: o objetivo não é lavar a roupa suja, é ajudar o outro a crescer e se desenvolver! Deixei isso bem claro no início da atividade e gostei de ver que ninguém se desvirtuou desse objetivo. Inclusive, a atividade foi bem aberta para conversas, para cada um explicitar o motivo de levantar determinado ponto e para que cada um pudesse entender o ponto de vista do outro e por que tal característica era vista como positiva ou negativa.

Depois da atividade, cada pessoa recebeu seu feedback para que os assuntos discutidos não fossem esquecidos. Com o tempo, era possível perceber que algumas coisas tinham sim melhorado, outras talvez nem tanto. Mas isso é normal. Não adianta termos a ilusão de que as pessoas mudarão de um dia para o outro. Isso é um processo, que pode ou não precisar do apoio de todos, e que precisa ser acompanhado e motivado sempre que possível.

Uma das coisas mais legais desta atividade foi ver que quem inicialmente mais teve resistência em participar, um tempo depois veio me perguntar quando a dinâmica seria repetida, pois a pessoa queria receber um novo feedback e ver se a opinião dos outros membros da equipe sobre o seu comportamento tinha mudado. Isso demonstra que mesmo que exista um receio inicial, ao perceber que as críticas são construtivas e que existe um ambiente seguro para crescer e melhorar, a pessoa se sente à vontade e estimulada a correr atrás desse crescimento. E isso é algo muito importante!

Infelizmente ainda não conseguimos repetir a dose da Retrospectiva, mas espero que seja possível em breve. Acredito que manter a frequência desse tipo de atividade quando os envolvidos estão abertos a ela, além de provocar melhorias contínuas, ainda mantém a equipe motivada a sempre buscar novas formas de trabalhar e se aprimorar.

No próximo post falaremos sobre mais uma dinâmica. Essa mais voltada para o desenvolvimento de competências em si. Não deixe de acompanhar e contar para gente como as coisas têm funcionado na sua empresa!

The post Feedbacks, motivação e desenvolvimento de competências – Parte 2 appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Já falamos aqui no Blog ScrumHalf sobre a importância do feedback e como essa prática pode influenciar positivamente no andamento do projeto, no relacionamento entre Time e PO, entre outras coisas. No entanto, apesar de falarmos bastante sobre o feedback em relação ao produto e à equipe como um todo, ainda não tratamos tanto assim do feedback sobre o desempenho individual das pessoas, que também é importantíssimo. Por isso, hoje dou início a uma série que buscará falar um pouco sobre a relação entre feedbacks, motivação e desenvolvimento de competências. A ideia com esta série é discutirmos um pouco sobre este assunto que pode trazer diversos benefícios para a equipe, e por consequência para o produto, quando realizado de forma a motivar e construir novas competências nas pessoas.

Por definição, no contexto empresarial, feedback quer dizer “uma ação que revela os pontos positivos e negativos do trabalho executado, tendo em vista a melhoria do mesmo” [1]. Certa vez, tive oportunidade de ler um livro chamado “O seu balde está cheio?” (não se deixe levar pelo nome, o livro é bem interessante =P) onde uma metáfora interessante é realizada: “Todos nós possuímos um balde invisível que se enche ou se esvazia o tempo inteiro, dependendo do que os outros nos dizem ou fazem. Quando o nosso balde está cheio, nos sentimos ótimos. Quando está vazio, ficamos péssimos.” [2]. Ao ler o livro é possível perceber que este encher ou esvaziar do balde pode ser diretamente relacionado ao retorno que recebemos das pessoas em relação ao que fazemos e, quando esses retornos são positivos, nosso balde enche e nos sentimentos mais felizes e estimulados. Já quando são negativos, nosso balde esvazia um pouco. Mas será que as pessoas gostam ou querem saber quão cheio andam os seus baldes? Será que isso as motiva a melhorar realmente? E como a gente pode trabalhar esses retornos para que eles não tenham efeito contrário?

Bom, como primeiro passo, para tentar investigar um pouco mais essas questões, fiz uma pesquisa com as pessoas aqui da GPE com o intuito de entender como elas se sentem em relação aos feedbacks e se eles são realmente bem vindos ou não. Abaixo vou mostrar a vocês as principais conclusões retiradas a partir das respostas coletadas, que de certa forma descrevem diretrizes a seguir quando se pensa em criar uma política de feedbacks dentro da sua equipe ou empresa.

1. As pessoas gostam de receber feedbacks!

Não duvide! As pessoas gostam de receber feedbacks, principalmente quando são feedbacks positivos. Elas conseguem ver a importância do feedback no processo de crescimento profissional e entendem que receber esses retornos é necessário e válido. Portanto, vá em frente! O potencial para motivar sua equipe através desta estratégia está aí, basta saber como fazê-lo.

2. Elogiar sempre! Criticar não!

Como disse, elogios são bem vindos. E devem vir naturalmente, com sinceridade e, se possível, no momento em que as atitudes que geraram o elogio acontecem. As pessoas gostam de ser elogiadas e, na maioria dos casos, se motivam quando percebem que seu trabalho está sendo reconhecido.

O mesmo não acontece com críticas. Críticas são mais delicadas e é preciso analisar primeiro a melhor forma de dar esse feedback negativo. É preciso saber se a pessoa está aberta a receber tal crítica e, dado o contexto, qual é a melhor forma de repassar essa informação. Em qualquer dos casos, quando se há uma ideia de construir e colaborar através dos feedbacks, o ideal é que esse retorno seja feito individualmente, pessoalmente ou por escrito, para que a pessoa possa entender exatamente o que está acontecendo e não se sinta menosprezada em relação aos demais da equipe. E criticar toda hora também não funciona! Pode acabar até por desmotivar por completo a pessoa.

Por último, não esqueça da definição de feedback, críticas devem ser produtivas. Se for criticar por criticar, talvez seja melhor esperar e analisar um pouco melhor a situação.

3. E elogiar toda hora não acomoda?

Acredito que não. Acho que na maioria dos casos isso motiva as pessoas. Mas é claro que esta questão depende de cada um. Existirão aqueles que irão se motivar a continuar a melhorar e existirão aqueles que, de repente, irão se acomodar um pouco. Para esses casos, a própria estratégia de feedback tem potencial de resolver o problema, já que, provavelmente, no próximo feedback essa acomodação será apontada como um ponto negativo. Outra ideia é também a de criar um sistema de recompensa onde a pessoa se sinta estimulada a sempre fazer o seu melhor para alcançar um objetivo. Pode dar certo para algumas pessoas.

4. Quando criticar ofereça apoio, mas dê espaço.

No caso de feedbacks negativos, é importante que a pessoa perceba que ela tem o apoio da equipe e que pode contar com ela para melhorar seu desempenho em relação ao que foi criticado.

No entanto, nem todos são iguais e algumas pessoas podem preferir trabalhar nisso sozinhas. Então, ofereça apoio, se mostre disponível, mas dê o espaço necessário para que a pessoa analise seu próprio comportamento, entenda o que está acontecendo e te procure quando achar que chegou o momento certo.

5. Motive o feedback entre as pessoas da equipe.

Muitas pessoas se preocupam muito em conseguir um feedback da empresa ou em buscar um feedback do cliente, mas um retorno altamente valorizado é aquele que vem de quem está diariamente trabalhando com quem está recebendo essas informações. Por isso, estimule também o feedback entre as pessoas da equipe! Bons momentos para isso são as reuniões de Retrospectiva, mas antes, claro, é preciso avaliar se todos se sentem à vontade para realizar tal atividade. E para descobrir isso nada melhor que perguntar. A atividade “Safety Check”, que busca avaliar o quão confortável a equipe se sente para expressar o que pensa, pode ajudar nisso.

6. Se prometeu o feedback, cumpra!

Pode não parecer, mas é chato prometer feedback e não dar. As pessoas criam expectativas e de certa forma se desestimulam ao ver que o retorno esperado não veio. Quando existe uma política de feedback na empresa que prevê uma frequência definida, tente ao máximo cumprir esses prazos. Quando as pessoas esperam e isso não vem, a política acaba ficando até meio desacreditada.

E se não houver uma política pré-estabelecida, dê o feedback na hora! Nada melhor! =P

Como a gente pode perceber, essa questão é muito importante e deve ser tratada com cuidado. Da mesma forma que possui altíssimo potencial para estimular as pessoas a alcançarem melhores resultados, também pode desestimulá-las por completo. Então, antes de criar sua política de feedback e desenvolvimento de competências, procure entender como as pessoas se sentem em relação a isso. Pode ser um primeiro passo decisivo para que a sua estratégia comece com o pé direito ou não.

Nos próximos posts falaremos um pouco mais sobre esse assunto, relatando também quais foram nossas experiências com as primeiras iniciativas que tivemos aqui na empresa, mostrando algumas dinâmicas e estratégias que já utilizamos e como foi o resultado que obtivemos com elas.

Referências:

[1] Significados.com.br – http://www.significados.com.br/feedback/

[2] Editora Sextante – http://www.esextante.com.br/publique/cgi/cgilua.exe/sys/start.htm?infoid=1967&sid=2

The post Feedbacks, motivação e desenvolvimento de competências – Parte 1 appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Problema #1: O que entregamos não era o que o cliente esperava.

Esse problema é recorrente em muitos projetos de software. O Scrum já nos ajuda a evitar esse problema devido às constantes inspeções e verificações que são feitas junto ao PO, mas mesmo assim isso pode ocorrer. Pode ser que a pessoa que ficou responsável por descrever aquela demanda deixou de fora pontos que, na Sprint seguinte, podem gerar retrabalho ou até aquela sensação de “fazer tudo do zero”.

Então, para evitar ao máximo essa situação, é importante que as especificações de novas demandas sejam realizadas junto às pessoas que realmente tem conhecimento sobre o requisito. Em muitos casos essa pessoa é o próprio PO, mas não há problema algum em envolver, em uma reunião de planejamento, a área da empresa que está demandando aquela funcionalidade, por exemplo.

Trazer os interessados para as reuniões de Planejamento e Revisão faz com que o feedback e a troca de informações sejam mais rápidos e mais precisos. No final, as decisões continuam sendo do PO, mas ter a opinião de quem está diretamente envolvido com o negócio a ser tratado é muito importante e pode evitar uma série de ruídos que venham a surgir na comunicação entre interessados, PO, time de desenvolvimento e quem mais estiver envolvido.

Problema #2: Começamos a desenvolver sem ter todos os pré-requisitos definidos.

A definição de história preparada existe e deve ser respeitada. Muitas vezes as pessoas acabam passando por cima dela na intenção de antecipar o início do desenvolvimento de uma demanda devido à urgência da mesma. O problema disso é que o time de desenvolvimento acaba assumindo a existência de outros recursos e suas definições para prosseguir com o andamento da história, para ir de encontro à expectativa do PO de que fazer isso antecipará a entrega da demanda.

A questão é que, na verdade, essa estratégia pode até atrasar a entrega. Isso acontece porque diversas decisões são tomadas acreditando que existirá uma determinada estrutura de banco ou um determinado retorno de outro sistema, por exemplo, que não se concretiza. Assim, o time tem de lidar com retrabalho ou então com impedimentos que paralisam o andamento da história.

Por isso, estabeleçam e respeitem a definição de história preparada dos seus projetos. A ilusão de que começar a desenvolver sem ter todos os itens da definição prontos é realmente apenas uma ilusão e não trará bons frutos depois. Pelo contrário, pode até prejudicar o cronograma inicial estabelecido.

Problema #3: Fizemos do jeito que achamos que deveria ser, mas não era.

Esse é outro problema causado por “colocar a carroça na frente dos bois”. Se a história não está preparada e é iniciada, chegará um ponto em que a equipe terá dúvidas. Caso a resposta para essas dúvidas não venha, ou a história ficará impedida e paralisada, ou o time assumirá definições que nem sempre serão verdadeiras. Outro efeito colateral disso é que tomar decisões sobre assuntos que não se tem domínio gera extensa discussão desgastando a equipe e gerando longas reuniões ou longas trocas de e-mail.

Então, mais uma vez, vamos respeitar a definição de preparada!

Problema #4: Fizemos a funcionalidade e ninguém usa.

Isso acontece diversas vezes, infelizmente. E muitas vezes o esforço para criar aquela funcionalidade é bastante grande e acaba que, no fim, acaba sendo trabalho desperdiçado, pois ninguém usa aquilo. Outra ponto negativo é que se isso começa a acontecer com frequência, pode acabar desestimulando a equipe de desenvolvimento que espera ver seu trabalho ajudando o usuário e, no fim, descobre que aquilo nunca foi para frente.

Uma forma eficiente de acabar com este problema é envolver na especificação da demanda representantes dos usuários. Ninguém mais que eles têm conhecimento sobre o negócio e sobre as necessidades que eles têm em relação ao produto. É claro que eles não vão interferir em questões técnicas da criação da funcionalidade, mas contar com a opinião para ter detalhes sobre o funcionamento e as regras de negócio e validar, até mesmo antes de implementar, se é isso mesmo que ele espera, é fundamental para evitar este problema.

Problema #5: Ninguém sabe porque tal funcionalidade é assim.

Existe o mito de que agilidade está ligada à falta de documentação, mas isso não é verdade. Na realidade, é importante sim documentar para que exista um histórico de mudanças do produto e lá na frente, se for necessário, seja possível verificar e justificar por que determinadas funcionalidades funcionam daquela maneira.

A forma como essa documentação será realizada depende das definições de cada equipe Scrum. É legal definir isso com todos os envolvidos inicialmente e incluir essa documentação na definição de história pronta. Isso vai garantir que toda história finalizada tenha a documentação necessária criada, no nível de detalhe desejado e acordado previamente por todos. Assim a gente documenta o software, tem histórico e continua sendo ágil.

É claro que esses 5 pontos não vão resolver todos os problemas de especificação, retrabalho etc que existem em um projeto. Mas acredito que se seguirmos essas estratégias, é possível diminuir significativamente esses 5 problemas que acabam frustrando usuário e equipe Scrum.

The post 5 problemas recorrentes que você pode evitar ao especificar bem suas demandas appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Esta é uma questão polêmica, de difícil resposta e que divide opiniões. Será que uma Equipe Scrum pode realmente viver sem um Scrum Master? Há os que defendam que sim e os que imaginam que isso só é possível na teoria. Mas já que é possível na teoria, por que temos tantas dúvidas de que na prática também é possível?

A ideia de que o Scrum Master é "dispensável" pode ser concluída a partir da própria definição do seu papel. Essa definição diz que o Scrum Master é um líder-servidor e sua responsabilidade se resume em manter a Equipe Scrum no trilho do processo, buscando sempre alcançar melhorias que aumentem a qualidade do trabalho e, por consequência, a satisfação da Equipe Scrum com o produto que está sendo construído. Se o Scrum Master for espetacular, teoricamente, ele conseguirá levar sua Equipe a trabalhar sem a necessidade do seu apoio e, logo, se tornará dispensável. Essa é a teoria.

Na prática, esse objetivo de tornar a Equipe independente do Scrum Master encontra impedimentos que podem ser explicados pelo teoria de construção de um time, de Bruce Tuckman. Nessa teoria, a tarefa de construir um time passa por 4 estágios, são eles:

1. Forming: neste estágio, o time está começando a se conhecer, todos estão animados, positivos e querem construir um bom relacionamento com os demais. Nesse momento, o papel de um líder é essencial porque ainda há muita incerteza em relação à papéis e responsabilidades de cada um.

2. Storming: neste estágio, é normal surgir questionamentos aos objetivos estabelecidos, além de conflitos. Esses conflitos podem aparecer porque as características de cada membro da equipe começam a florescer e podem começar a surgir frustrações com o andamento do projeto ou com o processo de trabalho. Neste ponto, é preciso estabelecer claramente os processos de trabalho, os combinados e, de fato, começar a construir a relação de confiança que deve existir em um time.

3. Norming: agora o time começa a se ajustar, a resolver seus conflitos e estabelecer uma relação de respeito. As pessoas começam a se socializar mais, se ajudar mais e o compromisso com os objetivos do projeto aumenta. Neste momento, é bom começar a delegar atividades e deixar que as pessoas do time comecem a tomar responsabilidade pelo progresso atingido.

4. Performing: neste estágio é fácil ser parte do time, mudanças de equipe não alteram muito o desempenho e novos desafios são bem recebidos e vistos como mais um degrau a subir para alcançar o objetivo do time. É neste momento que o líder pode começar a se distanciar e focar em outros objetivos de trabalho. O time já está pronto para seguir com o bom trabalho que está sendo realizado.

Há ainda um último estágio, Adjourning, que é quando a Equipe é desfeita, seja porque o projeto acabou ou porque a Equipe foi desmembrada.

O que fica claro através dessa teoria é que, a medida que uma Equipe avança e amadurece, a necessidade da existência de um líder para direcionar o trabalho e lidar com problemas e conflitos é cada vez menor, porque a própria Equipe consegue se ajustar e se sair bem de situações inesperadas. Sendo assim, ainda na teoria, se temos uma Equipe que está "performando", ela pode sim sobreviver sem um Scrum Master porque ela será um time tão sólido e bem formado, que conseguirá seguir o processo Scrum e produzir valor sem o apoio de um líder-servidor.

Depois de tudo que foi exposto, eu volto a perguntar: dado que temos uma Equipe que já trabalha junto há bastante tempo, que já tem "no sangue" todos os conceitos do processo Scrum, que já está performando, será que essa Equipe pode viver sem um Scrum Master?

Na teoria sim, mas na minha opinião não. É claro que essa Equipe terá um nível de independência do Scrum Master muito maior e conseguirá seguir performando sozinha. O problema é que novos desafios sempre aparecem e, acima de tudo, a Equipe está comprometida com o produto e não com o processo. O processo é o meio que permite que eles atinjam o objetivo final estabelecido. O fato de não ter ninguém na Equipe com este foco pode fazer com que situações inesperadas desvirtuem a Equipe do processo de trabalho que está sendo bem realizado, e é possível até que isso leve a Equipe a regridir e deixe de performar.

É claro que essa é a minha opinião e opiniões divergentes sobre este assunto podem existir. Por exemplo, para você, até quando uma Equipe precisa de um Scrum Master?

Referências:

Scrum Guide

Forming, Storming, Norming, and Performing – Understading the stages of a team formation

The post Até quando uma Equipe Scrum precisa de um Scrum Master? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.