Robert Martin é um nome que dispensa apresentações, para os iniciados em engenharia de software. É com certeza um dos mais influentes profissionais do meio, tendo uma grande bagagem de livros e artigos publicados, além de ter participado de diversos projetos. Conhecido no meio como Tio Bob (Uncle Bob), Robert foi convidado recentemente pela Scrum Alliance para escrever uma matéria sobre a sua percepção do Scrum. Tio Bob, em “The Land that Scrum Forgot” toca em uma das feridas: a importância da qualidade em um projeto Scrum e a sua relação com a produtividade do time.
 
Acredito que um dos grandes desafios em um projeto Scrum é a manutenção da produtividade ao longo de todo o projeto. Isso se torna ainda mais importante em projetos de longo prazo, especialmente se a equipe for uma equipe com pouca experiência. Não podemos confundir experiência com competência. Por mais competente que a equipe seja, o fato de possuir pouca experiência normalmente leva a equipe a ficar ofuscada pelo retorno conseguido com a agilidade. Ou seja, se o Scrum é bem utilizado, a equipe se vê produzindo de uma forma que não está acostumada. E essa produtividade, digamos exacerbada, sobe a cabeça… A equipe então passa a querer mais e mais e, para tal, acaba sacrificando a qualidade das decisões que toma e do que produz.
 
Como observa o Tio Bob porém, no início, tudo são flores: a base de código é pequena e de fácil administração. No entanto, ao longo do tempo, o quadro se modifica sensivelmente. O produto cresce e, além da esperada mudança de percepção, fruto da comparação do que é produzido a cada sprint com o que já está pronto, esse crescimento aumenta naturalmente a sua complexidade. Ou seja, o quadro como um todo realmente piora: mais dificuldade para produzir e menor percepção do valor da produção. E tudo isso pode ser pior. Se a qualidade foi sacrificada no início, tudo fica agora mais difícil. Aí, diante desse quadro, só falta o inevitável: a desmotivação da equipe. Mas a queda da produtividade é apenas um dos sintomas. Necessidade de rever a arquitetura, de mudar tecnologias e outros sinais semelhantes, começam a aparecer. Aumenta o clamor por sprints/histórias/tarefas técnicas.
 
Se chegamos a esse ponto, tudo isso é só constatação. Ou seja, tarde demais. Se nada de especial fazemos, na melhor das hipóteses, a velocidade do time se mantém, mas cada vez menos valor é entregue. Isso se contrapõe ao princípio básico do Scrum de sempre entregar valor para o cliente, pois, se tudo se mantiver, em breve só teremos sprints técnicas. Mas como podemos evitar isso? Segundo Martin estressa em seu artigo, testando, testando desde o início, testando de diversas formas, testando sempre, etc. E os testes servem também para medir. Resultados são publicados. Isso empurra o time na direção da constante melhora da qualidade do produto.
 
A visão de Martin é importante, mas para mim não é suficiente. Evitar o surgimento desse quadro em um projeto demanda outras providências. Duas importantes são: um bom trabalho em cima do valor agregado das histórias e a devida preocupação com o design do produto. A primeira ajuda toda a equipe a regular a sua produtividade, trabalhando junto com o P.O. para balancear a velocidade com a quantidade de valor entregue. A segunda dispensa comentários. Ou alguém ainda desconhece a importância do design para o sucesso de um produto?

Bom Scrum depende da qualidade. Qualidade ágil!