A entrada de um novo membro numa equipe é sempre um momento delicado tanto para a equipe quanto para quem está chegando. Para a equipe é uma mudança no status quo, uma possível mudança na dinâmica do time e para o novo membro é um terreno desconhecido, essa situação pode gerar certo desconforto se não for tratada com atenção. O sucesso na integração de um novo membro ao time é fator determinante na qualidade do ambiente e da produtividade do time daí em diante.
Infelizmente esse assunto não é tratado com a devida importância pela grande maioria das empresas que colocam seus novos profissionais em situações bastante difíceis até que eles mesmos possam caminhar com as próprias pernas. Quanto mais complexo for o projeto, mais atenção deve ser dada aos novos membros para que eles possam sentir-se a vontade para contribuir o mais rápido possível com sua nova equipe.
Lendo o blog do Patick Kua vi que ele também se interessa bastante pelo tema e isso me inspirou a escrever sobre algumas coisas que acho de grande importância no processo de integração de um novo membro ao time.
Nos próximos posts falarei mais sobre essas técnicas. Até mais!
O Daily Scrum sem dúvida é uma das reuniões mais importantes do Scrum, porém é a mais subestimada e negligenciada de todas. O Daily Scrum sincroniza toda a equipe, estimula a colaboração e faz com que todos percebam imediatamente quando algo começa a atrasar.
O blog ScrumLabs publicou uma lista de 10 dicas para um bom Daily Scrum.
1. Comecem o mais cedo possível, sempre no horário, sem esperar por ninguém. Definam a agenda do dia.
2. Limite a duração da reunião em 15 minutos – use algum tipo de alarme se necessário.
3. Levantem-se! Isso encoraja a brevidade entre os participantes e mantém todos acordados.
4. Mesmo lugar e horário todos os dias, de preferência na sala da equipe.
5. Organizem-se em formato de U em torno do taskboard, isso ajuda no contexto de quem estiver falando.
6. Jogue uma moeda para definir a ordem. Cara no sentido horário, coroa no sentido anti-horário.
7. Apenas os membros da equipe e o Scrum Master podem falar.
8. Não é necessário fazer as “3 perguntas”. Apenas criem a rotina de respondê-las.
9. Não comecem a resolver problemas durante a reunião. Façam isso após a reunião.
10. Anotem os impedimentos no taskboard para que o Scrum Master possa resolvê-los.
Além desses itens eu acrescentaria mais 2.
11. Se necessário, utilizem um token. Apenas quem estiver de posse do token poderá falar.
12. Criem penalidades para quem não estiver presente à reunião, algo que beneficie a equipe como um todo.
Todos os membros da equipe devem estar preparados para responder as 3 perguntas:
O que você fez desde a ultima reunião ?
O que você fará até a próxima reunião ?
Existem algum impedimento para a realização do trabalho ?
Imediatamente após a reunião a equipe atualiza o taskboard com o novo status das tarefas e os gráficos de burndown. Além disso os membros da equipe discutem os itens que foram levantados durante a reunião e que ainda precisem de mais esclarecimento.
Lembrem-se o Daily Scrum não é um Status Report para o Scrum Master, e sim uma reunião de sincronização e planejamento da equipe.
Ontem (26/06), convidado pela minha amiga Rebeka Maia, estive presente a um evento sobre design de interação com o usuário, organizado pelo UXrecife na Faculdade Marista.No fim do evento surgiu uma discussão sobre a necessidade de um programador aprender as atividades de um designer e de um designer aprender sobre as atividade de um programador. Isso me remeteu imediatamente a como as equipes Scrum devem se organizar. Os processos ágeis em geral valorizam a comunicação, ou seja, numa equipe multidisciplinar: designers, programadores, testadores, analistas, precisam interagir, precisam se comunicar e se todos não tiverem o mínimo de vocabulário comum, o trabalho pode se complicar. Durante o evento isso ficou muito claro no depoimento de todos.
Outra questão muito importante é que quando uma equipe tem seus papéis extremamente definidos e ninguém se envolve como nada fora da sua área de atuação, o que se vê é uma falta de colaboração dentro do time, onde cada uma faz o seu trabalho e passa para a frente sem se preocupar muito com o trabalho seguinte. Hum…, isso parece familiar, alguém falou Waterfall ?? Quando especializamos demais os membros de uma equipe, o que acontece é que criamos um pequeno waterfall onde não há colaboração entre as partes, onde cada “setor” da equpe faz seu trabalho e o “joga por cima do muro”, isso sem dúvida não é uma forma sadia de se trabalhar.
Toda a equipe deve ter o mesmo objetivo, entregar o produto, e não somente, “entregar o design” ou “entregar o código” ou “testar” e cada membro da equipe deve fazer o possível para que o objetivo maior seja atingido e não se limitar apenas ao seu título.
Durante o TED de fevereiro de 2006, Sir Ken Robinson fez uma apresentação sobre educação e criatividade. Sem dúvida é uma das melhores apresentações que já assisti, são 20 minutos realmente inspiradores.
A Nokia é uma das empresas que mais investem em Scrum no mundo e eles desenvolveram um teste simples para verificar se uma equipe está efetivamente o usando o Scrum ou só utilizando o vocabulário do Scrum, mas trabalhando da forma errada.
O teste é constituído de uma série de perguntas divididas em duas etapas, a primeira etapa foca no desenvolvimento iterativo. As perguntas são:
-As iterações devem ter um tempo menor do que quatro semanas.
-O software deve estar testado e funcionando ao fim de cada iteração.
-A iteração deve começar antes que toda a especificação esteja pronta.
A segunda parte foca no Scrum propriamente dito. As perguntas são:
- Existe um Product Owner definido.
- Existe um Product Backlog priorizado por valor de negócio
- O Product Backlog tem estimativas criadas pela equipe
- A equipe gera gráficos de burndown e sabe a sua velocidade
- Não existem gerentes atrapalhando e interrompendo o trabalho da equipe.
Acho o Nokia Test uma forma interessante e bem simples de verificar se um empresa realmente tentou adotar o Scrum, e não simplesmente usar o buzzword, mas não realizar as práticas corretamente. Claro que o Nokia Test não é completo, algumas coisas que acho muito importantes ficaram de fora, como por exemplo, as retrospectivas, mas acho que a simplicidade do teste é sua grande vantagem. Os tópicos cobertos no teste são o mínimo necessário e acredito que os critérios do teste também estão de acordo com os princípios do Scrum. Obviamente o teste não é uma unanimidade, alguns discordam dos critérios adotados, mas o importante é que concordando ou não, sem dúvida algum tipo de validação do processo é necessária para comprovar se uma equipe está realmente usando Scrum ou só falando Scrum.
Fui convidado pelo Boris para seu programa de mentoring, ou seja, vou auxiliá-lo em treinamentos de Certified Scrum Master sempre que possível, como foi o caso do treinamento do INdT. A cada treinamento terei uma participação mais ativa, apresentando uma maior parte do conteúdo, até que eu possa me tornar um Certified Scrum Trainer.
O SPIN Recife organizou no dia 23/05 um evento muito interessante sobre o uso de SCRUM em ambientes CMMI. O evento contou com a participação de vários palestrantes do Brasil todo e também do Boris Gloger, Certified Scrum Trainer.
Destaco as palestras do Felipe Furtado e Izabella Lira que apresentaram um case de utilização do Scrum no C.E.S.A.R. com CMMi, a palestra do Danilo Bardusco da Globo.com também apresentando seu case de utilização de Scrum, fiquei realmente impressionado como a Globo.com abraçou o Scrum, inclusive mudando até seu mobiliário para se adequar melhor as idéias de colaboração da equipe, também gostei da palestra da Ana Sofia sobre o SCRUMMI, um processo que utiliza conceitos de Scrum sendo mais aderente ao CMMI e por fim a palestra do Boris mostrando que na essência Scrum e CMMi buscam as mesmas coisas mas que diferem nas implementações.
Parabenizo a Teresa Maciel do SPIN Recife pela iniciativa e pela excelente organização do evento.
No dia 22/05 o Boris Gloger apresentou seus segredos de como montar um treinamento Scrum de sucesso. A idéia de montar esse pequeno treinamento informal aqui em Recife surgiu de algumas conversas que tive com ele por email, ele já havia feito algo semelhante na Globo.com no início do ano.
O treinamento foi muito interessante, aprendemos como planejar nossas apresentações, entendemos a diferença entre uma apresentação simples, um treinamento e uma consultoria. Entendemos o porquê da estrutura do treinamento de CSM.
Foi sem dúvida um treinamento muito rico e me ajudará bastante na minha jornada para me tornar um CST.
Quero agradecer ao Boris por ceder seu tempo para essa conversa e aos que participaram: Daniel Fernandes, Felipe Furtado, Rogério Raposo, Raony Araújo e Teresa Maciel
Nos dias 20 e 21 tive a grande oportunidade de trabalhar como assistente do Boris Gloger durante um treinamento de CSM para equipes do Instituto Nokia de Tecnologia, pude inclusive apresentar uma pequena parte do conteúdo no início do primeiro dia.
Foi interessante acompanhar o treinamento por outra perspectiva, já conhecendo a mecânica de cada atividade pude ajudar as equipes com as dúvidas que surgiam durante a execução. Além disso, pude também rever todo o conteúdo do treinamento e pude absorver ainda mais o que estava sendo passado, pude tirar mais dúvidas, pude entender melhor os conceitos, pude ver onde posso melhorar como Scrum Master e claro, puder ver mais uma vez como esse treinamento é importante para quem vai implantar o Scrum em sua empresa, só por isso já valeu demais.
A turma da Nokia foi realmente muito divertida, eles pareciam mesmo se engajar nas atividades e realmente pareciam interessados no conteúdo do treinamento, aproveito o momento para mandar um abraço a todos e agradecer ao Marco Mafra da Nokia por permitir a minha participação.
Ontem (26/06), convidado pela minha amiga Rebeka Maia, estive presente a um evento sobre design de interação com o usuário, organizado pelo 
