Recentemente deparei com um artigo que me chamou a atenção. Here’s Why Many Developers Hate Scrum, ou Porque Muitos Devs Detestam Scrum, faz uma análise do trabalho no Scrum, indicando, principalmente, um aumento de carga para o Dev, em função das necessidades criadas pelo uso do framework Scrum. Por mais interessante que tenha achado o artigo, e realmente é interessante, percebi vários pontos de discordância, ou que mereciam uma elucidação, o que acabou me levando a também fazer uma análise semelhante. Não há a intenção de criticar negativamente o seu autor, nem a sua opinião, inclusive porque foi graças a ela que desenvolvi essa, vamos dizer, análise complementar. Acredito que um outro olhar sobre o problema apresentado pode ajudar aos Devs que vivem esse dilema.

Acho que realmente alguns Devs têm a visão alinhada com o expressado pelo autor no seu artigo, e, por isso, resolvi debater um pouco mais os tópicos por ele elencados. Entendo que algumas pessoas possam realmente encontrar nesses tópicos motivos para “detestarem” o Scrum, mas acredito que uma outra visão sobre tais razões possa transformar esse ódio em amor.

A análise feita por Willem-Jan Ageling, autor do artigo, foca em novas responsabilidades encaradas pelo Dev ao trabalhar usando Scrum. Melhor então darmos uma olhada nessas “novas” responsabilidades, dissecando o problema para entendê-lo melhor.

  • No Sprint Planning – Determinar uma meta do Sprint, em cooperação com o Product Owner. A equipe de desenvolvimento precisa avaliar se eles podem cumprir a meta do Sprint, pois isso impulsiona o Sprint

Será que existem equipes tradicionais, ou não-ágeis, onde o gerente não pergunta sobre prazos, ou o que será possível ser feito até determinada data de entrega? Sinceramente, nunca vi isso acontecer. Muito pelo contrário. Sempre presenciei esse questionamento ser feito de forma repetitiva, gerando inclusive discussões acaloradas, e roubando o tempo, e muitas vezes a tranquilidade, do time. Essa questão nunca pode ser abandonada, pois não há como uma organização, que estabelece metas e objetivos, trabalha com KPI e OKR, não ter alguma ideia de quando chegará aonde. Na verdade, acho que o Scrum ajuda muito o time nesse sentido, definindo um momento específico para tal discussão, de certa forma limitando-a, e evitando que roube mais tempo do time.

  • No Sprint Planning – Criar um Sprint Backlog. Isso envolve selecionar os itens do Backlog do produto que ajudam a cumprir a meta do Sprint e criar um plano para entregá-los.

Na realidade, entendo que o Dev Team somente ajuda o PO, ou esclarece suas dúvidas, para que ele selecione as histórias a serem contempladas. É de interesse maior do PO e de sua responsabilidade definir uma meta com o time e definir o que será feito para cumprir tal meta. Já com relação ao plano necessário, acredito que haja dois aspectos. O primeiro é que essa prática de planejar o que irá ser feito no curto prazo é extremamente produtiva. De uma forma geral, ela evita o “hacking”. Ou não conhecemos Devs que ao ouvir a primeira notícia sobre alguma necessidade do cliente já querem sentar e sair programando? Esse pequeno planejamento, ajuda sensivelmente a evitar o efeito toupeira e fomenta a colaboração e a coordenação entre os membros do time, sob pena de ao não fazê-lo gerarem retrabalho e terem muita dificuldade de coordenação. Ou seja, na minha visão, tal responsabilidade sempre existiu. Apenas, algumas pessoas, ou times, esquecem da sua necessidade e acabam pagando um alto preço posteriormente.

  • Durante a Sprint – Garantir que os Itens do Backlog do Produto atendam à Definição de “Done” (DoD) e aos critérios de aceitação.

O time poderia trabalhar de forma diferente? Isso me parece ser inerente ao trabalho do Dev. Senão deixou o Dev de estar trabalhando para satisfazer a necessidade de algum cliente, para ser um diletante.

  • Durante a Sprint – Certificar-se de que o Backlog do Sprint sempre mostra o estado atual do progresso do trabalho nos Itens do Backlog do Produto e no plano da Sprint.

Essa responsabilidade não me parece trabalho extra, mas somente uma questão de disciplina, atenção ao framework e utilização de ferramenta adequada. A reunião diária, já prevista no Scrum e que não deve ser abandonada, já tem como parte do seu escopo a apresentação do fiz, farei e problemas. Isso, por si só já permite uma atualização da situação dos trabalhos. Se, adicionalmente, o time usar uma ferramenta para acompanhamento, como o próprio Scrumhalf faz, onde as tarefas trabalhadas sejam atualizadas pelo próprio realizador e gerem automaticamente informações, como o gráfico de Burndown, a transparência e a visibilidade ficam garantidas, sem nenhum esforço extra.

  • Na Daily Scrum – Avaliação diária do progresso em direção ao objetivo do Sprint. Isso inclui a atualização do plano conforme refletido no Sprint Backlog.

Realmente, a Reunião Diária – Daily Scrum – é algo que toma um tempo do time. Mas, no entanto, esse tempo, que deve ser muito curto, em torno de 15 minutos ou menos, seria muito maior caso o projeto contasse com um gerente formal e os membros do time tivessem que fazer seus relatórios de andamento para ele. Adicionalmente, é fundamental lembrar que a Reunião Diária é o que viabiliza a auto-organização do time, diminuindo os tradicionais atritos com a gerência e aumentando a satisfação no trabalho.

  • Na Revisão da Sprint – Discutir a Meta da Sprint e como eles conseguiram alcançá-la.

Isso realmente não é algo comum fora do Scrum. Entretanto, além de tal discussão não dever tomar muito tempo, deve-se lembrar que, entre outros motivos, essa discussão promove a transparência e acaba evitando, ou substituindo, as constantes discussões e debates do time com a gerência, quando usando uma gestão não-ágil.

  • Na Revisão da Sprint – Mostrando o que eles criaram e respondendo perguntas.

Nunca vi isso ser deixado de lado também. O Dev não pode só codificar e esquecer. A não ser que hajam outros membros para fazer a demonstração das funcionalidades implementadas, anotação de eventuais bugs, etc. A vantagem no Scrum é que isso é feito de forma organizada, mais rápida, e contando com a participação de todo o time permite que todos fiquem atualizados, reduzindo a solução de continuidade no trabalho em tarefas subsequentes.

  • Na Revisão da Sprint – Participar da discussão sobre o que fazer a seguir.

Apesar de sempre ter promovido esse tipo de discussão nos projetos que participei, especialmente nos que gerenciei, antes da agilidade, reconheço que muitas vezes o time é deixado de lado no momento dessa discussão. No entanto, em função disso, é normal o time perder muito tempo depois, reclamando e discutindo porque algo está sendo feito. Ou seja, o exercício de pensar o que deve, ou deveria, ser feito é efetivamente realizado. A grande diferença aqui é que o dev poderá exteriorizar o seu pensamento e ouvir o dos demais companheiros. E, deve-se lembrar, a responsabilidade, como a maioria delas no Scrum, é coletiva, do time, não individual.

  • Na Retrospectiva da Sprint – Inspecionar como foi a Sprint e criar um plano de melhorias.

Essa realmente é diferente. Kaizen, ou melhoria contínua, é uma responsabilidade que o Scrum leva muito a sério. Demanda um pequeno tempo do time, mas traz benefícios enormes, inclusive permitindo que ao longo do tempo cada vez mais o Dev foque na sua atividade principal, visto que o “processo” em si está funcionando bem. Cabe ao Scrum Master tornar essa cerimônia produtiva e agradável. Seus resultados, que em um caminho não-ágil também deveriam ser apontados por uma boa gerência, sempre serão implementados da mesma forma, independente do modelo de gestão. Quero dizer com isso, que se algo precisar ser mudado, revisto, terá que sê-lo. E alguém terá que fazer o serviço.

  • Criação e manutenção da Definição de “Pronto”.

Verdade. Agora o time deve se preocupar com isso. Mas vejamos bem. A definição de pronto, pelo menos na cabeça do Dev, já existe. Senão, como ele iria parar de trabalhar em algo? A diferença aqui é que agora o time, frisando que é o coletivo, deve criar uma definição compartilhada, que seja entendida por todos. E, na verdade, isso que inicialmente pode parecer algo pesado, após negociado evita uma série de conflitos e é de fácil manutenção, podendo, p.ex., ser um subproduto, quando necessário, da Retrospectiva.

  • Aprender, explorar e incorporar os Valores Scrum de Coragem, Compromisso, Foco, Abertura e Respeito.

Isso só ocorre, ou pelo menos de forma marcante, no momento da transição de um método não-ágil para o Scrum. É, nesse momento da transição, uma mudança cultural importante. Mas depois de algum tempo passa a fluir no sangue dos agilistas e não é nenhum fardo. Afinal de contas, a vida não é mais bonita assim?

Para resumir, montamos a tabela abaixo. Nesta tabela, representamos cada uma das responsabilidades, na mesma ordem do texto, e procuramos indicar a necessidade de sua adoção em um projeto qualquer, independente do modelo de gestão utilizado. Ao lado, procuramos demonstrar o impacto caso seja negligenciada. Em Scrum, procuramos mostrar a principal influência do Scrum no trato da responsabilidade e, finalmente, indicar aoned uma ferramenta pode facilitar sensivelmente o trabalho do time, caso seja aderente ao Scrum. Essa tabela é empírica, sem rigor científico, sendo somente fruto do que observamos ao longo dos projetos que participamos, direta ou indiretamente. O único propósito dessa tabela é compilar os dados, sob a nossa ótica, relativos a uma lista tão extensa, sintetizando-os, de maneira ainda que superficial, para permitir uma visão global por parte do leitor.

 

 

Bem, procuramos acima complementar a análise feita pelo colega Willem, visando dar aos Devs, ou a qualquer elemento de um time Scrum, uma outra perspectiva sobre as suas “novas” responsabilidades. O uso de elementos adicionais no time, para cuidar de determinados aspectos, ou a redistribuição de algumas atividades, podem sem dúvida ajudar, aliviando algum trabalho. Evidentemente, descontado o aspecto comunicacional deixado claro por Fred Brooks, em seu livro seminal The Mythical Man-Month, mais gente normalmente ajuda a deixar o fardo mais leve.

Concluindo, acho que o principal ponto é que o Scrum na verdade arruma uma série de coisas que na realidade já são realizadas de outras formas em atividades não-Scrum, e, quando acrescenta algo, é porque realmente é necessário e traz benefícios muito grandes para o time, e em última análise para o próprio Dev. Você consegue pensar fora da caixa e enxergar esses aspectos de forma positiva também?