O Scrum provoca um rebuliço organizacional tão grande que muitas vezes a cultura organizacional é posta em cheque. Em outras palavras muitas vezes se percebe que é necessário mover o elefante da cultura organizacional para outro lugar.
Obviamente isso toma tempo e para muitos a adoção orgânica, lenta e gradual do Scrum faz mais sentido. Em boa parte dos casos as tentativas de adoção abruptas e superficiais (ou os famosos, faça-se a luz e vou instalar e pronto) dificilmente se sustentam no longo prazo.
O motivo é simples, os novos valores são tão diferentes que não fazem sentido algum para os acostumados a forma corrente. E uma das consequências invariáveis dos novos valores é em relação a forma de contratação. Isso invariavelmente surge na mente dos novos praticantes no início.
Isso ocorre por que de acordo com os valores antigos é feita a contratação com um escopo de projeto fechado, e a partir do escopo é estimado um valor total do projeto e o tempo para a entrega. Dessa forma tem se a falsa ilusão de se fechar o escopo, valor e o tempo.
Essa ilusão perde sentido ao se fazer as seguintes reflexões:
->Com que frequência uma estimativa feita está correta?
->Com que frequência o seu cliente possui necessidade de mudar o escopo?
->Com que frequência o cliente consegue mudar o escopo sem entrar novamente em negociação?
->O cliente está contente com a entrega de TI?
A resposta para essas perguntas geralmente está relacionada a:
->As estimativas são superestimadas em 50% das vezes. Para evitar problemas adiciona-se gordura para as estimativas;
->O cliente não sabe o que quer e sempre deseja mudar o que foi combinado inicialmente;
->O cliente não consegue mudar o escopo sem antes ficar exaurido em uma negociação. Ou o cliente tem a opção de iniciar um novo projeto com um novo escopo, prazo de entrega e valor.
->Ouve-se nos corredores das corporações que o cliente de IT não está contente por causa dos atrasos na entrega, alterações no custo, e finalmente porque não ocorre a real materialização do sonho.
Esses problemas estão fortemente relacionados ao raciocínio de que contrato de IT é similar a contratos da engenharia civil. Em outras palavras, é utilizado modelo de contrato para uma reforma ou para a compra de um imóvel na planta em projetos de IT.
Felizmente em projetos de IT existe a necessidade de se utilizar mão de obra de profissionais criativos para concepção do produto final. Ao se utilizar esse tipo de mão de obra em sistemas complexos a margem de erro de estimativas é um fato.
“O cliente não sabe o que quer” é um fato, e é um fato a muito tempo.
Dessa forma deveríamos parar de fazer uma estimativa sobre um escopo cheio de incertezas e ajudá-lo a descobrir o que ele realmente precisa. Para isso precisaremos focar mais na solução de problemas do que propriamente na negociação de um escopo.
Todavia pode-se cair na armadilha de se mostrar a materialização da solução do problema apenas uma vez e assim jogar no lixo tempo e dinheiro. Não faria sentido seguir na direção errada por muito tempo.
Em outras palavras faz se necessário materializar e testar partes da ideia original com frequência e coletar feedbacks do cliente. E somente dessa formar descobrir junto com o cliente para qual direção seguir.
E o mais importante se o mercado mudar, é necessário fazer as adaptações necessárias para obter um produto que faça sentido para o novo mercado.
Dessa forma não é simplesmente alterar a forma de contratação de Fixed Price para Time Material. O foco do contrato deve ser solução de problemas dos clientes ao invés de uma solução especifica.
Afinal o foco agora está em colaborar com o sucesso do negócio do cliente mais do que ficar a apenas negociar e se proteger de contratos.
Se você estiver sentido essa dor, infelizmente não existe receita pronta, mas os links abaixo podem te ajudar:
http://www.agilecontracts.org/
http://www.adaptworks.com.br/TurmaDetalhes/epc-estimating-planning-contracting/1099/Produtos
http://www.infoq.com/articles/agile-contracts
http://www.stridenyc.com/blog/2014/10/3/im-agile-but-my-contract-isnt-how-to-align-contracts-with-agile-software-development-teams
http://www.twobirds.com/~/media/PDFs/Brochures/Contracting%20for%20Agile%20software%20development%20projects.pdf
