No meu post de 04 de fevereiro de 2011 discuti o porquê e como a crise financeira, que abalou o mundo a partir de 2008, influenciou negativamente na taxa de sucesso de projetos de TI (discutir se essa crise terminou não é meu objetivo) segundo o “The Standish Group”. Agora pretendo descrever como o Scrum contribui para reverter positivamente essa taxa.

O relatório CHAOS 2009 apontou razões para esse cenário e penso que três as são mais relevantes:

  1. Aversão a projetos de longa duração pelo risco intrínseco associado;

  2. Diminuição de quadro de funcionários, reduzindo o tempo médio dedicado aos projetos; e

  3. Excesso de controle, ampliando os prazos de desenvolvimento e impactando negativamente na primeira razão.

O Scrum entrega valor ao cliente a cada período de 15 a 30 dias (sprints). Se isso não acontecer, medidas de correção são tomadas imediatamente e não ao final do projeto. A cada sprint o Product Backlog é priorizado. Isso assegura que somente seja desenvolvido o que agrega valor ao negócio. Esses dois fatores (funcionalidades prontas a cada sprint e desenvolver somente o que agrega valor) diminuem os já mencionados riscos.

O Scrum apoia-se em equipes auto-organizadas com pouca necessidade de gerenciamento. A metodologia prevê reuniões frequentes, porém de curta duração e reduzida burocracia. O resultado é que a equipe investe mais tempo desenvolvendo o que agrega real valor. Relatórios periódicos de outras metodologias são substituídos por funcionalidade entregues e aceitas pelos usuários. Jeff Sutherland quantifica a produtividade de duas equipes desenvolvendo projetos de mesmo tamanho e complexidade (1.000 pontos de função), porém utilizando frameworks diferentes (Scrum e CMM). O tamanho da equipe CMM consistiu de 7 pessoas que entregaram os 1.000 pontos de função em 117 meses. A equipe Scrum era constituída de 5 pessoas e entregou os 1.000 pontos de função em 66 meses.

Com menos pessoas e utilizando o Scrum foi possível diminuir a necessidade de gerenciamento de um projeto, seu tempo de desenvolvimento e, consequentemente, seu risco. Dessa forma esse framework contribui para aumentar a taxa de projetos de TI em qualquer cenário, incluindo os adversos.

Várias equipes desejosas de implantar o Scrum deparam-se com o problema de como fazer isso, quando os projetos já chegam com funcionalidade, prazos e orçamentos fixados. Novamente Jeff Sutherland mostra uma solução. Ele a chamou de “Money for Nothing” e “Change for Free”.

Todos sabemos que as mudanças são constantes em projetos, principalmente naqueles de longa duração. Projetos rígidos partem do pressuposto de que nada muda. Isso está longe da realidade. A primeira coisa a ser feita é determinar o valor para o negócio de cada funcionalidade prevista. Depois devemos definir uma linha de corte baseada no retorno do investimento (ROI). Toda funcionalidade cujo valor para o negócio estiver abaixo dessa linha deve ganhar menor prioridade.

Se o custo do projeto é fixo a recomendação de Jeff é: “Change for Free”. Quando emerge uma nova funcionalidade, essa deve ter o seu esforço em pontos (ver Scrum em menos de 5 minutos) e valor para o negócio levantados. Ela será desenvolvida no lugar de uma ou mais funcionalidades que totalizem o mesmo número de pontos, porém cujos valores para o negócio estejam abaixo da linha de corte. Daí vem a ideia de “Change for Free”. Desenvolvem-se novas funcionalidades (requerida e priorizada pelo Product Owner – PO) em detrimento de outras cujos valores para o negócio diminuíram com o tempo. Não fazer isso implica no aumento do risco conhecido de desenvolver funcionalidades que nunca são não utilizadas. Se o prazo é fixo a recomendação de Jeff é: “Money for Nothing”. Consiste no seguinte: concluir o projeto quando restarem apenas funcionalidades cujo valor para o negócio estiver abaixo da linha de corte já mencionada. E por que “Money for Nothing”? Porque muitas vezes temos contratos com fornecedores que preveem o desenvolvimento de todas elas, mesmo aquelas que perderam valor com o tempo. No lugar de desenvolvê-las, Jeff sugere que se pague 20% do montante para os fornecedores, economizando os restantes 80%. Ou seja o fornecedor ganha para não desenvolver, ou “Money for Nothing”. O projeto termina antes ou no prazo. A realidade nos mostra que a maioria das funcionalidades que desenvolvemos em projetos de longa duração agregam pouco valor para o negócio. O que a metodologia nos permite é identificá-las logo no início e não desenvolvê-las. Não é mágica. É apenas bom senso. Simples. Não? Qual a sua opinião?