Quando fazemos alguma coisa da mesma forma repetidamente por muito tempo cria-se um hábito difícil de se livrar quando queremos fazer de maneira diferente. E qualquer problema encontrado durante a mudança faz que voltemos aos velhos hábitos. Isso acontece na maioria das empresas que mudam do sistema tradicional de desenvolvimento para o processo ágil SCRUM. Qualquer dificuldade enfrentada pelos time, os product owners, Scrummasters, e gestores, tendem a voltar aos hábitos antigos não ágeis porque sentem-se mais seguros usando-os.
Os hábitos antigos que mais voltam da tumba quando há problemas com o SCRUM são:
Pensamento em Cascata
Os processos em cascata (waterfall) são usados há mais de 25 anos e está bem enraizado nos profissionais de TI. A forma como os SCRUM lida com os requisitos é uma afronta para quem considera os ciclos em cascata a forma mais correta de escrever software. É inconcebível para eles criar código a partir de requisitos (histórias no SCRUM) incompletas ou pouco definidos.
Um arquiteto “em cascata” diria para um arquiteto “ágil” que a única forma de criar um software sólido é pensá-lo completamente antes de desenvolvê-lo ao que o arquiteto “ágil” responderia que a arquitetura seria mais estável se fosse construída a medida que os requerimentos evoluem porque ela seria validada peça por peça.
A especialização funcional do processo em cascata também entra em conflito com a prática do SCRUM. O time do SCRUM faz o design, codifica, testa e documenta. No time “em cascata”, o designer faz o design, o programador codifica, o analista de teste realiza os testes e o redator técnico documenta. Aplicar especialização funcional ao time de SCRUM cria dependências que reduzem a produtividade do time.
Comando e Controle
Ninguém melhor que quem faz o trabalho para descobrir como fazê-lo melhor. Os Scrummasters sabem que times auto gerenciáveis são mais produtivos, mas lá no fundo, eles acreditam piamente que estão no comando. Se alguma coisa dá errado é muito comum eles sairem dando ordens sobre como fazer as coisas.
Os times de SCRUM levam algum tempo para se auto gerenciar adequadamente, nessa fase, os Scrummasters devem ensiná-los a fazer isso, devem conduzi-los de forma que descubram por si só como melhor trabalhar em time.
Comprometer-se a desafiar as leis da natureza
Alguém diz que quer um novo software para uma determinada data. Ele diz que já se comprometeu com outra pessoa sobre essa entrega. Ele quer que você se comprometa a desenvolver o software sem atrasos. Você ainda não sabe exatamente qual a complexidade do software e quem o está pedindo também não detalhou tudo o que ele deve fazer. Mas ele tem poder sobre sua carreira e salário. O que você faz?
Pressionar alguém a se comprometer com alguma coisa apesar dela acreditar que não é possível é um péssimo hábito. As pessoas honestas não se comprometem, mas outras quando estão acuadas se comprometem mesmo sabendo que não vão entregar. É como se comprometer a quebrar as leis da física.
Esconder a Realidade
Os desenvolvedores estão cientes das complexidades que podem causar mudanças em suas estimativas originais. Eles também estão cientes que o cliente não ficará feliz com essas mudanças. Se um Gerente de Projetos tradicional precisa dizer como o projeto está indo um pouco depois da metade do tempo do projeto, ele provavelmente não sabe, talvez algum item crítico não tenha sido verificado adequadamente, mas ele sabe que não pode dizer “eu não sei”, então ele diz “tudo indo bem”, “tudo dentro do esperado” de forma que o cliente continua feliz em sua ignorância. A mentira é um hábito mais simples que expor todas as nuances e complexidades que existem no projeto.
SCRUM é baseado em confiança e transparência. Os product Owners precisam ter a melhor informação possível para tomar as melhores decisões o mais cedo possível.
Conclusão
Nem todos os hábitos são ruins. Mas para que as vantagens do SCRUM se manifestem nas empresas, os hábitos antigos devem ser deixados de lado e a empresa deve continuar usando o processo até que as práticas do SCRUM tornem-se elas mesmas um hábito.
(baseado em The Enterprise and SCRUM – Ken Schwaber)
#1 por Walter em 12/11/2008 - 04:33
Muito bom, só acho que a palavra hábito não é a mais adequada para o assunto deste post. Penso que essas coisas que “voltam da tumba” são na verdade vícios.
A diferença que eu faço é que as pessoas desenvolvem hábitos de forma natural e, geralmente, porque uma certa prática traz benefícios para ela e para as outras mesmas com quem convive. Já o vício se desenvolve a partir de uma dependencia, geralmente, uma consequencia de uma atitude que após algumas repetições cria uma situação de dependencia tao forte que chega a parecer impossível parar de fazer.
Assim como a nicotina causa dependência química no organismo, a ignorancia ou a mentira sobre a situação de um projeto numa organizaçao também causa dependencias, pois à medida que as pessoas fazem isso vão se criando situações cada vez mais comprometedoras e que dificultam que a verdade venha à tona sem causar maiores estragos. A prática da mentira passa a ser cada vez mais conveniente cada vez para mais pessoas. É uma doença.
Faço uma ressalva com relação à lista: O pensamento em cascata. Penso que esse não é um vício, e, nem mesmo no scrum ele deixa de existir. O que muda no scrum é o paradigma de deesenvolvimento do produto em cascata. Mas isso é assunto para um outro post.
#2 por Cruz em 11/05/2009 - 17:32
Boton, legal o post. Dá uma olhada aqui: Scrum Smells http://scrumcommunity.pbworks.com/Scrum-Smells. (ScrumMaster Assigns Work, Executive Pressue e We”re Not Acting Like a Team principalmente).
#3 por Elderclei Reami em 26/06/2009 - 18:07
Grande Wlad,
Ótimo momento para comentar esse post. Estamos num momento bem próximo ao que você descreve aqui. Ao meu ver, algumas pessoas parecem viciadas:
Por outro lado, colocar um chapéu de arquiteto, ou QA, ou ScrumMaster em alguém leva muitas vezes a uma percepção de poder irreal (eu digo como vai ser tecnicamente ou só eu garanto a qualidade para o cliente ou eu posso tornar essa equipe auto-gerenciável), quando na verdade esse chapéu deveria ser usado para aumentar sua percepção de responsabilidade sobre o sucesso.
Abs.
#4 por Ramal em 12/08/2009 - 19:32
Oi Wlad,
Acho que um ponto que merece atenção também é a “evangelização” constante do Scrum na empresa, pois acredito que a dinâmica dos negócios colabora para que os vícios de waterfall voltem à tona, dado que os gestores rapidamente se distanciam dos projetos quando percebem que tudo vai bem nos primeiros Sprints, e acabam assumindo compromissos inviáveis com a direção por não estarem realmente informados sobre o cenário atual dos projetos, que pode revelar uma dificuldade até então desconhecida.
A comunicação é sem dúvida um ponto que o Scrum Master deve trabalhar, mas muitas vezes simplesmente não se tem a devida atenção dos gestores pois apesar de apoiarem o Scrum não estão comprometidos com ele.
Abs