4 razões pelas quais sua implementação ágil não está funcionando

Em uma interessante postagem, Robert Pieper, descreve 4 razões pelas quais a implelemtação ágil pode não funcionar de maneira adequada.

  1. You’re not limiting risk
  2. Lead time
  3. Consistent cost overruns
  4. No one knows why

Agile frameworks are designed to help you be light on your feet, but they don’t promise you’ll succeed in using them as intended. – Robert Pieper

O post completo do Robert Pieper pode ser lido em: https://blog.scrum.org/4-reasons-agile-implementation-isnt-working/.

Lições aprendidas, são realmente aprendidas pelas equipes?

Um item importante que existe em toda a empresa, mas é muito notório em projetos chama-se: “Lições Aprendidas”. Como o próprio nome diz, devemos aprender algo sobre algum item/entregável/status/comunicação/etapa do projeto que ocorreu durante alguma fase do projeto.

É através das Lições Aprendidas que podemos tornar recorrentes os resultados desejados; e impedir a recorrência dos resultados indesejados

Durante os últimos anos, pude participar de vários projetos, alguns com o escopo pequeno ou simples, outros complexos. Alguns com equipes formada por recursos juniores outros com equipes formadas por profissionais seniores e com grande experiência em sua área de conhecimento.

Em alguns projetos é obrigatório a entrega formal de um documento contendo todas as lições aprendidas pela equipe do projeto aos patrocinadores do mesmo.

Lessons Learned (original: http://www.thefreedomchase.com/wp-content/uploads/2014/04/Entrepreneurial-Lessons.jpg)Em todos os projetos, ocorreram situações onde uma resposta precisava ser aplicada, porém não tínhamos nos preparados para tal situação. Uma ação teve que ser tomada/executada e com isso um resultado foi obtido. Mas, se ocorrem situações em que não houve um planejamento prévio, significa que o planejamento falhou? Pode ser que sim, pode ser que não. Depende do caso…

Bom, mas o que devemos aprender com esta etapa do projeto que não deveria ser esquecida ou ignorada?

Entendo que podemos aprender a evitar que determinadas circunstâncias se repitam, isso vale para a mesma empresa ou não e/ou para projetos semelhantes. Não devemos ter como lições aprendidas a resposta para uma situação. Devemos usá-la como um conhecimento prévio, de modo que determinadas circunstâncias não ocorram novamente.

Escrever, relatar e documentar é algo que muitas empresas não identificam valor, pois a própria empresa não tem a cultura de documentar e ler. Logo, pra que escrever?! Entretanto, existem clientes que precisam saber o que o prestador do serviço aprendeu durante a execução do projeto.

Mas o que devemos levar em conta quando vamos listar/estudar as lições aprendidas?

Vejamos alguns exemplos:

  • O que aprendemos sobre o projeto em geral?
  • O que aprendemos sobre gerenciamento de projetos?
  • O que aprendemos sobre comunicação?
  • O que aprendemos sobre o orçamento?
  • O que aprendemos sobre como trabalhar com os patrocinadores?
  • O que aprendemos sobre como trabalhar com os clientes?
  • O que aprendemos sobre as atividades que ocorreram de forma como foram planejada?
  • O que aprendemos sobre as situações que não ocorreram de forma satisfatória?
  • O que aprendemos que devemos mudar?

Projetos: Teorias versus Prática

Há muito tempo que a gestão de projetos deixou de ser algo novo e sem confiança. Hoje em dia, cada vez mais as empresas possuem projetos e consequentemente, precisam que os mesmos sejam geridos.

teoria_praticaAo passar dos anos, muitos estudos foram sendo realizados e algumas metodologias, de como gerir um projeto, foram sendo desenvolvidas. Algumas teorias são mais conservadoras outras nem tanto. Algumas focam no resultado final, deixando de lado alguns fatores “sem controle”.

Mas o foco deste post não é falar das características de cada teoria existente, nem conhecimento e tempo para falar de todas tenho disponível. O que quero relatar, são observações minhas que pude, felizmente, capturar ao longo dos anos atuando como membro de uma equipe de projetos ou até mesmo como gestor de projetos.

Atualmente as duas principais metodologias (frameworks)  que a grande maioria das empresas trabalha são o SCRUM e o guia PMBOK. Existem outras como o Prince2 e uma grande quantidade, quando focamos em desenvolvimento de software.

Ao meu entender são duas excelentes metodologias para a de gestão de projetos.

Com o passar do tempo, uma necessidade que observei e que ao meu entender é deixado de lado por estas metodologias e que é fundamental para que o projeto seja um sucesso é o que eu chamo de “Fator Humano” (relacionamento humano).

Saber controlar os custos/despesas de um projeto é fundamental, até mesmo obrigação do gestor.

Controlar o “escopo” é um assunto para um outro post, mas está diretamente relacionado ao “Fator Humano“.

Em alguns casos, a falta de gestão do “Fator Humano” pode ocasionar a perda de controle do projeto, qualidade inapropriada da entrega, atrasos e tudo isso acarreta perda de tempo. Logo, perde-se dinheiro!

Já tive a infelicidade de presenciar, projetos serem cancelados pela falta de gestão do “Fator Humano”.

O relacionamento humano, a cada dia que passa se torna mais difícil entre empresas e clientes.

No passado, a “palavra” tinha uma importância fundamental. Com o passar dos anos a importância que a “palavra” tinha ficou demasiadamente fraca, sem poder. Foram criados os contratos e por fim, clientes e fornecedores (de produtos os serviços), ficam analisando os contratos para identificar falhas de modo que o produto/serviço não seja entregue ou de forma que o que foi entregue não precise ser pago.

Infelizmente, casos assim ocorrem todos os dias em empresas de pequeno, médio, grande porte, multinacionais e governo.

É uma pena que dificilmente, seja possível adaptar grande parte destas metodologias e utilizá-las realmente na prática.

Como é o gerenciado o Fator Humano em seus projetos?

Algumas coisas sobre SCRUM

O que é o SCRUM?

É um framework para gerenciamento de projetos e desenvolvimento ágil de software (não é somente para o gerenciamento de software que se pode adotar o SCRUM, entretanto sua adoção é maior nesta área).

É um framework, não uma solução completa! Logo, você deverá adaptá-lo para usar com máxima eficiência.scrum-org-logo

SCRUM baseia-se no desenvolvimento iterativo e incremental, ajudando a guiar o time durante o desenvolvimento do software.

A equipe é o foco e não o processo.

O SCRUM adota uma abordagem empírica (aceita que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes).

O SCRUM possui um conjunto de valores, princípios e práticas que auxiliam a equipe de projeto a entregar produtos ou serviços de valor em um ambiente complexo, instável e desafiador.

Por que adotar o SCRUM?

  1. É objetivo e simples.
  2. Tem uma baixa curva de aprendizado.
  3. Define papéis e responsabilidades de forma clara e consistente.
  4. No entanto, não é um processo previsível. É um processo empírico.
  5. Identifica de forma mais fácil os problemas existentes.

O SCRUM não é um processo previsível, ele não define o que fazer em toda circunstância (Ken Schwaber, 2004).

No SCRUM o desenvolvimento é feito de forma iterativa e incremental. Desta forma, a evolução é constante.

Desenvolvimento Incremental – Adiciona funcionalidades ou partes de maneira incremental. É como adicionar tijolos a um muro. Depois de vários incrementos você tem um grande muro.

Desenvolvimento Iterativo – Constrói-se algo. Depois avalia-se e em seguida faz-se alterações.

Os eventos SCRUM

No SCRUM existem quatro eventos formais que podem ser utilizados para realizar a inspeção e a adaptação:

  1. Reunião de planejamento da sprint;
  2. Reunião diária;
  3. Revisão da sprint;
  4. Retrospectiva da sprint.

O SCRUM em 100 palavras

  • Scrum é um processo ágil que permite manter o foco na entrega do maior valor para o negócio, no menor tempo possível;
  • Isto permite a rápida e contínua inspeção do software em produção;
  • As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade;
  • Entre cada 2 a 4 semanas todos podem ver o real software em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais uma “Sprint”.

Fonte: http://runningagile.com/2007/12/02/scrum-in-100-words/

No SCRUM temos

3 papéis:

  1. Scrum Master
  2. Dono do Produto (Product Owner)
  3. Time de Desenvolvimento (Development Team)

4 artefatos:

  1. Backlog do Produto (Product Backlog)
  2. Backlog da Sprint (Sprint Backlog)
  3. Incremento (Increment)
  4. Histórias de Usuário (User Stories)

5 eventos:

  1. Sprint
  2. Planejamento da Sprint (Sprint Planning)
  3. Reunião Diária (Daily Scrum)
  4. Revisão da Sprint (Sprint Review)
  5. Retrospectiva da Sprint (Sprint Retrospective)

O Manifesto Ágil

O SCRUM baseia-se no Manifesto Ágil, na qual possui alguns valores.

Valorizamos indivíduos e Interação entre eles, mais que os processos e ferramentas
Valorizamos software em funcionamento, mais que documentação abrangente
Valorizamos colaboração com o cliente, mais que negociação de contratos
Valorizamos responder a mudanças, mais que seguir um plano

Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Para maiores informações sobre o Manifesto Ágil e os 12 princípios, acesse: http://manifestoagil.com.br.