e-Book sobre SAFe

Nesse e-book Manoel Pimentel dá dicas para quem  está interessado em dar seus primeiros passos em direção a escalar ágil dentro de grandes organizações.

Se você já roda Scrum com vários times em sua empresa, mas ainda não descobriu uma forma de interagir e expandir a mentalidade ágil para as demais áreas da empresa e camadas mais estratégicas, então chegou o momento. Esse material é um bom começo!

Nenhum comentário »

Categorias deste post

SAFe

É necessário alterar a forma de contratação para trabalhar com Scrum?

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

 

Nenhum comentário »

Categorias deste post

Agile, Product Owner, Scrum