Artigo escrito por: Pilar Sanchez Albaladejo, PMP, CSM
Você encontra ele em: https://www.linkedin.com/pulse/uma-r%C3%A1pida-reflex%C3%A3o-sobre-o-scrum-pilar-sanchez-albaladejo-pmp-csm/
Uma rápida reflexão sobre o Scrum
Depois de ver a Alemanha, campeã da Copa de 2014, falhar miseravelmente na primeira fase desta Copa de 2018, fiquei me perguntando se um dos melhores frameworks para gestão de projetos de ágeis, o Scrum, também poderia falhar dessa forma. Este artigo é uma rápida reflexão sobre o assunto.
O Scrum é um framework para organizar e gerenciar trabalhos complexos, tal como projetos de desenvolvimento de software; e as equipes que o implementam raramente se dão mal. No entanto, é errado supor que existem milagres, ou seja, que o Scrum vai remover todo e qualquer tipo de impedimento e problema que apareça durante o curso do projeto. Armadilhas existem e podem ser fatais se o time não souber lidar com elas, e as mais comuns são:
“Preciso de uma ferramenta que controle inclusive o lançamento de foguetes!”: o Manifesto Ágil defende que as ferramentas não são importantes (“Indivíduos e interações mais que processos e ferramentas”). Encontrar a ferramenta apropriada é apenas uma forma de procrastinar o início do desenvolvimento. Não tem um software no estilo Jira? Comece colando post-its na parede e fazendo o gráfico de Burndown em uma cartolina. O cliente não quer saber que ferramenta você vai usar para controlar o projeto, ele quer o produto dele pronto o quanto antes.
“Dê-me a visão além do alcance!”: não adianta perder tempo tentando planejar todo o Backlog do Produto em detalhes com muita antecedência, a não ser que você seja da área da construção civil (afinal, normalmente o cliente sabe definir bem como vai querer a casa…bom, normalmente sabe). Mas, se você é da área de desenvolvimento de software ou de produtos inovadores, a recomendação é: comece a desenvolver o quanto, assim o feedback coletado durante as reuniões de Revisão e Retrospectiva da Sprint irão fornecer uma importante indicação de que o que está sendo feito está no rumo correto e que está acrescentando algum valor para o cliente. Obviamente espera-se que exista um mínimo de planejamento para o início dos trabalhos…afinal, não há necessidade de sair como uma Kombi desgovernada gerando código e deploys.
“Daqui eu não saio, daqui ninguém me tira!”: a Daily Scrum (reunião diária) NÃO foi idealizada para discutir problemas nem para encontrar as soluções para esses problemas. As 3 famosas perguntas (“O que você fez ontem?”, “O que você fará hoje?”, “Há algum impedimento no seu caminho?”) têm que ser formuladas pelo Scrum Master e os membros do time têm que se ater a responder exatamente ao que foi perguntado. Qualquer outro assunto deve ser tratado em outro momento. Quando? A equipe deve decidir quando e como tais problemas podem ser discutidos. Se isso não for feito, a sua reunião diária nunca terá os 15 minutos previstos.
“Manda quem pode, obedece quem tem juízo!”: o Scrum prescreve que as equipes sejam auto-organizadas; sendo assim, não há necessidade de coordenadores ou gerentes de projeto dando ordens. O Scrum não prevê a existência do papel do gerente de projeto, mas se mesmo assim a sua empresa tem, apenas tenha em mente que as tarefas devem ser alocadas pelos próprios membros do Time de Desenvolvimento. O Dono do Produto estabelece a prioridade das entregas juntamente com o time e os membros desse time é que decidem como e por quem o trabalho será feito.
“Mas ele SÓ faz isso?!?”: o Scrum Master é um papel especializado, ou seja, um Scrum Master deve ser um observador e um facilitador, não um desenvolvedor ou um testador. Embora tenha visto por aí desenvolvedores acumulando a função, isso não é recomendado, já que com certeza ele não vai conseguir cumprir nenhuma das duas funções com eficiência. Além disso, ele não deve orientar a equipe sobre o que fazer e o que não fazer, pois isso quem faz é a própria equipe. A função do Scrum Master é garantir que todos os artefatos e cerimônias (ou eventos) estejam sendo realizados conforme prescrito pelo framework.
“Isso precisa estar pronto amanhã! Se vira, você não é quadrado!”: as equipes Scrum sabem melhor o que completar em uma determinada Sprint, portanto, nem as partes interessadas nem a gerência devem tentar impor prazos ou prescrever recursos, pois isso não só desmotivará a equipe, como também reduzirá sua produtividade. É claro que é impossível trabalhar sem datas previstas, afinal o cliente está pagando e quer saber quando vai começar a receber o produto. O que se deve ter em mente é que o Time de Desenvolvimento em comum acordo com o Dono do Produto indica o que será entregue conforme prioridades acordadas com o cliente.
“De lá pra cá, de cá pra lá”: o Scrum prefere equipes co-alocadas, pois a distribuição dos membros impede a comunicação direta e aberta, o que, por sua vez, reduz a produtividade e a qualidade do trabalho desenvolvido. Isto não quer dizer que o Scrum não funciona com times distribuídos, mas se você NUNCA utilizou o framework antes, aplique-o primeiro com uma equipe local, aprenda (e sofra um pouco) antes de tentar aplicá-lo em uma equipe distribuída.
“Apertem os cintos, o Dono do Produto sumiu!”: a presença do Dono do Produto é essencial. Embora não seja obrigatório que ele participe das Reuniões Diárias e das Retrospectivas é interessante que ele esteja por perto, já que ele é a ponte entre a equipe técnica e as partes interessadas. Mas veja que ele não pode conduzir esses eventos.
“Um pastel de carne e outro de queijo, por favor!”: como o Scrum segue o modelo iterativo e incremental de desenvolvimento, a equipe decide antecipadamente o que fazer em uma Sprint. Como tal, nem a gerência nem as partes interessadas devem acrescentar mais trabalho depois que a Sprint começou. Raras são as exceções em que isso seria permitido. Assim, acrescentar novas tarefas a todo instante vai sobrecarregar o Time de Desenvolvimento com mais trabalho. Esse time terá menos tempo para entregar o que já havia sido combinado e como resultado haverá menor eficiência e aumento do ressentimento de seus membros.
“Eu sou eu, vocês são os outros e só…”: o Scrum acredita no ditado que diz: “Se quer ir rápido, vá sozinho. Se quer ir longe, vá em grupo.” Assim, “estrelismos”, horas-extras (desnecessárias) e heroísmos individuais devem ser desencorajados, porque vão causar ressentimentos e conflitos. É impressionante como o comportamento de apenas um indivíduo é capaz de desestabilizar uma equipe inteira.
“O Dono do Produto programa melhor que você”: por melhor desenvolvedor de software que (possivelmente) seja o Dono do Produto, quem deve especificar a solução técnica são os membros do Time de Desenvolvimento. Isso ocorre porque a equipe está bem versada nos aspectos técnicos do software em desenvolvimento. E como o Scrum prescreve: a equipe é auto-organizada e sendo assim é ela que deve decidir como fazer o seu trabalho.
“Não quero ir pra escola!”: o Scrum acredita no desenvolvimento evolucionário, e isso requer aprendizado constante por parte dos membros da equipe; no entanto, muitas vezes eles deixam de aprender e adquirir conhecimento sobre os processos e técnicas porque acham que já são especialistas e que não há mais nada a ser aprendido (= acham que chegaram no nível “Jedi”). No entanto, deve ser encorajada a postura “Padawan”, que tem a humildade de acreditar que ainda falta muito a aprender.
“Tão te chamando lá na esquina!”: uma equipe Scrum é uma equipe de alto desempenho, e sendo assim, é aquela que desempenha sempre bem suas atividades e coopera para o crescimento profissional dos envolvidos e para o desenvolvimento da empresa. Formar uma equipe desse tipo leva tempo, portanto deslocar os membros com frequência não apenas reduz a eficiência e a produtividade, mas também desmotiva os seus membros.
Existem outras armadilhas, mas essas são as mais comuns e que devem ser evitadas. Tenho visto muitas empresas buscando a “solução mágica” no Scrum, e que não estão obtendo o resultado esperado por estarem justamente sendo pegos de surpresa por elas.