quarta-feira, março 31, 2010

Por que Agile e Lean funcionam? Ou como explicar para seus executivos e líderes a hiperprodutividade que esses tais de agilistas conseguem!

Analisando as pesquisas sobre sucesso de projetos encontramos números interessantes. De acordo com o Chaos Report de 2009, em torno de 30% dos projetos de TI são bem sucedidos. Enquanto isso, surveys sobre Agilidade mostram que em torno de 80% dos projetos Ágeis terminam com sucesso. E mais que isso: empresas como a SalesForce.com obtiveram uma melhoria de quase 400% no valor gerado após a adoção da cultura Ágil, em torno de 70% de redução nos defeitos e 50% de redução no time to market para lançamento de novas versões de seus produtos.

Será mágica? Será Bala de prata? Não. Então como explicar os números impressionantes acima?

Vou tratar um pouco dos 'segredos' do Agile / Lean funcionar tão bem quando ocorre uma mudança de paradigma real dentro da organização.

Os dois pilares do Lean (e que podem ser encontrados também embutidos no Manifesto Ágil) são:
- Respeito pelas pessoas
- Melhoria contínua

Podemos resumir esses dois pontos nessa frase: "A raiz do Lean/Agile é ser um eterno insatisfeito com o status quo. Você tem que se perguntar continuamente: 'Por que estamos fazendo isso?' ". Portanto é possível compreender que o princípio de Eliminar desperdícios do Lean está umbilicalmente relacionado com o pilar positivo da melhoria contínua e da eterna insatisfação com a mesmice.

Mas vocês devem estar se perguntando: Como isso explica a hiperprodutividade Agile? Vamos explicar agora, mas lembre-se de não tirar de sua cabeça os pilares: Respeito pelas pessoas e melhoria contínua com eliminação de desperdícios.

Quando ocorre uma mudança de paradigma para o Lean, as pessoas da organização voltarão seus esforços para eliminar tudo aquilo que não agrega valor na cadeia produtiva. O livro dos Poppendieck levanta uma série de elementos para identificar os geradores de desperdícios na área de desenvolvimento de software. Mas eu vou focar nos dois mais importantes e que geram o maior impacto inicial na produtividade da empresa:

- Projetos desnecessários
- Requisitos desnecessários

A adoção estratégica de Lean deve iniciar pelo esforço de Gestão Ágil de Portfólio de Projetos. Pela elaboração de business cases enxutos e continuamente avaliados para cada projeto da empresa. Conforme descrito por Donald Reinertsen em seu livro Desenvolvendo Produtos na Metade do Tempo: eliminar projetos com baixo retorno vai gerar mais velocidade no time to market dos projetos restantes. Apesar de contra-intuitivo, quando você corta projetos você entrega mais projetos num time to market menor! Esse nível mais estratégico do portfólio de projetos é pouco tratado em processos ágeis como Scrum, XP, OpenUP, etc. Porém é fundamental para a busca da hiperprodutividade.

O próximo nível é o de requisitos desnecessários. É aí em que os processos ágeis possuem práticas e mecanismos orientados para que o desperdício de criar requisitos de pouco valor não ocorra. Aí também entra a necessidade de boas pessoas e bom time. Um bom product owner (desgraçado ganancioso, como meu amigo Yoshima gosta de resumir) é fundamental para que o desperdício (quase uma hemorragia, já que segundo o Chaos Report quase metade dos requisitos não agregam valor maior que o custo para produzí-los) estanque.

Além disso, a filosofia e práticas da Agilidade/Lean focam na auto-organização do time, na responsabilidade conjunta pelos objetivos de negócio do projeto e na produtividade com qualidade e com ritmo sustentável. Todas elas são práticas de administração consagradas e evidenciadas por Peter Drucker para liderar trabalhadores do conhecimento. Nas palavras do próprio Peter Drucker: "Knowledge workers must take responsibility for managing themselves".

No tocante à gestão de projetos também temos efeitos benéficos. O PMBOK já fala sobre o clássico ou quadrante mágico de variáveis do projeto. Ele é composto por escopo, custo, prazo e qualidade. Há também uma lei em relação a esse quadrante: das quatro variáveis, você só pode fixar três... uma irá variar.

Num projeto tradicional cascata e com preço fixo (ainda no Brasil esse é o modelo mais usado, portanto o chamo de tradicional por causa disso) é fixado o custo, o prazo e o escopo. Acho que é fácil entender agora porque a maioria dos projetos de TI falha do ponto de vista dos stakeholders: o que varia é a qualidade... e ela varia lá pro fundo do buraco!

Uma empresa Ági/Lean, entendendo que defeitos são o terceiro grande gerador de desperdícios, muda isso. Ela fixa o prazo, o custo e a qualidade(a qualidade é fixada quando usamos as práticas de engenharia Ágil. Sem elas você não será hiperprodutivo) e deixa variar o escopo. Essa mudança fundamental também ajuda a resolver o segundo desperdício: requisitos desnecessários. Quando o prazo e o custo são fixos, o product owner e os stakeholders terão que se esforçar ao máximo para atingir os objetivos de negócio almejados pelo projeto realizando apenas os requisitos importantes e de maior valor agregado, despriorizando ou eliminado requisitos de baixo valor. Veja como é exatamente isso que o cara que paga (sponsor) e outros stakeholders querem: um resultado (produto) de alta qualidade contendo o mínimo necessário de funcionalidades que resolvam seus problemas e necessidades de negócio, e ainda com a facilidade de mudar de idéia no decorrer do projeto.

Algumas pessoas orientadas ainda pelo paradigma preço fixo costumam imediatamente perguntar o seguinte: isso significa que um projeto Ágil entrega menos escopo que um cascata? E respondo: Muito pelo contrário, ele entrega um escopo de maior qualidade e valor agregado para o negócio. E é isso que o faz ser visto como bem sucedido pela organização.

Em resumo: Por que Agile / Lean funciona? Porque o respeito pelas pessoas e a busca da melhoria contínua levam à hiperprodutividade. Mas como essa hiperprodutividade ocorre quando ocorre a mudança de paradigma? Ela ocorre porque eliminam-se desperdícios das mais variadas formas e devido ao foco no resultado com ritmo sustentável. Os principais itens que geram isso no início são:
- Eliminação ou redução de projetos de baixo valor agregado.
- Eliminação ou redução de requisitos de baixo valor agregado.
- Em relação ao quadrante de variáveis do projeto: fixar custo, prazo e qualidade e deixar variar o escopo.

Não é fácil resumir o segredo do sucesso de algo, mas precisamos tentar. Esses segredos é que explicam a executivos e stakeholders porque adotar a filosofia Ágil os levará a outro patamar e também esclarecerá que só o 'processo' Ágil e suas práticas não resolverão o cerne do problema. A organização precisa de um choque cultural para que a hiperprodutividade se torne uma realidade, assim como ocorreu na Salesforce e em outras empresas que precisam do desenvolvimento de software e sistemas para manter seus negócios.


Um breve pensamento para fechar: "O Modelo tradicional cascata é errado e perigoso. Nós temos que superá-lo." - Frederick Brooks, autor do livro 'The Mythical Man-Month', em seu novo livro 'The Design of design'

terça-feira, março 09, 2010

Visao: Um ingrediente chave para o sucesso de um projeto de desenvolvimento de produto

Elaborar um consenso sobre a visão de um produto e de seus objetivos principais é constantemente citado como um dos ingredientes fundamentais para o sucesso de um projeto (que visa a construir um release desse produto). Essa afirmação é citada fortemente por Jim Highsmith em seu excelente livro Agile Project Management: Creating Innovative Products, 2nd edition.

O RUP (Rational Unified Process) já dizia isso claramente também em seu processo. Mas, como inclusive discutimos em uma thread da lista Scrum Brasil, a tendência da maioria das pessoas que adotaram o RUP foi de tranformá-lo em um processo cascata e com foco em artefatos. Vale lembrar que desde o início o RUP define em seus princípios um foco em resultados e em desenvolvimento iterativo com entrega contínua e constante de valor para os clientes. Por causa das deturpações e do foco em artefatos, muita gente "preenche" o documento de Visão. Esse é um erro grave e que não atende o objetivo de definir em colaboração os objetivos do projeto.

Se a Visão é tão importante em qualquer projeto de desenvolvimento de um produto, por que tantos times sofrem com a falta de Visão? A resposta é que criar uma Visão interessante, objetiva, realista e focada é difícil. Ainda mais difícil porque elaborar a Visão de um produto não é "preencher" um documento... é discutir colaborativamente, com TODOS os stakeholders, os porquês, os o quês (o quês de alto nível) e os trade-offs de um produto.

Alguns podem se perguntar: mas se o processo é Ágil/Iterativo e a natureza do desenvolvimento de um produto é algo volátil, como criar uma visão clara e firme? Essa dicotomia se resolve, de acordo com Highsmith, quando você lembra que os detalhes dos requisitos sim são voláteis, mas não a visão geral dos objetivos de negócio que devem ser atingidos.

Projetos que começam com um Visão clara do que precisam construir como produto e dos tradeoffs que enfrentam tem a seguinte vantagem: entregar dentro de um prazo e de um custo fixo. Prazo e custo fizo em processo ágil? Esse Papo tá de papo com a gente... ficou louco! Não... rs. Projetos que usam um processo Ágil podem ter prazo e custo fixo sim. O prazo e o custo podem ser fixos, o que variará é o escopo! E essa variação do escopo é ótima, pois conhecendo os objetivos de negócio do produto fica mais fácil tomar a decisão mais importante em um projeto de desenvolvimento de software: saber o que NÃO construir. A visão nos ajuda a entender o que é menos importante e que em muitas instâncias não irá ajudar a resolver os problemas dos stakeholders do projeto. Ajuda a eliminar ou despriorizar aqueles requisitos que raramente ou nunca serão usados, conforme pesquisa do CHAOS Report.

Não vou dar dicas e técnicas de como criar uma Visão interessante e útil (só uma :-) !). Outros autores já fizeram isso bem melhor do que eu poderia fazer nesse artigo. Recomendo que comecem pelo livro do Jim Highsmith que já citei acima. A dica que vou dar e que parte de diversos autores (Mike Cohn, Scott Ambler, Philipe Kruchten e Jim Highsmith) é: Com o consenso sobre a visão podemos iniciar as iterações do projeto para construir o produto final pedaço a pedaço. Não precisamos esperar TODOS os requisitos detalhados serem definidos. Se o produto é pequeno, uma única reunião com todos os stakeholders pode ser suficiente para elaborar essa Visão. Se o produto é médio ou grande, utilize a idéia da Iteração Zero (o mesmo que a famosa "Fase de Iniciação" do RUP).

Meu foco neste post foi lembrar e reforçar o seguinte: a Visão NÃO é um documento a ser preenchido (só de escrever essa frase me dá arrepios!). Ela é um esforço consensual do time de stakeholders para definir quais problemas precisam resolver, quais objetivos de negócio devem ser atingidos, o que esperam do produto final como solução e os trade-offs que devem ser respeitados. Lembre-se: o sucesso de um projeto de desenvolvimento de um produto depende diretamente do alinhamento da equipe com a Visão e os objetivos de negócio.


Veja as Estatísticas