Perigos dos “Mini-Waterfalls” utilizando Scrum

Tenho lido muito a respeito sobre mini Waterfalls camuflado de Scrum. Fato é que pessoas tem enganado a si próprias e a seus cliente tentando fazer um Scrum em fases dentro das sprints. A estes desavisados ou mal intencionados fica a dica, isto não é Scrum. O Scrum antes de qualquer coisa segue os princípios do Manifesto Ágil, ou seja, se o teu cliente não está próximo ao desenvolvimento, não é Scrum!! Se no início da sua sprint você dedica 1 ou 2 dias a análise e documentação, isso não é Scrum. Se você deixa para testar as features no final da sprint, ou seja, se não escreve os testes antes, lamento informar, isso também não é Scrum. Nosso framework de desenvolvimento para produtos complexos é relativamente simples nos princípios e nas regras, mas estritamente difícil de ser aplicado na prática. Requer boa vontade, determinação e muita, mas muita coragem.

Modificar o Scrum é tarefa para quem já conhece seus benefícios e dentro do ecossistema da sua empresa, adapta para otimizar o processo, otimizar os resultados e ser desta forma mais ágil. Tal mudança deve ser cautelosa, somente quem conhece bem o framework é que deve ser aventurar a modificá-lo. A grande mudança do ocorre é mesmo nas pessoas, pois sem elas não há processo ágil no mundo que seja efetivo. ou seja, tem que querer mudar a cultura e é aí mesmo que você irá encontrar obstáculos. Há pessoas realmente acomodadas com os processos existentes, que não querem expandir suas zonas de conforto e à estas pessoas só tenho algo a dizer: Boa sorte! O mundo muda meu amigo e se você não é capaz de acompanhar a mudança dele, fique no passado com sua documentação abrangente, processo altamente prescritivo sem as boas práticas de engenharia.

The difference between waterfall iterative waterfall scrum and lean featuredO maior ganho do Scrum ou de qualquer método ágil a meu ver é o Feedback do cliente( isso mesmo o cliente, aquele cara que paga a conta do final). O grande problema dos projetos tradicionais era justamente a falta de proximidade entre quem desenvolve e quem está diretamente ligado ao negócio, e consequentemente o desalinhamento entre negócio e software. Existe uma ditado lá na minha terra que diz que é o olho do dono que engorda o gado, parece até insanidade, mas é justamente a participação do cliente no processo de desenvolvimento que faz com que o software tenha aderência necessária para satisfazer as necessidade do negócio do nosso parceiro-cliente.

Interações curtas são o que provêm esse Feedback com nosso cliente, ao contrário daquelas intermináveis e cansativas fases onde tudo é minimamente analisado, muito é planejado, porém pouco é realizado. Mas não apenas isso, temos que ter coragem para mudar a mentalidade de nossos clientes, que na maioria das vezes estão acostumados e até preferem pedir tudo o que pensam ser necessário no início do projeto e voltar no final para “pegar” o sistema pronto.

Planejamento da sprintFato é que sem a consciência do nosso parceiro que ele tem uma parcela e grande no sucesso do projeto, não há metodologia ágil, sem participação dele não há alinhamento, assim, não há sucesso. Fazer sprints onde o cliente só participa da planning e depois no final da review é demonstração clara de waterfal disfarçado de Scrum. Vejo isto como um erro comum, que muitas pessoas têm feito, sem saber o verdadeiro motivo da inclusão do cliente no processo de desenvolvimento.ab

Scrum é simples e como todo framework deve deixar aqueles que o utilizam a vontade para criar sobre ele uma metodologia para trabalhar. Pessoas é que são complicadas e pensam que podem juntar partes de coisas que não são misturáveis, como o alto grau de controle do PMI, por exemplo.

Fazer uma sprint de planejamento, outra de análise, outra de desenvolvimento, mais uma agora de estabilização são provas de que estamos vendo um waterfall ao invés de Scrum. Da mesma forma dividir dentro de uma sprint, alguns dias para análise, outros para modelagem, mais alguns dias para implementação e testes é evidência de waterfall. Cuidado se você está fazendo isso, pois está se desviando dos princípios do Manifesto Ágil. Sei que fazer Scrum da forma correta leva tempo, muita coisa tem que ser mudada, tanto no cliente, quanto na própria equipe, para que todos juntos formem um time vencedor, mas é aí mesmo que está a graça de tudo. Esse desafio é o que deve motivar a fazer o melhor sempre e se você seguir o que diz o Scrum Guide, sem pressa mas com comprometimento, quando menos esperar estará fazendo Scrum.

Sucesso a todos e até o próximo post!!

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s