Características do Scrum Master, como sair da teoria e ir para a prática

As características do Scrum Master vão além do que está escrito no Scrum Guide: empoderar e facilitar as decisões do time, manter o foco na entrega, construir relações de confiança, antecipar problemas, saber fazer as perguntas certas, trabalhar com o Product Owner (e não contra ele), conhecer práticas de engenharia, cumprir promessas e pedir/aceitar feedback.

Empoderar e facilitar

Ajudar o time a encontrar o melhor caminho para entregar o objetivo do Sprint, sem tomar as rédeas quando o prazo aperta.

Foco na entrega

Observar o time e eliminar distrações técnicas que tirem o foco da meta do Sprint.

Relações de confiança

Reconhecer pontos fortes das pessoas e encorajar o crescimento de cada uma dentro do time.

Antecipar problemas

Fazer gestão de impedimentos de forma organizada, com indicadores que permitam agir antes do problema travar o fluxo.

Perguntas certas

Perguntar sem tirar a autonomia do time, gerando insights que mudam a percepção do que estava travado.

Trabalhar com o PO

Garantir um bom trabalho do Product Owner em vez de competir com ele.

Práticas de engenharia

Conhecer e fomentar automação de build, refactoring, TDD e pair programming.

Cumprir promessas

Não prometer o que não pode cumprir – é isso que sustenta a confiança do time.

Pedir e aceitar feedback

Buscar ativamente sugestões de melhoria, mesmo quando incomodam.

Está cada vez mais frequente as vagas de Scrum Master abertas no Brasil, por causa do crescimento dos métodos ágeis por aqui. Com esse crescimento, muita gente tem a teoria afiada, mas ainda sem entender as características do Scrum Master na prática.

Certificações valem a pena?

O crescimento das certificações para Scrum Master chama a atenção – são tantas instituições que fica difícil saber qual é o valor profissional real que elas trazem. Na prática, vale sim – mas não pela certificação sozinha (que não vale nada isolada), e sim pelo aprendizado que o processo de se certificar traz. A certificação garante que você sabe a teoria; a teoria sem a prática não leva muito longe.

09 características do Scrum Master

Muita gente está entrando no mercado ágil com uma base teórica rica, mas ainda sem a mesma quantidade de experiência prática. As 9 características a seguir foram aprendidas na prática, sem curso ou certificação.

Empoderar e facilitar as decisões do time

O grande foco do Scrum Master é ajudar o time a encontrar a melhor maneira de entregar o objetivo do Sprint. O cenário comum é: o time atua sozinho no começo do Sprint, sem interferência do SM – mas faltando poucos dias para terminar, ao perceber que não vai atingir o objetivo, o Scrum Master começa a determinar atividades e tomar as rédeas. Isso já é perda de empoderamento.

O objetivo do SM é empoderar o time e também estar presente. Deixar o time decidir sem facilitar sua jornada durante o Sprint aumenta as chances das coisas não saírem como planejado – o SM deve estar presente no dia a dia, não ser apenas um facilitador de reuniões. A soma de empoderamento e facilitação garante uma Sprint mais tranquila.

Estar sempre focado na entrega

O bom Scrum Master observa tudo que acontece em volta do time e dentro dele, agindo a qualquer sinal de desvio de foco. Distrações não vêm só de fora do time – podem acontecer quando o time começa a desenvolver algo que não está relacionado à meta do Sprint em vez de algo mais prioritário. Estar atento, focado e eliminar essas “distrações técnicas” é uma das principais características do Scrum Master.

Constrói relações de confiança

A melhor maneira de empoderar o time é confiar nele – com atitudes simples, como ajudar novos membros a liderar reuniões ou facilitar conversas dos desenvolvedores diretamente com o cliente. Reconhecer os pontos fortes de cada pessoa e encorajá-la a usá-los também gera confiança: por exemplo, pedir para um desenvolvedor forte em determinada tecnologia ajudar na formação de outros, trabalhando em par. Construir relações de confiança é o que ajuda a formar um time de alta performance.

Antecipar problemas

Remover impedimentos não é função exclusiva do Scrum Master – é algo que todos devem observar, para não deixar que impedimentos travem o fluxo. A resposta para “como impedir que impedimentos aconteçam” é fazer uma excelente Gestão de Impedimentos, organizada a ponto de gerar indicadores como:

• As principais causas de impedimentos
• Fase em que mais ocorrem impedimentos
• Tipos de criticidade dos impedimentos
• Tempo de resolução dos impedimentos

Com essas quatro métricas, é possível antecipar e resolver problemas. Por exemplo: se os impedimentos ocorrem na maioria das vezes durante o desenvolvimento, causados pela falta de Ready das histórias de usuário, gerando em média 3 dias de demora por user story – isso significa que os itens deveriam estar Ready pelo menos 3 dias antes do Sprint Planning.

Saber fazer as perguntas certas

Todo Scrum Master deve saber fazer as perguntas certas na hora certa. O desafio é perguntar sem incomodar nem retirar a autonomia do time – por isso o SM deve estar atento aos detalhes falados durante o dia e durante a Daily. Uma pergunta bem feita pode gerar um insight que muda toda uma percepção sobre algo que estava travado.

Trabalhar com o PO e não contra o PO

O Product Owner tem mais contato com cliente e stakeholders, mas isso não o torna diferente dos demais – o trabalho de PO e SM é fazer o time render o melhor possível. É comum o ambiente onde SM e PO trocam mais farpas do que geram resultados juntos; a ação correta é o SM trabalhar para garantir um bom trabalho do PO. Se existe dificuldade com o Product Owner ou com as atividades dele, provavelmente o Scrum Master não está executando bem o seu papel.

Conhecer de práticas de engenharia

“Scrum Master cuida do ágil e a engenharia cuida das práticas de engenharia” é uma divisão de responsabilidades até aceitável, mas isso não deve fazer o Scrum Master se calar para tudo de engenharia (e vice-versa). Uma das características do Scrum Master é conhecer boas práticas de engenharia, como automação de testes, integração contínua e refactoring – e saber fomentar:

• Automação de builds e integração contínua: reduzir o tempo com trabalho manual gera produtividade e qualidade.
• Refactoring: backlog de débito técnico é uma das causas mais comuns de fracasso de projetos.
• Automação de testes e TDD: reduz o tempo de execução de testes e garante que todo incremento entregue não quebre o que já foi entregue.
• Pair programming: melhora a qualidade e o tempo de desenvolvimento.

Outras práticas de engenharia também são bem-vindas – tudo que facilitar e garantir a qualidade da entrega é válido. Todo Scrum Master deve facilitar boas decisões técnicas, não só reuniões e conflitos.

Cumprir promessas

Não prometa o que não pode cumprir. Se você promete e não cumpre, provavelmente seu time não tem tanta confiança em você. Se disse que uma história vai sair ou entrar no Sprint, isso deve acontecer; se prometeu alinhar algo com o cliente, faça. Caso contrário, você perde a confiança do time – e isso faz tudo ruir.

Pedir e aceitar feedback

Um bom Scrum Master deve saber escutar que algo não vai bem e transformar isso em aprendizado. Pedir feedback não é simples, porque as pessoas ficam incomodadas em dar – mas pedir sugestões (como “como vocês acham que podemos fazer nossa retro?”) é uma forma simples de receber. O importante é estar sempre preparado para absorver o máximo das sugestões, mesmo as que soarem ruins.

Erros comuns nas características do Scrum Master

• Tomar as rédeas do time quando o prazo aperta, em vez de manter o empoderamento até o fim do Sprint.
• Ser apenas um facilitador de reuniões, sem estar presente no dia a dia do time.
• Tratar SM e PO como lados opostos, em vez de trabalhar para garantir um bom trabalho do Product Owner.
• Deixar de fazer Gestão de Impedimentos de forma organizada, perdendo a chance de antecipar problemas recorrentes.
• Prometer prazos ou alinhamentos que não podem ser cumpridos, corroendo a confiança do time.
• Evitar pedir feedback por desconforto, perdendo oportunidades reais de melhoria.

Perguntas frequentes sobre as características do Scrum Master

Sprint Retrospectiva: Em busca da Melhoria Contínua

Sprint Retrospectiva é o rito do Scrum em que o Time Scrum avalia o Sprint que acabou de se encerrar – o que foi bom e o que deve melhorar – traçando planos de ação em busca da melhoria contínua. É a última cerimônia do ciclo, logo após a Sprint Review, e dura cerca de 1 hora.

O que é a Sprint Retrospectiva

Não importa o quão bom é o Time Scrum: os membros devem sempre buscar oportunidades de melhoria para o próximo ciclo. A Sprint Retrospectiva fecha o ciclo de desenvolvimento, normalmente sendo a última cerimônia, logo após a Sprint Review. Participam todo o Time Scrum, o Scrum Master e o Product Owner, com duração aproximada de 1 hora – podendo se estender quando algum assunto fica mais “quente”.

Técnicas de Sprint Retrospectiva

Existem várias técnicas de retrospectiva, e cabe ao Scrum Master definir qual a melhor para cada momento. A mais utilizada – e talvez a mais simples – é o modelo “start-stop-continue”, em que os membros do time respondem a três perguntas:

• Devemos começar a fazer… (start)
• Devemos parar de fazer… (stop)
• Devemos continuar a fazer… (continue)

O Scrum Master, junto com o Time Scrum e o Product Owner, discute todos os pontos levantados nas três perguntas e, quando necessário, cria um plano de ação para o item em questão.

Priorizando as ações de melhoria

É comum que muitos planos de ação sejam levantados numa Sprint Retrospectiva. Por isso, é importante que todos os presentes votem para definir qual a prioridade e qual plano de ação será de fato executado dentro do próximo Sprint.

Erros comuns na Sprint Retrospectiva

• Levantar muitos planos de ação e não priorizar nenhum, perdendo o foco no próximo Sprint.
• Não aplicar nenhuma técnica estruturada (como start-stop-continue), tornando a conversa vaga.
• Deixar de incluir o Product Owner na retrospectiva, perdendo a visão de negócio sobre os pontos levantados.
• Tratar a retrospectiva como reunião de reclamação, sem transformar os pontos em planos de ação reais.

Perguntas frequentes sobre Sprint Retrospectiva

Sprint Scrum: Ciclo de desenvolvimento

Sprint Scrum é o nome do ciclo de desenvolvimento do Scrum, com duração de 2 a 4 semanas (o time-box do ciclo). Todos os Sprints de um projeto devem ter a mesma duração. Dentro do Sprint acontecem a Daily Scrum todos os dias e, ao final, a Sprint Review, Sprint Retrospectiva e a Sprint Planning do próximo ciclo.

O que é o Sprint Scrum

Sprint Scrum é o nome de um ciclo de desenvolvimento do Scrum. Os Sprints podem durar de 2 a 4 semanas – esse é o time-box do ciclo – e todos os Sprints de um projeto devem ter a mesma duração. Diariamente, o Time Scrum realiza a Daily Scrum; ao final do Sprint acontece a Sprint Review, em que é apresentado um incremento de software funcionando.

Tamanho do Sprint Scrum

O que define o tamanho do Sprint é a estabilidade do escopo: se o projeto tem um escopo que sofre muitas alterações ao longo do tempo, é indicado um Sprint menor; se as alterações são poucas e o escopo é mais estável, pode-se avaliar Sprints maiores. Durante o projeto, não é recomendado variar o tamanho do Sprint – isso gera instabilidade na Velocity do time.

Quando o Sprint Scrum acaba?

O Sprint Scrum termina em duas situações: quando se atinge o time-box definido, ou quando o Time Scrum entende que a Meta do Sprint não será mais alcançada ou mudou.

Executando o Sprint Scrum

Durante o Sprint, o Scrum Master atua para resolver todos os impedimentos que o time possa ter, além de garantir que o time esteja blindado de interferências externas, mantendo o foco nas atividades do Sprint.

Mudanças de escopo nos itens do Sprint Backlog não são bem-vindas – devem ser evitadas nos itens que o time já está desenvolvendo. Quando necessárias, devem ser negociadas junto ao Time Scrum e ao Product Owner sobre como entrarão no Sprint Backlog.

Ao final do Sprint Scrum, acontecem a Sprint Retrospectiva e a Sprint Review – e logo na sequência já se realiza a Sprint Planning do próximo Sprint.

Erros comuns no Sprint Scrum

• Variar o tamanho do Sprint entre ciclos, gerando instabilidade na Velocity do time.
• Aceitar mudanças de escopo nos itens do Sprint Backlog sem negociar com o Time Scrum e o Product Owner.
• Deixar o time exposto a interferências externas durante o Sprint, perdendo o foco na meta.
• Continuar um Sprint mesmo quando o time já percebeu que a Meta do Sprint mudou ou não será mais alcançada.

Perguntas frequentes sobre o Sprint Scrum

17 mitos sobre Métodos Ágeis: E como existem mitos! (O 14º é o melhor)

Os mitos mais comuns sobre métodos ágeis incluem achar que agilidade é novidade, que elimina documentação e design, que tem pouco planejamento, que só funciona em projetos pequenos ou colocalizados, que Scrum e Kanban são inimigos, e que é a cura para todos os problemas. Na prática, métodos ágeis são disciplinados, estruturados e funcionam melhor com deadlines claros.

Depois de anos trabalhando com projetos ágeis, é normal ver as mesmas dúvidas voltarem à tona repetidas vezes. Desmistificar essas questões exige tempo e, às vezes, muita paciência – o que motivou esta lista com o TOP 17 mitos sobre métodos ágeis.

1. Agilidade é novidade

O Manifesto Ágil foi publicado em 2001 – mais de 15 anos atrás – e os métodos ágeis chegaram com força no Brasil entre 2004 e 2007. Indo mais a fundo, chegamos ao conceito de Adocracia, citado por Warren Bennis em 1968 e definido por Alvin Toffler como “um sistema temporário, variável e adaptativo, organizado em torno de problemas a serem resolvidos por grupos de pessoas com habilidades diversas e complementares” – uma alternativa à departamentalização tradicional. Os conceitos ágeis já existiam e eram praticados há pelo menos 49 anos.

2. Métodos ágeis significa não ter que criar documentação

Dificilmente é verdade – você pode acabar criando tanta documentação quanto linhas de código. A diferença é que, no Waterfall, toda a documentação é criada antes de qualquer linha de código; nos métodos ágeis, a documentação surge junto com as entregas de software funcionando, porque ela também é um entregável. Documentar é necessário, mas só o que agrega valor ao produto entregue em cada ciclo, evitando desperdício.

3. Ser ágil é não ter que se preocupar com o design

Pelo contrário: adotar métodos ágeis significa abraçar o design e seus princípios de experimentação, adaptação e evolução. Design deve estar envolvido em tudo – nas plannings e no direcionamento do objetivo do produto. O design emergente aparece claramente na refatoração de código, quando o desenvolvedor melhora o design já existente. Design é onipresente nos métodos ágeis, não uma fase inicial do projeto.

4. Métodos ágeis têm pouco planejamento

Planejar nos métodos ágeis acontece naturalmente, o tempo todo: há o plano do projeto todo (revisitado ao final de cada iteração), o planejamento da iteração (um plano detalhado do que será desenvolvido) e o planejamento diário que acontece na Daily. Planejar é algo natural e constante no cotidiano de todos os envolvidos.

5. Tamanho e/ou padrão certo de User Story

Não existe um modelo único de User Story para todos os times – cada time tem o seu, e pode variar conforme o que julgarem necessário. Uma boa prática é que uma User Story dure no máximo de 2 a 3 dias de desenvolvimento, e consiga ser independente, testável e entregável. O tamanho da história varia de acordo com o conhecimento e a experiência do time no projeto.

6. Tudo deve caber dentro do Sprint

A ideia de que histórias não devem ser quebradas é um mito perigoso – sua consequência é um Sprint Backlog inchado que o time dificilmente vai cumprir. Quebrar User Stories maiores que um Sprint não precisa ser traumático, mas também não deve virar regra para toda história. Uma boa prática é quebrar as grandes histórias ordenadas por valor de negócio, sempre garantindo um entregável funcionando – quanto menor a história, melhor para o fluxo produtivo do time.

7. Desenvolvedores fazem o que querem

Se isso está acontecendo no seu time, algo está errado. Desenvolvedores não fazem o que querem – seguem o que é estipulado pelo cliente e/ou Product Owner. Um time que faz o que acha melhor tem grande chance de entregar algo que o cliente não precisa. Equipes ágeis são equipes disciplinadas, focadas no que o cliente e o PO direcionam para atingir o maior valor de negócio possível.

8. Scrum e Kanban são inimigos!

Apesar de afirmações como “ou você usa Scrum, ou usa Kanban”, os dois estão longe de serem inimigos – compartilham a mesma base de valores. Existem diferenças (um é mais flexível que o outro), mas no fundo eles podem se ajudar muito: um bom Kanban pode amplificar a transparência dentro do Scrum e promover a melhoria contínua do fluxo. Há até livros que tratam o Scrumban como uma metodologia própria, como o de Corey Ladas.

9. Método ágil não funciona com deadlines

Métodos ágeis funcionam melhor com deadlines. Quando há um deadline bem definido, é natural um empoderamento do time, trazendo mais motivação e engajamento – além de eliminar desperdício, já que só será desenvolvido o necessário para cumprir o prazo conhecido.

10. Agilidade não funciona em sistemas legados e caóticos

Só por ser legado e caótico, é comum assumir que nada vai funcionar – e esse mito acaba se tornando verdade quando estratégias mais engessadas são escolhidas por medo do desconhecido. Na prática, uma abordagem ágil costuma fazer a diferença nesse tipo de ambiente: os métodos ágeis nasceram para lidar com o caos, e quando empoderamos as pessoas e deixamos o conhecimento sobre o legado emergir ao longo da jornada, os resultados surpreendem.

11. Vamos esperar o momento certo

“Gostamos da ideia de sermos ágeis, mas vamos esperar o projeto certo”

Não existe um projeto “certo” para começar – sempre é possível encontrar uma desculpa (ou um bom motivo) para não mudar. O melhor momento costuma ser quando se busca fazer mais e melhor do que o habitual, não quando se encontra o projeto perfeito.

12. É necessário todos no mesmo local físico

Métodos ágeis enfatizam o forte envolvimento de todos os participantes de um projeto, e daí surge a associação de que as pessoas precisam estar fisicamente juntas. Comunicação é historicamente um desafio mesmo com todos no mesmo lugar – o problema costuma vir mais de uma cultura de “cada um por si” do que da distância física. Cada vez mais, times espalhados se conectam em tempo real por videochamada; o que importa não é mais onde a comunicação acontece, e sim quando.

13. Só funciona em projetos pequenos

Como os times ágeis costumam ser pequenos, é fácil associar que métodos ágeis só funcionam em projetos pequenos – um mito absurdo, já que existem projetos ágeis com 100, 200 e até 500 pessoas. Em grandes projetos, o lema deve ser dividir para conquistar: organizar os times por funcionalidade ou tema de negócio, com times focados na evolução da arquitetura, reduz dependência e redundância. Scrum of Scrums, Nexus, SAFe ou qualquer outro processo de escala ajudam a organizar isso.

14. Usando métodos ágeis, não sabemos quando vai estar pronto

No modelo tradicional, todo o planejamento é detalhado antes da primeira linha de código – o que parece cômodo, mas faz qualquer mudança de plano custar muito mais caro depois. A abordagem ágil é menos detalhada no início: há um planejamento macro, baseado em incertezas que vão sendo substituídas por certezas ao longo do desenvolvimento, e refinado conforme o progresso real do projeto. Isso dá a todos um entendimento claro do curto prazo (como a entrega de uma ou duas sprints) e uma visão cada vez mais nítida, ainda que macro, do longo prazo.

15. Métodos ágeis são menos estruturados e disciplinados do que Waterfall

Ser ágil é ser disciplinado e estruturado – os frameworks mais utilizados estão entre os mais prescritivos que existem. As implementações ágeis mais bem-sucedidas são orientadas a processos e coordenação, da gestão do escopo até a gestão do projeto. Métodos ágeis exigem disciplina porque o escopo é gerenciado o tempo todo, do início até a entrega em produção, com as partes interessadas revisando o progresso em intervalos definidos.

16. Método Ágil = Scrum

Scrum é, sem dúvida, o processo ágil mais difundido e utilizado no mundo – por méritos próprios, ao se encaixar bem em ambientes complexos. Mas métodos ágeis não se resumem a Scrum: existem várias outras abordagens, como Kanban, XP e Agile UP. O ideal é avaliar qual se encaixa melhor no seu contexto – começando com um processo “by the book” e adaptando aos poucos até criar seu próprio modelo híbrido.

17. É a cura para todos os seus problemas

Agilidade traz alinhamento das partes interessadas, ajuda a identificar problemas mais cedo e reduz o tempo de entrada em produção – vantagens reais. Mas isso não significa que métodos ágeis funcionam em qualquer situação: existem muitos motivos para um projeto falhar, e o principal costuma ser a execução errada do modelo. Métodos ágeis tendem a não funcionar bem em projetos que não conseguem quebrar funcionalidades em itens pequenos, ou onde não há envolvimento real do cliente. Avaliar o próprio contexto – e distinguir problemas resolvíveis de uma realidade imutável – é essencial antes de adotar qualquer metodologia.

Fonte de pesquisa: agileconnection.com – Top Twelve Myths of Agile Development.

Erros comuns ao avaliar métodos ágeis

• Achar que adotar métodos ágeis elimina a necessidade de documentação ou de design.
• Tratar Scrum e Kanban como abordagens concorrentes, em vez de complementares.
• Evitar deadlines por achar que eles são incompatíveis com agilidade.
• Supor que métodos ágeis só funcionam em projetos pequenos ou com todos no mesmo local físico.
• Esperar o “projeto perfeito” para começar a adotar práticas ágeis.
• Achar que agilidade resolve qualquer problema, independentemente da execução.

Perguntas frequentes sobre mitos dos métodos ágeis

Scrum Master, para garantir Valores e Práticas!

Scrum Master é o responsável por garantir que os valores e práticas do Scrum estejam vivos no dia a dia do time – também chamado de Dono do Processo. Ele atua como coach do Time Scrum, removendo impedimentos, facilitando reuniões e protegendo o time de interferências externas, sem ter autoridade de gestão sobre as pessoas.

Scrum Master, o que é?

Scrum Master é o responsável por garantir que os valores e práticas do Scrum estejam vivos no dia a dia do time – é considerado o coach do time, ajudando o Time Scrum a fazer o melhor trabalho possível. Também pode ser chamado de Dono do Processo, criando equilíbrio entre o time, o Product Owner e os stakeholders do projeto.

Dia a dia

O Scrum Master deve fazer todo o esforço para ajudar o time a atingir o máximo de performance – removendo impedimentos, facilitando reuniões e atuando no refinamento de itens do próximo Sprint junto com o Product Owner. Também deve proteger o time, blindando os membros contra interferências externas.

Embora não tenha autoridade para dizer coisas como “você está demitido” ou “as atividades que vamos fazer são essas”, o Scrum Master pode dizer algo como “eu decidi que vamos fazer Sprints de 2 semanas” – uma decisão sobre o processo, não sobre as pessoas.

Personal Master?

Um Scrum Master está na equipe para ajudar com a utilização do Scrum – como um personal trainer, que elabora uma rotina de exercícios e ajuda a executá-los corretamente. Como um bom treinador, ele fornece motivação e, ao mesmo tempo, garante que os exercícios sejam executados de maneira correta, sem ignorar os mais “puxados”. O SM tem atitude de formador, mas com autoridade limitada.

Assim como o personal trainer, o Scrum Master não executa a atividade pelo time – em vez disso, relembra os objetivos e como o próprio time definiu que iria atingi-los. Ser um bom observador, um bom ouvinte e um bom facilitador são características essenciais de um bom Scrum Master.

Erros comuns sobre o papel do Scrum Master

• Tratar o Scrum Master como gestor de pessoas, com autoridade para decidir atividades ou demitir.
• Executar as atividades pelo time, em vez de relembrar os objetivos e deixar o time decidir como atingi-los.
• Não proteger o time de interferências externas durante o Sprint.
• Confundir “autoridade limitada” com ausência de liderança – o SM ainda decide sobre o processo, como a duração do Sprint.

Perguntas frequentes sobre o Scrum Master

Equipe de Alta Performance: Descubra todos os segredos e tenha resultados extraordinários

Uma equipe de alta performance é um grupo de pessoas com talentos complementares, alinhadas e comprometidas com um objetivo em comum, que mantém a constância de bons resultados ao longo do tempo – não apenas um sucesso pontual. Suas características centrais incluem objetivo claro e transcendente, times pequenos e multi-funcionais, autonomia real e foco em terminar uma coisa de cada vez.

Objetivo claro e transcendente

Times de alta performance querem mais do que entregar valor – querem criar uma história e serem lembrados.

Equipes pequenas

Times menores se comunicam melhor e produzem mais, com menos defeitos, do que times grandes.

Multi-funcionais

A liderança não interfere e deixa as habilidades se encaixarem por conta própria.

Autonomia real

O time toma suas próprias decisões sem interferência externa, mesmo em momentos de dificuldade.

Mono-tarefa

Terminar uma coisa de cada vez (One-Piece-Flow) é mais produtivo do que multitarefa.

Sucesso ou alta performance: o que vem primeiro?

Ter sucesso em algo não significa alta performance – alta performance é quando uma equipe consegue manter seu sucesso por um período, ou seja, está relacionada à constância de bons resultados. Um bom exemplo da combinação dos dois é o velocista Usain Bolt, que atingiu sucesso enorme através da constância de resultados positivos. Já o Leicester City, campeão surpreendente da Premier League depois de anos nas divisões inferiores, é um exemplo de sucesso sem alta performance.

No desenvolvimento de produtos, pode existir um time que se doou ao máximo – fazendo horas extras, corrigindo defeitos, arrumando o deploy – e mesmo assim entrega com sucesso. Em contrapartida, uma equipe que faz entregas consistentes, sempre dentro do plano e gerando valor de negócio continuamente, também alcança sucesso – mas esse sucesso vem da sua alta performance. Você pode ter sucesso “suando sangue”; uma equipe de alta performance com certeza vai ter sucesso.

O que é uma equipe de alta performance?

É um grupo de pessoas com talentos e competências que se complementam, alinhadas e comprometidas com um objetivo em comum. Demonstra alto nível de colaboração e inovação, gerando resultados de excelente qualidade – unida e focada em seu objetivo, sempre pronta para apoiar um membro que enfrente alguma dificuldade. Em resumo: altíssimo grau de comprometimento com um resultado de alto nível, usando a colaboração como característica central para resolver problemas.

Objetivo deve ser claro e tangível

Ter um objetivo claro é característica de uma equipe de alta performance – só conseguimos ser produtivos e criativos quando temos um objetivo claro e tangível. É através de metas que os times promovem auto-organização, dando o primeiro passo em direção ao resultado final. Mas não é só objetivo: é comum uma equipe de alta performance ter um objetivo transcendente, em que os membros querem mais do que entregar valor – querem criar uma história incrível e se tornar inesquecíveis.

Equipes pequenas produzem mais

Equipes menores são mais produtivas do que equipes grandes. Um estudo de Carl Erickson mostrou que um time de 20 pessoas levou 8,92 meses para desenvolver um projeto de 100 mil linhas de código, enquanto um time de 5 pessoas levou 9,12 meses no mesmo projeto – uma diferença de apenas 1 semana. Além disso, o time de 20 pessoas produziu 5 vezes mais defeitos. Com muitas pessoas, o custo de comunicação tende a subir sem ficar mais assertivo, gerando desperdício; equipes pequenas são mais coesas, melhor gerenciadas e mais colaborativas.

O segredo dos times multi-funcionais

Quanto maior a diversidade, maior será a chance de bons resultados.

Diversidade gera conhecimento e adaptabilidade nas pessoas de um mesmo time. Equipes de alta performance costumam ser formadas por pessoas com habilidades específicas e distintas que se completam. O grande segredo dos times multi-funcionais é a liderança não interferir e deixar que as habilidades se encaixem sozinhas – é comum a liderança tentar forçar a maneira como esses times trabalham, mas deixá-los se adaptar sozinhos costuma gerar resultado muito superior.

Autonomia sem interferências externas

Equipes de alta performance têm a autonomia como característica muito forte – tentar tirá-la ou diminuí-la costuma gerar sérios problemas, já que autonomia gera engajamento e motivação. Em momentos de dificuldade, a equipe é capaz de tomar suas próprias decisões, sem interferência externa, baseando-se na sua própria competência. É comum gestores se incomodarem com essa autonomia, mas o papel deles é controlar o ambiente, não as pessoas.

Mono-tarefa: comece a terminar as coisas

Pare de começar e comece a terminar.

É comprovado que pessoas mono-tarefa são 30% mais produtivas do que multitarefa – o mesmo vale para times: equipes que fazem o mínimo possível de trabalho por vez são mais produtivas. É o conceito do One-Piece-Flow: todo trabalho iniciado deve ser terminado antes de começar outro, garantindo o menor estoque em progresso possível. Uma equipe de alta performance trabalha com a ideia de que 99% não é a mesma coisa que 100%.

Passo a passo para alcançar resultados extraordinários

Não existe uma receita pronta para transformar um time em uma equipe de alta performance, mas há boas práticas que favorecem esse ambiente.

Energizar as pessoas

Energizar a equipe está ligado a como você motiva cada pessoa – e para isso é preciso conhecê-las a fundo. Motivadores extrínsecos são externos (bônus, salário); motivadores intrínsecos são o oposto (alegria no trabalho, aprendizagem, auto-estima) – e não é uma festinha no fim do mês que vai gerar motivação real. Como os motivadores intrínsecos variam de pessoa para pessoa, conhecer bem cada membro do time é essencial – tratar o time de forma generalista não constrói uma equipe de alta performance.

Promover a melhoria contínua

Fazer sempre melhor.

Esse deve ser o lema do time – não há como construir uma equipe de alta performance sem promover a melhoria contínua. Todos somos bons em apontar pontos de melhoria, mas em geral não somos bons em criar planos efetivos para resolvê-los. Melhoria contínua é executar planos enxutos que gerem resultados visíveis no dia a dia: priorize os itens resolvíveis até o final do próximo ciclo, e crie soluções definitivas em vez de paliativas.

Empodere o seu time – de verdade!

Empoderar é a arte de delegar.

Uma equipe de alta performance deve ter empoderamento na medida certa para tomar decisões e executar com sucesso – mas, no caminho até o sucesso, o time vai errar e gerar desperdício, e isso faz parte do processo. É nesse momento que a tentação de retomar o controle aparece; a dica é não fazer isso, o erro faz parte do aprendizado. Um bom líder acompanha o time sem simplesmente empoderar e virar as costas – empodere e deixe que o time faça o que faz de melhor.

Continuidade vai gerar resultados

Continuidade é um ponto-chave de uma equipe de alta performance.

Equipes que trabalham juntas por mais tempo, na mesma formação, tendem a ser muito mais produtivas e eficientes – principalmente na comunicação, um ponto crítico em qualquer time. Por isso, evite mudar as pessoas do time com frequência: deixe que se adaptem à melhor forma de trabalho de cada um, se conheçam e passem por todos os níveis de maturação de uma equipe de alta performance.

5 segredos de uma equipe de alta performance

1. Transcender o objetivo normal

Equipes de alta performance normalmente não têm “apenas” o objetivo de entregar algo – elas querem ser diferentes, criar uma história e serem lembradas. Existem times de desenvolvimento que adotaram o objetivo de plantar uma árvore rara a cada incremento entregue, ou que se juntaram a alguma causa social. Ter objetivo claro é importante, mas para ter alta performance a equipe precisa querer mais do que “só” entregar valor.

2. Diga não à passividade

Acomodação é um cenário em que o time até tem bom resultado, mas vive em passividade total – a Daily vira rotina mecânica, a Planning não tem debate real, a Retrospectiva discute sempre os mesmos problemas. Uma equipe de alta performance não pode ser passiva: ela é agressiva na resolução de problemas, sempre discutindo como melhorar um processo, nunca caindo no comodismo.

3. Descentralização de habilidades

Um time formado só por especialistas não é a solução universal que parece ser – especialistas são ótimos para resolver problemas pontuais, mas concentrar demais neles gera dependência, desperdício e ociosidade do resto do time. Um dos segredos de uma equipe de alta performance é descentralizar as habilidades.

4. Liderança focada em evolução de pessoas

Uma liderança focada no melhor para as pessoas do time é um dos principais segredos de uma equipe de alta performance, com foco em dois pontos: evolução das pessoas e relação de confiança. Seus membros estão em constante evolução técnica e pessoal, com a liderança mapeando gaps individuais e investindo em treinamentos, coaching, mentoring, reuniões one-on-one e feedback constante.

5. Gestão de sistemas, não de pessoas

Com a ascensão do Management 3.0, o foco passa a estar na gestão de sistemas, não de pessoas. Um ambiente onde gestores controlam pessoas mata a criatividade e a liberdade, com impacto direto nos resultados. Em ambientes de comando e controle existe a cultura de procurar culpados em vez de criticar o sistema em que essas pessoas estão inseridas.

Como saber se minha equipe é uma equipe de alta performance?

Não existe uma maneira científica ou matemática de avaliar um time – o que existe são avaliações com base no comportamento dos seus membros. Uma das mais difundidas é o Modelo de Tuckman, criado em 1965 para descrever os estágios de desenvolvimento de pequenos grupos, sugerido para equipes de 10 a 25 pessoas (mas aplicável também a times menores). O modelo tem 5 estágios: Forming, Storming, Norming, Performing e Adjourning.

O Modelo de Tuckman não é totalmente conclusivo, mas ajuda a entender o passo a passo dos times e como os membros se comportam em cada estágio – uma boa ferramenta de apoio às decisões de liderança.

Erros comuns ao tentar construir uma equipe de alta performance

• Aumentar o tamanho do time achando que mais pessoas geram mais produtividade, quando o oposto costuma ser verdade.
• Retomar o controle do time assim que surgem erros, em vez de deixar o erro fazer parte do aprendizado.
• Tratar a motivação do time de forma genérica, ignorando que motivadores intrínsecos variam de pessoa para pessoa.
• Concentrar o conhecimento em poucos especialistas, gerando dependência e ociosidade no resto do time.
• Trocar as pessoas do time com frequência, perdendo a continuidade que sustenta a alta performance.
• Gerenciar pessoas em vez de gerenciar o sistema em que elas estão inseridas.

Perguntas frequentes sobre equipes de alta performance

Time Scrum: Saiba tudo sobre o Scrum Team

Time Scrum é o grupo de 5 a 9 pessoas que trabalha de forma multidisciplinar e auto-organizada para completar com sucesso um Sprint – sem tarefas fixas separadas por cargo (programador, tester, designer). Suas características centrais são colaboração, multidisciplinaridade, auto-organização, tamanho certo e cultura própria.

Colaboração

Todos compartilham conhecimento, riscos e problemas em busca do mesmo objetivo.

Multidisciplinaridade

Mesmo com uma atividade principal, todos se organizam juntos para atingir a meta do Sprint.

Auto-organização

O time tem autonomia para decidir como vai desenvolver cada atividade do Sprint.

Tamanho certo

Entre 5 e 9 pessoas, garantindo comunicação assertiva e integração face a face.

Cultura

O time cria sua própria maneira de trabalhar no dia a dia – quanto mais tempo junto, melhor.

O que é o Time Scrum

O Time Scrum tem de 5 a 9 pessoas, e não existem tarefas fixas definidas para programador, tester, designer etc. – cada um é responsável por uma atividade, mas todos trabalham juntos para completar com sucesso um Sprint.

Características do Time Scrum

A colaboração entre os membros do time é essencial – todos estão em busca do mesmo objetivo, e para isso compartilham conhecimento, riscos e problemas de maneira colaborativa. O time deve ser multidisciplinar: mesmo que cada membro tenha sua atividade principal, todos devem ser capazes de se organizar para atingir a meta do Sprint – o alinhamento diário acontece na Daily Scrum.

A auto-organização é outra característica importante: os membros têm a autonomia necessária para decidir como vão desenvolver cada atividade do Sprint. Ter o tamanho certo – entre 5 e 9 pessoas – garante comunicação assertiva e promove a integração face a face; times pequenos se comunicam de forma mais eficiente. Por fim, a cultura do time: deixar que ele crie sua própria maneira de trabalhar no dia a dia é fundamental para mantê-lo unido e em constante melhoria – quanto mais tempo o Time Scrum fica junto, melhor.

A importância do time

O Time Scrum tem papel fundamental no projeto: é ele que transforma requisitos em funcionalidades – é quem desenvolve e entrega todo o produto. Aplicar técnicas de engenharia também faz diferença: TDD, programação em par e outras práticas ajudam tanto na qualidade do produto quanto na integração de todo o time.

Erros comuns sobre o Time Scrum

• Dividir o time em funções estanques (só programador, só tester), em vez de promover multidisciplinaridade real.
• Montar times muito grandes, perdendo a comunicação assertiva do “tamanho certo” (5 a 9 pessoas).
• Impor uma cultura de trabalho de fora para dentro, em vez de deixar o time construir a sua própria.
• Trocar a composição do time com frequência, perdendo a integração acumulada ao longo do tempo.

Perguntas frequentes sobre o Time Scrum

Transformação Ágil: Como criar um plano de transformação que vai te trazer resultados extraordinários

Transformação Ágil é o processo de mudar a cultura organizacional – não só a área de TI – para um ambiente de autonomia, confiança e motivação. Não existe fórmula mágica: funciona melhor com ciclos curtos de planejar, executar, verificar e agir (PDCA), formando times multifuncionais, conscientizando e capacitando as pessoas, em vez de combater a resistência de frente.

É comum encontrar “fórmulas mágicas” de transformação ágil, que prometem funcionar em qualquer projeto ou organização – basta seguir um roteiro. Este texto não traz mais um método mágico, mas mostra como não fazer e qual seria a melhor maneira de iniciar uma transformação ágil. Já passamos da fase de conhecer e começar a praticar agilidade; agora vivemos a era da Transformação Digital.

O que o Digital tem a ver com a Transformação Ágil?

O mercado vive a realidade do “ou mude ou morra”: empresas com mercados antes intocáveis sofrem com startups inovadoras que vêm engolindo o mercado – o Netflix com as TVs, o Uber com os táxis, o Spotify com o rádio. Essas empresas rompem mercados com produtos que atendem exatamente o que o cliente deseja, focando no valor real de negócio. A Transformação Digital já está impulsionando a Transformação Ágil, trazendo mais dinamismo, flexibilidade e time-to-market.

Cultura organizacional: a porta de entrada

O Manifesto Ágil nasceu no desenvolvimento de software, mas trata muito mais de pessoas do que de como se faz software. No Scrum – a metodologia ágil mais usada no mundo – percebemos o forte valor nas relações entre pessoas; por isso as organizações devem construir um ambiente que fomente autonomia, confiança e motivação. Construir uma cultura organizacional focada no empoderamento do indivíduo, e não nos processos, é um grande passo para o sucesso.

Empoderamento das pessoas

É comum que as pessoas estejam empoderadas, mas normalmente de forma limitada ao contexto do projeto em que estão inseridas. Transformação Ágil não é só ser ágil na TI – a empresa deve se transformar como um todo, com a relação entre departamentos pautada em relações interpessoais.

A Transformação Ágil deve ter a liberdade de transformar toda a organização.

Uma cultura organizacional que dá autonomia para tomada de decisões e confiança às pessoas gera, automaticamente, um ambiente de alto engajamento e motivação.

Os principais motivadores da Transformação Ágil

Quando se busca uma transformação ágil, normalmente é porque algo não vai bem na organização – ninguém muda o que já está funcionando. Os motivadores podem ser classificados em dois grupos: externos e internos.

Motivadores externos

O maior motivador externo talvez seja a própria transformação digital, que obriga a organização a repensar como desenvolve seus produtos. Outro motivador comum é a busca por produtividade: ser mais produtivo significa ser mais competitivo e lucrativo – por isso esse motivador costuma ser prioritário em transformações ágeis.

Motivadores internos

Projetos sempre fora do prazo, pessoas desmotivadas e sem comprometimento são sintomas comuns. Sem um objetivo claro, ou quando as pessoas não sentem seu trabalho valorizado, o comprometimento desaparece – as pessoas só se comprometem com o que acreditam. A falta de comprometimento costuma ser consequência, não o problema em si: muitas vezes está ligada à forma como os projetos são geridos, com uma gestão centrada na figura do líder (que define como fazer e quando deve estar pronto, mais preocupado em atualizar planilhas de controle do que em remover obstáculos) e prazos irreais baseados em teorias mirabolantes – o resultado é um time desmotivado e um cliente insatisfeito.

Como deveria ser uma Transformação Ágil

É quase regra as empresas contratarem consultores e coaches para conduzir a transformação ágil, seguindo um padrão de capacitar e executar – o risco é transferir a responsabilidade da transformação para os consultores. A transformação é da empresa como um todo, não de uma área isolada: quanto mais pessoas de diferentes áreas envolvidas (TI, RH, Finanças, Comercial), melhor – não importa se vem de cima para baixo (top-down) ou não, o importante é ter pessoas envolvidas. Uma das primeiras ações de um processo de transformação ágil costuma ser formar um time multifuncional.

Conscientizar e capacitar vai ser a base do sucesso

A maioria das empresas inicia a transformação pela capacitação das pessoas – necessária para que entendam conceitos, mindset, fluxos e métodos – mas existe outro passo igualmente importante: conscientizar. É preciso levantar as dificuldades e problemas que vão surgir, e principalmente os benefícios que a mudança vai trazer. Conscientizar e capacitar juntos ajudam muito no combate à resistência.

Fazer acontecer a Transformação Ágil

Realizar uma transformação ágil é uma atividade complexa – por isso a melhor forma de executá-la é usando os próprios pilares da agilidade: iterações curtas, medição de resultados e melhoria contínua com base no que foi obtido. A abordagem PDCA (Planejar, Executar, Verificar, Agir) funciona bem aqui, com o primeiro ciclo pautado nos resultados que a organização já está gerando.

Uma transformação ágil não tem script ou passos fixos a seguir – os conceitos e práticas devem ser adaptados ao contexto em que vão rodar, sempre buscando a melhoria contínua.

Passo a passo do fracasso

Segundo o State of Agile, 94% das empresas utilizam alguma prática ágil, mas só 8% têm todos os times ágeis – um sinal de que estamos longe de ter empresas 100% ágeis. A não evolução de uma transformação ágil costuma acontecer por três motivos principais: cultura da empresa, falta de apoio, falta de conhecimento – e vale acrescentar a resistência.

Não deixe de gerar resultados

Muito da falha em transformações ágeis vem da ansiedade por resultados, ou da falta deles – quando os resultados demoram a aparecer, a descrença cresce e puxa a resistência das pessoas junto. A melhor forma de gerar resultado é usar ciclos pequenos: assim os resultados aparecem com frequência e as pessoas sentem a evolução do contexto em que estão inseridas.

Não combata a resistência

Resistência é comum em qualquer cenário de mudança – a melhor maneira de lidar com ela é entender seus motivos, não combatê-la na força. As pessoas resistem porque estão inseguras com a nova maneira de trabalhar, ou porque não acreditam no valor da mudança; conscientizar e capacitar ajudam nos dois casos. Combater a resistência na força gera o que pode ser chamado de “resistência dos dois lados” – uma reação natural contrária que só piora o problema.

Toda mudança é “dolorida” – não encare a transformação ágil esperando que seja simples e rápida. Prepare-se, planeje-se e lembre-se de que a chave do sucesso está nas pessoas: são elas que vão executar tudo o que for implementado.

Erros comuns na Transformação Ágil

• Transferir toda a responsabilidade da transformação para consultores externos, sem engajar pessoas da própria empresa.
• Tratar a transformação ágil como um projeto só de TI, em vez de uma mudança organizacional completa.
• Capacitar as pessoas sem conscientizá-las sobre os motivos e benefícios da mudança.
• Definir prazos irreais baseados em teorias mirabolantes, gerando desmotivação e madrugadas em claro.
• Combater a resistência na força, gerando uma reação ainda mais forte contrária à mudança.
• Esperar resultados rápidos demais, abandonando o processo antes dos ciclos curtos mostrarem evolução.

Perguntas frequentes sobre Transformação Ágil

Management 3.0 – Conheça todos os conceitos desse novo modelo de gestão

Management 3.0 é um modelo de gestão criado por Jurgen Appelo, baseado no pensamento complexo: em vez de focar hierarquias e cargos, prioriza como as pessoas se comportam e se relacionam, tratando as organizações como grandes redes de relacionamento. Compartilha princípios com os métodos ágeis (autonomia, auto-organização, melhoria contínua), mas seu objetivo é crescer a organização e as pessoas, não entregar projetos.

O que é Management 3.0?

Management 3.0 é um modelo de gestão baseado no pensamento complexo. Em vez de focar hierarquias e cargos, prioriza a maneira como as pessoas se comportam e se relacionam – enxergando as empresas como grandes redes de relacionamento, ou sistemas de alta complexidade. É um movimento de liderança que define o gerenciamento como responsabilidade de um grupo de pessoas, tendo a felicidade das pessoas como uma de suas prioridades.

De onde veio o Management 3.0?

Jurgen Appelo criou o Management 3.0 baseado em suas experiências como Agile Manager – por isso é um modelo prático e “vivo”. Ele mesmo afirma que o modelo não é uma receita a ser seguida à risca, e sim um conjunto de conceitos para entender e adaptar à própria realidade. A concepção do Management 3.0 vem do somatório de conceitos já validados em vários livros e empresas pelo mundo.

Management 3.0 é Gestão Ágil?

Os métodos ágeis surgiram para fazer frente aos modelos de gestão mais robustos e pesados, com foco na autonomia dos times e na capacidade de auto-organização em busca de objetivos e metas. Trocando “métodos ágeis” por “Management 3.0” nessa definição, ela continua fazendo sentido – por isso o M30 pode ser considerado uma abordagem ágil à gestão organizacional. Os princípios são os mesmos (experimentação, melhoria contínua, autonomia, auto-organização), mas os objetivos são distintos: métodos ágeis focam em entregar projetos e produtos, enquanto o Management 3.0 foca em crescer a organização e as pessoas.

Por que o 3.0?

Para entender os motivadores do nome, é preciso olhar a evolução da gestão ao longo dos anos.

Management 1.0

No início do século XX, o mundo buscava eficiência – as indústrias organizavam linhas de produção, com a matéria-prima entrando de um lado e o produto saindo do outro. Nesse modelo, os trabalhadores eram apenas executores, sem precisar se importar com muito mais do que a rotina diária. Por isso surgiram as hierarquias, com o poder de decisão centralizado no topo da pirâmide – nasce aqui o famoso comando e controle.

Management 2.0

Com o insucesso e as dificuldades do Management 1.0, surgiram novos movimentos como Six Sigma, TQM, Balanced Scorecard e ideias como “Good to Great”. Mas esses movimentos eram voltados principalmente para os gestores, funcionando quase como extensão de boas práticas do modelo anterior – os problemas continuaram os mesmos: burocracia, lentidão na tomada de decisão e desperdício.

Management 3.0

No final dos anos 90 e início dos anos 2000 surgiu o Management 3.0 – pela primeira vez, um modelo de gestão com base na complexidade, o que o fez se adequar muito bem à realidade atual. Além da base na complexidade, o M30 também tem foco no bem-estar das pessoas. O nome “3.0”, segundo Jurgen Appelo, vem da facilidade com que as pessoas associam o número ao século XXI e por ser considerado uma evolução dos modelos anteriores.

As visões do Management 3.0

Por que usar Management 3.0?

Quando as organizações têm pessoas felizes e engajadas, o crescimento tende a ser natural. Mas não basta cuidar das pessoas: a organização também precisa ser dinâmica, aprendendo com as situações que o mercado impõe – ter uma estrutura que permite rápida adaptação a mudanças é um diferencial competitivo.

Erros comuns ao adotar o Management 3.0

• Tratar o Management 3.0 como uma receita fixa a ser seguida à risca, em vez de adaptar os conceitos à própria realidade.
• Confundir Management 3.0 com métodos ágeis – os princípios são parecidos, mas os objetivos são distintos (crescer a organização vs. entregar produtos).
• Focar só no bem-estar das pessoas sem tornar a organização dinâmica e adaptável às mudanças do mercado.
• Manter estruturas de comando e controle típicas do Management 1.0 enquanto se diz adotar o Management 3.0.

Perguntas frequentes sobre Management 3.0

Agile Coach: Como aumentar seu resultado criando uma excelente cultura ágil

Agile Coach é muito mais que um Scrum Master experiente: é alguém que cria uma excelente cultura ágil, transforma pessoas, eleva a maturidade do processo e impulsiona os resultados da organização, unindo técnicas de Coaching com conhecimento prático em métodos ágeis. Sua jornada passa por entender o ambiente, adaptar práticas, construir confiança e autonomia, e guiar a transformação de pessoas, processos e organização.

Respeito

Respeitar os motivos de como as coisas são hoje, as crenças e opiniões do ambiente.

Coragem

Ser o agente de mudanças, propondo soluções que nunca foram propostas antes.

Transparência

Dar visibilidade aos problemas e às soluções, sendo transparente em ações e objetivos.

Colaboração

Atuar mais como agregador do que como solucionador, envolvendo as pessoas.

Humildade

Reconhecer os próprios erros e aprender com eles, sabendo que existem opiniões melhores que a sua.

Estamos vivendo a era da transformação digital, que demanda cada vez mais conhecimento, criatividade e conexão entre pessoas – por isso é necessário ter uma cultura que proporcione colaboração, criatividade e crescimento. É nesse desafio que se encaixa o Agile Coach.

Agile Coach: do que ele é feito?

Agile Coach é uma função que une Coaching e Agile – duas competências que exigem desafio real para atuarem bem em conjunto.

A origem e o conceito de Coaching

Na Idade Média, os condutores de carruagens eram chamados de cocheiros – daí a origem da palavra Coaching. O conceito surgiu em Oxford em 1830, como o nome dado ao tutor particular de alunos que se preparavam para provas; com o tempo passou a se referir a instrutores e treinadores de cantores, atores e atletas. Coaching vem do inglês “coach” (treinador) – um profissional que motiva, incentiva e facilita o aprendizado do cliente em busca de um objetivo pessoal ou profissional.

O que é Coaching?

A atuação do coach começa quando o cliente estabelece uma meta a alcançar, geralmente sem prazo definido. A missão do coach é fazer o coachee alcançar essa meta, usando técnicas de autoconhecimento para maximizar seu potencial. Existem vários tipos de coaching (financeiro, pessoal, empresarial, profissional), mas o Coach de Liderança é um dos mais procurados – orientando o coachee a desenvolver competências que tornam a liderança mais fácil e eficaz.

Agile Coach precisa ser um Coach formado?

Ter a formação não é uma necessidade, mas conta muito no resultado final – o Agile Coach é, de certa forma, um “coach de processo” ou “coach de mindset”, e por isso conhecer técnicas e ferramentas de coaching é fundamental. Mesmo sem a formação formal, o Agile Coach precisa levar seu cliente – pessoa, time ou organização – a alcançar a meta estabelecida no início da jornada.

Experiência e conhecimento necessários em ágil

Ao contratar um coach, o que normalmente se avalia são seus resultados e experiências. Um Agile Coach precisa ter experiência real em métodos ágeis – não só em executar processos e práticas, mas em alcançar resultados, positivos ou negativos. Um dos maiores problemas é tratá-lo apenas como “um Scrum Master experiente”: isso ajuda, mas não é suficiente. É crucial conhecer vários ambientes ágeis diferentes, o que traz riqueza à principal característica de um agilista – resolver problemas – e entender como a agilidade se adaptou às premissas, processos e pessoas de cada um.

Atuação do Agile Coach

O Agile Coach deve criar e fortalecer o mindset ágil através dos valores e princípios do Manifesto Ágil, maximizando resultados por meio de práticas ágeis e da evolução de pessoas e processos. Três focos centrais guiam essa atuação: valor de negócio acima de software funcionando (entregar valor constantemente puxa todo o sistema para frente), entrega contínua (cadência consistente das entregas) e melhoria contínua (autoavaliação constante, adaptação e mudança em busca da perfeição – de processos, pessoas e ambiente).

Entender o ambiente e adaptar práticas

A atuação começa ao entender o ambiente onde o Agile Coach está inserido – conhecer problemas, desafios, restrições e resistências é um grande trunfo. Identificados os problemas, o passo seguinte é pensar quais práticas aplicar e como adaptá-las ao contexto para extrair o melhor resultado. O foco do Agile Coach deve ser disseminar os objetivos a serem alcançados, não como alcançá-los – embora em certos contextos seja normal, inicialmente, determinar como fazer algumas atividades, como parte da construção da cultura. A autonomia surge quando as pessoas compreendem o real valor de cada prática e passam a criar seus próprios caminhos até o objetivo.

Ferramentas devem ser utilizadas corretamente

Ferramentas de coleta de indicadores de performance, maturidade de processos e até de pessoas fazem parte da jornada do Agile Coach. O grande risco é como essas informações são usadas: em vez de entender problemas, é comum usá-las para comparar performance entre times e pessoas. O Agile Coach deve trabalhar a informação para o que ela é – só informação – e usá-la para priorizar sua própria atuação.

Agile Coach atuando como Coach

Priorizando a atuação com base nas informações coletadas, o Agile Coach maximiza resultados naturalmente: quando um time apresenta problemas de produtividade, é hora de entender as dificuldades e ajudar a traçar um plano de melhoria – ser o coach daquele time na jornada. Quando uma pessoa está com performance abaixo das demais, é hora de entender a situação e, junto com o coachee, traçar um objetivo – nesse momento, a atuação se aproxima de um coach profissional e pessoal. É assim, acompanhando e traçando objetivos que potencializam resultados, que o Agile Coach se torna um coach na essência.

A construção de um ótimo ambiente

Um ambiente ágil é centrado em dois grandes pilares: confiança e autonomia. As pessoas devem confiar umas nas outras e, principalmente, em si mesmas – sem medo de errar ou de culpa, não há soluções criativas nem entregas de qualidade. Para construir confiança, o Agile Coach deve cultivar a ideia de que errar é bom, mas aprender com os erros é melhor ainda.

Confiança não é ter certeza de que dará certo, é ter certeza de que não será culpado.

Já a autonomia surge com a evolução das pessoas – ser autossuficiente é conhecer a fundo o que se está fazendo, a ponto de ter total ciência do que precisa mudar e como mudar.

Quanto mais o Agile Coach focar na evolução e no conhecimento das pessoas, mais autônomas elas serão.

Para chegar à autonomia, as pessoas precisam de liberdade, conhecimento e independência.

Valores e princípios de um Agile Coach

Assim como todo mundo, o Agile Coach tem valores conectados às suas atitudes no dia a dia: respeito pelos motivos de como as coisas são hoje; coragem para ser o agente de mudanças; transparência nas ações e objetivos; colaboração, atuando mais como agregador do que como solucionador; e humildade para reconhecer erros e aprender com eles.

A jornada da transformação

A jornada do Agile Coach é de transformação de pessoas, organizações e processos, sempre com foco em potencializar resultados. Ele transforma pessoas através do acompanhamento e do processo de coaching, focando em potencializar suas capacidades – e, ao transformar pessoas, o ambiente se transforma automaticamente.

O ambiente nada mais é que a soma das pessoas que ali estão.

A organização passa por uma grande mudança – talvez a parte que mais “sofre” na jornada, por ser uma mudança de dentro para fora, uma revisão de seus próprios valores e princípios. Como toda mudança, vão existir vitórias e derrotas, e o Agile Coach deve estar preparado: perder faz parte da vitória a ser construída. É um processo evolutivo, um passo de cada vez – não basta contratar um Agile Coach para que tudo se transforme sozinho. Ele é o agente de mudanças, mas a empresa precisa estar pronta para ser transformada e confiar que a mudança trará resultados.

Erros comuns sobre o papel do Agile Coach

• Tratar o Agile Coach apenas como “um Scrum Master experiente”, sem considerar a experiência em múltiplos ambientes ágeis.
• Usar ferramentas de indicadores para comparar performance entre pessoas e times, em vez de entender problemas.
• Esperar que a organização se transforme sozinha só por ter contratado um Agile Coach.
• Determinar “como fazer” em vez de disseminar os objetivos a serem alcançados, travando a autonomia do time.
• Construir um ambiente com medo de errar, impedindo a confiança e a criatividade necessárias.

Perguntas frequentes sobre o Agile Coach