É 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

Posso mudar o tamanho de uma Sprint?

O Roberto Pereira, Product Owner, nos mandou a seguinte dúvida:

O timebox da Sprint pode variar no decorrer do projeto? Exemplo: Sprint1: 2 semanas, Sprint2: 3 semanas, Sprint3: 2 semanas e assim por diante…

Nossa Resposta

Caro Roberto,

Uma Sprint pode mudar de tamanho quando não iniciada, em alguns momentos isso é recomendável mas na maioria das vezes isso é danoso.

É interessante quando o time percebe que não consegue entregar incremento de software no tempo pré-determinado de uma Sprint. Desta maneira, o time aumenta o tamanho da próxima Sprint e segue assim por um bom tempo.

Todavia alterar o tamanho da Sprint possui como trade-offs a perda do referencial de timing e de velocidade de uma Sprint, e demorar mais para se adaptar as mudanças.

A perda de noção de timing de Sprint, ocorre quando o time perde a ideia de quando deve começar a fazer processos importantes dentro de uma Sprint, como quando deve implantar no ambiente de homologação master ou quando deve obter assinaturas que autorizam a subida em produção.

Já a perda de referencial de velocidade ocorre porque ao aumentar o tempo de Sprint em 1/3 não ocorre um aumento na produtividade de 1/3. Na prática a velocidade pode tanto aumentar como diminuir…

Ops, como assim diminuir?

A famosa síndrome de estudante pode atacar o seu time… Ou seja, o seu time pode operar como nos tempos de faculdade no qual deixava para fazer as atividades perto do prazo de entrega.

Aumentar o tamanho da Sprint também significa demorar mais para escutar o PO, e por consequência o software muda de maneira mais lenta. Isso pode ser mais danoso que os dois itens acima juntos.

Para finalizar, no coração do Scrum encontra-se o conceito de trabalhar com timebox… E o seu time deve aprender a trabalhar com uma timebox definida.

Se vocês acordarem que vai ter um incremento de software a cada duas semanas, todos vão ter que gastar massa cinzenta para conseguir este objetivo.

O time de desenvolvimento vai aprender a ser mais objetivo, o que envolve organizar melhor as tarefas, os processos, e a eliminar o desperdício com supérfluos técnicos.

O Product Owner vai aprender a granularidade correta das atividades para caber na Sprint. De início ele vai achar impossível quebrar as tarefas, mas depois de um tempo ele vai conseguir acertar a granularidade.

Não sei por qual motivo você quer mudar, mas agora que já sabe alguns trade-offs, você pode tomar uma decisão bem fundamentada.

Em caso de dúvidas sobre metodologias ágeis mande um sinal de fumaça ou envie sua dúvida por e-mail.

1 Comentário »

Categorias deste post

Adaptworks Responde, Product Owner, Scrum, Sprint, Timebox

Requisitos Ágeis “à moda da casa” !

Gravamos um vídeo sobre a nossa compilação de aprendizados na disciplina de requisitos!

Esclarecemos, em um quadrante – Why, What, Where e How – , quais técnicas, de levantamento de requisitos e funcionalidades, podemos utilizar em processos ágeis. Conectar essas técnicas e direcionar os profissionais envolvidos; através da prática de dinâmicas baseadas em “canvas”; a alcançar um alto nível de conhecimento sobre as características técnicas e de negócio deste produto, em tempo otimizado, é o objetivo do treinamento de Requistos Ágeis – que estruturamos a partir deste nosso aprendizado!

Este treinamento será ministrado, com super descontos, e com três instrutores no do Agile Trends 2014!

Assistam o vídeo e venham participar!

Videocast Adaptworks #4 – Requisitos Ágeis

Nenhum comentário »

Categorias deste post

Agile, Eventos, Gestão de Produtos, Product Owner, Requisitos, Videocasts

TeamStart – Vídeo do webinar sobre Estimativas Ágeis

Nesse webinar promovido pela Rally Software,  faço uma dobradinha com Andreano Lanusse para dar uma visão prática de como funcionam as estimativas ágeis num projeto de software. O vídeo,  com duração de 01:36h,  mostra uma série de dicas para escopo, classificação de tamanho, tratamento da incerteza, da complexidade, orçamentação, preparação e refinamento do backlog. Bons estudos!

Nenhum comentário »

Categorias deste post

Agile, Gestão de Produtos, Product Owner, Requisitos, Videocasts

Grooming Canvas – Todas as user stories estão no inferno!

Dentro do paradigma ágil, quando estamos num processo de desenvolvimento de um produto,  buscamos iniciar todos os nossos esforços de entendimento e até mesmo de desenvolvimento por aquilo que acreditamos que será o maior valor do produto.

O  próprio Scrum estimula que um Product Owner (vulgo PO) comece a “povoar“ seu Product Backlog aplicando um forte senso de priorização baseada em valor. E de maneira geral, muitas organizações tem uma enorme dificuldade em definir  ou consensualizar o que é valor. Mas isso é assunto para outro texto.

Contudo, ao longo do tempo, comecei a notar uma tendência forte entre os POs e times de produtos. Podemos nomear essa tendência com a famosa frase de “no final, tudo é importante!”

Isso acontece pois seria uma ingenuidade achar que conseguiríamos, de imediato, já iniciar o nosso pensamento sobre o produto pelo mais importante e excluir as funcionalidades que não agregam valor. Na verdade isso é bastante perigoso. O perigo se dá pois, na tentativa de começar um Product Backlog pelo seu topo de prioridade, ordem e valor, acabamos gerando o mesmo problema de excesso de funcionalidades nos produtos desenvolvidos. Na prática, muitos Product Backlogs tem um topo muito extenso.  E é aí que mora o perigo.

Ao meu ver, isso acontece pois muitos praticantes de agile se distanciaram de um item muito importante do manifesto ágil. Na verdade, o item em questão é um dos doze princípios ágeis (pois é, eles existem! Usa Agile e não sabia disso? Shame on you!). Mas especificamente,  estou me referenciando ao décimo princípio.

O Décimo princípio do Manifesto Ágil diz:  Simplicidade – A arte de maximizar a quantidade de trabalho não realizado – é essencial.  Esse princípio, na minha opinião, é matador!  Na prática ele  toca na ferida ou na maior dificuldade na adoção do pensamento ágil na criação de produtos. Essa dificuldade se dá pelo fato de que Agile preconiza o desapego de (muitas) partes desejadas para um determinado produto.   Quando se contrasta “coisas que tem valor” versos “coisas que não tem tanto valor”,  o exercício  de priorizar e descartar fica fácil. Mas quando se contrasta “coisas que tem valor” versos “coisas que também tem valor”, aí o desafio começa.

Meu amigo Rodrigo de Toledo menciona:  “Nos tempos atuais, o trabalho do profissional de informática deveria passar a se concentrar na SÍNTESE de sistemas. Devemos remover funcionalidades ao invés de gerar mais.” Sendo assim, um dos maiores desafios econômicos e culturais do desenvolvimento de software é criar e efetivar uma inteligência saudável de descartar o máximo possível de trabalho não feito, para poder focar na menor parte de maior valor do produto.

Para ajudar a resolver esse problema (veja bem, ajudar, não resolver, ok?) há algum tempo sugiro para os POs o seguinte exercício:  Vamos adotar a premissa de que “Todas as user stories têm baixo valor até que se prove o contrário!”. A ideia é transformar esse pensamento numa espécie de mantra ou numa regra que deve ser seguida a risca a cada item desejado para o Product Backlog.

Ao seguir essa regra, O PO precisa fazer um difícil exercício. Esse exercício é difícil pois como todos os itens já nascem com baixa prioridade, o PO, tem se esforçar em fazer aquele item merecer ir para o topo do Product Backlog.

É  importante alertar que o elemento que mostrarei em seguida, não oferece uma maneira explícita para identificar a priorização.  Cabe a cada PO identificar uma forma ou técnica para fazer essa priorização. O importante que essa priorização aconteça por critérios transparentes e passíveis de discussão dentro da organização.

Para apoiar esse exercício, criei uma espécie de canvas (ver figura abaixo) para guiar, de maneira visual, esse raciocínio.  A esse canvas chamo carinhosamente de Grooming Canvas, pois  sua aplicação serve exatamente para ajudarmos o processo de grooming (refinamento e organização) dos itens de um Product Backlog.  Essa prática de grooming, no fundo, tem um caráter contínuo no desafio em tornar os itens mais prioritários em estágio de DOR (Definition Of Ready).

GroomingCanvas-ManoelPimentel

Nesse canvas,  temos 2 eixos. No eixo vertical, temos a dimensão de valor seguindo a premissa de priorização que explicamos acima. E no eixo horizontal, temos a dimensão de tamanho. A dimensão de tamanho segue o mantra de “Todas as user stories são um ÉPICO/TEMA até que se prove o contrário!”. O tamanho é outro ingrediente importante nessa conversa.  Pois se algum item tem pouco valor de negócio, não precisamos investir (ou gastar) tempo em detalha-lo. A ideia do Épico ou Tema é uma forma de identificarmos e mostrarmos o quanto um item ainda está muito grande, ou há muita incerteza, ou ainda não está num tamanho suficiente pequeno para entrar em uma Sprint.  Dessa forma, por ser um TEMA/ÉPICO isso significa que aquele item precisa ser quebrado/desmembrado em itens menores e factíveis de entendimento, por exemplo.

Juntando as regras de que todas as user stories são grandes e também têm baixo valor, notamos que por padrão, os itens do backlog já nascem no final do mesmo (representado pelo canto inferior direito do canvas). E cada vez que vamos refinando e entendo mais sobre o seu contexto de negócio, o  item vai subindo ao topo do backlog (que no canvas é representado pelo canto superior esquerdo).

Uma maneira de compreender a dinâmica e os fenômenos que ocorrerão no canvas, é usando a metáfora Dantesca para classificar as coisas. Nessa visão (ver figura abaixo), é possível resumir que todo e qualquer item, já nasce no inferno (cruel, não?) e ele precisa ser trabalhado em termos de prioridade e redução de tamanho para poder merecer entrar no céu.

GroomingCanvas-DivinaComedia-ManoelPimentel

Esse canvas acaba sintetizando uma forma um pouco contra-intuitiva para priorizar e refinar itens de um Product Owner.  Pelo fato de ser contra-intuitivo, demanda um esforço maior por parte de um PO. Lembro-me que na primeira vez que usei essa abordagem era possível ouvir (metaforicamente) os estalos das sinapses na cabeça do pobre PO.

Infelizmente apliquei e acompanhei esse canvas em poucos projetos reais. Mas mostro-a de maneira frequente aos alunos do curso de Requisitos Ágeis aqui na Adaptworks.  E durante ou após o treinamento, sempre recebemos feedbacks muito positivos quanto à mesma. Dessa forma, o objetivo desse texto foi socializar essa simples abordagem.  Desejo que outras pessoas sintam-se estimuladas a experimentarem e nos falarem dos resultados/dificuldades encontradas em sua aplicação. Maiores dúvidas ou sugestões, sintam-se convidados a me contatar em manoel@adaptworks.com.br ou pelo meu twitter: http://twitter.com/manoelp .  Até lá!

4 Comentários »

Categorias deste post

Gestão de Produtos, Product Owner, Requisitos

Definition of Ready : Qualidade na entrada das Sprints

Uma reclamação frequente de times de desenvolvimento (Dev Team) em Scrum é que, com o discurso de agilidade, requisitos chegam nas Sprints com baixa qualidade. Não é difícil encontrar Product Owners que mantém no topo do Product Backlog itens com granularidade ruim, pouco (ou nenhum) detalhamento e  – pior – baixo entendimento do próprio Product Owner sobre o que está sendo pedido. Isso, na maioria das vezes, transforma a Sprint Planning Meeting em uma reunião arrastada e com muitas perguntas não respondidas. Consequentemente, times fazem um planejamento de baixa qualidade e são surpreendidos ao longo das Sprints com impactantes descobertas do Product Owner sobre aquele item, o que resulta em mudanças no objetivo e desenvolvimento. Resultado: Time desmotivado. Sprint não consegue atingir meta. Product Owner insatisfeito com o time. Sistema em colapso.

Requisitos Ready se transformam em entregáveis Done

Uma prática que tem ajudado bastante nestes casos é a adição ao Scrum do conceito de “Definition of Ready”. Este conceito age de forma bem parecida com a conhecida “Definition of Done”, mas enquanto “Done” garante qualidade na saída da Sprint, “Ready” garante qualidade na entrada da Sprint.

Enquanto o Dev Team tem o compromisso de entregar ao Product Owner apenas funcionalidades Done, este por sua vez assume o compromisso em manter apenas itens Ready no topo do Product Backlog.

Um exemplo de Definition of Ready

Uma “Definition of Ready” precisa ser capaz de expressar o mesmo significado para todos que a lêem, principalmente Dev Team e Product Owner. Um exemplo:

Um Product Backlog Item está Ready quando:

– Está escrito como uma User Story INVEST;
– Possui um Teste de Aceitação automatizável;
– Possui um Wireframe de baixa fidelidade;

Caso você trabalhe com itens de diferentes tipos no seu Product Backlog, como por exemplo: itens de negócio, itens técnicos, spikes, bugs, etc., você pode optar por ter uma Definition of Ready diferente para cada um deles; afinal de contas pode não fazer sentido gerar um Wireframe para um Spike entitulado “Escolha de solução para Pagamento de Cartão de Crédito”, certo?

Quem tem a responsabilidade de tornar um item Ready?

A responsabilidade é do Product Owner, mesmo que para isso precise envolver outras pessoas. Enquanto o Dev Team trabalha, por exemplo, na Sprint 3, o Product Owner tem que garantir que os itens do topo do Product Backlog estejam Ready para quando da Planning Meeting da Sprint 4. Caso ele precise envolver o Dev Team neste trabalho,  seria interessante “oficializar” reunião(ões) de “Grooming” que já fossem previstas no TimeBox da Sprint.

O uso de “Definition of Ready” não está limitado ao Scrum, e pode ser muito útil também quando trabalhando com Kanban e outros métodos.

Treinamentos da AdaptWorks relacionados ao tema

Certified Scrum Product Owner
Requisitos Ágeis

6 Comentários »

Categorias deste post

Gestão de Produtos, Product Owner, Scrum, Time de desenvolvimento