Você conhece o “Tipo Scrum”?

A onda ágil continua a todo vapor e tenho percebido que as empresas brasileiras estão utilizando cada vez mais estas práticas para utilização em seus processos de desenvolvimento de software.

Entre processos e frameworks tais como, XP, AUP, FDD e Scrum, acredito que o Scrum é o framework mais utilizado, seja pela sua maior disseminação, simplicidade de uso e/ou conteúdo disponível na internet.

Meu primeiro contato com o Scrum foi há uns 6 anos atrás em um workshop da ThoughtWorks. Neste workshop, o palestrante frisava vários pontos mal interpretados de utilização de Scrum e um dos mais comum era a criação de sprints de planejamento. A frase foi bem clara: “Se alguém cria sprints de planejamento não está utilizando Scrum“.

Tenho tido contato com diversas empresas de desenvolvimento de software seja através de consultoria, amigos ou interfaces comerciais e tenho percebido, uma vasta adaptação do framework para o método de trabalho das empresas.

Algumas empresas apenas utilizam a Kanban Board para controlar suas demandas e acreditam estar utilizando Scrum, outras aplicam o papel do Product Owner e do Scrum Master para uma mesma pessoa acreditando não estarem erradas. Gerentes ou coordenadores funcionais implantam os processos do Scrum mas passam atividades individualmente para os membros da equipe e também realocam pessoas no meio dos projetos para apagar outros incêndios. Alguns Scrum Masters e Product Owners estimam todo o backlog do projeto, prevendo exatamente o que irá ocorrer em cada sprint cobrando assim a equipe por tal execução.

Não estou dizendo que essas utilizações não sejam bem sucedidas, estou apenas mencionando que muito do propósito do Scrum está sendo perdido desta maneira e essas empresas de fato não estão utilizando Scrum, mas sim o famoso “Tipo Scrum“.

O Scrum é um framework compacto com um método prescritivo bem simples, definindo papéis, eventos e artefatos para ter-se uma abordagem value-driven. Baseando-se nas teorias do empirismo, acredita que a tomada de decisão tem que ser realizada em cima dos fatores conhecidos, definindo assim, abordagens iterativas e incrementais para reduzir os riscos.

Com base no modelo de sistemas complexos de Cynefin, o Scrum é um framework que deve ser utilizado quando se tem uma baixa previsibilidade do trabalho do projeto, da mesma forma, como já se é conhecido, em grande parte dos projetos de P&D, Desenvolvimento de Software, campanhas publicitárias, entre outros.

Fora esta estrutura principal, o framework não prescreve como realizar estimativas, como levantar requisitos, como controlar as atividades, entre outras coisas, ele apenas permite que sejam “plugadas” práticas emergentes para ajudá-lo com outras funções, daí vem a utilização da Kanban Board, User Stories, Story Points e diversas outras técnicas.

Diferente das abordagens convencionais (plan-driven) onde escopo define custo e tempo, uma abordagem value-driven as restrições se invertem e o tempo e o orçamento passam a definir o escopo. Está é uma importante inversão conceitual que muitos que buscam aprender Scrum de forma independente deixam escapar. Com estas restrições (custo e tempo) busca-se entregar o máximo de valor para resolver o problema em questão descrito na visão do cliente.

Outro ponto que gera polêmica é a auto-organização. Os times Scrum devem ser auto organizados e isto é um importante tema que faz garantir o sucesso de projetos em ambientes complexos.

Os papéis no Scrum são claramente definidos. O Product Owner preocupado com a macrogestão e a priorização dos itens do backlog, o Scrum Master sendo um facilitador e guardião da utilização do Scrum e o Development Team um time multidisciplinar e auto organizado, trabalhando nas tarefas conforme sua própria ótica. Não há hierarquia entre esses papéis.

Talvez esta seja uma das maiores dificuldades de implantação do Scrum e causa da criação do “Tipo Scrum” nas empresas. Quando realizei o treinamento, lembro de diversos outros gerentes ficarem ensandecidos defendendo seus papéis e sua hierarquia que lutaram tanto para conquistar.

Muitos têm medo da auto-organização se preocupando em como medir o desempenho do time. Não podemos esquecer, que as vezes quando nos preocupamos muito em medir os outros, esquecemos de nos medir. Já dizia Deming que grande parte dos problemas que ocorrem em uma organização é culpa do sistema (ambiente) por ela criado.

O intuito deste artigo era apenas dar a ênfase de que grande parte das organizações acreditam utilizar Scrum quando de fato possuem métodos baseados e adaptados deste framework, de forma que acabam perdendo parte do propósito do mesmo. Outro propósito é de enfatizar alguns valores as vezes esquecidos da utilização do verdadeiro Scrum, lembrando que sempre é possível plugarmos práticas emergentes para resolver outros tipos de problemas, mas nunca mudando o eixo central inserido pelo mesmo.

Sabendo que esta é uma das naturezas da melhoria contínua, venho deixar claro no final, que de forma alguma mencionei que a adaptação da estrutura do Scrum possa ser ineficiente, apenas podemos perder certos benefícios quando não identificamos ou não nos preocupamos com os valores bases deste framework.

Comentários

comentarios

Marcelo Leite Barros
na