Agile além do desenvolvimento de software

Recentemente escrevi um artigo falando da essência dos métodos ágeis. A ideia era dar uma visão da origem da agilidade e mostrar que ela não nasceu no software e até mesmo provocar um pensamento mais amplo sobre a mesma, uma vez que métodos ágeis são facilmente aplicáveis em outras áreas que não apenas ao desenvolvimento de software.

No artigo de hoje, trago alguns cases de aplicação de métodos e princípios ágeis nas mais variadas indústrias e até mesmo em casa! A ideia é desmistificar de uma vez por todas de que isso só se aplica a times de desenvolvimento. Enquanto que não me estendo em nenhum deles, todos estão recheados de referências em links ao longo dos trechos, para que se aprofunde no tópico que mais lhe interessar.

Marketing Ágil

Você já ouviu falar de Agile Marketing? O Agile Marketing tomou corpo através de um manifesto criado por diversos profissionais da área que buscavam adaptar o modelo de gestão de times comerciais ao novo cenário.

Os valores definidos pelo Manifesto são:

  1. Aprendizado validado na prática acima de opiniões e convenções;
  2. Colaboração focada em entrega de valor para os clientes ao invés de criação de silos e hierarquia;
  3. Campanhas interativas, adaptativas e não estelares/complexas;
  4. Validação e contato direto com o consumidor ao invés de predição sobre preferências e comportamentos;
  5. Planejamento flexível ao invés de rígido
  6. Responder às mudanças mais que seguir um plano
  7. Vários pequenos experimentos perante poucas grandes apostas

Não são conceitos complexos de se entender, mas adaptar sua cultura e os processos é que se tornam um desafio diário. Principalmente se consideramos o cenário geral do mercado quando se trata de Marketing e Publicidade. No entanto, temos profissionais que são referências em Marketing Digital, como Sean Ellis, o mesmo que cunhou o termo Growth Hacking, defendendo ferozmente a aplicação do Agile Marketing como diferencial para alcançar resultados em um mercado tão competitivo.

Olhando para os 7 valores do Agile Marketing Manifesto, nós conseguimos entender que a grande maioria deles procura adaptar os processos de Marketing à maneira de trabalhar das novas gerações e, principalmente, novas tecnologias existentes. Não é plausível manter um sistema de gerenciamento engessado, hierárquico, baseado meramente em criatividade quando se possui mais do que um punhado de opções mais viáveis, mensuráveis e flexíveis à sua disposição.

Faz completo sentido, então, se adaptar ao que o mercado pede e alterar sua cultura e hierarquia para melhorar os resultados, como as startups começaram a fazer e, hoje, as grandes empresas procuram conseguir também.

No site Outbound Marketing eles dão algumas dicas de como implementar um kanban em um time de marketing (embora usar Scrum também possa ser interessante). Já o site Marketing de Conteúdo faz uma análise dos 12 princípios ágeis originais com o foco no marketing, ajudando a traduzir as ideias dos signatários do Agile Manifesto para o mundo do marketing. No blog da Resultados Digitais você encontra algumas dicas também de como agilizar o seu time de marketing, enquanto que a McKinsey escreveu um artigo enorme como um passo a passo de como implementar o Agile Marketing.

Na Umbler, empresa que eu trabalhei antes de virar Agile Coach no Agibank, o setor de marketing usava métodos ágeis, conforme uma das lideranças do setor relata neste guest post no blog do Trello. E se você está curioso em saber se isso é uma moda passageira ou se é um movimento global, dê uma olhada neste estudo de 2016.

Agile Selling
Agile Selling

Comercial Ágil

Falamos bastante de Agile Marketing até o momento, mas e Agile Selling, já ouviu falar?

Esse termo foi cunhado pela autora Jill Konrath no seu livro homônimo, disponível à venda na Amazon. Após ver que tudo aquilo que ela sabia sobre vendas não funcionava mais e depois de perder alguns clientes e passar por algumas situações difíceis (pressão de todos os lados, dúvida, baixa autoconfiança, etc), ela percebe que existem dois caminhos: desistir e aceitar a derrota ou aprender a lição e achar uma resposta.

Felizmente, ela acabou seguindo o último caminho.

Esse Agile no título do texto, segundo a autora, significa, adivinhe só: ligeiro, rápido. Ser capaz de mudar rapidamente e se adaptar às novas condições de mercado.

Entender o que está acontecendo, quais são as mudanças que o mercado está sofrendo e aprender a responder rapidamente. Mas é claro que esse é um processo iterativo e você precisa aprender a priorizar o que aprender primeiro. Isso é ser ágil!

O site Outbound Marketing tem um artigo interessante que resume em linhas gerais os ensinamentos do livro, que a autora organizou em 6 estratégias para conseguir reagir às mudanças de mercado rapidamente

RH Ágil

Nossa próxima parada é no RH. Já ouviu falar de Agile HR (Human Resources)? Sim, os métodos ágeis agora estão transformando como as organizações contratam, desenvolvem e gerenciam pessoas, como bem explicado neste artigo de Harvard. Uma vez que o RH toca cada aspecto – e cada empregado – de uma organização, uma transformação ágil neste departamento pode ser bem mais trabalhosa do que em outros.

Foi-se o tempo em que o RH apenas tinha de entender como os times ágeis funcionavam e ajudar a criar uma interface de tradução de como os times praticavam versus como a empresa lidava com eles. Incorporando princípios e práticas ágeis ao RH chegou-se inclusive a se desenhar um manifesto ágil do RH, em analogia ao Agile Manifesto original da TI, o qual reproduzo a imagem abaixo.

Manifesto Ágil RH
Manifesto Ágil RH

Umas das mudanças do Agile HR, por exemplo, é nas análises de performance. Originalmente anuais, vindas de um único gestor, perdem o seu sentido uma vez que os times mudam com maior frequência, possuem servo-líderes e em ciclos bem menores que um ano. Feedback contínuo permite melhoria contínua dos profissionais e é algo que um RH ágil deve buscar.

Outra disciplina que ganha destaque neste contexto é o coaching. As empresas que tem conseguido maior sucesso em práticas ágeis de RH como Cigna, Regeneron, Johnson & Johnson, Gap, Pfizer, GE e IBM têm investido pesado em seus gestores para eles se tornarem mais coaches e menos “chefes”. A Digital Ocean inclusive tem coaches dedicados a ajudar os gestores no dia a dia.

Outra mudança é o foco nos times além do foco individual tradicional dos RHs. Feedback multidirecional é uma prática, onde os integrantes do time ajudam a avaliar seus pares e principalmente o feedback 360 onde os liderados avaliam também os seus gestores.

Fornecer mais autonomia aos times, um sistema de compensação mais flexível e variável, em ciclos curtos, são alguns dos desafios deste RH ágil. A IBM por exemplo, usa um sistema de inteligência artificial para ajudar seus funcionários a desenvolverem novas habilidades, mapeando seus perfis, gaps de conhecimento e sugerindo cursos na plataforma de conhecimento deles ou gerando demandas para educação corporativa.

Como um excelente artigo da Forbes relata, o Agile HR deve se tornar um Agile Business Partner, realmente apoiando o negócio e deixando de agir apenas como um moderador ou como um executor (modelo mais antigo ainda). A tabela abaixo, retirada do referido artigo ilustra as diferenças de atuação do RH, sendo que o que buscamos em um RH ágil é a terceira coluna.

Agile Business Partner
Agile Business Partner

No livro The Age of Agile (à venda na Amazon) Stephen Denning trata mais sobre como organizações têm se transformado usando o agile mindset, principalmente através de uma transformação em seus departamentos de gestão de pessoas.

Escola Ágil

A primeira vez que ouvi falar do EduScrum foi no livro best-seller do Jeff Sutherland (um dos criadores do Scrum) Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo (à venda na Amazon), o famoso livro amarelo do Scrum. Ele seria um framework adaptado do Scrum e do Kanban para uso em sala de aula.

Neste artigo do Rodrigo Zambon ele fala do futuro da educação e como escolas no RS tem usado o EduScrum em sala de aula par aumentar o engajamento dos alunos e incentivar o trabalho em equipe. Nestes ambientes, cada aluno pode contribuir com algo nos times em que participa e o professor atua como um Scrum Master da turma, fazendo coaching com os alunos e ajudando-os a avançar através dos desafios. Quem acompanha meu blog há um tempo já deve ter lido meu principal artigo sobre educação intitulado Por que Stanford trocou Java por JavaScript e sabe que eu apoio este tipo de iniciativa para modernizar o ensino.

O EduScrum é um movimento que nasceu na Holanda (posteriormente revisado pelo Jeff) e no manual oficial e gratuito você encontra um framework semelhante ao Scrum original, onde temos os papéis de Student Teams, EduScrum Master e Product Owner. Temos as mesmas cerimônias e praticamente os mesmos artefatos, com a oficialização do Scrum Board, um artefato derivado do Kanban. Qualquer pessoa minimamente familiarizada com o Scrum vai entender rapidamente e sair aplicando o EduScrum em turmas de qualquer curso ou nível.

Família Ágil

E para encerrar este artigo vou trazer um uso um tanto inusitado de métodos ágeis: na sua própria família. Sim, isso mesmo que você leu: já parou pra pensar como o uso de métodos ágeis pode ajudar na organização doméstica? Pensando nisso que o agile coach autor do Scrum 4 Kids iniciou um experimento com sua família, rendendo excelentes aprendizados e um case muito interessante.

E se você pensou apenas em um board de atividades, saiba que ele foi muito além, aplicando Scrum mesmo e não apenas kanban, que seria a prática mais óbvia. No blog do autor você encontra fotos realmente interessantes de dailys com os filhos do casal, boards de atividades domésticas de sábado e muito mais.

E se esse último exemplo não é a prova cabal de que os métodos ágeis podem ser utilizados em qualquer contexto, eu não sei mais o que escrever para lhe convencer disso. 🙂

Gostou do assunto? Quer aprender mais sobre métodos ágeis? Conheça meu livro Scrum e Métodos Ágeis clicando no banner abaixo!

Certificações Ágeis para Scrum Master e Product Owner

Obtive minhas primeiras certificações em métodos ágeis, mais especificamente Scrum, em 2010, logo após fazer meu primeiro curso sobre o assunto e definitivamente mudar a minha carreira pra sempre. Estas certificações me forma muito úteis em diversas ocasiões e arrisco dizer que não seria hoje um Agile Coach no Agibank se não possuísse as mesmas.

A ideia do artigo de hoje é explicar um pouco sobre certificações em métodos ágeis, principalmente as disponibilizadas pela Scrum.org, a fundação sem fins lucrativos criada por Ken Schwaber em 2009, um dos fundadores do Scrum.

Por que tirar uma certificação?

Para quem nunca tirou uma certificação antes, ela funciona como um diploma, um certificado de proficiência mas em um assunto bem específico, como programação Java, administração de servidores Linux ou neste caso, atesta que você sabe toda a teoria sobre o framework Scrum e um papel em específico (Scrum Master ou Product Owner).

Ser certificado não é garantia de que você tenha experiência com algo, mas de que ao menos domina a teoria daquele assunto. Mais do que isso, um profissional certificado mostra o seu interesse genuíno sobre determinado assunto, uma vez que certificações levam certo tempo para estudo e aplicação da prova, além do valor que pode ser bem salgado às vezes.

É bem comum no mercado de desenvolvimento as pessoas acharem que qualquer um pode ser um Scrum master ou um Product Owner e saber se a pessoa possui ou não certificação no papel demonstra que ela realmente busca uma carreira naquele papel em específico e não está apenas atrás de alguma vaga de emprego qualquer. Existem exceções? Com certeza. Mas entrevisto regularmente candidatos a vagas com essas nomenclaturas e é triste ver pessoas que não fazem ideia onde estão se metendo.

Quem emite certificações?

Falarei aqui apenas das duas principais certificadoras do mercado em métodos ágeis: Scrum.org e Scrum Alliance.

A Scrum Alliance foi fundada pelos criadores do Scrum: Jeff Sutherland e Ken Schwaber em 2003. Ela promove a disseminação do Scrum ao redor do mundo desde seus dias iniciais e muito da popularidade do seu método vem da atuação desta empresa. Aproximadamente em 2007 Ken e Jeff entraram em desacordo sobre os rumos da empresa, que estava com um apelo cada vez mais comercial (por exemplo, não era exigida prova para certificar um aluno à época, apenas um curso caríssimo e obrigatório) e que também não estava preocupado com o papel do Dev Team, apenas PO e SM.

Desse desacordo surgiu a Scrum.org aproximadamente em 2009, com o intuito de educar e certificar não apenas SMs e POs, mas também desenvolvedores em práticas ágeis de engenharia. Com um cunho mais educativo e menos comercial, a Scrum.org não exige cursos, embora eles existam para quem deseje fazer, para certificar alguém, apenas uma prova online em Inglês que explicarei mais sobre na sequência. Embora a Scrum Alliance possua provas também há alguns anos, as provas da Scrum.org são notoriamente mais difíceis.

Independente deste histórico, tanto as certificações da Scrum.org quanto da Scrum Alliance são bem avaliadas no mercado, embora existam rumores no forum da Scrum.org de que na Europa as certificações assinadas pelo Ken Schwaber (Scrum.org) possuam maior prestígio.

Sinceramente não recomendo qualquer outra certificadora. Como o Scrum Guide é mantido por estes dois senhores até os dias de hoje, somente ELES podem dizer o que o Scrum é ou não, ou como devem ser a atuação dos papéis ágeis. Já vi muita prova de outras certificadores falando besteira que contradiz o Scrum Guide, que é a fonte oficial de informação sobre o Scrum. Não vou citar nomes aqui por uma questão de ética, mas já vi gente ensinando e cobrando em prova conceitos errados. Tenha cuidado!

Certificação Professional Scrum Master I (PSM-I)

Eu vou me focar aqui nas certificações da Scrum.org pois foi onde tirei as minhas e sei como funciona tudo em detalhes. A certificação PSM-I é a equivalente CSM (Certified Scrum Master) da Scrum Alliance e mostra que o certificado possui conhecimento teórico completo do framework Scrum e do papel do Scrum Master.

As suas principais características são:

  • custo de U$150 por tentativa;
  • somente em Inglês;
  • somente aborda conceitos vistos no Scrum Guide;
  • totalmente objetiva, com questões de múltipla escolha e V/F;
  • média de 85% para aprovação ou 80% para cidadãos cuja primeira língua não é Inglês;
  • 80 questões;
  • 60 minutos para conclusão;

Ao contrário da CSM, a PSM-I não expira e não requer renovação anual. Tirei a minha em 2010 e continua lá no site deles o meu nome até hoje.

Certificação Professional Scrum Product Owner I (PSPO-I)

A certificação PSPO-I é equivalente à CSPO da Scrum Alliance (Certified Scrum Product Owner) e mostra que o certificado possui conhecimento teórico completo do framework Scrum e do papel do Product Owner, bem como de outros princípios mais além relacionados ao desenvolvimento ágil de produtos.

As suas principais características são:

  • custo de U$200 por tentativa;
  • somente em Inglês;
  • aborda conceitos vistos no Scrum Guide e em outras leituras para POs;
  • totalmente objetiva, com questões de múltipla escolha e V/F;
  • média de 85% para aprovação ou 80% para cidadãos cuja primeira língua não é Inglês;
  • 80 questões;
  • 60 minutos para conclusão;

Também não expira.

Dicas de Estudo para as Provas

A dica mais quente que posso dar é decorar o Scrum Guide de ponta a ponta. Ele é a fonte oficial de informação sobre Scrum e é nele que você deve confiar para saber o que é cobrado nas provas sobre o framework Scrum.

A segunda dica de estudo é fazer os simulados presentes no site da Scrum.org, o Scrum Open e o Product Owner Open. Se for fazer a PSM-I, fazer o Scrum Open vai te permitir conhecer algo entre 30-40% da prova (semelhante ao que acontece com as provas do Detran, sabe?) e se estiver fazendo 100% nos simulados, tem grande chance de conseguir passar na prova. Já se for fazer o PSPO-I, recomendo fazer tanto o Scrum Open quanto o Product Owner Open. Os simulados são bem didáticos e possuem questões no mesmo nível da prova, além de serem gratuitos.

A terceira dica é anotar e fazer resumos. Você tem de ter em mãos tabelas e anotações que te permitam rapidamente saber as principais atribuições de cada papel, as características de cada cerimônia (objetivos, timeboxes, etc) e o uso de cada artefato. Você também vai precisar ter a mão a definição do que é o Scrum e quais são seus valores.

Não recomendo qualquer outro simulado ou livro, pois eles podem mais confundir do que ajudar. A única exceção são os excelentes cursos da TI Exames que são preparatórios para as respectivas provas. Já fiz um deles, de Product Owner especificamente, e considerei muito bom, além de outros colegas de trabalho que também tiveram experiência semelhante.

Dicas para Realização da Prova

Como a prova é online, ter os rascunhos e anotações à mão facilita bastante, bem mais do que ter o Scrum Guide, embora este último também seja importante. Somente se inscreva para a prova (você paga e recebe uma senha para poder iniciar a prova) depois de estar tirando 100% em todos simulados que esteja fazendo, consecutivamente.

Quando eu fiz as provas, eu me tranquei em um local fechado, desliguei o celular e avisei minha esposa que eu não poderia ser incomodado sob hipóteses alguma. Você precisa de muita concentração e silêncio, só deixe o celular por perto como backup de Internet, caso sua banda larga dê problema no meio da prova. Usar um notebook também é importante caso falte luz, pois assim você terá a bateria do note para garantir que consiga fazer a prova até o final (ela dura no máximo 60 minutos).

Feche todas as abas do navegador e demais softwares do seu computador. Deixe no máximo um tradutor de Inglês aberto, caso tenha problema com alguma palavra.

Uma última dica é quanto à interpretação das questões: seja o mais literal possível. Não leve para o seu entendimento pessoal ou para qualquer prática que já tenha tido. Se no Scrum Guide diz que a cerimônia x deve ser feita sempre em pé, sim, a resposta é sempre em pé, mesmo que você eventualmente não siga esta regra, só pra citar um exemplo.

Eu também tenho a certificação de Professional Scrum Developer I (PSD-I), pois na época que comecei a trabalhar com Scrum eu ainda era um analista/programador. As regras são praticamente as mesmas, com a diferença que a PSD-I exige conhecimento de práticas de engenharia ágil, principalmente algumas abordadas no framework Extreme Programming (XP). Como tirar esta certificação não é algo muito comum no mercado, resolvi focar o artigo apenas nas duas supracitadas.

Então é isso. Essas são as orientações que eu poderia deixar sobre o assunto e qualquer dúvida que tiver, pode deixar nos comentários que terei o maior prazer em responder.

Gostou do assunto? Quer aprender mais sobre métodos ágeis? Conheça meu livro Scrum e Métodos Ágeis clicando no banner abaixo!

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:

Manifesto Ágil de Software
Manifesto Ágil de Software

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:

12 Princípios Ágeis
12 Princípios Ágeis

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.

Processo com sobreposição
Processo com sobreposição

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.

Casa da Toyota
Casa da Toyota

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?

Gostou do assunto? Quer aprender mais sobre métodos ágeis? Conheça meu livro Scrum e Métodos Ágeis clicando no banner abaixo!