A essência do Agile

Tem cerca de 20 anos que surgiram os primeiros métodos ágeis do jeito que os conhecemos hoje, em frameworks e “receitas prontas”. No meio de tantas transformações ágeis e digitais acontecendo em empresas ao redor do mundo, muito da essência do agile tem se perdido em prol de corridas desenfreadas por estar na dianteira do mercado em termos de produtos e resultados.

No entanto, rodar Scrum ou SAFe à risca não é garantia de agilidade e nem o objetivo da agilidade é formar times que apenas sabem executar uma receita. O objetivo dos métodos ágeis é formar times de alto desempenho para resolver os mais variados desafios, respondendo às mudanças inerentes ao cenário moderno e inovador das empresas, em especial as digitais. A capacidade de um time em responder a mudanças, entregando valor contínua e ininterruptamente é o real sentido de ser ágil, embora muitas empresas acreditem erroneamente que agilidade é apenas outro nome para velocidade.

Mas afinal, se rodar XP, Kanban, etc não garante que o seu time é realmente ágil, quais seriam as características que dizem se o seu time é ou não ágil?

Para responder a esta pergunta temos de voltar no tempo e entender a essência da agilidade…

Manifesto Ágil: 2001

Em 2001, 17 dos mais renomados profissionais de tecnologia do mundo se reuniram para discutir a forma como estavam tocando os seus projetos de software. Todos eles discordavam da forma tradicional de gerir projetos à época, extremamente burocratizada e que mais destruía do que entregava valor aos clientes.

Desta reunião em que estavam os criadores de frameworks famosos como Scrum, XP, Crystal e muitos outros, surgiu o chamado Manifesto Ágil: um documento composto por quatro premissas e doze princípios que norteariam tudo o que se criou sobre métodos ágeis daí em diante.

As quatro premissas são:

Atente à frase que fecha o manifesto, ela é muito importante: mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

O manifesto é complementado por 12 princípios:

Note que o Manifesto Ágil foi criado por profissionais de TI e para profissionais de TI, mas que se você trocar a palavra software pelo produto do trabalho do seu time, verá que muita coisa faz sentido até mesmo fora da área de TI. Isso se deve ao fato de que estas ideias não surgiram exatamente aqui e nem exatamente por estas pessoas, o que nos leva um pouco mais atrás na história da agilidade…

O Novo Jogo de Desenvolver Novos Produtos: 1986

Em 1986, 15 anos antes do Manifesto Ágil ser assinado, dois professores da Harvard Business School, Hirotaka Takeuchi e Ikujiro Nonaka, escreveram um famoso artigo intitulado The New New Product Development Game. Neste artigo, eles retratam a situação do mundo à época, em que a velocidade e flexibilidade necessários para se criar produtos competitivos forçava as empresas a mudarem suas estratégias, atuando mais como times esportivos do que como departamentos, inclusive fazendo uma analogia ao rugby que mais tarde seria continuada com o advento do Scrum (que é uma jogada do rugby).

A abordagem pregada por Takeuchi e Nonaka é baseada em seis características: instabilidade embutida (missão-controle ao invés de comando-controle), times de projeto auto-organizados (como uma startup), fases de desenvolvimento sobrepostas (sprints), multiaprendizado (fail fast e shared knowledge), controle sutil (checkpoints ao invés de microgerenciamento) e transferência organizacional do aprendizado (compartilhamento fora do time). Essas características juntas tornariam-se a base de uma mudança cultural no desenvolvimento de produtos uma vez que os métodos antigos não permitiam que as empresas se mantivessem competitivas ao longo que o mercado não pára de mudar.

Foi a primeira vez documentada que se desafiou o status quo de desenvolver projetos instaurado desde a década de 60, faseado e linear, onde o valor somente era gerado quando passasse pela última etapa ao final de todo o processo, como em uma corrida de bastão, onde vence quem chegar na reta final com o bastão na mão. Na nova abordagem, as fases se sobrepõem, com analogia de um time de rugby avançando com a bola, que é passada de mão em mão e o time avançando junto, o que mais tarde originaria as sprints do Scrum.

Estas conclusões foram tiradas a partir de projetos de produtos bem sucedidos em empresas americanas e japonesas daquela década, que mostraram que era possível tirar proveito do trabalho em equipe e de uma abordagem sobreposta para reduzir o go-to-market entre outros desperdícios. Essa busca incessante pela redução do desperdício nas fábricas americanas nos leva a ideias ainda mais antigas que Nonaka e Takeuchi beberam da fonte…

Sistema Toyota de Produção:1950

O Sistema Toyota de Produção foi desenvolvido pela Toyota Motor Corporation para fornecer a melhor qualidade, o menor custo e o lead time mais curto por meio da eliminação do desperdício. O TPS é formado sobre dois pilares, Just-in-Time e Jidoka, e é normalmente ilustrado pela “casa” mostrada a seguir. O TPS é mantido e melhorado por interações entre trabalho padronizado e kaizen, seguidos de PDCA.

O desenvolvimento do TPS é creditado a Taiichi Ohno, chefe de produção da Toyota no período posterior à Segunda Guerra Mundial. Começando nas operações de usinagem, Ohno liderou o desenvolvimento do TPS ao longo das décadas de 1950 e 1960, e sua disseminação à cadeia de fornecedores nas décadas de 1960 e 1970.

O seu trabalho depois foi levado ao ocidente por James Womack e Daniel Jones no livro Lean Thinking (Mentalidade Enxuta, 1996) criando a cultura Lean nos anos 2000 (Lean Development, Lean Startup, Lean Enterprise, etc), outra vertente muito forte que influenciou e foi influenciada pela cultura agile, sendo como já foi dito, focado na eliminação dos sete desperdícios da cadeia produtiva:

1. Defeitos
2. Superprodução
3. Espera
4. Transporte
5. Movimentação
6. Processamento errado
7. Estoque

Uma vez que se trabalhe na eliminação destes desperdícios, chegaremos cada vez mais próximos de produtos Lean (enxutos): baixo custo, alta qualidade e tempo de entrega menor. Note que inclusive a superprodução é encarada como nociva, o que pode ser contraintuitivo para algumas pessoas mas que faz total sentido uma vez que o Princípio de Paretto se aplica a produtos em geral (80% das funcionalidades raramente são usadas).

O conceito de Kaizen também é muito forte aqui, garantindo a melhoria contínua dos processos em uma eterna busca pela perfeição, algo mais tarde levado pelos agilistas através de cerimônias como as retrospectivas.

E por fim, ferramentas de gestão à vista do chão de fábrica japonês, como o Kanban, mais tarde foram adaptadas para o mundo dos projetos, neste caso pelo americano David Anderson, criando outra legião de seguidores.

Agilidade para Todos

Note que os princípios da agilidade são universais e aplicáveis a qualquer grupo de pessoas que tenham de empreender projetos complexos e adaptativos. E se você leu o que escrevi acima sobre a origem da agilidade (e em consequência sua essência) deve ter entendido que um time ágil:

• trabalha como um verdadeiro time, além de ser pequeno e auto-organizado, compartilhando a responsabilidade;
• colabora e comunica-se clara e constantemente entre si, com clientes e com stakeholders, através de comunicação direta e gestão visual;
• foca na entrega de valor contínua e incremental, aprendendo a cada entrega;
• elimina desperdícios e ganha mais agilidade através de melhoria contínua;
• compartilha seus aprendizados interna e externamente ao time;

Se você tem todas estas características no seu time, parabéns, você tem um time ágil!

Note que não estou menosprezando os frameworks populares, que aliás eu adoro e uso há anos. Note também que possuir todas estas características em um time não é uma tarefa fácil, exige pessoas maduras, organizadas, com desenvolvimento orientado a valor e foco no cliente e que sim, muito provavelmente usar um método vai lhe ajudar a criar a disciplina e musculatura para chegar em um time essencialmente ágil.

Então sim, usar Scrum e outros métodos pode ser um caminho para se chegar a times ágeis e de alta performance, mas note que esses métodos são um caminho, um meio, e não o fim. Ser ágil não é e nunca será executar uma receita, mas reagir às mudanças entregando valor de maneira contínua e incremental, em um ciclo perpétuo de melhoria contínua. Ponto.

Ninguém te disse que seria fácil, certo?

Quer conhecer algumas práticas que podem ser adotadas por qualquer pessoa ou time? Leia este artigo e assista ao vídeo abaixo também!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!