Como montar sua estratégia de transição para a Agilidade

Estamos repletos de situações e contextos onde há uma grande dificuldade de aplicação prática dos conceitos Ágeis. Alguns dizem que o problema é cultural, outros culpam a mentalidade de chefes e gestores. Será que é isso mesmo? ou será que estamos tentando encaixar a qualquer preço a solução desejada, ao invés da solução necessária? O fato é que todos os métodos Ágeis – Scrum, XP, Kanban – seguem uma certa composição estratégica. E é disso que você precisa para fazer sua transição para Agilidade.

A meta não é usar um método. A meta é fazermos melhor, entregando o software certo na hora certa para nossos clientes. Métodos são grandes abstrações de implementações que se concretizam no campo de batalha. Problemas e dificuldades começam a aparecer quando o instrumento de desejo é o método, o rótulo, ou o selo. Dependendo do contexto, buscar a conformidade com Scrum, ou com qualquer outro método Ágil, pode ser tão danoso quanto buscar a conformidade com processos rígidos.

Qual é então a função de um método Ágil? Todos os métodos tem seu espaço de aplicabilidade. Scrum é indicado para quando há um time multi-disciplinar buscando entregar um único projeto/produto de forma auto-organizada para um único cliente. Qualquer mudança em qualquer uma dessas variáveis torna a fórmula muito instável, com efeitos colaterais imprevisíveis. Infelizmente, o contexto para o qual o Scrum é indicado é a excessão. A regra, ou seja, a situação mais comum, é o caos.

Vários clientes, equipe dividida entre múltiplos projetos, plataformas tecnológicas diferentes, estruturas de gestão ainda muito hierarquizadas. E a pergunta de muitos continua sendo: Aqui na minha empresa temos essa e essa situação, como faço Scrum nesse caso? A resposta franca e direta deveria ser: “Não faça! O Scrum não foi feito pra isso!”

A busca pelo selo “Aqui fazemos Scrum”, nos cega para as grandes possibilidades que o modelo Ágil nos dá. Quando usamos Ágil como modelo, como molde para compor uma estratégia de melhoria, uma estratégia de design do processo; aí entramos em outro jogo.

O chef de cozinha vs o cozinheiro

A analogia do chef de cozinha vs cozinheiro é ótima para explicar a natureza de processos. O chef de cozinha faz o design de uma receita que o cozinheiro repetirá à exaustão até ser capaz de fazer o prato no menor tempo e com a maior conformidade possível a especificação original do prato.

Na busca pela Agilidade, às vezes tentamos ser cozinheiros. Tentamos implementar a receita pré-concebida até uma conformidade plena. Nos frustramos porque não conseguimos planejar o escopo em um timebox, porque não conseguimos estimar com planning poker, porque o cliente não respeita os pontos da iteração ou porque a equipe não se levanta para fazer a Daily Meeting no horário combinado.

O plano de obter o selo “Aqui fazemos Scrum” é desafiado pelo mundo como ele é.

É hora de aprendermos a usar a Agilidade para criarmos sistemas de trabalho que vão, de fato, endereçar os problemas que temos nas mãos. É hora de colocar o chapéu de chef e de criar receitas para os problemas do dia-a-dia. A solução one-fits-all simplesmente não faz sentido.

As Estratégias

Há um pouco de estratégia em todo o design. Todos os métodos lidam com certas questões que são bem universais para apoiar a gestão de qualquer sistema de trabalho.

as-5-estrategias

  1. É preciso que o seu sistema se preocupe de forma proativa em “fazer a coisa certa”.
  2. Grandes lotes de trabalho carregam consigo muita ineficiência de fluxo e são ineficazes para dar boas soluções a qualquer problema que você esteja tentando resolver para seus clientes. É preciso que o trabalho seja quebrado em unidades pequenas.
  3. As melhores soluções para os problemas do seu cliente virão de múltiplas mentes debruçadas e alinhadas em torno de uma meta comum. É preciso colaborar para conquistar.
  4. A gestão do trabalho em progresso é fundamental. É preciso coordenação tática em torno de um sistema com opções e regras explícitas.
  5. Resultados precisam estar tangíveis. Sistemas de trabalho precisam ser empíricos, rodando em pequenos ciclos de feedback com resultados tangíveis para a execução de cada ciclo. É assim que conseguimos avaliar objetivamente os resultados do que estamos fazendo e dirigir as coisas para o caminho que queremos seguir.

Nesse vídeo, eu entro em detalhes sobre como cada uma dessas estratégias deve se posicionar no seu plano estratégico, enquanto você faz o design do seu sistema de trabalho.

Todos os métodos que lidam bem com desenvolvimento de software atualmente, incluindo o Scrum, o XP, o Kanban, seguem essa composição estratégica. Essa essência é mais importante do que os métodos. Ao usar essas estratégias para compor o seu sistema de trabalho, você vai otimizar os seus resultados. E estará usando a essência Ágil pra fazer isso.

E aí sim, Ágil será um meio para obter o que realmente queremos, e não um fim em si mesmo.

Para saber mais

Se você quer saber mais sobre como se tornar um verdadeiro chef para o design de sistemas de trabalho e, assim usar a essência Ágil para obter melhores resultados, eu recomendo dar uma olhada no programa “Zen e a Arte da Gestão de Software”.

Para uma estratégia nesses moldes para o caso de você estar em um contexto de manutenção do seu produto de software, eu recomendo assistir ao webinário gratuito: Como gerir a manutenção do seu produto de software.

No dia 09/08/2016 fiz uma palestra exatamente sobre esse assunto no Agile Trends Gov em Brasília.
Baixe aqui os slides da palestra

  • Anizair Lopes

    Ótimo artigo, bem didático e focado no ponto em que temos que mudar nossas mentes voltando para a pergunta se realmente estamos fazendo Ágil em nossos trabalhos. Muito Obrigado.