Série: Agile Brazil 2010 | Parte 1 de 6 > Cobertura completa da primeira conferência nacional de métodos ágeis do Brasil
Acabei de voltar para o hotel. Ainda sinto a energia do dia inteiro mergulhado em uma experiência prática de XP que mexeu comigo em vários níveis. Foram horas intensas, cheias de teoria aplicada, interações sinceras, e desafios reais. Mas o que mais me marcou foi o cuidado dos facilitadores — Bruno Pedroso, Dairton Bassi, Daniel Wildt, Giovanni Bassi, Hugo Corbucci e Renato Willi — em não apenas ensinar, mas provocar mudança. É raro sentir tanta coerência entre discurso e prática num evento.
Pomodoros e Propósitos
Logo no início fomos apresentados à dinâmica do Pomodoro. As sessões cronometradas de 25 minutos, seguidas por pequenas pausas, funcionaram não só como gestão de tempo, mas como delimitadores claros de foco. Cada novo Pomodoro trazia um tema central, que era explorado com uma breve introdução teórica e, na sequência, uma atividade prática. Essa alternância criava um ritmo que nos mantinha atentos e ativos, mesmo depois do almoço, quando a maioria dos eventos costuma perder energia.
Durante um dos primeiros ciclos, os instrutores pediram que colocássemos no mural o que esperávamos do workshop. Foi um gesto simbólico, mas que me pegou: naquele momento, senti que estávamos sendo tratados como participantes, não como meros espectadores. O mural virou uma espécie de backlog emocional da turma — e foi revisitado durante o dia.
A Caixa Eletrônica de Papel
A principal atividade do workshop foi a simulação de desenvolvimento de um produto — um caixa eletrônico. Cada grupo deveria construir a interface e a funcionalidade com papel, canetas, caixas de sapato, tesouras e fita adesiva. Soa infantil? Pode até parecer, mas foi uma das experiências mais imersivas que já tive. A limitação do material aguçava a criatividade e forçava a colaboração verdadeira.
Trabalhamos em sprints curtas, com papéis bem definidos: devs, testadores, cliente, facilitador. A cada iteração precisávamos apresentar uma versão funcional do nosso produto, receber feedback do cliente (representado pelos facilitadores), ajustar, testar, e seguir. A cada ciclo, novas exigências surgiam — às vezes conflitantes com requisitos anteriores, o que tornava tudo ainda mais próximo da realidade de um projeto ágil real.
Percebi como é fácil cair em armadilhas mesmo num ambiente controlado: falar mais do que ouvir, decidir sozinho sem validar, ignorar os testes para entregar mais rápido. E vi o contrário também: o poder da comunicação frequente, da simplicidade, de iterar com propósito. No fim, não foi sobre construir um caixa eletrônico de papel — foi sobre construir um time.
Lidando com WIP: Menos é Mais
Durante uma das simulações, nossos grupos foram surpreendidos por uma interrupção: os facilitadores nos desafiaram a reduzir o número de funcionalidades sendo desenvolvidas simultaneamente. Foi aí que o conceito de Work In Progress (WIP) apareceu com força. Até então, estávamos trabalhando em três, quatro frentes ao mesmo tempo. O resultado? Nenhuma delas estava realmente pronta.
Controlar o WIP é essencial em XP porque o excesso de tarefas paralelas aumenta o tempo de entrega de cada uma delas e sobrecarrega o time. Ao limitarmos o número de funcionalidades ativas, percebemos um aumento imediato na fluidez do trabalho e na clareza da comunicação. Ficava mais fácil saber quem estava com o quê, o que precisava de ajuda e o que realmente era prioridade.
A sensação era libertadora: terminar algo completamente antes de começar outra coisa trazia um senso de conquista que motivava o grupo. Mais do que isso, fortalecia a confiança — tanto entre os pares quanto com os stakeholders. Essa mudança simples no fluxo aumentou a qualidade geral e reduziu os retrabalhos.
WIP limitado é mais do que uma métrica. É uma prática cultural. É um lembrete de que fazer menos com mais foco é frequentemente a melhor forma de entregar valor rapidamente. E XP, com seu foco em entregas frequentes e contínuas, depende diretamente dessa disciplina para funcionar bem.
Lead Time: O Que Demora Não É o Código
Em outro momento do dia, fomos convidados a refletir sobre o tempo entre uma funcionalidade ser solicitada e estar pronta para uso: o famoso Lead Time. Essa métrica, que parece simples, revelou gargalos interessantes. Percebemos que a maior parte do tempo era consumida antes de qualquer linha de código ser escrita. Espera por validação, ajustes no escopo, dúvidas mal resolvidas — tudo isso empurrava a entrega para frente.
XP responde a isso com ciclos curtos, feedback constante e presença ativa do cliente. Quanto mais rápido identificamos o que está em dúvida ou mal definido, mais rápido conseguimos resolver. Isso exige coragem: coragem de chamar o cliente para conversa difícil, de jogar fora funcionalidades que não agregam, de dizer “ainda não sabemos”.
No exercício da caixa eletrônica, vimos que alguns times tinham lead time pequeno porque faziam entregas menores. Outros optaram por agrupar funcionalidades, mas o resultado foi menos entrega real e mais sensação de progresso ilusório. O aprendizado aqui foi claro: fragmentar o valor não é enfraquecer — é tornar visível e gerenciável.
Trabalhar com atenção ao lead time nos força a refletir: quanto do que estamos fazendo é realmente desenvolvimento? E quanto é ruído, espera, burocracia? XP convida a enxugar esse ruído para que possamos dedicar nosso tempo ao que realmente importa: entregar valor para o usuário.
Cycle Time: Entender o Ritmo do Time
Por fim, discutimos o Cycle Time — o tempo que leva para uma tarefa sair do “em andamento” até o “feito”. Diferente do lead time, ele foca exclusivamente no tempo de produção. Foi interessante perceber como, mesmo em uma dinâmica de papel e tesoura, essa métrica fazia sentido.
Alguns grupos tinham cycle times muito curtos — mas à custa de pular etapas. Outros mantinham uma cadência mais constante, com entregas pequenas mas sólidas. Isso gerou uma discussão valiosa: a velocidade não pode sacrificar a qualidade. E XP está sempre batendo nessa tecla: só entregue quando estiver realmente pronto. Testado, revisado, útil.
Entender o cycle time ajuda o time a fazer previsões melhores e ajustar sua capacidade. Nos exercícios, times que monitoravam de perto os tempos de entrega conseguiam se adaptar mais rápido às mudanças de requisito. Era como se tivessem desenvolvido um senso de ritmo coletivo.
Esse senso de ritmo, no XP, é reforçado por práticas como Integração Contínua e Testes Automatizados. Quanto mais fluido o ciclo, mais espaço para inovação e aprendizado. E menos ansiedade. Afinal, quando se sabe o tempo médio para entregar algo, é mais fácil alinhar expectativas e planejar de forma realista.
Cycle time nos lembra que sustentabilidade é chave. Não adianta correr uma maratona em ritmo de sprint. Equipes XP precisam saber quando acelerar, mas também quando respirar. O segredo está em medir, conversar e ajustar — sempre como um time.
XP é uma Postura
Daniel Wildt trouxe uma fala que me pegou forte: XP não é sobre ferramentas, é sobre postura. A frase soava simples, mas vinha carregada de crítica a ambientes onde a técnica é celebrada, mas os valores são ignorados. Ele nos apresentou o Chaos Report, apontando que projetos falham mais por problemas de comunicação e alinhamento do que por bugs. Falta de escopo claro, falhas de expectativa, ausência de iteração com o cliente — esses são os reais vilões.
Durante esse momento, discutimos também os valores centrais do XP: coragem, feedback, simplicidade, comunicação e respeito. E ficou evidente que não basta dizer que o time é ágil. É preciso praticar esses valores diariamente, nos pequenos detalhes: num commit bem descrito, numa retrospectiva sincera, na humildade de refatorar algo que foi escrito às pressas.
Programação em Par: mais do que código
Mais para o fim do dia, fizemos uma atividade de programação pareada. A tarefa parecia simples: escrever um algoritmo que convertesse números para palavras em inglês. Mas logo se tornava claro que a dificuldade não estava no problema, mas no como resolver juntos. Era um espelho do trabalho em equipe. Tivemos que ouvir, explicar, refatorar decisões, ajustar estilo de código — tudo em tempo real.
Foi nesse exercício que entendi de verdade o impacto do XP no cotidiano. Trabalhar em par não é apenas uma técnica, é um treinamento para a colaboração. Cada linha de código se tornava uma conversa. E isso muda tudo.
Saí Exausto, Mas Animado
Quando voltei para o hotel, ainda segurando minha mochila, fiquei parado olhando para a parede por alguns minutos. Eu estava mentalmente exausto, mas ao mesmo tempo inspirado. Com vontade de aplicar. De estudar mais. De ensinar. A experiência foi além do conteúdo técnico — foi sobre um jeito diferente de existir dentro de um time de desenvolvimento.
A todos os facilitadores, meu mais sincero agradecimento. E a todos os colegas que dividiram essa jornada hoje: que possamos carregar esse XP no dia a dia. Com mais testes, mais pares, mais escuta, mais entrega.
Com mais propósito.
Navegação da Série Agile Brazil 2010:
- Atual: Parte 1 - Workshop de XP na Prática
- Próximo: Parte 2 - Story Mapping com David Hussman
- Parte 3: Minha Primeira Palestra Ágil
- Parte 4: Retrospectivas com Hugo Corbucci e Mariana Bravo
- Parte 5: Coaching de Guerrilha com Francisco Trindade
- Final: Parte 6 - Ponha as Cartas na Parede com Paulo Caroli