16 dicas para times de software NÃO serem ágeis


Tópico: Não agregar valor ao cliente

1 – O cliente/usuário não entende tanto de software como o time de desenvolvimento, sempre que ocorrer algum problema, seja de escopo mal entendido ou mesmo atraso no projeto é uma ótima prática colocar a culpa no cliente/usuário.

2 -Se o cliente está insatisfeito é porque você  é mal compreendido e  ele não tem a honra de ser seu cliente/usuário.

3 – Focar em entregar o máximo de requisitos que aparecer no backlog não tentando entender a real necessidade da companhia, não entregando em primeiro o que agrega mais valor e gera mais retorno. Afinal no final do mês ele vai pagar de qualquer forma suas horas trabalhadas, por que se preocupar com o lucro do cliente?

Mas se você quiser agregar valor ao cliente, uma forma é entregar em primeiro lugar o que mais agrega valor ao cliente na medida certa e na hora certa. Um exemplo real é o caso da startup Easy Taxi, seu primeiro MVP foi um simples formulário online onde perguntava o nome da pessoa, seu número de telefone e endereço. O botão de “pedir taxi” era pra mandar um e-mail que Tallis(fundador) recebia, ele via o ponto de taxi mais próximo, ligava para o taxi e ligava para a pessoa. Conseguiu fazer quatro vendas e viu que o negócio fazia sentido. Depois foi fazer o aplicativo.

Outro exemplo é se tem a demanda para construir um e-commerce, poderia começar pela página mais importante, a de visualização e venda do produto, os cadastros periféricos podem ficar em banco de dados, deixe as telas de cadastros de produtos para depois, pois ela não agrega valor, o que agrega mais valor é visualização e venda do produto, com isso vai conseguir lançar o e-commerce de forma mais ágil gerando retorno de investimento antecipadamente e também aprendendo mais rápido o que precisa ser melhorado.

4 – Não aceitar mudanças de requisitos, senão irá atrasar o cronograma e gerar retrabalho para a equipe.

Tópico: Não ter Planejamento

5 – Não fazer planejamento de roadmaps (mensal ou trimestral), não ter plano de entregas de sprints, seguindo a metodologia dos grandes desbravadores, navegando sem saber onde vai chegar.

Tópico: Não ter gestão da equipe

6 – Não ter métricas da equipe,  não contar quantidade de histórias entregues por sprint, histórias planejadas x realizadas, quantidade de bugs por sprint, bugs em  homologação e produção.

7 - Não saber qual é quantidade de histórias que a equipe tem capacidade de entregar, seja por sprint ou em um determinado período de tempo.

8- Medir as entregas através de gráficos de gantt bem elaborados em vez de entregas reais de software funcionando.

9 – Não ter controle e avaliação de riscos de capacidade e competência da equipe, o time é totalmente alto gerenciável, certo?

10 – Não fazer cerimônias de retrospectiva no mínimo 1x por mês, pois o time não precisa melhorar, deixe o cliente reclamar pra descobrirmos se tem algo errado.

11 – Caso faça retrospectivas, não precisamos falar sobre os indicadores e métricas da equipe para tentar melhorar a performance e qualidade, pois não precisamos destas métricas, certo? Fale apenas dos pontos positivos e negativos, vai conseguir ter melhoria continua baseado em achismos, e o cliente vai ser obrigado a acreditar na sua palavra, decisão em cima de dados/fatos não são importantes mesmo.

12 – Não se preocupar com a motivação da equipe, nem com o seu ambiente de trabalho, a Google fala que o ambiente influencia na motivação das pessoas, e pessoas motivadas produzem melhores resultados, mas isso só funciona na Google, não na sua empresa.

Topico: Qualidade

13 – Não se preocupar em entender de arquitetura,  boas práticas de engenharia de software e excelência técnica da equipe.

14 – Não ter software funcionando utilizado pelo cliente ao final de ciclos de iteração, seja em sprints ou mensal, etc.

15 – Não trabalhar em conjunto com outros times, nem se preocupar em entender toda arquitetura de forma integrada, fazer apenas a sua parte da entrega, caso aconteça algo errado, a culpa é do outro time que é fraco.


16 – Não se preocupar em ter boas Histórias de Usuário com critério de aceite, gerando documentações em excesso que ninguém consegue ler ou não ter nenhum tipo de documentação sem processo de descoberta e validação de necessidades.

1 comentários:

  1. Oi Thiago,

    Como você avalia a aplicação do Ágil em contextos mais determinísticos que complexos?

    Abs,
    Buzon

    ResponderExcluir

 

Sobre

Agile Coach, Scrum Master, Eng. de Software com formação em Administração de Empresas em Análise de Sistemas.

Paixão por Software e Administração, foi como unir fogo com gasolina, combustão!

Comecei a programar aos 13 e nunca mais quis parar de respirar software.

Acordo todos dias até hoje com a mesma empolgação de um garoto de 13 anos para criar ou aprender algo novo.
A arte de criar formas de vida virtuais #Tron

Thiago Torricelly

Thiago Torricelly