Como ensinar Scrum na prática #2

Em 2010 eu fiz um curso em SP de Scrum onde eu aprendi uma dinâmica para ensinar Scrum a outros times muito simples e divertida que consistia em, após estudar o básico da metodologia, em sintetizar o aprendizado em um folder, daí o nome da dinâmica que eu chamo de Agile Folder. Esta dinâmica pode ser conferida neste artigo aqui.

No artigo de hoje, vou falar de outra dinâmica que pode ser utilizada para ensinar Scrum na prática, oriunda de um treinamento de Agile Coach que fiz em 2018 com o Andy Barbosa, onde aprendemos alguns princípios em cima de uma Fábrica de Aviões. Obviamente estamos falando de aviões de papel. 🙂 Eu já fiz esse treinamento algumas vezes com times variados no Agibank, incluindo pessoas de áreas que não são de TI como Gestão de Pessoas, Backoffice, Marketing e tive excelentes resultados.

Dinâmica da Fábrica de Aviões
Dinâmica da Fábrica de Aviões

Se preparando

Reserve uma manhã ou tarde inteira, no mínimo, para realizar essa prática. Eu costumo fazê-la em uma manhã, em uma segunda-feira de preferência, que é para que eles tenham o restante da semana para aplicar o que foi aprendido.

Você precisará de um projetor digital ou televisor grande, uma sala que caiba toda sua equipe (ou faça turmas), um quadro branco ou mural para colar/fixar post-its/cartões (se não tiver, vai na parede mesmo), muitas folhas A4 (no mínimo 10 por pessoa) e tudo o que você encontrar para rabiscar: canetas, lápis, giz de cera, etc. É importante que as pessoas tenham mesas para trabalhar.

Instale algum software de cronômetro (como o CoolTimer) ou use algum Countdown Timer online ou em última caso tenha o seu celular carregado para usá-lo como cronômetro. E por fim, leve uma gravata com nó pronto e um boné e/ou apito. Se não tiver uma gravata, um blazer, jaleco ou paletó já resolve. Explicarei mais adiante.

A teoria

Crie uma apresentação de slides ou alguma outra dinâmica qualquer que lhe permita dar um overview do Scrum e de alguns artefatos que você pretende utilizar na equipe para melhorar os processos de desenvolvimento. Caso não tenha ideia alguma para a apresentação, use esse meu exemplo do Slideshare. Note como estruturei apenas tópicos e poucas frases, isso faz com que o palestrante tenha de ter mais domínio sobre o assunto e passe mais confiança de que você sabe do que está falando. Aqui no blog tenho dois posts que podem te ajudar a se preparar para esse momento, este e este.

A sua apresentação de slides deve abrir o treinamento e não deve demorar mais de 1h. Peça que sua audiência leia o Scrum Guide antes de vir para o treinamento e que tragam dúvidas e questionamentos. Use cada uma dessas dúvidas para iniciar debates e facilitar a colaboração de todos, visando que fique claro que somente terão sucesso se todos tentarem. Após a teoria, diga que farão uma prática para que eles vejam como funcionam as reuniões e os papéis e até mesmo os problemas que o Scrum não vai resolver e que eles terão de buscar soluções por conta própria.

Se o seu time não é composto por profissionais de projeto, talvez apresentar o conteúdo do Scrum Guide diretamente não fará sentido. Neste caso, sugiro introduzir os conceitos aos poucos, se baseando mais fortemente na essênca da agilidade, usando este meu outro artigo como apoio.

Explicando a Prática

A prática envolve o desenvolvimento de um produto que, em teoria, não é complexo: aviões de papel.

Diga para que se organizem em times de 4-5 integrantes, deixe os materiais de papelaria à disposição, mas não distribua nada, os times tem de ser auto-organizáveis. Explique que iremos simular a construção de aviões para entender como funciona a metodologia Scrum na prática e que quando estiver de gravata (coloque a gravata para mostrar) você estará no papel de cliente, autoridade sobre as prioridades do projeto e sempre preocupado com o ROI (retorno do investimento).

Agora, quando estiver de boné (tire a gravata e coloque o boné), você estará no papel do Agile Coach, ensinando o time a utilizar o Scrum corretamente e provocando as discussões. Sempre que algum time quiser falar com o Agile Coach ou com o cliente, deverá chamá-lo adequadamente para que você coloque a gravata ou boné e aja de acordo com sua persona.

Cada time deverá ter um Product Owner, que é quem fará a interface com o cliente e dará o aceite nos aviões, pois ele representa os interesses do cliente no dia a dia do projeto.

Cada time deverá ter um Scrum Master também, que pode ter mais de um papel caso o time seja muito pequeno (4 ou menos pessoas). Ele só não pode ser o P.O. e S.M., mas pode ser S.M. e Desenvolvedor. O Scrum Master dará o ritmo pro time, removerá impedimentos, cuidará dos materiais e do fluxo de trabalho combinado.

Os demais membros do time (2 a 3 pessoas) serão os desenvolvedores, responsáveis pelas atividades de confecção dos aviões: dobras, pintura, testes, etc. Deixe que se organizem os papéis antes de prosseguir e opcionalmente peça que criem nomes para seus times.

Executando a Prática

O próximo passo é entrar em acordo com todos de quanto tempo demorará a prática. Se você reservou a manhã inteira como eu mesmo faço, você terá 3h totais para o treinamento, sendo 1h para a teoria e 2h para a prática (já fiz prática em menos de 2h, mas ficam meio corridas demais). Explique que usará um cronômetro para contabilizar as cerimônias e consequentemente a duração das sprints e que devem respeitá-lo quando disser que a sprint acabou e coisas do tipo. Se você tem 2h, será possível fazer um bate papo ao final da sprint para conversarem sobre o que acharam.

Iremos rodar mais de uma sprint de construção de aviões e, para que tudo caiba dentro do tempo disponível, sugiro usar a seguinte divisão:

  • 10 minutos para a primeira Sprint Planning, sendo 5 para a explanação do cliente e 5 para o time entrar em acordo de como vão trabalhar e o quanto vão entregar;
  • 5 minutos para a construção dos aviões (e propositalmente pequeno e não faremos daily nesta dinâmica, pois teremos mais de uma retrospectiva);
  • 5 minutos para o Sprint Review de cada time
  • 5 minutos para um Sprint Retrospective geral

A prática começa com os primeiros 10 minutos de Sprint Planning, que nesse caso serão com a presença do cliente (você de gravata). Será feito apenas uma Sprint Planning geral, com todos os times escutando e fazendo perguntas. Você deve explicar que deseja um lote de 10 aviões em um tempo de 5 minutos, mas que todos eles devem ser iguais, devem voar e devem respeitar o modelo que você vai apresentar em um slide (escolha um modelo minimamente complexo, como o abaixo, em que a traseira possui um ângulo não tão óbvio de fazer e cujas dobras ficam escondidas na parte inferior do avião, ao invés da superior).

Avião de Papel
Avião de Papel

Avise que está buscando estes lotes com estes times mas que o contrato final só vai ser realizado com um deles, o que se sair melhor na dinâmica como um todo. Isso deve dar uma esquentada nas expectativas, mesmo sendo uma brincadeira bem simples.

Dê tantos detalhes quanto julgar necessários, mas tente deixar com que os participantes lhe questionem os detalhes mais importantes, como o tamanho do avião, adicione uma logomarca se quiser complicar, cores diferentes na fuselagem, que todos devem ser testados, etc. Uma das lições desse treinamento é que sempre o time tem de se comunicar com o cliente para que a “magia” aconteça. Então se eles não perceberem a necessidade de fazer as perguntas certas, o fracasso logo adiante vai ensinar isso a eles. Pense no avião final e deixe um pronto como referência, mas não mostre a eles ainda, deixe que eles tenham de interagir com você para descobrir.

Não tome mais do que 5 minutos nessa explanação inicial e diga que eles devem deliberar sobre o projeto do avião, o lote a ser feito, planejar as atividades dos membros, a ordem que farão e com o que se comprometem a entregar. Dê a eles 5 minutos para conversarem entre si (somente os membros do mesmo time) e conforme forem terminando, diga para chamarem o cliente para mostrar o resultado do seu planejamento. Lhes responda as últimas perguntas e anote o que cada time se comprometeu a entregar, isso é muito importante, pois você cobrará essa entrega mais tarde. Geralmente o excesso de confiança faz com que digam que entregarão tudo, mesmo sem terem muita ideia de como dividirão as tarefas e executarão o trabalho.

Rode os 5 minutos da sprint 1 com o timer visível para todos, bem como o modelo do avião (geralmente eu imprimo este último). Não faremos a Daily neste treinamento pois as retrospectivas serão bem próximas para gerar aprendizado e o tempo da sprint é muito curto. O Scrum Master, enquanto facilitador do processo deve avisar a todos quando os minutos estiverem terminando, deve controlar o tamanho do lote e auxiliar coordenando as atividades conforme combinado. Deixe em aberto a possibilidade de chamarem o cliente (coloque a gravata quando isso acontecer) ou o Agile Coach (boné) quando quiserem tirar dúvidas do produto (cliente) ou do processo (Agile Coach).

É comum que nesta primeira sprint os times façam aviões diferentes, não testem todos aviões, não façam validações com o cliente nem mesmo novas perguntas. Caso algum time tente renegociar prazos com o cliente não aceite, mas com muita relutância permita alteração no escopo por exemplo, mas sem exageros, como reduzir em algumas unidades o lote ou mudar algum padrão estético (pintura somente). A tendência é de falha nessa primeira tentativa, mas não avise eles disso, esse é o principal insumo para a retrospectiva que é feita ao término da sprint.

Quando os 5 minutos terminarem (o CoolTimer adiciona um efeito dramático à isso pois você pode escolher um MP3 bem barulhento para quando isso acontecer), diga a todos para pararem o que estão fazendo e que será feito agora a Sprint Review, onde os times apresentarão seu trabalho para o cliente (coloque a gravata) avaliar.

Para cada um dos times, analise criteriosamente o lote. Verifique se todos aviões seguem o modelo combinado, se fizeram todo o lote combinado, se todos estão iguais, etc. Se você reparou problemas na fabricação, como a ausência de testes, pergunte se alguém voaria em um avião que não foi testado. Se você reparou mudanças estéticas não acordadas, questione porque não lhe perguntaram se isso era permitido. E principalmente, se o time não entregou todo o lote, reclame, pois eles disseram que iam entregar.

O ponto que não deve ser esquecido aqui é comparar a entrega da equipe com o que ela havia prometido. No Scrum, o time define o tempo que irá levar para desenvolver as tarefas, e portanto, deve ser cobrado se não entregar o que o próprio time havia prometido. Use 4 minutos para avaliação e 1 minuto para reflexões com o grupo (quase uma retrospectiva coletiva, onde vai haver trocas de aprendizados).

Ao término das reviews, e consequentes frustrações de quem não entregou o que o cliente esperava, é hora da retrospectiva. Eu não vou falar aqui em detalhes dessa dinâmica porque já fiz isso em outro post aqui do blog, que falo somente de como conduzir retrospectivas de sprint que realmente funcionam.

Em linhas gerais, aqui é onde o time (e somente o time, com a mediação do Scrum Master) vai expor o que considerou que fluiu legal no desenvolvimento deste lote (deixe que eles falem), o que não fluiu tão bem assim e as ações que o time se compromete a executar na próxima sprint para que os mesmos erros não voltem a acontecer. Esse é o momento de maior aprendizado de toda prática e ele. Como todo bom erro, é na falha em que mais aprendemos e geralmente os times falham nessa prática.

Reserve 5 minutos para que eles decidam entre si como vão se organizar para a próxima sprint e passeie como Agile Coach pelos times para ajudar a tirar dúvidas do processo, instigá-los a melhorar o que está com problema (uma vez que os Scrum Masters de cada time não terão experiência pra isso) e cobre ao menos uma melhoria no processo de cada time.

Sprint #2

A segunda sprint vai começar e a dinâmica será muito parecida, com algumas poucas exceções.

Primeiro, o tempo de Sprint Planning será de 5 minutos ao invés de 10, uma vez que eles já se conhecem mais e tem pouca variação em relação à sprint anterior.

Segundo, introduza um novo modelo de avião ou uma variação no modelo anterior, como uma mudança de cor, uma dobra diferente, etc. Peça um lote de 10 aviões, mas sendo um número específico de cada modelo, pra complicar um pouco a vida dos times.

Desta vez espere muito mais perguntas e tentativas de negociação, pois eles estarão mais espertos e entenderão que o time tem mais poder do que estão acostumados. Seja teimoso, mas saiba ceder quando fizer sentido os argumentos e sempre explore a competição entre os times de uma maneira saudável, pois se um time entregar apenas um avião com qualidade top e outro time entregar cinco, você vai fechar contrato com o outro.

Após formalizar as entregas previstas com cada time, rode nova sprint de 5 minutos, faça nova review e finalize esta sprint com outra retrospectiva.

Quando acaba?

Você pode rodar tantas sprints quanto julgar necessário, mas no mínimo duas, para que tenham a oportunidade de aprender com seus erros e melhorar. É importante que a cada sprint sejam adicionadas novas complexidades, como por exemplo:

  • novos modelos de avião;
  • lotes variados;
  • que tal um avião extra solicitado no meio da sprint?
  • que tal uma mudança de requisito na confecção de um modelo no meio da sprint?
  • que tal a saída de um membro ou troca de membros entre os times?

A grande sacada não é ser simplesmente sádico, mas provocar diversas situações que acontecem no dia a dia dos times e que o treinamento já vai lhes preparar para reagir adequadamente.

Se tiver tempo, você pode introduzir no treinamento o conceito de Scrum Board também (um kanban bem simples), para gerenciar o fluxo de construção de múltiplos aviões, de múltiplos modelo oriundos de pedidos de múltiplos clientes (!!!). Uma sprint com esse grau de complexidade requer uma gestão mais eficiente e o kanban é uma ótima ferramenta para isso.

Tive a oportunidade de aplicar este mesmo treinamento em algumas dezenas de times do Agibank com um excelente grau de sucesso. Espero que você consiga usá-lo ou adapte-o às suas necessidades, mas que tenha sucesso também em melhorar os processos da sua empresa.

Outra ideia de treinamento de Scrum é transmitida pelo Jonas Salengue em seu livro Scrum em times de Infra, uma dinâmica baseada em construção de uma casa. Bem interessante também.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!

Utilizando o Scrum em um time que não é de desenvolvimento

scrum4infra

No artigo de hoje abri espaço para o consultor de TI e gerente de projetos na Umbler, Jonas Salengue, falar da sua experiência implementando Scrum em times que não eram de desenvolvimento. Jonas é um profissional com muitos anos de mercado e já trabalhou em multinacionais, como a HP. Recentemente lançou um livro sobre Scrum para equipes de infraestrutura que está disponível à venda na Amazon.

Olá, sou o Jonas, consultor de TI e analista de infraestrutura. Sou um grande apreciador de desafios e foi dentro de um desafio que tive o contato na prática com o Scrum pela primeira vez. Recebi o pedido de ajuda de um líder de uma equipe de infraestrutura que enfrentava dificuldades para controlar as atividades do dia-a-dia e projetos da sua área, então decidi apostar no Scrum como solução para este problema.

Antes de relatar alguns detalhes desta experiência, gostaria de agradecer ao Luiz (autor do blog) por este espaço. O Luiz é um com certeza uma referência no Scrum com algumas obras excelentes disponíveis na Amazon.

Utilizar o Scrum, independente da característica do time, deve ser um projeto com planejamento e adaptações adequadas. Dificilmente alguém utilizará 100% do que o framework descreve, pois isto acarretaria uma série de complicações, principalmente a resistência e, consequentemente, a desistência das pessoas. Saber como abordar os conceitos do scrum foi fundamental para que o time de infraestrutura “comprasse” a ideia de utilizá-lo. Para tal, utilizei uma dinâmica na qual descrevo em detalhes no livro, porém, resumidamente, trata-se da construção de uma maquete de uma casa utilizando os eventos, papéis e artefatos do framework.

Importante é que para a realização desta dinâmica, não foram utilizados os termos “técnicos” do Scrum, por exemplo, o backlog do produto nós o abordamos como “lista geral”, a sprint como “período de execução” e o backlog da sprint como “lista de execução”. Talvez seja mais interessante no início utilizar palavras e expressões que façam sentido ao pé-da-letra, pois, para esta experiência, fez toda a diferença. O próprio papel do Scrum Master foi apresentado como “facilitador” e na execução da dinâmica o time concluiu o porquê deste nome.

Após este trabalho de construção dos conceitos, garantimos que todos os integrantes do time estavam falando a mesma língua. Dai sim, começou-se o planejamento para adequar o framework à realidade do time de infra que possui características distintas, principalmente devido ao fato de prestarem suporte, ou seja, executarem várias demandas no dia-a-dia que concorrem com a execução das atividades planejadas dos projetos da área.

Basicamente utilizamos os eventos: planejamento da sprint, reuniões diárias, revisão e retrospectiva. Como artefatos definimos o backlog do produto e o backlog da sprint durante o planejamento desta. Inicialmente eu realizei o papel de Scrum Master, participando ativamente durante as 4 primeiras sprints do time. Ah, importante lembrar que desde o início utilizamos métricas através da pontuação das atividades com a técnica de planning poker. Essa técnica foi utilizada inclusive na dinâmica da casa para que o time já se tivesse contato e fosse desenvolvendo seu poder de estimar e controlar o progresso.

O resultado final desta adaptação do scrum para um time de infraestrutura foi um sucesso. Apesar de ter sido uma consultoria, algo temporário, mantenho contato com o time até hoje e continuam utilizando o framework. Eles mantém o controle do progresso dos projetos e demandas utilizando as métricas da pontuação das tarefas, construindo o gráfico burndown para representar as entregas planejadas versus o burnup que representa as demandas que surgem e devem ser atendidas durante as sprints.

Bem, resumidamente o livro aborda as questões que comentei acima, porém é claro, com muito mais detalhes e uma narrativa na qual procurei tornar interessante.

Confiram a obra em www.scrum4infra.com

Abraços e até!

Jonas

Resenha

Eu li recentemente o livro do Jonas (sim, eu estava devendo a leitura deste livro há muito tempo) e ele é bem interessante. Diferente dos livros tradicionais sobre métodos ágeis, o Scrum em Equipes de Infraestrutura é uma narrativa interessante das consultorias realizadas por ele e pelo irmão dele a uma empresa, cujo nome e funcionários foram alterados para evitar problemas legais.

Ao invés de ater-se meramente às técnicas, Jonas relata muito bem as percepções dos envolvidos, as ansiedades, angústias e sim, as práticas utilizadas também. Tudo isso de uma forma que seja possível reproduzir o passo-a-passo que ele utilizou com o cliente, seja na íntegra ou apenas parcialmente.

O livro é ricamente ilustrado com diagramas, gráficos e imagens de apoio que tornam muito fácil abstrair o que é dito e principalmente os artefatos utilizados nesta pequena transformação ágil que ele relata.

Não é um livro denso, o que facilita a leitura mas que pode desanimar quem busca uma resposta para todas perguntas para este tópico tão polêmico que é Scrum além do desenvolvimento de software. É sim uma leitura rápida, envolvente, divertida e muito didática. Recomendo a quem estiver assumindo a missão de colocar um pouco de métodos ágeis em times que tradicionalmente não vêem valor nessas práticas por não lidarem com desenvolvimento de software.

Deixem seus comentários para o Jonas no espaço abaixo, que eu aviso ele para ler!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!

Agile além do desenvolvimento de software

Atualizado em 27/11/2018!

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.

Se todas as práticas tradicionais funcionam em times de marketing? Talvez sim, talvez não, mas o barato é que muitos profissionais têm compartilhado suas descobertas em como adaptar práticas comuns, como a Daily Meeting, ao seu repertório ou o Kanban (sobre Kanban tem esse outro aqui com vídeo de como começar).

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. 🙂

Bônus: Scrum em times de UX.

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