O Water-Scrum-Fall ("Cascata-Scrum") seria a forma de adoção do Scrum atualmente mais comum nas organizações, de acordo com Dave West, diretor de Pesquisas e Vice-Presidente da Forrester. Dave escreveu sobre a análise da Forrester em um artigo recente da SD Times.
As organizações estão adotando cada vez mais as metodologias ágeis de desenvolvimento de software, através da combinação de uma adoção de baixo para cima e mudanças nos níveis estratégicos. Entretanto, a realidade na adoção do Agile tem divergido das ideias originais descritas no Manifesto Ágil, assemelhando-se muito ao que a Forrester tem chamado de Water-Scrum-Fall.
Segundo a Forrester, isso ocorre porque a adoção do Agile é geralmente conduzida por profissionais técnicos e estes se concentram no domínio com o qual estão mais familiarizados, o que, na maioria dos casos, significa desenvolvimento de software. Logo, áreas como gerenciamento de releases ou planejamento de projetos ainda são tratadas através de métodos tradicionais.
O artigo busca então elucidar o termo Water-Scrum-Fall:
Water - Define o processo de planejamento inicial do projeto que ocorre comumente entre o setor de TI e o negócio.
Scrum - Uma abordagem iterativa e adaptativa para realizar o plano geral que foi gerado da fase anterior ("Water").
Fall - Um ciclo de lançamentos controlados e pouco frequentes, que é regido por políticas organizacionais e limitações de infraestrutura.
O artigo também fornece dicas às equipes de desenvolvimento que estão enfrentando a realidade do Water-Scrum-Fall e buscam maior agilidade. Dentre as dicas citadas:
- Uma equipe Scrum devidamente preparada deve incluir todas as pessoas necessárias para a entrega de software funcional. Isso significa, basicamente, desenvolvedores, analistas de teste e analistas de negócio trabalhando em prol de um objetivo comum.
- Os desenvolvedores devem contestar o status quo de implantações pouco frequentes em produção e impulsionar a criação de melhores processos e práticas de liberação de releases dentro da equipe.
- Gastar muito tempo em detalhes no início do projeto não irá aumentar a qualidade da release; ao contrário, é um desperdício.
- Documentos são meios pouco eficazes para gerar software funcional. Além disso, todo documento criado deve conter somente o suficiente para apresentar o contexto do problema e permitir um planejamento de alto nível para que o trabalho de desenvolvimento comece.
No post de Mike Dwyer, de junho de 2011, no blog Big Visible, Dwyer argumenta que a comunidade Scrum pode ser dividida em três grandes grupos: os puristas, os arrogantes e os pragmáticos.
Será que as equipes Water-Scrum-Fall começam no grupo dos arrogantes e depois se tornam puristas, ou seria o Water-Scrum-Fall a essência de ser pragmático? O que você acha?