Scrum e a Crise Mundial - Por que Scrum é a melhor opção para projetos em tempos de crise

I. Introdução

O mundo enfrenta uma das piores crises financeiras de sua história. Enquanto alguns acreditam que o momento atual se assemelha à crise de 1989, que gerou repercussões relativamente brandas e o mercado não demorou a se recuperar, outros afirmam que suas consequências serão catastróficas, comparáveis às da quebra da bolsa de Nova Iorque de 1929.

O fato é que diversos países europeus, Estados Unidos e Japão já se encontram em recessão. O Fundo Monerário Internacional (FMI) recentemente divulgou um relatório onde afirma que não só o mundo demorará a sair da recessão, mas também a recuperação das economias será menos vigorosa que em crises anteriores. Deverá haver também uma fuga maciça de capitais de países emergentes como Índia e Brasil. O Fundo divulgou ainda uma previsão de que a economia mundial encolherá 1,3% em 2009.

Mesmo o Brasil, que fortaleceu sua economia e vem resistindo à recessão, tem previsão de retração dos mesmos 1,3% para este ano.

II. Investimentos em Tecnologia

Uma vez configurada a recessão mundial, as empresas em todo o mundo começaram a cortar seus orçamentos. Por consequência, os investimentos em tecnologia deverão sofrer uma queda de 3 ou 4% em 2009, em previsões das consultorias Forrester e Gartner, respectivamente. Os gastos com programas de computador deverão permanecer praticamente estáveis, já que software é visto como algo que pode ajudar as empresas a economizarem, mas os investimentos em hardware e serviços de TI fecharão o ano em queda.

Recentemente, saíram os resultados das empresas do primeiro trimestre deste ano e o cenário não é animador. A Nokia, por exemplo, teve uma redução de 90% em seu lucro quando comparado ao mesmo período do ano passado, enquanto que a Toshiba teve um prejuízo de US$ 2.5 bilhões. Ambas têm planos de cortes de milhares de empregos. Empresas como a Intel viram suas ações despencarem na bolsa. Mesmo a gigante Google, que parecia intocável e contratou como ninguém nos últimos anos, divulgou a primeira redução na história em seu lucro trimestral e eliminou centenas de empregos.

III. O Novo Cenário para Projetos

O mercado de projetos vem se reconfigurando diante da crise. Os projetos de tecnologia, em particular, sofrem um forte impacto. Neste ambiente de incertezas e constantes mudanças, os atores do mercado de projetos já encontram racionalização do uso de recursos, acesso limitado a crédito, pressões por margens menores e problemas financeiros com grande parte dos clientes, tornando o processo decisório mais longo e gerando uma notável redução na demanda por projetos.

Esta nova configuração exige que as organizações mudem sua forma de trabalhar para conseguirem sobreviver, se fazendo necessária uma verdadeira quebra de paradigma.

Essa nova forma de trabalhar deverá:

• funcionar bem em ambientes que mudam rapidamente, permitindo replanejamento frequente;
• focar-se em maximizar o retorno do investimento (ROI) do cliente;
• ajudar a reduzir o tempo de entrada em produção ou o tempo de lançamento do produto no mercado;
• evitar desperdício de esforço e tempo com subprodutos e funcionalidades que nunca serão utilizados;
• sempre entregar valor para o cliente, mesmo que o projeto seja interrompido antes do seu final previsto;
• priorizar a comunicação e feedback entre as pessoas do projeto, para que todos saibam o que deve ser feito e o que está sendo feito.

Scrum é um framework para desenvolvimento de projetos focado em lidar com todas estas questões. Demonstraremos neste artigo que Scrum é a melhor opção para projetos em momentos de crise.

IV.Scrum e a Crise Mundial

Imaginemos alguns personagens do mercado de projetos inseridos na crise financeira:

• uma organização (ou grupo dentro da organização) prestadora de serviços em projetos que deve aumentar sua competitividade para não perder clientes, internos ou externos;
• um diretor ou gerente precisando reduzir custos operacionais para sua organização sobreviver, e para isso utiliza-se de projetos internos, visando melhorar seus processos;
• um cliente que precisa contratar determinados projetos, internos ou externos, mas tem que reduzir custos para torná-los viáveis.

Forneceremos importantes argumentos para ajudar estes e outros decisores e influenciadores a defenderem a escolha de Scrum em suas organizações nestes tempos turbulentos.

a. Não ao Desperdício!

Metodologias não-ágeis defendem que devem ser gerados inúmeros documentos para se obter o sucesso do projeto. Uma parte significativa do custo e tempo do projeto é gasto na geração e manutenção desses documentos. No entanto, eles dificilmente são atualizados com a frequência necessária, até mesmo porque as mudanças correm mais rapidamente do que a capacidade da equipe de mantê-los, enquanto realiza o trabalho de implementação. Assim, grande parte dessa documentação muitas vezes se torna inútil e acaba deixada de lado.

Ken Schwaber, em seu livro The Enterprise and Scrum, afirma que cerca de 50% do tempo é gasto com requisitos, arquitetura e especificação em projetos típicos, e isso tudo é feito antes de se construir qualquer funcionalidade. No entanto, 35% dos requisitos mudam e 65% das funcionalidades descritas pelos requisitos nunca ou raramente serão utilizadas. Em tempos de crise, este desperdício de tempo e esforço não é aceitável.

Scrum defende que se deve utilizar somente a documentação estritamente suficiente e necessária para ajudar no desenvolvimento do projeto. Nem mais, nem menos. Exceto por alguns artefatos próprios do framework, Scrum deixa livre para que cada grupo decida qual documentação atende a esses requisitos, que pode ser simplesmente um papel rabiscado ou um quadro-negro. É importante lembrar que o objetivo do projeto é o produto, e não a documentação.

No Scrum, a lista priorizada de funcionalidades a se implementar é chamada de Product Backlog. Essa lista é dinâmica, pois deve sempre acompanhar as necessidades do cliente, que mudam ao longo do projeto. Além disso, sempre serão feitas as funcionalidades que são de maior importância para o cliente no momento anterior ao início de cada ciclo curto de desenvolvimento, chamado de sprint. Dessa forma, o que for entregue, terá muito mais chances de ser usado pelo cliente.

b. Maior Valor Primeiro!

Em um projeto típico waterfall, o cliente só recebe o produto pronto para ser usado ao ser aprovado nos testes de aceitação, depois de inteiramente especificado, implementado e testado. De forma parecida, para projetos de TI que usam o Rational Unified Process (RUP), o cliente só começa a ter algo em mãos no final da fase de construção, mas o produto só estará realmente utilizável na fase de transição. Em tempos de crise, o cliente necessita de retorno rápido ao investimento feito, mas com metodologias não-ágeis, ele só recebe valor no final do projeto.

Diferentemente de outras metodologias, Scrum prioriza explicitamente o retorno ao investimento (ROI) do cliente. Uma das principais funções do Product Owner é maximizá-lo através da atualização e priorização frequentes do Product Backlog, de forma que os itens de maior valor para o cliente em cada momento do projeto sejam implementadas primeiro. Assim, o incremento ao produto realizado ao final de cada sprint gera retorno ao investimento, quando entregue ao cliente. As entregas frequentes garantem que isso ocorra diversas vezes ao longo do projeto.

A priorização do Product Backlog pelo maior valor permite à organização se manter competitiva ao entregar resultados para seus clientes mais rápido que a concorrência, ao colocar em produção funcionalidades que agregam maior valor a seu negócio mais rapidamente ou ao lançar produtos e novas versões mais frequentemente no mercado, de forma que acompanhem as inevitáveis mudanças.

c. Que Venham as Mudanças!

Grandes e frequentes transformações acontecem em períodos de crise. Mudam a legislação e regulamentação, mudam nas regras de negócios, surgem oportunidades de novos negócios, importantes concorrentes deixam o mercado, verbas antes disponíveis se tornam escassas, empresas enfrentam grandes prejuízos, acontecem diversas fusões e aquisições na tentativa de se salvarem empresas e há frequentes intervenções do governo para tentar minimizar os problemas.

Para as metodologias tradicionais, a mudança é vista como indesejada, arriscada e cara. Estas metodologias pretendem que os contratos protejam a empresa contra mudanças de escopo, colocando o cliente como um potencial inimigo. Assim, cada mudança deve ser negociada e seu impacto deve ser quantificado dentro do projeto. A mudança então deve ser revista, aprovada, planejada, documentada e gerenciada.

O gerenciamento da mudança é fonte de estresse em projetos que utilizam metodologias não-ágeis. O estresse no relacionamento com o cliente se estabelece nas frequentes negociações das inevitáveis mudanças solicitadas ao longo do projeto, o que acaba refletindo no relacionamento de longo prazo. O tratamento da mudança como indesejada também se transforma em estresse no dia-a-dia da equipe de desenvolvimento.

O Manifesto Ágil defende que responder às mudanças é mais importante que seguir um plano. Como um framework ágil, Scrum encara a mudança como parte natural do processo de desenvolvimento. Com a atualização frequente do Product Backlog, as novas solicitações do cliente já podem ser introduzidas no produto no sprint seguinte. Esta resposta rápida à mudança se transforma em vantagem competitiva e, assim, a crise pode se transformar em oportunidades.

d. Quem Não se Comunica...

Em um projeto waterfall típico, o cliente só é encorajado a participar na fase de análise de requisitos e muito depois, nos testes de aceitação. O cliente percebe o projeto como uma grande caixa preta, cujo conteúdo será revelado apenas no final do processo. Assim, terminado o projeto, o resultado dificilmente atenderá às suas necessidades naquele momento, já que não houve interação durante todo o processo.

Em um projeto que adota Scrum, o Product Owner está sempre contato com o cliente para levantar suas necessidades e manter o Product Backlog constantemente atualizado e priorizado. O cliente recebe frequentemente novas versões e, assim, pode mais rapidamente dar feedback para a equipe através do Product Owner. Desta forma, o cliente se sente envolvido em todo o processo, compartilhando com a equipe a responsabilidade sobre o projeto e aumentando seu grau de confiança na equipe e no processo. A relação com o cliente deixa de ser meramente comercial e passa a contemplar parceria, cumplicidade, satisfação e fidelidade. Cria-se, assim, uma relação de longo prazo com o cliente, muitas vezes capaz de superar fortes períodos de crise.

Em metodologias não-ágeis, a visibilidade no projeto é promovida para seus stakeholders principalmente através de documentação. Como já mencionamos anteriormente, a documentação dá trabalho para ser feita, não é eficiente, não se mantém atualizada e acaba sendo deixada de lado.

No Scrum, a visibilidade no projeto é constantemente promovida. Alguns exemplos podem ser citados. As reuniões diárias servem para que os membros da equipe dêem visibilidade para os outros membros ao que eles fizeram desde a reunião anterior, e ao que irão fazer até a próxima. O kanban mostra, para quem quiser ver, todas as atividades que têm que ser feitas, as que estão sendo feitas e as já terminadas. As equipes trabalharem em um mesmo ambiente estimula a constante comunicação. Os gráficos de burndown mostram a todos o progresso do projeto, seja em horas ou em pontos. As entregas frequentes mostram ao cliente o que foi produzido, que por sua vez dá seu feedback para a equipe. A reunião de revisão mostra ao Product Owner o que foi desenvolvido naquele sprint, que por sua vez também dá seu feedback. Por fim, as reuniões de retrospectiva dão visibilidade para todos ao que funcionou bem no sprint e ao que pode melhorar.

Manter comunicação aberta entre os stakeholders do projeto é a melhor forma de garantir que todos saibam o que deve ser feito e o que está sendo feito. Isso gera aumento de produtividade, essencial para se sobreviver à crise.

e. Se o Projeto For Suspenso?

Em tempos de crise, é comum a verba acabar ou o fornecedor sair do mercado no decorrer do projeto, que tem que ser interrompido. Em um projeto não-ágil, o que o cliente receberá caso isso aconteça?

Se o projeto for suspenso logo após a fase inicial de especificação, o cliente receberá uma série de documentos que para nada servirão. Caso isso ocorra no meio da implementação, ele terá em mãos funcionalidades feitas pela metade e sem testes. Mesmo que isso aconteça no meio da fase de testes, o produto entregue dificilmente será confiável. Dessa forma, se o projeto for suspenso antes de seu final previsto, a chance de o cliente não receber retorno algum do investimento realizado será grande.

Um projeto com Scrum sempre produz um incremento ao produto potencialmente entregável ao final de cada sprint. Assim, se o projeto é suspenso em qualquer momento, o cliente pode utilizar o que foi gerado em sprints anteriores, reduzindo o seu risco. Em um ambiente de incertezas, isso se torna uma importante vantagem competitiva.

f. Se Tiver Que Reduzir a Equipe?

Em períodos de crise, pode ser necessário dispensar ou realocar membros da equipe. Em projetos waterfall, os papéis dentro do projeto são muito bem definidos. Em um projeto de TI, por exemplo, o programador programa, o testador testa, o designer faz a programação gráfica etc. Assim, se o designer sair do projeto, as telas novas ficarão sem programação gráfica; se o testador sair do projeto, o projeto ficará sem testes; se o responsável pelo banco de dados sair do projeto, ninguém cuidará do banco de dados; e pior, se o gerente de projetos sair do projeto, o projeto ficará desgovernado. Assim, o sucesso de todo o projeto ficará ameaçado.

Com Scrum, a responsabilidade pela entrega é de toda a equipe, independente de papéis. Embora haja uma especialização natural, as pessoas são estimuladas a desenvolverem e utilizarem suas habilidades secundárias e, em geral, farão todo o possível para compensar a falta de membros da equipe. Assim, mesmo que com uma capacidade menor, a equipe deverá continuar garantindo as entregas.

Vale alertar que demitir membros da equipe nunca deve ser a primeira alternativa para a contenção de despesas. Ao diminuir a equipe, estará sendo reduzida a sua capacidade de entrega de valor. Consequentemente, irá diminuir a satisfação do cliente, que acabará por procurar outros fornecedores que o atendam melhor. Isso irá piorar a situação da organização, criando um ciclo vicioso de perde-perde.

V. Conclusões

Neste artigo, mostramos que Scrum é a melhor opção para projetos nesses tempos de crise. Scrum supera outras metodologias por funcionar bem em um ambiente com constantes mudanças, por entregar mais valor frequentemente para o cliente, focando-se em maximizar o retorno do seu investimento, por evitar o desperdício e por priorizar a comunicação e visibilidade ao que é importante para o bom andamento do projeto, de forma que todos saibam o que deve ser feito e o que está sendo feito em cada momento.

Oferecemos diversos argumentos para que pessoas com poder de influência ou decisão possam ajudar a decidir pelo uso de Scrum em suas organizações.

Uma vez superada a crise, as organizações que tiverem adotado Scrum estarão mais próximas do cliente, focadas em resultado, enxutas, objetivas e transparentes. Assim, para estas organizações, a crise terá funcionado como mola propulsora, de forma que, no momento da recuperação do mercado, estas organizações largarão à frente de sua concorrência.

Referências

• Associated Press, 01/04/2009
• IDG News Service/EUA, 14/01/2009
• Jornal Valor Econômico, 17/04/2009, 22/04/2009 e 24/04/2009
• Cockburn, Alistair (2007). Agile Software Development: The Cooperative Game. Addison Wesley.
• Kniberg, Hernik (2007). Scrum and XP from the Trenches. Lulu.com.
• Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. Addison Wesley.
• Schwaber, Ken; Beedle, Mike (2002). Agile Software Development with Scrum. Prentice Hall.
• Schwaber, Ken (2004). Agile Project Management with Scrum. Microsoft Press.
• Schwaber, Ken (2007). The Enterprise and Scrum. Microsoft Press.

Sobre os Autores

Rafael Sabbagh, CSM - é Engenheiro de Computação graduado na Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) e tem MBA em Gestão Empresarial. Seu histórico inclui sete anos de experiência em gerência de projetos de TI e liderança de equipes de desenvolvimento.
Ele é Certified ScrumMaster e tem trabalhado nessa função neste último ano. Ele está cursando o Mestrado em Administração na PUC-Rio e sua dissertação é sobre o uso de Scrum e valores ágeis no Brasil. Website: http://scrumability.net

Marcos Garrido, CSPO - é Tecnólogo em Ciência da Computação graduado na Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) e tem MBA em Gestão Empresarial. Seu histórico inclui seis anos de experiência em gerência de projetos de TI e liderança de equipes de desenvolvimento.
Ele é Certified Product Owner e tem trabalhado nessa função neste último ano. Ele está cursando o Mestrado em Administração na PUC-Rio e sua dissertação é sobre percepções de clientes em projetos que utilizam Scrum no Brasil. Website: http://scrumability.net