The post (Português) Feedbacks, motivação e desenvolvimento de competências – Parte 3 appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post (Português) Feedbacks, motivação e desenvolvimento de competências – Parte 2 appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 (Português) Feedbacks, motivação e desenvolvimento de competências – Parte 1 appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 ScrumHalf Blog - Agile and Scrum Software - Brazil.

This is a controversial question, difficult to answer and which divides opinions. Can a Scrum Team really survive without a Scrum Master? There are those who argue that yes and those who imagine that this is possible only in theory. But since it is possible in theory, why do we have so many doubts about it being possible also in practice?

The idea that the Scrum Master one day will be no longer necessary can be deduced from the very definition of the role. This definition says that the Scrum Master is a servant-leader and his responsibility boils down to make sure that the team adheres to the Scrum process, always seeking to achieve improvements that increase the quality of work and, consequently, the satisfaction of the Scrum Team with the product being built. If the Scrum Master is spectacular, theoretically, one day his team will be able to work without the need of his support and thus he’ll become unnecessary. That is the theory.

In real life, this goal of making the Team independent of the Scrum Master runs into some impediments that can be explained by the team building theory, by Bruce Tuckman. In this theory, the task of building a team goes through 4 stages, they are:

1. Forming: on this stage, the team is getting to know each other, everybody is excited, positive and want to build a good relationship with others on the team. At this moment, the role of a leader is essential because there is still too much uncertainty about the roles and responsabilities of each person.

2. Storming: on this stage, it is common to arise questionings about the goals established and also some conflicts. These conflicts may come up because each member’s characteristics start to show and there may be some kind of frustation about the project or the work process. At this point, it is crucial establishing the work processes clearly, create team agreements and, indeed, start to build the trust that must exist within a team.

3. Norming: now the team starts to adjust, solve their conflicts and respect one another. People start to socialize more, help each other more and the commitment to the project’s goals grows. At this moment, it is good to start delegating activities and let team members take responsability for the progress achieved.

4. Performing: on this stage, it becomes easy being part of this team, changes on the team don’t affect the performance and new challenges are seen as a good thing toward the team’s goal. At this point, the leader starts to take a step back and to focus on other work goals. The team is ready to keep up with the good work on their own.

There is still one last stage, Adjourning, that happens when the team is disbanded.

What is clear from this theory is that, as a team progresses and matures, the need of a leader to direct the work and deal with problems and conflicts decreases because the team itself can adjust and do well in unexpected situations. Thus, in theory, if a team is performing, it can survive without a Scrum Master because it is such a strong and well-trained team that it will be able to follow the Scrum process and produce value without the support of a servant-leader.

After everything is said, I ask you again: given that we have a Team that works together for a long time, that has the concepts of the Scrum process in mind, that is already performing, can this Team survive without a Scrum Master?

In theory yes, but in my opinion no. It is clear that this team will have a great level of independence and will be able to perform alone. The problem is that new challenges always appear and, above all, the team is committed to the product and not the process. The process is the means that allows them to reach the ultimate goal established. The fact of not having anyone in the team that focus on it may cause unexpected situations to mislead the team from the work that is being well done, and it might even take this team to regress and fail to perform.

But that is, of course, my opinion and there are plenty of different ones about this subject. For example, to you, until when a Scrum Master is needed?

References:

Scrum Guide

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

The post Until when a Scrum Master is needed? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.