O novo Guia do Scrum – Scrum Guide 2020 – está nas ruas, e disponível em vários idiomas. E o que isso significa para você? Depende de três fatores:

    • Você realmente usa o Scrum?
    • O quão aderente você é ao framework?
    • Suas equipes têm dificuldade em lidar com os conceitos do Scrum?

As repostas a essas perguntas determinam o quanto essa nova versão do guia pode ter influência no que você e sua equipe fazem.

No dia do lançamento os autores, demais responsáveis e diversos especialistas fizeram algumas lives sobre a nova versão. Participamos de algumas para colher visões diferentes e opiniões sobre o assunto.  Vamos discorrer sobre as principais mudanças e ao final discutir um pouco o que ocorreu.

O Novo Guia

O guia propriamente dito encolheu. Saiu de mais de 20 páginas para 16. Além disso, foi lançado com o propósito de democratizar o Scrum, ou seja, a linha mestra de seu lançamento foi a sua redução e alguns ajustes que foram feitos para permitir que o guia seja utilizado por outras atividades que não desenvolvimento de software. Ou seja, a principal ideia da redução do tamanho, e que também se manifestou em outros aspectos, é tornar o guia menos prescritivo, focando mais em sua essência ágil. Um exemplo claro disso é o caso da Reunião Diária. Em sua nova versão desaparecem as 3 perguntas basilares dessa reunião – o que fiz ontem, o que farei hoje e obstáculos encontrados – para focar na sua essência como uma reunião de micro-planejamento de atividades.

Da mesma forma, os autores acreditam que as modificações agora introduzidas tornam o guia mais abrangente, no sentido de comtemplar outras áreas, que não somente a TI, visto que atualmente o Scrum já é largamente utilizado em outras atividades que não sejam desenvolvimento de software.

As seguintes alterações realizadas merecem destaque.

Time

Agora temos somente um time: o Time Scrum. Anteriormente o Time era definido por um PO, um SM e o Dev Team (ou time de desenvolvedores). Em sua nova versão, o Dev Team dá lugar aos “Devs” (desenvolvedores). Assim, um Time Scrum passou a ser formado por PO, SM e Devs. Time agora só existe um. Uma tentativa de diminuir as barreiras internas e aumentar o comprometimento do grupo como um todo, promovendo a coesão.

Papéis e Responsabilidades

Seguindo a mesma toada, os papéis que já eram definidos por responsibilities agora se resumem a accountabilities.  Em português ambos os termos seriam definidos como responsabilidades. No entanto, segundo os autores, o termo Papel (Role) foi removido pois estava sendo incorretamente usado como cargo em muitas organizações. De certa forma me parece que novamente se buscou a flexibilidade. Ao remover o Papel e definir responsabilidades para participantes do time, abriu-se também a possibilidade de haver outras responsabilidades associadas aos participantes do Time, além das definidas no guia. Entretanto, o Time continua sendo formado por um PO, um SM e Devs.

A Meta do Produto

Visando evitar que o Time seja um fabricante de features simplesmente, rodando Sprints com o objetivo de executar o máximo possível de trabalho, eventualmente perdendo a perspectiva de real valor para o cliente, o guia agora introduz o conceito de Meta do Produto. A Meta do Produto serve para manter o time orientado ao que efetivamente o cliente deseja – Foco.

Ao mesmo tempo, isso permite também a criação de boas Definições de Concluído – DOD (Definition of Done) – utilizadas para avaliação do incremento do produto, visto que devem ser sempre criadas com a visão do atingimento da Meta do Produto.

O guia agora deixa claro que para cada um dos artefatos seguintes há uma orientação associada: Product Backlog orientado à Meta do Produto; Sprint Backlog orientado à Meta da Sprint; e Incremento orientado à Definição de Concluído. Se você usar o Scrumhalf, já tem lugar para tudo: Product Goal na descrição do projeto, Sprint Goal na descrição da Sprint, e DOD nas configurações do seu projeto.

Ainda no mesmo caminho, o de dar transparência e gerar foco, o guia passa a incluir no planejamento de uma Sprint, além das costumeiras questões de o que fazer e como fazer, a necessidade de se mostrar o porquê fazer. Isso demonstra o compromisso do Scrum em promover o alinhamento de todo o Time em uma só direção.

Auto-gerenciamento

Em suas versões anteriores o guia definia que a equipe, ou os Devs, eram auto-organizados. Desta feita, o guia passa a definir a equipe como auto-gerenciada, de certa forma estabelecendo que a própria equipe pode definir quem executará cada uma das tarefas. Talvez passe só como uma reescrita, mas pode vir a ter outras consequências. Vamos ver como será o impacto dessa mudança, se houver.

Nossa Impressão

É sem dúvida louvável a redução do tamanho do guia, bem como a intenção de torná-lo menos prescritivo. As mudanças de uma forma geral são simples e eficazes, mesmo que sejam de certa forma somente uma nova roupagem para práticas existentes, como no caso da mudança de auto-organizada para auto-gerenciada.

A grande decepção, no entanto, ficou por conta da abrangência do guia, principalmente no que diz respeito ao linguajar utilizado. Durante o seu lançamento, tivemos a oportunidade de perguntar, por exemplo, “porque o guia insistia em Devs, se isso é um termo exageradamente TI”. A resposta veio bem aquém do que se esperava. Os debatedores alegam que vários Times de diversas áreas foram consultados e que os profissionais se consideravam Devs, ou seja, desenvolvedores, porque desenvolvem algum tipo de produto ou serviço. Sinceramente, não convenceu. Agilistas que trabalham com equipes que não são de desenvolvimento de software sempre encontram dificuldade ao ter que utilizar termos diferentes do que está definido no Scrum, para poderem melhor adaptar o framework à realidade de suas áreas. Uma real modificação nesse sentido seria muito bem vinda.

Finalmente, considerando o mercado atual e a própria organização do trabalho no Scrum, o efeito da remoção dos papéis, substituindo-os por responsabilidades somente, terá pouco efeito prático, em nossa opinião. Acabará servindo para patrocinar acaloradas discussões na rede, pelo menos. Basta, p.ex., dar uma olhada nessas definições de responsibilities e accountabilities.

Espero que o feedback dos utilizadores venha a influenciar uma próxima versão do guia, tornando-o realmente mais adequado a outras áreas profissionais.

Você já leu o novo guia? O que achou?