Rafa Nascimento

Escalando o Monte Everest: o Scrum e a cultura Waterfall

Posted in scrum by Rafa Nascimento on 14/12/2010

“A disposição para mudar demonstra força, mesmo que a mudança signifique mergulhar a empresa em total confusão por algum tempo.” – Jack Welch

Por muito tempo, o mercado de TI acostumou-se a utilizar o modelo Waterfall de desenvolvimento de software, que, por sua vez, é baseado no processo definido de produção. Ou seja, antes de iniciar-se uma fase de produção, a fase anterior deve estar finalizada, com subsídios suficientes gerados para que a próxima fase se inicie. Modelos de contrato, utilizando-se das mais diversas ferramentas para medição (Pontos por Função, Homem-Hora, Time Material, etc) foram criados levando em consideração o processo Waterfall. Com o advento do RUP, toda uma metodologia surgiu para apoiar e organizar o processo definido de desenvolvimento de software. E, para tentar tornar tudo isso útil e até possível, surgiram as fábricas de software, fortes entusiastas da certificação CMMI de controle de qualidade em processos de desenvolvimento de software. Uma nova forma de construir software, iterativa e incremental, baseada no processo empírico de produção, onde a inspeção e adaptação contínuas são mais importantes do que um plano de execução, chegava com o RUP. Porém, por falta de força e por questões culturais das organizações, o iterativo e incremental seria adaptado para o processo de maior costume no mercado: o Waterfall.

Durante aproximadamente 25 anos, todo o breve parágrafo acima tomou forma e amadureceu. Organizações e, principalmente, as fábricas de software, construíam seus softwares e adaptavam seus processos incansavelmente, em busca do Santo Graal da componentização, que permitiria, enfim, uma montagem rápida de softwares, baseada em bibliotecas de componentes surgidos em projetos anteriores ou componentes criados pelas equipes de arquitetura. A alta tecnologia estava em sua melhor forma e, cada vez mais, surgiam idéias para otimizar o reaproveitamento e aumentar a produtividade dentro das fábricas de software. Porém, algo mais importante do que a tecnologia estava sendo esquecido: o problema do cliente. Mais importante do que criar excelentes frameworks e bibliotecas de serviços e processos que conduziam à alta produtividade era resolver o problema do cliente dentro do prazo que ele precisava e de acordo com as suas possibilidades financeiras. E tal modelo, na maioria das vezes, falhava. Segundo pesquisas do Gartner Group, até hoje, mais da metade dos projetos de software tradicionais faliram ou atrasaram. Algo estava muito errado e o mercado de software perdia rapidamente a confiança de seus clientes. Surgia, então, em 2001, o processo Ágil de desenvolvimento de software e, com ele, diversas frameworks para apoio ao processo, como XP, Lean e Scrum. Em aproximadamente 10 anos, com foco total no cliente e em seus processos de negócio, o Ágil mostrou-se a forma mais confiável para desenvolver software. Mas a caminhada até este ponto foi muito árdua, e ainda não está terminada.

Com sua grande base de utilizadores concentrada na Europa e na América do Norte, o Ágil e seus frameworks ainda não dominam regiões como América do Sul e Ásia. Por questões culturais e governamentais, o caminho nestas regiões ainda é longo e de provação. É necessário, talvez, um grande case de sucesso, público ou privado, para que as grandes organizações invistam sem receios nesta nova forma de construir software. Todas as esperanças estão sendo depositadas no Scrum, o processo de gestão de projetos ágeis de softwares baseado no processo empírico de produção, iterativo e incremental. Uma quebra de paradigma muito forte para o nosso atual mercado de tecnologia. Em um mercado global, não basta competir com base somente nos resultados. É preciso, também e fundamentalmente, adotar uma mentalidade de funcionamento global, ou seja, se as organizações e governos destas regiões que estão sempre a perseguir os resultados dos chamados “líderes de mercado” não adotarem a mesma mentalidade, princípios e cultura que rege tais lideranças, estarão fadados a eternamente perseguir os líderes tentando utilizar-se de uma cultura pré-globalização, talvez não mais tão efetiva, inclusive, no próprio mercado interno.

O Scrum nasceu junto com o processo Ágil, mas só agora vem ganhando notoriedade e força no mercado, devido à sua facilidade de adoção, leveza e fácil adaptação à realidade das empresas. Porém, existem valores no Scrum e no Ágil que não podem ser adaptados, sob pena de perda de toda a performance que os processos oferecem. Tais adaptações, demandadas pela forte raiz da cultura Waterfall nas organizações, têm sido o principal motivo para a lentidão do sucesso destes processos por aqui, com um agravante: no Ágil, não há certo ou errado. Ele se adapta às necessidades das organizações, mas não ao Waterfall. Por serem provenientes de processos de produção distintos (definido e empírico), uma mudança cultural se faz necessária em toda a organização, e não somente no departamento de TI. Os contratos devem mudar, as medições devem mudar e a forma como os requisitos são solicitados devem mudar. Os projetos devem mudar. A gestão deve mudar. Para tal, a transição deve ser realizada de forma típica: pelo Scrum.

No livro The Enterprise And Scrum, Ken Schwaber, um dos criadores do Scrum e um dos fundadores da Agile Alliance e da Scrum Alliance, comenta que algumas pessoas sentem-se profundamente desconfortáveis quando são solicitadas a utilizar o Scrum. Parece arriscado. É desconfortável. Seus instintos preferem a utilização do Waterfall. Segundo Schwaber, os requisitos são tratados de forma bem diferente no Scrum. Aproximadamente 50% de um projeto típico é gasto na criação dos requisitos, arquitetura e desenho. Durante o mesmo projeto, 35% dos requisitos mudam e mais de 65% das funcionalidades descritas pelos requisitos são raramente utilizadas… ou nunca. No Waterfall, todos os requisitos, arquitetura e desenho são desenvolvidos antes do time começar a construir funcionalidades. O Scrum enxerga requisitos e arquitetura como inventório. Se alguns requisitos mudam ou não são utilizados, o tempo gasto para entendê-los ou desenhá-los é perdido.

Para que haja a possibilidade de o Scrum funcionar, é necessário erradicar 3 costumes que foram, ao longo do tempo, fortemente enraizados no dia-a-dia e na cultura das organizações que hoje, ainda utilizam o Waterfall, total ou parcialmente.

Comando e controle
A pessoa mais indicada para descrever como uma tarefa deve ser executada é quem vai executá-la, não seu gestor. O trabalho é complexo e possui nuances inesperadas. Se os executores obedecem instruções de outras pessoas, eles não estão livres para fazer o seu trabalho da melhor maneira possível.

ScrumMasters sabem que times Scrum auto-gerenciáveis são mais produtivos. Os primeiros 10% de seus pensamentos são focados no auto-gerenciamento. Mas os outros 90% sabe que eles estão à frente. Se alguma coisa sair errado, eles vão entrar e dizer o que o time deve fazer. Inspecionar e adaptar, ou ensinar, no caso, é a melhor maneira de garantir que tudo dará certo. É extremamente difícil descartar o Comando e Controle.

Para que um time esteja formado e comece a performar leva tempo. Alguns times necessitam de mais atenção do que outros. Afinal, times são formados por humanos, diferentes entre si e suscetíveis a falhas. Por isso, os ScrumMasters são responsáveis por ensinar o trabalho em equipe auto-gerenciável para os times. Por exemplo, se um time pergunta ao ScrumMaster: “Esta história é muito grande para esse sprint! O que fazemos?”, o mesmo não dá uma resposta. Ao contrário, o ScrumMaster guia o time pelo processo de descobrir como desconstruir a história. O ScrumMaster ensina, o time aprende e o exercício é concluído. Da próxima vez que uma situação similar aparecer, o time saberá resolver. A partir do momento que o ScrumMaster diz ao time o que ou como fazer, ele exerce comando e controle. No comando e controle, o ScrumMaster acredita ser o responsável pela produtividade e resolução dos problemas. No auto-gerenciamento, o gestor acredita ser o responsável por ensinar ao time auto-gerenciamento e resolução de problemas.

Compromisso em desafiar as leis da natureza
Negócios se resumem a compromissos. Quando assumimos um compromisso com alguém, damos a nossa palavra. A outra pessoa organiza o seu negócio de acordo, contando com o que dissemos que faríamos. Essa abordagem é baseada na confiança e é uma enorme fonte de eficiência.

Porém, pressionar alguém a se comprometer com uma tarefa sem se preocupar com o que esta pessoa pensa que é possível é um mau-hábito. Se a pessoa sob pressão é honesta, não prometerá nada. Se está encurralada, provavelmente se comprometerá com algo que não é entregável. Nenhuma das alternativas ajuda se uma ação se faz necessária. Nosso costume nos diz que podemos pedir para nosso time se comprometer com uma tarefa. O costume do nosso time é se comprometer, não importa as circunstâncias.

Esconder a realidade
Os novatos no Scrum não acreditam que a transparência, ou a verdade, é aceitável onde trabalham. Eles temem a demissão caso digam a verdade. A verdade não é o que seus clientes querem ouvir. Acreditam que alguém fará isso caso não façam. As pessoas envolvidas com desenvolvimento de software acreditam que seus clientes só querem escutar notícias se forem boas, ou preferem escutar uma mentira no lugar da verdade. “Mentira” é uma palavra pesada. Mas não consigo encontrar nada que defina dizermos que algo é verdadeiro quando sabemos que não é. Os Product Owners querem acreditar em mágicas, e os desenvolvedores alimentam esta crença mentindo. “Pode nos entregar em dezembro?” “Claro, sem problemas.”

Os desenvolvedores desconhecem as complexidades que causam mudanças em suas estimativas. Não sabem que o cliente está infeliz. Se um gerente de projetos é confrontado por um cliente durante o marco de 60% de andamento de um projeto e este lhe pergunta como está o projeto, de fato ele não sabe. Ele sabe que algumas coisas estão caminhando bem. Também sabe que algumas outras coisas não estão indo tão bem assim. Também sabe que não checou, ainda, algumas coisas que podem se tornar críticas. No entanto, dizer “Não sei” é inaceitável. Então, os gerentes de projeto aprenderam a dizer “Tudo ok”, “Chegando lá”, “De vento em popa”, ou qualquer coisa equivalente que faça o cliente ir embora e deixá-lo em paz para tentar entregar tudo no prazo e dentro do orçamento. Basicamente, mentem. É mais simples do que expor tudo o que vem junto com “Não sei.”

Gerentes de projeto também acreditam que mentir os faz ganhar tempo. Mas, porque o Scrum se pauta na transparência, mentir destrói toda a aplicação do Scrum. Se um Product Owner não sabe exatamente como andam as coisas em um determinado ponto no tempo, ele será incapaz de tomar as melhores decisões possíveis para atingir seus objetivos. Eles precisam da melhor informação possível, seja ela boa ou ruim.

Anúncios
Tagged with: , ,

Deixe um comentário

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

%d blogueiros gostam disto: