A adoção do Scrum e o Impacto Cultural para as Pessoas e as Organizações

Olá pessoal!

Nesse mês de fevereiro realizamos uma série de promoções para comemorar o aniversário de um ano do ScrumHalf. Numa das promoções sorteamos um jogo de cartas de planning poker para os participantes que respondessem a seguinte pergunta:

Quais foram as dificuldades encontradas para adotar o Scrum em sua empresa?

Quase que em sua totalidade todos os participantes responderam que uma das maiores dificuldades é de fato a mudança cultural, tanto para as pessoas como para a organização em si.

Relato a seguir alguns trechos de algumas respostas. Omiti propositadamente as autorias em atendimento às questões de privacidade dos participantes.

– “Mudar algo cultural é muito complexo. E quando se trata de gestão pior ainda, tem que ir por partes. A maior dificuldade é encontrar a rotina certa para migrar pouco a pouco (projeto por projeto), adotando de uma vez por todas a metodologia ágil”.

– “A empresa está tendo que se adaptar e está passando por mudanças culturais para se adequar a este novo método de trabalho. A maior dificuldade em adotar o Scrum, foi fazer com que os Gerentes de Projetos (PMO) entendessem como se trabalha com SCRUM, afinal o cliente exigia receber cronogramas baseados no PMI para gerir os projetos, sendo assim nossos PMO tiveram que se adequar para entender completamente o processo de SCRUM e assim refletir para o cliente em cronogramas o nosso trabalho”.

– “Foi difícil de convencer a todos a começarmos um piloto para pelo menos testar um processo baseado em Scrum. Depois, foi difícil de realizar a implantação no processo: antes, o pessoal que cuidava das funcionalidades faziam todas as especificações (documentos de requisitos extremamente detalhados), as enviava para um Gerente, que delegava tarefas para algumas pessoas, não havia interações entre os desenvolvedores, e no final juntavam os pedaços e iniciavam os testes. Nesse cenário, foi difícil de começar a criar histórias, fazer reuniões de planejamento, reuniões diárias e de não ter mais um Gerente”.

– “Tínhamos gerentes que delegavam as tarefas para as pessoas. Depois, com o Scrum não teríamos mais gerentes e sim um time auto-organizado. Acabamos tendo que colocar os gerentes com o papel SM/Time, porém o time acabava respondendo para ele nas diárias, sendo assim o time perdeu o autogerenciamento. Mas como o Scrum é empírico, um dia percebemos a falta de comprometimento do time, e identificamos que o motivo era que o time apenas respondia para o antigo gerente. Removemos o gerente das reuniões diárias, e aí tudo ficou bem melhor”.

– “Mas, todas essas dificuldades estão relacionadas à cultura da empresa. Em todas as dificuldades comparei com modelos de processo fechado devido à cultura da empresa está associada a ela, ou seja, desconhecem as metodologias ágeis e julgam como verdade as dos modelos fechados”.

-“Mudar o mindset dos gestores funcionais, que são controladores e não abrem mão de atribuir tarefas e fazer à micro-gestão”.

– “A maior dificuldade enfrentada pelos líderes de projeto da empresa foi a assimilação dos paradigmas preconizados pela metodologia ágil, frente às metodologias com ciclos de vida de projeto em Cascata (Simples ou com Sobreposição) e Iterativo-Incremental”.

– “Em nosso grupo encontramos dificuldade para adotar o modelo da autogestão num grupo acostumado à cadeia de comando tradicional”.

Na realidade, as respostas vieram a confirmar o que nós já esperávamos, em vista das experiências que obtivemos nos nossos trabalhos de capacitação e implantação do Scrum no processo de desenvolvimento de software realizados com os nossos clientes. Incluo aí a experiência de implantação na nossa própria empresa, onde hoje adotamos o Scrum na gerência de todos os nossos projetos, inclusive o projeto de comunicação e marketing.

Sabendo disso buscamos apoiar as organizações no processo de capacitação e implantação do Scrum, tornado essa transição o mais suave possível.

Em primeiro lugar fazemos uma campanha de disseminação da cultura Scrum na organização ou para o maior número de setores envolvidos. Divulgamos as principais informações sobre os benefícios, as vantagens e as possibilidades da metodologia em relação às abordagens tradicionais. Essas informações devem ser adequadas aos níveis organizacionais ao quais se destinam, sejam eles diretores, gerentes ou equipes de desenvolvimento. Pois afinal, de diferentes formas todos saem lucrando em termos de tempo, custo e qualidade nas entregas.

Em seguida é a hora e a vez do Treinamento & Prática das equipes Scrum. Treinadas as equipes, vem a última e mais importante fase do processo que é o acompanhamento na definição e execução de um projeto piloto real e imediato. Evidentemente, aqui temos que ter na eleição desse piloto um forte critério de abrangência em termos de escopo e profundidade, em razão das expectativas de entrega de valores aos clientes.

Depois da segunda ou terceira sprint os bons ventos começam a soprar, pois a transparência, a inspeção e a adaptação já denotam os seus benefícios reais, como tive oportunidade de abordar em outro post (E o Scrum para manutenção de sistemas? Podemos usar?).

Não havendo nenhuma restrição por parte do cliente, essa fase é totalmente suportada por nossa ferramenta, o ScrumHalf. A experiência nos mostrou que ela torna mais transparente e facilita bastante a transição para a prática do Scrum.

O bom de tudo é que, ao final do projeto piloto, apesar de todos os contratempos e dificuldades que irão ocorrer, é bem provável que se tenha uma equipe Scrum treinada, um projeto ou uma release entregue e um contingente de pessoas acreditando na Metodologia.

Além do impacto cultural outras dificuldades foram mencionadas das quais podemos citar:

– Projetos de escopo variável X prazo fixo;

– A mudança nos Papéis;

– Utilização de outras ferramentas para gerência projetos que não trabalham com o Scrum;

– Comprometimento do PO;

– Falta de conhecimento dos processos Scrum;

– Derrubada dos mitos sobre documentação, expectativas de prazo e estimativas por pontos  X horas;

– O time de desenvolvimento ser auto-organizável e multifuncional; e

– Decomposição em unidades de um dia de duração ou menos para as tarefas das histórias;

Mas, esses são tópicos que trataremos em outros posts mais específicos futuramente.

E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?

Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

Não esqueçam que, se precisarem, estamos prontos e experientes para ajudá-los nessa transição. Fale conosco em http://gpetec.com.br/informacoes.asp.

Encontro vocês num próximo post. Até lá!