Detalhes de retrospectivas são assuntos privados?
Durante uma Sprint Retrospectiva, os membros da equipe reúnem e discutem suas oportunidades de melhoria. O Scrum Master e o Product Owner também devem participar da retrospectiva, já que fazem parte da equipe. Os membros da equipe não precisam se limitar a melhorias nos seus processos. Podem, por exemplo, decidir desenvolver suas habilidades em relação a uma determinada tecnologia ou aproveitar outras oportunidades de formação.
No entanto, as equipes frequentemente não têm certeza se devem compartilhar as melhorias identificadas com outros ou se é melhor mantê-las para si.
Na minha opinião, o ideal é que os resultados das retrospectivas de todas as equipes sejam sempre compartilhados com outros. Afinal, a transparência é um dos pilares sobre os quais o processo Scrum é construído. Mas mesmo que eu acolhesse muito bem uma cultura de abertura, onde tudo pode ser compartilhado com todos, isso infelizmente acontece muito raramente.
Percebi que a maioria das equipes Scrum não tem problemas em tornar públicos a maior parte dos pontos de melhoria identificados na Retrospectiva. Esses itens são coisas previsíveis com as quais outras equipes ágeis na organização também se ocupam: melhorar em uma determinada área, aprender algo específico ou descobrir como conseguir fazer mais ou como realizar certas coisas mais cedo no Sprint.
De vez em quando acontece de uma equipe não querer compartilhar algo com outras pessoas
Estes são alguns exemplos que eu mesmo já presenciei:- A equipe quer aprender uma nova tecnologia que não se encaixa totalmente na direção da empresa, mas que parece tão promissora que a equipe quer experimentá-la mesmo assim.- O código em uma parte do sistema precisa ser organizado, o que o Product Owner também sabe, mas por certas razões não se quer divulgar que ele está tão ruim e que um alto nível de refactoring é necessário.- A equipe quer descobrir como colaborar melhor com outro grupo, cujos membros, se lessem isso aqui, perguntariam por que exatamente o relacionamento precisa ser melhorado.
Quero enfatizar novamente que, embora a transparência seja extremamente vantajosa para equipes ágeis, nem todas as equipes chegaram a esse ponto ainda. Enquanto talvez queiram manter os resultados das suas próximas retrospectivas para si, podem trabalhar para conseguir se abrir melhor no futuro.
Quando se torna pública uma melhoria planejada, isso pode influenciar a capacidade de realizar essa melhoria. É o caso, por exemplo, do último exemplo mencionado acima.
Anunciar que se quer melhorar a colaboração com o Marketing pode levar a que lá se resista a essa mudança ou que queiram saber o que exatamente não está bem e por que uma mudança é desejada.
(Claro que também poderia ser que estejam abertos à melhoria do relacionamento. Por isso, eu sempre discutiria a situação com alguém desse grupo.)
Simplesmente perguntar na Retro
A equipe tem então, no final do Sprint, uma lista de mudanças desejadas, acordadas em conjunto. Eu sempre pergunto à equipe se alguém tem algo contra publicar essa lista. Se não houver objeções, coloco essa lista na porta da sala da equipe ou na homepage da equipe.
Se houver objeções, muitas vezes basta simplesmente remover esse item da lista pública.
No final das contas, as equipes Scrum devem ter a coragem de tornar transparentes o máximo possível das suas melhorias planejadas. No entanto, em certos casos é vantajoso manter um ou outro item da retrospectiva para si.
