customer success okrs
Agile, OKR

OKRs para Customer Success: o que é, benefícios, como adotar + exemplos!

OKRs para Customer Success é o caminho que leva ao sucesso do cliente. Veja como tudo isso funciona, na prática, e como implementar em suas estratégias!

Será que você realmente sabe como atrair e fidelizar os seus clientes? Uma das maneiras de fazer isso é com OKRs para Customer Success, um jeito de definir objetivos que melhorem a vida do seu cliente e, consequentemente, gere crescimento aos negócios. 

Mas é claro que todo esse termo não se limita por aqui. Há ainda outros fatores, cuidados e vantagens a se descobrir. 

Neste conteúdo, eu vou te mostrar o que são OKRs de Customer Sucess, além de por que e como implementá-los. 

Aproveite todas as informações e dicas, pois elas podem fazer você encantar de vez os seus clientes! 

Não perca a chance! 

Treinamento de OKR introdutório e gratuito
Como obter alinhamento, foco e agilidade com OKR

OKRs para Customer Success: o que é?

Vou dividir os termos (Costumer Sucess e OKRs) para facilitar o entendimento. Então, vamos lá...

Primeiramente, Customer Sucess, em tradução direta, significa o sucesso do cliente. 

Na prática, trata-se do trabalho de entender quais são as expectativas dos clientes e, assim, fazer com que determinados produtos ou serviços atendam àquelas necessidades.  

Essa estratégia começou a ser implementada em empresas que oferecem soluções de tecnologia. 

Mas, não demorou muito para que outros segmentos também começassem a usar o CS (Customer Sucess) em suas rotinas. 

Independentemente do nicho, é muito importante que a forma de olhar com mais atenção para os clientes seja algo presente em todas as áreas da empresa. 

Nesse sentido, vem o papel dos OKRs - Objectives and Key Results, traduzido como Objetivos e Resultados-chave. 

Isso quer dizer definir os objetivos e fatores que podem indicar se a área de CS está na rota certa, sendo assim, se realmente caminha em direção à satisfação dos clientes. 

Resumindo: o primeiro termo é uma estratégia e o segundo é uma ferramenta para gestão de metas. 

Por que usar OKRs para Customer Sucess?

Sem dúvidas, os clientes são o foco de qualquer empresa. 

Afinal, se as necessidades e desejos deles não forem atendidos, não é possível ter um bom número de vendas e conquistar muito crescimento. 

Mas, afinal, como agradar totalmente o público-alvo? É justamente aqui que entra a importância de OKRs para Customer Success.. 

OKR te auxilia a fazer a definição clara e objetiva de que benefícios devem ser gerados para o cliente. 

Por exemplo, vamos supor que, a cada três meses, você reúna todo o seu time de CS para avaliar quais as oportunidades de melhoria. Com isso, vocês definem os principais objetivos a serem alcançados. 

Além disso, a escolha de como medir o alcance dos objetivos através de Resultados Chave  (espécie de termômetro) para entender se as oportunidades e os principais problemas serão realmente endereçados. 

customer success okrs beneficios

Quais os benefícios dos OKR para Customer Success?

A ideia de OKRs para Customer Success proporciona vários benefícios aos profissionais e, consequentemente, aos clientes. 

Veja quais são esses pontos positivos: 

Foco

É comum que as empresas acabem sofrendo dois extremos: ou estabelecem objetivos demais ou não conseguem chegar a nenhum realmente possível. 

OKR, então, vem para mostrar como escolher pontos de chegada para ciclos de curto período. 

Ao mesmo tempo, ajuda a eliminar aqueles objetivos e projetos sem muito fundamento, priorizados com base em “achismos” 

Alinhamento 

Quando se tem foco na escolha de bons objetivos e metas, as equipes também podem trabalhar de forma mais alinhada. 

Aliás, não só o time de CS, mas todos os outros também. No geral, os times entendem o que é preciso fazer, em conjunto, para chegar aos objetivos tão esperados pela empresa e pelos clientes. 

Engajamento 

OKR para Customer Success, além de tudo, gera mais engajamento nos profissionais

Afinal, com a clareza dos objetivos, os processos e as tarefas podem ser melhor pensados. As pessoas passam a saber como realmente é preciso agir no cotidiano.  

A objetividade também gera mais comprometimento e satisfação dos colaboradores. 

Agilidade

OKR também tem, por princípio, aumentar a agilidade. O que quero dizer é que as equipes conseguem definir os objetivos e resultados-chave que possam ser revisados de tempos em tempos, ajudando o time a se adaptar às mudanças. 

Ao mesmo tempo, se os profissionais percebem que o atingimento dos resultados-chave não são satisfatórios, já podem readaptar as ações quanto antes. 

Como aplicar OKRs para Customer Success?

Agora que já mostrei o que é OKR e Customer Success, além das vantagens, vamos entender como aplicar os dois conceitos. 

O primeiro passo, claro, é ter uma equipe especializada em CS. Depois, o time deve retomar quais são os propósitos e prioridades da empresa. 

O time deve compreender o comportamento dos clientes no seu produto e serviço, definindo assim a estratégia para atacar as principais oportunidades ou problemas.

A próxima ação é a de fazer uma descrição qualitativa de cada objetivo e como isso será medido (key results). 

Também entra aqui a tarefa de estabelecer por quanto tempo valem os OKRs de Customer Success, ou seja, se serão reavaliados a cada três meses ou se alguma outra duração faz mais sentido. 

Eu recomendo períodos mais curtos para que a equipe possa se reunir mais vezes, discutir os propósitos e fazer um acompanhamento mais detalhado. Tipicamente os ciclos de OKR são trimestrais.

Por fim, você deve avaliar os resultados-chave semanalmente e, depois, ao final do ciclo de OKR, reavaliar o que havia sido acordado e quais foram os resultados obtidos. 

Exemplos de OKRs de Customer Success 

Como a descrição dos objetivos e resultados-chave é algo bem importante, deixei alguns exemplos de OKRs de  Customer Success, abaixo. 

Confira: 

Objetivo

Oferecer uma experiência incrível de suporte ao cliente

Vamos supor que você tenha uma startup que oferece serviços bancários on-line, ok?

Nesse sentido, o objetivo é proporcionar o melhor suporte aos clientes. 

customer success okrs resultados chave

Resultados-chave

Já os resultados-chave para este objetivo são os seguintes:

Atingir um tempo médio de resolução de problemas menor que 24 horas

O primeiro  resultado-chave traz essa especificação de que qualquer problema deve ser sanado em até 24 horas. 

Reduzir a abertura de tickets de incidentes em 10%

Vale lembrar que o termo “abertura de ticket” condiz à solicitação de suporte ao cliente.

Sendo assim, o ideal é que a equipe diminua as chances do público precisar de qualquer resolução de dilema.  

Aumentar a receita proveniente de clientes da base de R$ X para R$ Y

O último ponto é sobre conseguir mais lucratividade com clientes que já fazem parte da carteira da empresa. 

Isso pode ser conseguido, por exemplo, por meio das estratégias de cross-sell (compra de serviços ou produtos complementares) e up-sell (troca de produtos ou serviços por aqueles de maior valor).

Em todos esses OKRs de Customer Success, percebe-se a preocupação em resolver todos os problemas dos clientes de forma eficiente e ágil. 

Assim, é possível melhorar a experiência deles e, claro, conseguir mais lucratividade e renome para a empresa. 

Atenção: É muito comum que, para atingir certos Key Results, o time de CS dependa muito de outros times. Neste caso o Key Result pode ser “compartilhado” com o outro time. 

Neste sentido, ambos os times são responsáveis pelo atingimento do Key Result

Treinamento de OKR introdutório e gratuito
Como obter alinhamento, foco e agilidade com OKR

Conclusão 

Neste pequeno guia, você pôde ver que OKRs de Customer Success  combinam estratégia e gestão de metas. 

A definição dos objetivos e resultados-chave melhoram o alinhamento, a produtividade e o engajamento das equipes. 

Fora isso, claro, permite que as oportunidades e problemas dos clientes sejam verdadeiramente entendidas e solucionadas da melhor forma. 

Com tantas vantagens, não dá para deixar de fora os OKRs de CS, concorda? 

Então, confira como a minha consultoria pode te ajudar a implementar essa grande ideia em pauta! 

A chance do sucesso está apenas a um clique. Aproveite!

Read More
Agile Coach
Agile

Agile Coach: O Que É e Quais as Competências Necessárias?

O papel de Agile Coach está entre os mais importantes em uma empresa que busca evoluir seu modelo de gestão para obter mais agilidade, flexibilidade e melhores resultados para o negócio e para os seus clientes.

Infelizmente muitos ainda acreditam que a missão de Agile Coaches é treinar times em métodos ágeis. Esta é uma visão bastante estreita da realidade e é justamente por isso que muitas transformações ágeis (e digitais) fracassam.

Neste artigo eu trago uma visão mais ampla do papel de Agile Coach, suas responsabilidades e perspectivas de atuação. 

O Que É Um Agile Coach?

Agile Coach é a pessoa que ajuda times a irem além da adoção e execução de métodos ágeis, buscando de forma deliberada, consistente e engajadora o alto desempenho.

Os melhores Agile Coaches que conheci sabiam como tirar os times de sua zona de conforto e ir em busca de crescimento com o objetivo de gerar o maior valor possível para os clientes e para o negócio.

Treinamento de OKR introdutório e gratuito
Como obter alinhamento, foco e agilidade com OKR

Quais as Competências Necessárias Em Um Agile Coach?

Agile Coaches têm experiência e nível de expert em práticas Lean-Agile, além de habilidades evidenciadas com facilitação e de alguma experiência com coaching, mentoria e ensino.

Porém, certa vez me perguntaram quais são as principais soft skills que um Agile Coach precisa ter. A partir desta pergunta iniciamos uma boa conversa sobre inteligência emocional.

Embora conhecimento e experiência com práticas e ferramentas ágeis sejam fundamentais para um Agile Coach, inteligência emocional é um fator ainda mais importante para que este papel tenha sucesso.

Daniel Goleman mostrou com diversas pesquisas que inteligência emocional “é duas vezes mais importante que outras habilidades em qualquer posição de liderança”. Agile Coach são líderes!

Mas o que é inteligência emocional?

Segundo o EI Consortium, Inteligência Emocional é a capacidade que temos de, primeiramente, reconhecer nosso estado interno, nossas preferências, emoções e necessidades, ao mesmo tempo que reconhecemos nossas forças e limitações.

Uma vez que reconhecemos isso, temos inteligência emocional quando também somos capazes de gerenciar nosso estado interno e nossos impulsos, sempre os observando com atenção no momento presente, enquanto agimos de forma coerente com nossos valores. 

Assim, diante de tantos desafios complexos presentes nos diferentes times de uma empresa, a inteligência emocional passa a ser um dos pilares dos Agile Coaches.

Qual o Papel do Agile Coach?

O papel de Agile Coach é bastante diverso e uma das maneiras de compreendê-los é através do Agile Coaching Competency Framework, criado pelo Agile Coaching Institute, ilustrado na imagem abaixo.

Os lados direito e esquerdo do framework mencionam 4 papéis distintos dos Agile Coaches:

  1. Instrutor (professor)
  2. Mentor
  3. Coach profissional
  4. Facilitador
Quais as responsabilidades de um agile coach

Primeiramente veja que no lado esquerdo temos os papéis que trazem profundidade ao conteúdo em questão (instrutor e mentor). 

Quando “colocamos” o chapéu de professor (ao dar um treinamento de Scrum ou Kanban, por exemplo) ou mentor, estamos trazendo nossa autoridade e experiência nos temas.

Por outro lado, no lado direito temos os papéis responsáveis pelo processo de desenvolvimento e geração de conhecimento (coach e facilitador). 

Ao colocar os chapéus de coach ou facilitador, trazemos nossa experiência e autoridade nos processos de facilitar e fornecer coaching profissional para nossos clientes.

A seguir vamos descrever cada componente do framework.

Praticante Agile-Lean

O componente praticante Agile-Lean do framework se refere à capacidade de compreender profundamente as práticas, princípios e valores dos frameworks ágeis e lean.

Ensino

Como instrutor ou professor, Agile Coaches compartilham seu conhecimento, no momento certo, através do ensino de temas específicos de forma eficaz. 

Quando uma Agile Coach fornece um treinamento de Kanban o Scrum, por exemplo, para as equipes, ele está assumindo este papel de ensino.

Mentoria

Como mentor, Agile Coaches devem ter a capacidade de transmitir a sua própria experiência, conhecimento e orientação para ajudar a desenvolver as equipes. 

Desta forma, mentoria é ir além do ensino. Trata-se de transmissão de conhecimento e experiências já vividas no passado e que irão ajudar no desenvolvimento dos times e indivíduos.

Facilitação

Com o chapéu de facilitador, o Agile Coach se torna detentor neutro do processo de orientar a descoberta do indivíduo, equipe ou organização. Trata-se de guiar grupos de forma neutra em um processo que os ajuda a criar soluções e tomar decisões. 

Para isso, é importante que Agile Coaches dominem diferentes técnicas e ferramentas de facilitação.

Coaching

Na minha opinião este é o aspecto mais poderoso do framework. Sinto falta do lado “coach” em muitos Agile Coaches. 

Com este “chapéu”, Agile Coaches demonstram a capacidade de atuar como coaches, sempre com o interesse do cliente determinando a direção, ao invés da experiência ou opinião do coach.

Enquanto coaches, acreditamos que todo indivíduo possui internamente os recursos necessários para o desenvolvimento.

Nosso papel aqui passa a ser criar uma relação de parceria com o cliente para ajudá-lo a chegar nas respostas através da sua própria reflexão e descoberta, ao invés de trazer nosso “expertise” para solucionar seus problemas.

"É melhor saber algumas perguntas, do que todas as respostas". - James Thurber

Preciso ter fluência em todos esses papéis?

Certamente é muito difícil querer exercer esses 4 papéis com excelência. Cada um de nós tem estilos e habilidades diferentes, portanto é natural que a gente sinta mais conexão e fluidez com 1 ou 2 desses papéis.

O bom Agile Coach não é aquele que atua bem em todos os papéis, mas ele deve saber quem chamar para cobrir outras partes do framework quando necessário.

Um exercício interessante para você... Pare e reflita:

  • Em quais desses papéis você se sente mais confortável e por quê?
  • Quais desses papéis você gostaria de buscar mais desenvolvimento?

Quais os Diferentes Tipos de Agile Coach?

Além de navegar nos 4 papéis descritos, diferentes Agile Coaches podem ter diferentes níveis de domínio nos campos técnico, negócio ou transformação, dependendo da sua trajetória e experiência profissional.

De fato é isto que observamos na parte inferior do framework ilustrado acima. Vejamos cada um desses domínios.

Domínio técnico

Agile Coaches com domínio técnico conseguem "colocar a mão na massa” de forma prática e exemplar quando se fala em engenharia de software ou alguma outra prática técnica. Não é necessário ser formado em tecnologia para ser um Agile Coach, embora possam ter esse background.

Domínio de negócio

Este domínio se refere à capacidade de aplicar estratégias de negócios como uma vantagem competitiva. Exemplos são a adoção de técnicas de inovação de produtos como Lean Startup, Business Model Generation ou Customer Development

Domínio de transformações

Agile Coaches com domínio de transformações são capazes de facilitar, catalisar e liderar a mudanças organizacionais, incluindo o aspecto cultural da empresa. 

Aqui estamos falando de gestão de mudanças, cultura organizacional, desenvolvimento organizacional, pensamento sistêmico e outras ciências comportamentais.

Quais as Responsabilidades de Um Agile Coach?

Agile Coach vs. Scrum Master: Quais as Diferenças?

Scrum Master é um dos papéis definidos pelo framework Scrum. Sua missão é ajudar o Time Scrum (incluindo o Product Owner) a compreenderem e adotarem os valores e práticas do Scrum da melhor maneira possível. Por isso dizemos que o Scrum Master é, entre outras coisas, um facilitador.

Por outro lado, o escopo de atuação de um Agile Coach vai além da facilitação de um time. Agile Coaches ajudam a desenvolver diferentes times, outros Agile Coaches, Scrum Masters e facilitadores para que os princípios e práticas ágeis tenham sucesso no ambiente ao seu redor.

Qual a diferença entre Agile Coach e Enterprise Coach?

O escopo de Enterprise Coaches é um pouco maior. Este papel foca no desenvolvimento de capacidades da empresa como um todo no uso de princípios e práticas ágeis. Isso inclui mudança cultural e desenvolvimento da liderança em todos os níveis da empresa. 

A imagem abaixo mostra os diferentes escopos de atuação, segundo o Agile Coaching Institute.

O que é um Agile Coach

Como Se Tornar Um Agile Coach?

Após atuar durante anos como Agile Coach e Enterprise Agile Coach, convivendo com colegas incríveis nesta área, eu diria que 3 coisas são fundamentais para se tornar um ótimo Agile Coach:

Em primeiro lugar, buscar autoconhecimento é essencial (já falamos acima de inteligência emocional), além de tornar a sua escuta o mais ativa possível. É preciso treinar os 3 níveis de escuta:

  • Escuta Interna (nível 1): nossos pensamentos, julgamentos e sentimentos
  • Escuta Focada (nível 2): a conexão presente, aqui e agora com o outro
  • Escuta global (nível 3): consciência do ambiente ao seu redor, incluindo sua intuição

Em segundo lugar, é preciso acumular experiência prática. Ninguém se torna Agile Coach da noite para o dia, e nem fazendo um treinamento ou bootcamp de 5 dias. É preciso, como tudo na vida, errar e acertar durante anos para ganhar fluência.

Em terceiro lugar, acredito que estudo e capacitação são coisas muito importantes. Algumas pessoas valorizam certificações mais que outras. Independente de certificações, é importante passar por treinamentos sérios, preferencialmente os cursos internacionais.

Treinamento de OKR introdutório e gratuito
Saiba dar os primeiros passos com eficácia

Conclusão

Apesar do papel de Agile Coach ter se tornado muito popular, especialmente em empresas de tecnologia, ainda existe oportunidade de evolução. Muitas empresas ainda têm a crença que Agile Coaches são os que treinam os times em Scrum, o que está longe de ser realidade.

Vimos neste artigo os diferentes papéis que devem ser assumidos por Agile Coaches, dependendo do contexto. Navegar entre esses papéis é fundamental para ajudar os times a incorporarem valores e princípios ágeis no seu dia a dia, para gerar mais valor para clientes e para o negócio. 

Referência de leitura para Agile Coaches: Coaching Agile Teams, Lyssa Adkins
Read More
Squad o que é
Agile

Squad: O Que É, Características, Vantagens e Como Adotá-lo

Você quer saber afinal o que é uma Squad? Confira tudo por aqui: desde a definição ao modo de implementação!

Saber o que é squad e se inspirar neste modelo pode trazer muitos benefícios para seus projetos, para os membros da equipe e, claro, para o sucesso da empresa. 

Pensando nessa oportunidade de ter mais agilidade, preparamos este conteúdo sobre times estruturados em squads. 

Continue a leitura e descubra como é possível dar mais agilidade ao trabalho, com colaboração e engajamento. 

Receba uma consulta de OKR completa e personalizada. Saiba como!

Squad O Que É ?

Squad  é um time multifuncional geralmente composto por de 6 a 12 profissionais de diferentes disciplinas com uma missão clara, objetivos em comum e grande autonomia para tomada de decisão.

Como surgiu a metodologia squad?

Primeiramente, squad não é uma "metodologia", pois não existe um procedimento exato (passo a passo) que define uma squad.

Então, podemos dizer que squad é uma forma diferente de trabalhar (com alguns princípios claros), ao invés de um processo de trabalho definido.

A palavra squad, de origem inglesa, significa “pelotão” ou "esquadrão".  

Nos ambientes de trabalho, o termo foi inicialmente adotado pela empresa Spotify e foi popularizado através deste vídeo criado por Henrik Knibert.

Quando o Spotify ainda era uma organização com alguns poucos colaboradores, eles utilizavam o framework Scrum em seus poucos times.

Em seguida, com o crescimento acelerado que tiveram, passaram a identificar alguns gargalos no Scrum. Esse método específico passou a não ser mais suficiente, fazendo com que eles evoluíssem seu modelo, que acabou inspirando o mundo todo.

Como resultado, o Spotify renomeou o antigo papel de “Scrum Master” para “Agile Coach”. A intenção era que o Agile Coach fosse menos um especialista em Scrum, e mais um líder-servidor capaz de estimular e suportar a melhoria contínua. A segunda medida foi passar a chamar as equipes multidisciplinares de “Squads“, ao invés de “Times Scrum”.

Como funciona a metodologia squad?

Uma squad pode, por exemplo, ser formada por profissionais de marketing, tecnologia e User Experience, que atuam juntos de forma auto-gerenciada ao longo do desenvolvimento de um produto, acompanhando de perto o comportamento dos clientes neste produto. 

Aliás, o modelo é algo muito comum em startups — empreendimentos em busca de um modelo de negócio repetível e escalável em um curto espaço de tempo. 

No próximo tópico, você verá porque o conceito de squad ajuda tanto a gerar agilidade para uma empresa. 

Quais as Vantagens de Trabalhar Com Estrutura Squad?

Agora, sim, vamos às vantagens do squad. Já vale adiantar que realmente existem pontos muito interessantes e valiosos. 

Confira: 

Autonomia

Os membros de uma squad são, por princípio, autônomos. Isso não quer dizer que cada um faz o que bem entender a qualquer momento (o que significaria um playground).

Brincadeiras à parte, quando dizemos que uma squad é autônoma, significa que nela existem pessoas que têm capacidade e autoridade para tomar decisões referentes ao produto ou serviço de sua responsabilidade. 

Essa autonomia permite tomada de decisões mais rápidas e maior capacidade de criação e experimentação do time, levando a um maior grau de inovação.

Autonomia significa também que os membros da squad decidem o que fazer, como fazer e como se organizar para isso.

Agilidade

O squad contribui bastante para a agilidade do trabalho. Afinal, a equipe composta por em geral até 10 pessoas, geralmente, tem todo o poder de decisão no tocante ao desenvolvimento de seus produtos e projetos. 

Todas as ideias e tarefas não precisam passar, por exemplo, pela aprovação de um coordenador ou gestor de forma centralizada. A própria squad contém pessoas com conhecimento e habilidades complementares para gerar o valor para o cliente.

Desta forma, a equipe multidisciplinar de uma squad trabalha em alta colaboração e, com isso, tende a reduzir os ciclos de feedback de seus produtos e acelerar o desenvolvimento e o aprendizado sobre o produto. 

Produtividade

Uma vez que o trabalho se torna mais ágil, é claro que se tem maior produtividade também. 

O tempo que se gastaria esperando aprovações ou, então, reuniões de brainstorming com outras equipes, já dá para fazer tal projeto andar mais ou, ainda, iniciar outros. 

A ação do squad, sem dúvidas, é mais integrada, focada e organizada. Tudo isso somado a muita produtividade constante. 

Engajamento

Como disse ainda na definição sobre o que é squad, nesse modelo de trabalho, os profissionais têm maior autonomia. 

Isso proporciona maior liberdade de criação e ação, fatores que também fazem as pessoas se sentirem mais envolvidas nos projetos.

É claro que estar em uma squad não significa fazer o que quer! A missão da squad delimita até onde ela pode ir.

É desse ponto que também vem à tona mais engajamento, aquela real sensação de pertencimento e, claro, de satisfação ao se deparar com bons resultados.  

Colaboração

É importante mencionar que, no método Squad, não só a equipe possui autonomia, como cada membro também tem a liberdade de falar e opinar. 

Assim, há a prática daquele velho ditado que diz “duas cabeças pensam melhor do que uma”.

A partir desse pressuposto cria-se uma cultura de colaboração muito maior e melhor entre os profissionais. 

Colaboradores Mais Capacitados

O poder da autonomia, além de tudo, permite que outros colaboradores se desenvolvam mais de maneira profissional e pessoal. 

Eles realmente entendem como funciona o trabalho deles, o quanto ações focadas são necessárias para o sucesso da empresa como todo. Então, passam a agir de forma independente. 

Tudo isso também só faz com que haja pessoas mais capacitadas no trabalho, além de descentralizar decisões e reduzir o tempo de geração de valor para os clientes. 

Squad como funciona

O Que É Squad Com Metodologia Ágil?

Bom, relembrando…

O squad é um time de trabalho composto por pessoas de diferentes áreas e que, ao mesmo tempo, possui ações mais focadas, colaborativas e ágeis. 

Já as metodologias ágeis se baseiam em uma filosofia de gestão que aplica quatro valores essenciais: 

  1. indivíduos e interações mais do que processos e ferramentas;
  2. software em funcionamento mais  que documentação abrangente;
  3. colaboração com o cliente mais que negociação de contratos;
  4. responder a mudanças mais que seguir um plano. 

Dá para notar que os dois conceitos coincidem bastante, uma vez que são focados em estabelecer mais eficácia, produtividade e colaboração no dia a dia.

Quando o Spotify começou a criar suas Squads, um de seus objetivos era sair um pouco da definição restrita de papéis do Scrum, como o Product Owner e Scrum Master, por exemplo, gerando mais flexibilidade. 

Vale a Pena Implantar o Modelo de Squads na Sua Empresa?

A resposta para essa grande dúvida é muito particular. 

Afinal, tudo vai depender do seu modelo de negócio, da quantidade de colaboradores e do nível de expertise e maturidade desses profissionais. 

Sendo assim, o melhor é analisar cada ponto sobre squad e ver se ele faz sentido dentro das suas singularidades e expectativas. 

Se tudo der certo para o método ser implementado, não tenha dúvidas de que você e a sua empresa colherão mais valor e sucesso! 

Squad como implementar

Como Implantar Squads Dentro da Sua Empresa?

Como montar Squads? Antes de tudo, vale ter todos os objetivos da empresa muito bem definidos. 

Ao mesmo tempo, também é importante definir a missão e quais serão os objetivos que representam o sucesso da squad.

Para isso, conte com a metodologia OKR

Em seguida, vem a tarefa de conhecer o perfil de cada colaborador, entender quais são as facilidades e limitações de pessoa por pessoa. 

O terceiro passo é montar equipes com até 10 a 12 pessoas e, claro, explicar muito bem o que é squad, quais são os benefícios e o que é esperado dos times.

A empresa Spotify, além de nos inspirar com o conceito de squad, também inspira com outros conceitos estruturais que os ajudaram a organizar e evoluir um modelo de gestão, principalmente quando estamos falando de escala.

São eles:

  • Chapters
  • Tribes
  • Guilds

Chapters

No Spotify, um chapter é uma área de competência. Podem haver, por exemplo, chapters de qualidade de software,  Agile coaching, UX Design, Gestão de Produtos, etc..

Em cada chapter (não obrigatoriamente para todos) existe um chapter lead (líder do chapter). Em geral é um(a) gerente que tem missão de co-construir a evolução daquela disciplina na empresa. 

Tribes

Outra estrutura usada no Spotify, uma tribe é uma estrutura composta por um conjunto de squads

Enquanto uma squad tem um Product Owner, uma tribe tem um tribe lead, que que ajuda a direcionar os objetivos de negócio para toda a tribe.

Guilds

Por fim, o Spotify adota o conceito de guilds - comunidades de prática focadas em um determinado tema. Um tema pode ser engenharia de software, liderança, comunicação não violenta, inovação, etc.

São temas transversais a diferentes tribes, squads e chapters. Um ponto interessante de uma guild é que a participação nela é voluntária. Uma pessoa entra e sai de uma guild a qualquer momento, conforme seu interesse.


Receba uma consulta de OKR completa e personalizada. Saiba como!

Quais os desafios da implementação de squads?

Ao observar a realidade de muitas empresas, vemos que um grande desafio para trabalhar com squads é a própria cultura organizacional.

De fato empresas com uma cultura mais comando-controle, com hierarquias rígidas e voltadas somente para entregar atividades e projetos terá dificuldades com o conceito de squads.

Essa dificuldade é proveniente do fato que muitos gestores não querem ou não sabem como dar autonomia e preparara times de alta performance. O que buscamos com squads é uma performance que jamais teríamos que se pessoas ficarem divididas em silos departamentais.

Outro desafio é a comunicação. squads eficazes se comunicam com frequência através de rituais que são respeitados e melhorados com o tempo. Uma squad tem acordos explícitos e claros, desde o primeiro dia de sua formação.

Empresas inovadoras que usam o modelo de squads

Apesar deste conceito ter nascido no Spotify, ele invadiu muitas empresas por todo o mundo, principalmente as empresas de tecnologia.

Além dos exemplos clássicos de gestão inovadora como Google, Facebook, Twitter, etc, basta você conversar com colegas de empresas de tecnologia de ponta para ver que este conceito já faz parte de muitas empresas, mesmo fora do setor de tecnologia.

Conclusão 

Então, o que achou deste conteúdo sobre o que é squad

Analise agora mesmo os objetivos da sua empresa e veja onde faz sentido estruturar squads, de forma a aumentar o desempenho e gerar mais valor. 

Lembrando que este conceito traz agilidade, produtividade, colaboração, engajamento e muito aprendizado. 

Já para outras informações sobre agilidade e OKR, continue aqui no blog Thomaz Ribas

Read More
O que é Cultura Organizacional?
Agile

Cultura Organizacional: O Que É, Quais Seus Tipos + EXEMPLOS!

Veja como a cultura organizacional pode melhorar a relação entre os funcionários e manter uma atmosfera saudável!

SUMÁRIO

A cultura organizacional é um dos principais pilares para qualquer negócio. Isso porque ela tem como objetivo criar uma conexão entre as pessoas e o trabalho de todos os colaboradores do time. 

Além disso, é comprovado que uma cultura saudável ajuda a empresa a encantar mais clientes e atingir resultados desafiadores.

Com tantos benefícios, não dá para deixar esse assunto de lado, concorda? 

Então, confira tudo sobre o que é e do que se trata a cultura de organização dentro das instituições!

Receba uma consultoria de OKR completa e personalizada. Saiba como!

O Que É Cultura Organizacional?

A cultura organizacional é o conjunto de crenças, valores, comportamentos e práticas criados e seguidos dentro de uma empresa.

Para tudo ficar ainda mais claro, vamos “quebrar” o termo…

De acordo com o dicionário Michaelis, a palavra cultura significa:

“Conjunto de conhecimentos, costumes, crenças, padrões de comportamento, adquiridos e transmitidos socialmente, que caracterizam um grupo social.”

É exatamente isso o que também acontece dentro de instituições, só que com teorias e práticas personalizadas, pensando sempre em cada tipo de negócio. 

Seguir essa lógica é o que soma à organização, sincronia entre equipes e, consequentemente, ao crescimento da empresa. 

Tipos de Cultura Organizacional

Agora que já sabemos o significado de cultura organizacional, veja as variações existentes: 

1. Cultura do Poder

Nesse tipo de cultura organizacional, quem estabelece e controla os padrões é o dono do negócio, apenas. Apesar de ser muito comum em diversas instituições, não é uma opção muito interessante, já que concentra as decisões em uma só pessoa. 

Isso pode gerar sobrecarga de trabalho, menos autonomia dos colaboradores e, logo, impasses no dia a dia dos times. 

2. Cultura de Papéis

Já a cultura de papéis acredita que cada funcionário deve ter uma forma diferente de agir, conforme o cargo que ocupa e as tarefas que desempenha.

Mas, claro, todas as individualidades precisam entrar em um consenso. Afinal, sem isso, não é possível manter a organização. 

3. Cultura de Tarefas

A cultura de tarefas propõe a organização a partir do levantamento de problemas e dificuldades diárias. 

Depois, então, é preciso pensar nas soluções com criatividade. Nesse modelo, vários colaboradores costumam opinar e ajudar a melhorar os processos e atividades. 

4. Cultura de Pessoas

Mais um tipo de cultura organizacional é a de pessoas. Como já é de se esperar pelo termo, nesse caso, o foco de tudo são os funcionários. 

Ou seja, a definição de todas as crenças e práticas é feita de acordo com o que os colaboradores pensam e sentem como necessidade. 

Assim, temos uma maneira de dar ainda mais valor ao capital humano. 

Exemplos de Cultura Organizacional de Grandes Empresas

Na tarefa de implementar uma cultura organizacional, alguns exemplos podem te dar ainda mais ideias e inspirações. 

Confira:

Google

O Google é uma das maiores empresas do mundo. Muito dessa fama foi construída por meio da cultura organizacional voltada às pessoas. 

Nos escritórios, os funcionários têm liberdade e segurança psicológica para serem autênticos, serem eles mesmos. Existe um ambiente de autonomia com responsabilidade, o que permite a liberdade.

Mas, o publicitário Vicente Carrari — um dos funcionários mais antigos do Google, ressalta que a cultura não se limita a isso. 

Em uma entrevista ao UOL, ele explica que todos também são estimulados a darem as suas opiniões e criarem sempre. 

Netflix

A Netflix também possui um exemplo de cultura organizacional direcionada às pessoas. 

Ela incentiva seus colaboradores a tomarem decisões de modo autônomo. E ainda afirma que sempre deixa claro todas as informações, de modo muito sincero. 

Também evita regras e busca manter pessoas muito capacitadas em seus times. 

Nubank

A Nubank é conhecida como um dos maiores cases de sucesso do Brasil. Ela conseguiu mudar a forma como muita gente usa serviços bancários de forma digital. 

Já a cultura organizacional é focada no cliente. Mas, afinal, como os funcionários agem no dia a dia? 

É preciso estar direcionado às tomadas de decisões, todas pautadas na melhora da experiência dos usuários. Veja o vídeo abaixo reforçando este conceito:

Qual a Importância e os Benefícios da Cultura Organizacional?

A cultura de organização traz benefícios a todos: empresas, funcionários e clientes. 

Separei alguns pontos específicos muito interessantes para qualquer negócio. 

Sentimento de Pertencimento

Quando existe uma cultura bem definida, os colaboradores podem saber que as características deles completam o padrão estabelecido. 

Isso, sem dúvidas, gera um sentimento de pertencimento. 

Engajamento

Quando alguém se sente acolhido e pertencente, logo, pode ter mais motivação e demonstrar maior engajamento. 

Aqui entra aquela clássica frase do funcionário realmente “vestir a camisa da empresa”. 

A própria instituição e, claro, os clientes ganham muito com isso. 

Exemplos de cultura organizacional

Mais Produtividade

A sensação de pertencimento somada ao engajamento também resulta em mais produção. 

As pessoas se sentem mais à vontade para criar, ajudar e inovar em todas as tarefas e processos. 

Recrutamento e Seleção Otimizado

A definição clara de uma cultura ajuda, ainda, o time do RH. Afinal, eles conseguem ter a visão clara de qual perfil profissional é perfeito para cada função. 

Isso gera menos tempo e trabalho para recrutar grandes talentos. 

Bom Relacionamento

Ter uma boa cultura de organização também facilita o diálogo e o relacionamento entre todas as pessoas da empresa. 

Mais do que isso, ajuda a ter trabalhos e um atendimento ao cliente mais eficiente. 

Como é Formada a Cultura Organizacional de Uma Empresa?

Na hora de estabelecer a sua cultura de organização, foque em:

Mentalidade dos Fundadores

O que os fundadores pensam sobre o próprio trabalho? 

Quais são suas principais facilidades e dificuldades? O que eles gostariam que mudasse de forma que otimizasse o trabalho?

Identidade da Empresa

A identidade da empresa também conta muito nesse processo. É preciso levar em conta o propósito dos negócios, para o que e para quem eles nasceram. 

Tudo isso deve compor a cultura da empresa, também. 

Missão, Visão e Valores

Para esmiuçar o propósito da empresa, traga à tona, a missão, a visão e os valores. Tudo isso precisa realmente ser claro a todos.

Fora isso, o ideal é que esses pontos sejam constantemente lembrados e praticados no dia a dia. 

Cultura Organizacional

Qual a Diferença Entre Clima e Cultura Organizacional?

Enquanto a cultura é o conjunto de crenças, valores e práticas dentro de uma instituição, o clima organizacional é como as pessoas percebem e são afetadas nessa atmosfera. 

As sensações podem ser tanto positivas quanto negativas. Mas, claro, o foco é criar e manter o ambiente sempre favorável ao bem-estar humano. 

Receba uma consultoria de OKR completa e personalizada. Saiba como!

Conclusão

A cultura organizacional realmente atinge a todos. É o modo de fazer com que donos, diretores, gestores, analistas, estagiários, etc. pensem e falem a mesma língua. 

Essa sincronia abre espaço para processos e tarefas mais claros e fáceis de executar. Sem contar que melhora as relações interpessoais dos funcionários, e a satisfação dos clientes. 

Então, não perca mais tempo e estabeleça a cultura organizacional do seu negócio o quanto antes! 

Read More
Product Owner
Agile

Product Owner: O Que é e Quais Suas Principais Responsabilidades?

Um dos profissionais mais procurados nos últimos anos é o de Product Owner (PO). Cada vez mais vemos vagas de PO sendo abertas com salários e condições atrativas de trabalho. Mas o que de fato é um Product Owner e quais as suas responsabilidades?

Certamente o Scrum é um dos frameworks ágeis mais populares em todo o mundo. Em um time Scrum existem três papéis distintos: Product Owner, Scrum Master e Time de Desenvolvimento (os Developers).

Neste artigo iremos mergulhar mais a fundo no papel do Product Owner, compreendendo qual a sua missão diante do produto de sua responsabilidade.

Receba uma consultoria de OKR completa e personalizada. Saiba como!

O Que É um Product Owner?

Um Product Owner é um dos 3 papéis de um time Scrum e é responsável pela liderança e pelo sucesso do produto como um todo, além de decidir quais funcionalidades devem ser construídas e em que ordem.

Segundo o Scrum, a principal função de um Product Owner, também chamado de PO, é garantir que o trabalho de maior valor seja realizado, incluindo também trabalho com foco mais técnico quando necessário.

Qual a Importância do Product Owner na Gestão de Produtos?

Um Product Owner é considerado a “voz do cliente”. Neste sentido, seu papel é fundamental para conhecer as necessidades dos clientes, suas dores e expectativas.

Este papel é bem diferente de um Gerente de Projetos (Project Manager). Tradicionalmente, um gerente de projetos é responsável pelo famoso triângulo de ferro de um projeto (escopo, prazo e custo), no qual sucesso significa equilibrar e cumprir com o planejado para estes 3 elementos.

Por outro lado, quando falamos de gestão de produtos, sucesso é resolver os problemas dos clientes, ao mesmo tempo que trazemos benefícios mensuráveis para o negócio. Neste sentido, o PO torna-se um papel muito mais estratégico.   

Avaliando o significado de Product Owner, sua tradução literal seria Dono do Produto. Mas o que faz um PO na prática?

O que um Product Owner faz?

O que um Product Owner faz o dia todo? Como seria um dia típico de um PO? Na verdade, a natureza das atividades de um PO pode variar bastante.

Há momentos em que essa pessoa estará atuando mais próximo ao time, apoiando no planejamento do produto, releases e sprints e esclarecendo quaisquer dúvidas que o time tenha referente ao produto sendo desenvolvido.

Por outro lado, muitas vezes o PO atua fora do time, interagindo com outros stakehoders (internos ou externos à empresa).

Quais as Responsabilidades do Product Owner?

Embora não exista uma lista “oficial” do que um Product Owner faz, vejamos com mais detalhes algumas de suas principais responsabilidades no dia a dia.

Garantir o ROI para o produto

A missão primordial de um PO é gerar valor para os clientes e para o negócio através do produto, ao invés de simplesmente entregar uma lista de funcionalidades. Mais adiante falarei sobre como medir valor.

Infelizmente a viabilidade econômica do produto é algo que dificilmente vemos um PO fazendo, seja por falta de autonomia ou falta de conhecimento. Porém, tomar decisões economicamente viáveis deveria ser parte do dia a dia deste papel tão importante. 

Uma Product Owner deve ter condições e autonomia para realizar trade-offs entre mudanças de escopo, datas e orçamento. Ela inclusive deve decidir se um próximo sprint deve ser autorizado ou mesmo cancelado.

Apoiar no planejamento

Certamente um Product Owner tem participação ativa nos diversos ciclos de planejamento propostos pelo que conhecemos por planejamento ágil, no qual existem diferentes escopos e cadências de planejamento:

  • Portfólio
  • Produto
  • Release
  • Sprint

Esses diferentes níveis de planejamento são realizados com diferentes stakehoders, de acordo com o negócio e a empresa em questão.

Organizar o Backlog do Produto

A organização do Backlog do Produto (chamado também de Backlog Grooming) é considerada uma das principais responsabilidades de um Product Owner

Na prática, essa organização implica em atividades de criação de itens do backlog, refinamento dos itens, apoio nas estimativas e nas priorizações juntamente com o time.

Definir critérios de aceitação

Uma outra atividade de responsabilidade de um PO é a definição e a verificação dos critérios de aceitação para os itens do backlog

Esses critérios são condições que determinam se os requisitos funcionais e não funcionais serão aceitos.

Uma forma interessante de descrever os critérios de aceitação “Dado / Quando / Então”, que é parte da técnica de BDD (Behavior Driven Development)

O que é um Product Owner

Interagir com time de desenvolvimento e stakeholders

De fato um Product Owner é um trabalho full-time. Ele está sempre interagindo com diferentes públicos, incluindo o time de desenvolvimento, clientes e demais stakeholders dentro e fora da empresa.

Infelizmente ainda vemos muitos PO’s que dizem não ter tempo para interagir com o time. Isso fatalmente causa uma lentidão na comunicação, tornando os feedbacks longos e consequentemente desacelerando as tomadas de decisão e ajustes no produto.

Quais Habilidades Você Precisa Ter Para Ser um Product Owner?

Você deve estar se perguntando quais habilidades e competências são necessárias para ser um Product Owner. Afinal, o que torna um ótimo Product owner? 

Conhecimento de negócio

Product Owners devem conhecer muito bem o negócio no qual seu produto está inserido. Conhecer o negócio lhe possibilita liderar o processo de definição e comunicação da visão do produto para o time e toda a empresa.

Conhecer a fundo o negócio e o cliente é fundamental para que o PO possa liderar de forma efetiva um produto.

Autonomia para tomada de decisões

É comum encontrarmos nas empresas Product Owners que na verdade não têm nenhuma autonomia para tomar decisões. São PO’s que sempre precisam pedir autorização de alguém mais alto na hierarquia da empresa para qualquer questão referente ao produto.

Neste sentido, o trabalho do PO passa a ser algo mais tático somente. Esta disfunção infelizmente é frequente e muitas vezes gera perda de agilidade no processo de desenvolvimento do produto. 

Um Product Owner deve ser empoderado para poder tomar decisões. É para isto que este papel existe. 

Relacionamento interpessoal

Certa vez me fizeram a seguinte pergunta: “Como você lidaria com um product owner difícil?

Essa simples pergunta me faz pensar que este PO possivelmente não se relaciona com diferentes stakeholders de forma saudável e eficaz. 

Se o PO é considerado a “voz do cliente”, habilidades como relacionamento interpessoal, negociação e gestão de prioridades conflitantes são fundamentais, inclusive para superar momentos difíceis e desafiadores que acontecem no ciclo de vida de qualquer produto.

OKR e Gestão de Produtos: Por Que Devem Andar Lado a Lado?

Certamente uma das responsabilidades principais de uma pessoa de produto é garantir a geração de valor. Mas “gerar valor” é muito ambíguo. Se você não definir o que é valor no seu produto, trata-se apenas de palavras ao vento.

Pare e observe o backlog do seu produto neste momento. Por que ele está priorizado desta forma? Porque alguém com mais autoridade na empresa orientou, ou porque esta priorização ajudará a gerar benefícios mensuráveis? 

O que se espera dos líderes de produto é que eles saibam medir seu sucesso, ao invés de passar uma lista de funcionalidades e itens de backlog para seus times.

Neste sentido, uma das formas mais eficazes de definir valor de forma mensurável e pragmática é através de OKR (Objectives and Key Results). 

OKR é uma forma muito eficaz de definir objetivos e medir seu progresso baseado em resultados atingidos, através de foco, colaboração e alinhamento, ajudando a direcionar os esforços para o que mais importa para o produto.

Receba uma consultoria de OKR completa e personalizada. Saiba como!

Qual É a Diferença Entre um Product Owner e um Product Manager?

Uma das dúvidas mais recorrentes nos últimos tempos nas empresas que iniciam a sua jornada com uma forma mais ágil de trabalhar é a diferença entre Product Managers e Product Owners.

Este é um debate que acontece já há algum tempo na comunidade. Para alguns, os dois papéis são sinônimos. Para outros, existe uma diferença muito grande entre eles.

De fato, o termo Product Manager existe já a algumas décadas, enquanto o termo Product Owner é bem mais novo, tendo surgido com o Scrum na década de 90 já em sua primeira publicação.  

Na verdade, quando o Scrum surgiu, a disciplina de gestão de produtos era diferente do que é hoje.

Product Managers faziam pesquisas de mercado, planejamento de produtos e especificação de requisitos que eram “entregues” para um gerente de projeto, o qual liderava o desenvolvimento e testes do produto. 

Neste sentido, o Product Manager voltaria a interagir com o time apenas para gerar solicitações de mudança ou ajudar com o lançamento do produto. 

Porém essa abordagem vai na contramão da colaboração e do desenvolvimento incremental e iterativo que propõe a filosofia ágil. Neste sentido, o papel do PO trouxe uma visão mais moderna.

qual a diferença entre um product owner e um product manager

O fato é que, em muitas empresas, Product Managers atuam na parte mais estratégica do produto (marketing, distribuição, inovação, roadmaps, precificação, etc.), enquanto Product Owners são responsáveis "somente" pela administração do backlog do produto (trabalho mais tático). 

Esta prática é considerada por praticantes do Scrum como uma distorção do papel. Separar a “pessoa de negócio” da “pessoa que fala com o time de desenvolvimento” pode gerar um grande gargalo e burocracia no processo.

Em uma pesquisa, realizada com 850 líderes de produto, verificou-se que 70% são na verdade este tipo de Product Owners que realiza trabalho mais tático. 

Esta confusão fica ainda maior quando alguns frameworks de escala (SAFe, por exemplo) prescrevem esses dois papéis separadamente.  

Já autores como Marty Cagan do Silicon Valley Product Group defendem que o Product Manager é o dono do produto, e portanto não faz sentido a existência do papel de Product Owner!

Para Marty, não faz sentido ter pessoas que “olham para dentro” enquanto outras “olham para fora”. Todos devem olhar para fora e compreender o que está acontecendo com o mercado e com os clientes.

Concluindo, eu acredito que, mais do que o nome do papel, o importante é compreender que é preciso ter “pessoas de produto”. Aliás, algumas empresas já usam o termo Product Person.

Mais importante ainda é entender que este é um papel muito complexo e que ninguém se torna apto a assumi-lo somente com uma certificação obtida em um curso de 2 dias que ensina somente algumas práticas ágeis. É uma longa jornada.

Para esclarecer um pouco mais sobre o papel de Product Manager, leia este artigo.

Read More
kanban-o-que-e-e-como-funciona
Agile

Kanban: O Que É, Como Funciona e Como Adotar? [GUIA 2021]

Kanban é um método para definir, gerenciar e melhorar serviços que entregam trabalho do conhecimento, ajudando a empresa a aumentar a visibilidade e a colaboração e a reduzir desperdícios e time-to-market. Saiba como adotar na sua empresa.

Considerado um dos métodos mais eficazes de gestão de todo o mundo, o Kanban ajuda a realizar melhorias evolucionárias nos serviços da empresa, permitindo que você comece com o que você faz hoje e busque evoluir ao longo do tempo.

Se você busca melhoria de performance, maior satisfação dos clientes, maior engajamento e colaboração, continue lendo e saiba como adotar Kanban no seu time e na sua empresa.

O método Kanban está em crescente adoção no Brasil e no mundo, seja como o processo principal de gestão ou em conjunto com outros métodos e frameworks ágeis, como o Scrum.

Deseja adotar OKR? Receba uma consulta personalizada. 


Kanban: o Que É e Para Que Serve?


Vejamos a seguir o que provocou o método conhecido como Kanban, qual seu objetivo e quando usar.

Qual é o Objetivo do Sistema Kanban?

O método Kanban foi concebido para projetar, gerenciar e melhorar fluxos de trabalho do conhecimento.

Mas o que é “trabalho do conhecimento”?

Trata-se do trabalho que é realizado por profissionais cuja linha mestre de trabalho requer pensar para solucionar problemas. Estamos falando de serviços profissionais, trabalhos criativos, design ou desenvolvimento de produtos físicos ou digitais.

Como exemplos de trabalhadores do conhecimento tempos desenvolvedores de software, arquitetos, engenheiros, cientistas, design thinkers, advogados, entre outros.

Em times de desenvolvimento de software e produtos digitais, por exemplo, pessoas com diferentes habilidades realizam diferentes tipos de atividades de forma colaborativa para a construção de um produto. 

Neste caso, o trabalho é realizado por analistas, programadores, designers entre outros, que colaboram para construir produtos e gerar valor para os clientes.

Profissionais como esses são chamados de trabalhadores do conhecimento (em inglês: knowledge workers).

Diferente de uma fábrica tradicional que tem como resultado a produção repetitiva de determinados produtos, o trabalho do conhecimento produz elementos intangíveis, como funcionalidades de um software ou vídeos de uma campanha de marketing, por exemplo. 

De fato, esses elementos podem variar bastante em sua natureza, mas a ideia é que estes itens de trabalho passam por diferentes estágios de um fluxo bem gerenciado, até possivelmente chegar a um cliente, gerando o valor que se deseja. 

O que provocou a técnica conhecida como Kanban?

O método Kanban foi concebido por David Anderson em meados de 2007. David é um inovador no pensamento da gestão, tendo trabalhado na IBM, Sprint, Motorola e Microsoft.

Para criar o método Kanban (com “K” maiúsculo), David se inspirou fortemente na filosofia Lean de gestão, de origem na Toyota, principalmente no conceito de kanban, com “k” minúsculo”: um mecanismo de sinalização visual que ajuda a controlar e gerenciar o trabalho em progresso.

Certamente uma das obras mais marcantes do autor foi seu livro Kanban: Successful Evolutionary Change for YourTechnology Business

Quando Utilizar o Kanban?

De fato o poder do Kanban está em visualizar e gerenciar os itens intangíveis, garantindo que o fluxo de trabalho esteja saudável e eficiente. 

Portanto, se você está sentindo que seu processo de trabalho está sem visibilidade, os times estão sempre sobrecarregados e as pessoas estão sempre mudando de contexto pois tem sempre muita coisa ao mesmo tempo sendo feita, o Kanban é para você!

Ele vai  te ajudar muito a garantir que haja capacidade para entrega sem sobrecarregar o sistema de trabalho, entregando o item certo para o cliente, no momento certo.

Como Funciona o Kanban?


Para ajudar a dar visibilidade no fluxo de trabalho e garantir que ele funcione sem sobrecarga e com eficiência, você deve projetar o seu sistema Kanban

Um sistema Kanban é um sistema de fluxo de entregas. Uma de suas principais características é o fato de ele limitar a quantidade de trabalho em progresso, ou Work in Progress (WiP), em Inglês, com a utilização de sinalizações visuais em quadros, como veremos mais adiante.

Neste sentido, o que buscamos com um sistema Kanban é evitar que o sistema receba muito trabalho de uma vez (sobrecarga) ou fique sem nenhum trabalho (ociosidade), otimizando o fluxo de entrega de valor.

Em resumo, dizemos que um sistema Kanban é um sistema “puxado”. Ou seja, apenas “puxamos” (escolhemos) algo para ser feito se itens anteriores foram finalizados e se houver capacidade no sistema.

Veja que esta abordagem é oposta a um sistema “empurrado”, no qual iniciamos um novo item de trabalho mesmo com outros itens inacabados e independentemente se as pessoas estão ou não já sobrecarregadas.

Você pode utilizar o Kanban para modelar o fluxo de trabalho do seu time, mas um dos aspectos mais interessantes do método é seu direcionamento a entrega de serviços.

Em outras palavras, uma entrega de serviço acontece quando uma ou mais pessoas colaboram para produzir algum produto ou serviço para um cliente. 

O que é um quadro Kanban?


Ao adotar o método Kanban, o fluxo de trabalho é mapeado em uma sequência de passos que representam as etapas pelas quais os itens de trabalho passam. 

Desta forma, cada serviço da sua empresa terá um conjunto de etapas específico, de acordo com o seu processo. Essas etapas são representadas visualmente por um quadro Kanban

Por exemplo, a imagem abaixo exibe um sistema de fluxo no qual os itens de trabalho fluem da esquerda para a direita, passando por algumas etapas explícitas.

o que é e para que serve o kanban

Neste exemplo acima, a equipe decidiu que as etapas do fluxo têm os seguintes significados:

  • Ideias: um conjunto de ideias ou demandas que podem ser selecionadas para entrega ou serem descartadas.
  • Análise de viabilidade: itens que estão sendo analisados com relação a sua viabilidade de implementação.
  • Selecionado: itens comprometidos que foram selecionados para serem feitos e passarão pelo fluxo mapeado no quadro.
  • Desenvolvimento: itens sendo trabalhados por uma ou mais pessoas envolvidas neste serviço.
  • Testes: itens passando por um processo de validação de qualidade.
  • Finalizado: itens que passaram por todo o fluxo e são considerados entregues (finalizados).

Certamente esta clareza do significado de cada etapa é fundamental. Quanto mais transparência neste sentido, mais fluidez o fluxo terá. 

A imagem abaixo destaca duas informações importantes em um fluxo de trabalho.

Como usar o Kanban

Em primeiro lugar, ele mostra os pontos de comprometimento e de entrega

Itens que estão antes do ponto de comprometimento (etapas “ideias” e “análise de viabilidade” no exemplo deste quadro) ainda não tiveram seu trabalho iniciado e, portanto, podem ser descartados a qualquer momento ou aguardar para serem feitos. 

Assim, não houve ainda um comprometimento com a sua entrega, pois ainda são apenas opções que podem inclusive serem descartadas.

A adoção do Kanban antes do ponto de comprometimento é também chamada de Discovery Kanban

Uma vez que um item é selecionado, ele passa do ponto de comprometimento e segue pelas etapas ao longo do fluxo até ser entregue.

Em segundo lugar, um item é considerado “em progresso” quanto estiver entre os pontos de comprometimento e entrega. Quando o item é trabalhado nas etapas do fluxo e passa do ponto de entrega (é movido para “finalizado”, neste exemplo), ele é considerado terminado.

O ponto de comprometimento e o ponto de entrega representam acordos explícitos dentro do processo de trabalho. 

Na verdade, todos os itens entre esses pontos são considerados trabalho em progresso (WiP). 

Desta forma, podemos dizer que no fluxo de trabalho da imagem acima existem 10 itens em progresso (soma dos itens das etapas selecionado, desenvolvimento e testes).

Quais são as práticas do Kanban?


Existem 6 práticas de gestão do Kanban que, se forem aplicadas com consistência ao longo do tempo, lhe ajudarão a colher os frutos deste método tão eficaz:

  1. Visualizar o trabalho
  2. Limitar o trabalho em progresso
  3. Gerenciar o fluxo
  4. Tornar as políticas explícitas
  5. Implementar ciclos de feedback
  6. Melhorar colaborativamente, evoluir experimentalmente.

Vejamos na prática cada uma delas a seguir. 

Visualizar o trabalho

Certamente a prática a ser adotada logo no início da adoção do Kanban é a visualização do trabalho. Isso acontece através do quadro Kanban (Kanban board, em Inglês), como ilustrado nos exemplos das imagens acima.

Essa prática é fortemente inspirada na filosofia de gestão à vista popularizada pelo Sistema Toyota de Produção que nos ensinou o poder da visualização do trabalho. 

Perceba que o quadro Kanban fornece diversas informações a respeito do trabalho que está sendo executado e do processo adotado (colunas do quadro).

Na verdade, cada coluna representa claramente um estágio do fluxo de trabalho.  

Desta forma, cada serviço mapeado em uma organização pode ter um fluxo diferente de trabalho, portanto não se prenda aos exemplos deste artigo.

Portanto, avalie quais são as etapas que definem de forma transparente e realista o processo que você deseja mapear.

Além de colunas que representam etapas do fluxo, pode-se adicionar raias (ou swimlanes, em inglês), representando diferentes tipos de demandas, produtos, projetos ou outros critérios de gestão de risco.

Por exemplo, a imagem abaixo exibe um quadro Kanban com três raias, sendo duas para projetos e uma para atendimento de chamados de suporte.

Práticas do Kanban - Visualização

No exemplo acima, os itens de trabalho fluem através das mesmas etapas dentro de cada raia. Essa é uma forma de organizar visualmente diferentes tipos de itens.

Não existe um formato “certo” para projetar um quadro Kanban. Ao montar o seu primeiro quadro, antes de tudo comece com o que você faz hoje

Isso mesmo! Primeiro mapeie o seu processo atual e com o tempo faça pequenos experimentos adicionando ou removendo etapas do quadro conforme a sua necessidade.

Veja a seguir um outro quadro Kanban. Nesse quadro a equipe optou por mapear de forma explícita etapas que representam filas de trabalho em espera (itens aguardando o momento certo para serem movidas). 

Kanban Fila de Espera

Observe que as etapas “análise”, “desenvolvimento” e “testes” têm etapas internas (“fazendo” e “feito”). Isso torna transparente a visualização de possíveis gargalos dentro de cada etapa do fluxo. 

Ferramentas para Kanban

Os quadros Kanban podem ser construídos fisicamente (criados em paredes por meio de elementos visuais como post-its e fitas) ou podem ser eletrônicos. 

Hoje existe uma quantidade enorme de ferramentas eletrônicas que simulam quadros Kanban. 

Com a pandemia do coronavirus (COVID-19) essas ferramentas se tornaram fundamentais. Uma das ferramentas mais eficazes para utilização do Kanban é o Kanbanize.

Porém, se for possível, inicie com um quadro físico para fomentar a colaboração entre todos os envolvidos no fluxo. Isso irá despertar a criatividade das pessoas para tornar o quadro cada vez mais interativo e eficaz.

Limitar o trabalho em progresso

Limitar o trabalho em progresso é outra prática fundamental do método Kanban.

Seguindo essa prática, novos itens de trabalho não são iniciados até que algum trabalho tenha sido finalizado.

Isso evita um dos maiores ladrões da eficiência: o acúmulo de itens de trabalho em andamento e não finalizados, gerando filas de espera. 

O quadro acima também exibe, em lilás, os limites de WIP em cada etapa. Desta forma, o número “5” na etapa de Desenvolvimento significa que não podem haver mais do que 5 itens ao mesmo tempo nesta etapa.

Deste modo, um item poderia ser puxado da etapa “análise” somente quando algum item da etapa desenvolvimento for puxado para a etapa testes, evitando gargalos no fluxo. 

É exatamente desta forma que o método nos ajuda a evitar sobrecargas - limitando a quantidade de trabalho em andamento.

Para ser considerado um sistema Kanban, além dos limites de WiP, devem existir pontos claros de comprometimento e entrega. Sem isso, você pode até ter um fluxo de trabalho, mas não tem um sistema Kanban.

Certamente quanto mais itens são iniciados e não finalizados, maior o trabalho em progresso (WiP) e consequentemente maiores são as filas entre as etapas. 

Como consequência, temos o aumento no tempo de entrega de cada item (maiores leadtimes), gerando perda de agilidade. 

Quando a quantidade de itens de uma etapa atingir este limite, novos itens podem entrar na etapa somente após um item sair desta etapa. 

Gerenciar o fluxo de trabalho

Um sistema Kanban deve ser gerenciado a todo o momento para trazer resultados. Assim, no dia dia é comum que itens de trabalho sejam bloqueados devido a problemas que vão acontecendo. 

Além disso, gargalos podem surgir em uma ou mais etapas do fluxo. Por isso, uma das práticas do Kanban é o constante gerenciamento do fluxo.

Vamos simular a seguir como o fluxo é gerenciado utilizando o quadro Kanban e os limites de trabalho em progresso.

A imagem abaixo representa um projeto iniciado por um time. Veja que a equipe já tem quatro itens preparados para entrar no fluxo de trabalho mapeado no quadro.

Como adotar Kanban na empresa

As etapas definidas por esta equipe estão ilustradas no quadro. São elas: a fazer, análise, desenvolvimento, testes e finalizado. 

A quantidade de pessoas que atuará em cada etapa foi representada neste quadro com avatares (1 analista, 4 desenvolvedores e 2 testadores). 

Em quadros físicos esses avatares podem ser imãs ou post-its que representam cada membro da equipe. Os limites de trabalho em progresso também estão representados acima de cada etapa.

Imagine agora que dois itens sejam selecionados para análise. A imagem abaixo mostra que o analista puxou esses dois itens para a coluna “fazendo” da etapa “análise” e começou a trabalhar neles. 

Como adotar Kanban no time

Após algum tempo, o analista termina os 2 itens e seleciona novos itens para análise. Enquanto isso, os desenvolvedores podem atuar nos itens já analisados, conforme a imagem abaixo. 

Kanban para gestão do fluxo

Nesse caso, os quatro desenvolvedores decidiram se dividir, atuando em pares em cada um dos itens. 

Mas o que acontece se uma tarefa precisa voltar no fluxo devido a algum erro em uma determinada etapa?

Em geral, a melhor solução não é voltar o item para etapas anteriores do fluxo, mas sim imediatamente sinalizar que a tarefa está com problema para que a equipe se mobilize. 

Dessa forma, estamos adotando um princípio da manufatura Lean chamado “parar a linha” (Stop the Line, em Inglês). 

Vejamos esse cenário a seguir, na imagem abaixo. Os dois testadores estão atuando em um item de trabalho e estão encontrando problemas. 

Método Kanban como adotar

Como a etapa de testes tem um limite de 4 itens, eles não podem iniciar outro item sem antes terminar o que estão fazendo. 

Já os desenvolvedores estão enfrentando uma outra questão. Eles já estão com 4 itens feitos, aguardando os testadores e existem 2 desenvolvedores ociosos. 

Porém eles não podem puxar mais itens analisados, pois o limite da etapa de desenvolvimento foi atingido. Existem 5 itens neste estágio (1 fazendo e 4 feitos).

O que fazer nesse caso? Uma possível ação a ser feita para evitar a interrupção do fluxo é os desenvolvedores ociosos ajudarem os testadores a desbloquear o item bloqueado. 

Mesmo se os desenvolvedores não estivessem ociosos, eles parariam imediatamente o que estavam fazendo (stop the line) para priorizar o problema na etapa de teste, evitando a total interrupção do sistema. 

Trata-se de uma atitude de auto-organização da equipe, realizada para o bem do fluxo como um todo. 

Veja na imagem abaixo que o item que apresentou problema nos testes recebeu atenção especial. 

Como funciona Kanban

Todos que tinham condições naquele momento foram ajudar, independente da etapa de sua especialidade. Após alguns dias o fluxo se normalizou, conforme a imagem a seguir. 

Método Kanban

Cenários como esse são frequentes em um fluxo de trabalho do conhecimento. Bloqueios, impedimentos e gargalos acontecem quando menos se espera, e a auto-organização da equipe é fundamental para a rápida tomada de decisões no dia a dia.

Tornar as políticas explícitas

Além de definir o workflow do seu processo, é importante que você defina as políticas explícitas dele. 

Essas políticas dizem quais são as restrições do seu sistema Kanban e elas podem ser ajustadas a qualquer momento.

Por exemplo, definir visualmente um limite de WiP para etapas do seu fluxo é uma política explícita. Os critérios para seleção de itens a serem trabalhados também é uma política.  

Um outro exemplo de política explícita é a “Definição de Pronto”, ou seja, os critérios que definem o que de fato significa um item de trabalho “pronto” (ou finalizado).

Implementar ciclos de feedback

Para que as melhorias do processo ocorram de forma evolucionária (melhoria contínua), é fundamental que existam ciclos de feedback no seu sistema.

São esses feedbacks que possibilitam parar por um instante e refletir sobre o que pode ser melhorado no processo.

Neste sentido, o método Kanban define 7 cadências periódicas específicas que são grandes oportunidades de melhorias. Tratam-se de reuniões estrategicamente posicionadas ao longo do tempo.

Vejamos a seguir quais são essas 7 cadências, a frequência sugerida para elas e uma breve descrição.

Quais as cadências do método Kanban?

Cadência

Frequência sugerida

Descrição curta

Strategy Review

Trimestral

Cadência altamente estratégica para avaliação do ambiente externo, dos serviços e sua adequação às necessidades dos clientes.

Operations Review

Mensal

Avaliação abrangente de dependências e balanceamento entre diferentes serviços da empresa.

Risk Review

Mensal

Cadência específica para endereçar riscos e dar respostas à eles.

Service Delivery Review

Quinzenal

Aqui acontece uma análise e investigação do serviço em questão, em busca de melhorias

Replenishment Meeting

Semanal

Cadência para ressuprir o sistema Kanban com itens e preparar próximas opções de itens de trabalho futuros

Kanban Meeting

Diária

Coordenação diária entre as pessoas que colaboram em um determinado serviço. Também conhecida como Daily Meeting.

Delivery Planning Meeting

De acordo com a sua cadência de entrega

Cadência para monitorar e planejar as entregas que estão sendo feitas para clientes.

As cadências em azul se aplicam a um serviço específico. As demais são para os diversos serviços de uma empresa ou unidade de negócio.

Mas atenção! Isto não significa que a partir de amanhã você precise acrescentar 7 reuniões na sua empresa. 

Você pode começar a adotar o Kanban com as cadências mais essenciais: a Kanban Meeting e o Replenishment Meeting. As demais cadências podem facilmente utilizar e adaptar reuniões já existentes na empresa.

Melhorar colaborativamente, evoluir experimentalmente

Podemos dizer que o Kanban é um método para buscar melhorias contínuas. Desta forma, não existe um estado ideal ou ótimo de agilidade a ser atingido. 

Trata-se de um processo contínuo de busca por melhorias de forma evolucionária. E isso é feito a partir das pessoas colaborando no dia a dia. A ideia é que ao longo do tempo você identifique os problemas e proponha melhorias de forma experimental.

Executar um experimento significa que ele pode ou não dar certo. No pior cenário, você voltará atrás com o seu experimento e tentará algo diferente, mas não irá parar de buscar a evolução. 

Quais os papéis do método Kanban?


Já comentei anteriormente que para a adoção do método Kanban você pode literalmente iniciar com o que você tem e faz hoje. Assim, não é necessário sair definindo novos cargos ou papéis de uma hora para a outra.

Entretanto, nos últimos anos dois papéis particulares foram emergindo em empresas que adotaram Kanban. Esses papéis passaram a ser parte integrante do método.

Service Request Manager

O Service Request Manager é responsável por compreender as necessidades e expectativas dos clientes. Ele lidera o processo de seleção dos itens de trabalho na  Replenishment Meeting. 

Dependendo da empresa, é comum encontrarmos outros nomes para este papel, como Product Manager, Product Owner ou Service Manager.

Service Delivery Manager 

Também conhecido como Flow Manager ou Delivery Manager, o Service Delivery Manager tem a missão de garantir que o fluxo da entrega de trabalho funcione da melhor forma possível até gerar o valor para o cliente.

A Kanban Meeting e a Delivery Planning são tipicamente facilitadas por este papel.

É importante frisar que, mais do que papéis ou cargos, o Service Request Manager e o Service Delivery Manager são “chapéus” que tem propósitos bem claros junto ao sistema Kanban.

Quais os valores do método Kanban?


O Kanban traz de forma explícita 9 valores que deixam claro o comportamento necessário para ter sucesso com o método. A seguir listo cada valor e uma breve descrição:

Valor

Descrição curta

Transparência

Compartilhar informação abertamente melhora o fluxo de entrega de valor

Equilíbrio

Demanda e capacidade desbalanceados por muito tempo causam colapso no sistema

Colaboração

O trabalho colaborativo está no coração do Kanban, o qual ajuda a melhorar a forma com a qual as pessoas trabalham juntas 

Foco no cliente

O cliente e o valor que ele recebe é o foco do Kanban. O fluxo de todo sistema Kanban tem como objetivo a entrega de valor. 

Fluxo

O trabalho é um fluxo de valor

Liderança

Liderança é fundamental em todos os níveis para inspirar através de exemplos e reflexões, gerando melhorias e entregas de valoR

Compreensão

Autoconhecimento (individual e da organização) é fundamental para reconhecer onde estamos e saber o que melhorar

Acordo

Respeito às diferentes opiniões e abordagens junto com o comprometimento de melhorar juntos rumo aos objetivos desejados.

Respeito

Valorizar, compreender e demonstrar consideração pelas pessoas é o valor base do Kanba

Quais as métricas do método Kanban?


Existem três métricas fundamentais para a gestão do seu sistema Kanban:

  • WiP
  • Leadtime
  • Throughput (ou vazão)

Já falamos anteriormente sobre o WiP (Work in Progress). Esta métrica representa a quantidade de itens sendo trabalhados em um dado momento. 

Em resumo, o leadtime é a duração de tempo entre o início de um item (comprometimento) e seu término (entrega). Já o throughput representa a taxa de entrega do seu sistema Kanban por unidade de tempo (exemplo: 8 itens por semana).

Essas métricas nos ajudam a realizar uma das tarefas mais complexas da gestão: previsão de entregas.

Diferente de muitos métodos especulativos de estimativas, o método Kanban adota a técnica chamada previsão probabilística (probabilistic forecasting, em Inglês). 

Ao invés de especular uma estimativa de entrega, este método observa o comportamento histórico das métricas de fluxo citadas acima para estabelecer previsões mais embasadas e sustentadas em estatísticas.

De fato o tema de métricas e previsibilidade do Kanban é bastante denso, então deixarei para mergulhar mais neste tema em um próximo artigo. Mas saiba que para iniciar sua jornada com o Kanban você não precisa medir e dominar todas essas métricas no início.

Como Adotar o Kanban na Sua Empresa?

Se você chegou até aqui, deve estar se perguntando:

“Como adotar Kanban na prática na minha empresa e nos meus times?”

“Quais as dicas para começar a aplicar o método Kanban?”

A seguir a resposta curta para essas perguntas:

Comece pelo que você faz hoje e obtenha melhorias através de mudanças evolucionárias, ao mesmo tempo que encoraja atos de liderança em todos os níveis.

Porém, para ajudar as empresas a ter uma resposta mais completa para a pergunta acima, abrimos mão da abordagem STATIK (Systems Thinking Approach to Introducing Kanban).

Segundo Peter Senge, autor de “A Quinta Disciplina”, através do pensamento sistêmico podemos analisar e compreender as forças e inter-relações que modelam o comportamento dos sistemas, permitindo mudar os sistemas com maior eficácia.

Neste sentido, a abordagem STATIK pode ser aplicada não somente para iniciar a adoção de Kanban em um dado serviço, mas também para melhorar uma implementação Kanban já existente.

Mas atenção! Os passos a seguir não são uma receita de bolo linear. Dependendo do contexto, nem todos os passos são necessários, e sua execução pode ser feita de forma iterativa.

Os passos do STATIK

O “passo zero” para adotar Kanban através do STATIK é identificar os serviços existentes e compreender quem é de fato cliente dos serviços.

Em seguida, para cada serviço identificado, o seguintes passos são recomendados:

1 - Identifique o que torna o serviço “Fit for Purpose”

Em primeiro lugar, Defina o que significa “sucesso” para seu cliente. O que ele busca? Qualidade? Previsibilidade? Segurança? Como você pode medir isto?

Quais indicadores de performance são importantes e quais Objetivos e Resultados Chave (OKR) devem ser conquistados?

2 - Compreenda as fontes de insatisfação

Em segundo lugar, uma vez que você sabe o que significa sucesso para seu cliente, investigue quais são as fontes de insatisfação. 

Isso mesmo! Pergunta para os clientes o que deixa eles insatisfeitos. Além disso, pergunte aos colaboradores e líderes quais as suas fontes internas de insatisfação. 

O que será que os impede de fazer um ótimo trabalho e cumprir com as expectativas?

3 - Analise a demanda

Identifique os tipos de demanda existentes, e com que frequência elas chegam. Por exemplo, em um serviço de desenvolvimento de produtos digitais, é comum encontrarmos demandas do tipo “features”, “produtos”, “projetos”, “User Stories”, “Bugs”, etc.

4 - Analise a capacidade

Analise a capacidade do seu fluxo de trabalho atual. Para isso, avalie os dados históricos das entregas (leadtimes, previsibilidade, etc.). Entenda como está a saúde do sistema em termos de capacidade.

5 - Modele o fluxo de trabalho

Nesta etapa você irá fazer a modelagem do fluxo de trabalho (para cada tipo de item de trabalho identificado anteriormente). 

Para isto, mapeie as etapas de descoberta e geração de conhecimento. Em um serviço de desenvolvimento de software, por exemplo, descobrimos conhecimento a partir da análise de um problema ou domínio de negócios. 

Em seguida, podemos projetar uma solução, desenvolver código e testar. Desta forma, Em cada etapa desta temos mais conhecimento, mais detalhes do produto final. 

Este mapeamento é fundamental para mais tarde (etapa 7) projetarmos o quadro Kanban.

6 - Descubra as classes de serviço

Um dos conceitos chave do Kanban são as classes de serviço. São políticas sobre como um item deve ser gerenciado no fluxo, dadas as suas características. As principais classes de serviço existentes no Kanban são:

  • Urgente: precisamos entregar o quanto antes, senão haverá perdas (inclusive financeiras)
  • Data fixa: temos que entregar até uma data sem falta (campanhas de Natal, por exemplo).
  • Padrão: itens do dia a dia que não têm grandes expectativas de entrega ou urgência.
  • Intangíveis: Itens cujo retorno ou valor gerado é incerto ou não identificável, mas podem gerar alguma inovação.

7 - Projete o sistema Kanban

Finalmente você está pronto agora nesta etapa para projetar o seu sistema Kanban, seja em um quadro físico ou em uma ferramenta eletrônica. Em geral, as etapas mapeadas na etapa 5 se tornam colunas do quadro. 

Busque inicialmente o quadro mais simples possível, e faça as melhorias com o tempo. Lembre-se: o Kanban é sobre mudanças evolucionárias e não revolucionárias.

8 - Socialize o sistema

Compartilhe o resultado do trabalho realizado até a etapa 7 com os demais stakeholders. Peça feedback dos envolvidos no fluxo e impactados por ele e faça ajustes que a equipe julgar necessário e comece a vivenciar o poder do fluxo!

Concluindo, o método Kanban de fato tem ajudado muitas empresas a levar o desempenho de seus serviços para patamares superiores.

Sua abordagem evolucionária permite que qualquer trabalho do conhecimento tenha visibilidade e se beneficie das práticas citadas para gerar mais valor para seus clientes e para o negócio.

Conheça nossa Consultoria Especializada em OKR

Read More
Agile Scrum
Agile

Scrum: O que É, Como Funciona e Exemplos Práticos [GUIA]

O Scrum é um framework leve e eficaz que ajuda equipes e empresas a gerar mais valor e endereçar problemas complexos, através de seus produtos, de forma flexível e adaptativa.

Mas como funciona este framework que se tornou tão popular? Quais as vantagens e principais dificuldades ao adotar Scrum e como superá-los?

Neste artigo eu trago um material completo que vai além do Scrum Guide, para te ajudar a compreender os componentes do Scrum, seus artefatos, papéis, eventos e principais desafios.

Você também pode se guiar através do índice abaixo.

Boa leitura!

Afinal, o que é Scrum?

Primeiramente é importante sabermos o que o Scrum não é. Scrum não é uma metodologia prescritiva ou um conjunto de práticas de engenharia de software.

Também não é um processo ou uma técnica para criar produtos. 

Scrum é um framework leve e simples criado para gerenciar o desenvolvimento de produtos. Com base no framework Scrum, você pode adicionar as práticas, técnicas ou ferramentas que julgar mais adequadas de acordo com a sua indústria, seja ela desenvolvimento de software, marketing, recursos humanos, educação, etc. 

A seguir a definição de Scrum segundo o Scrum Guide (2020):

Scrum é um framework leve e simples que ajuda pessoas, equipes e organizações a gerar valor por meio de soluções adaptativas para problemas complexos.

Neste vídeo o Jeff Sutherland, um dos criadores do Scrum, fala sobre a inspiração que teve para desenvolver o framework.

Qual a origem do nome Scrum?

O termo Scrum tem origem no jogo de Rugby. As jogadas representadas no vídeo abaixo na qual ambos os times ficam em formação coesa lutando pela posse da bola se chama “scrum”. 

Você percebe quais as características dessas jogadas? Times unidos, coesos, em busca de um objetivo comum, com responsabilidades bem claras entre as pessoas.

Um dos artigos considerados precursores do Scrum é o “The new product development game”, publicado na Harvard Business Review em 1986.

Nele, Nonaka e Takeuchi (professores da Harvard University) utilizaram a metáfora da jogada do Rugby (scrum) ao descrever a maneira na qual empresas como Honda, Canon e Fuji-Xerox conquistaram grandes resultados.

De fato, os times dessas empresas utilizavam uma abordagem de trabalho escalável baseada em times com autonomia e intensa auto-organização - pilares dos métodos ágeis como o framework Scrum. 

O modelo PDCA (cuja sigla em inglês significa planejar, fazer, verificar e agir), conhecido como Ciclo de Deming, foi também uma das bases do Scrum.

Com base no artigo citado acima, no modelo PDCA e no conceito de timebox (períodos com duração fixa de tempo), Jeff Sutherland e Ken Schwaber, grandes nomes do desenvolvimento de software, criaram o framework Scrum na década de 90, publicando seu primeiro livro sobre o tema em 2001. 

Apesar de ter origens na indústria do desenvolvimento e software, os princípios do Scrum estão sendo amplamente adotados em outras diferentes áreas de negócio para organizar o fluxo do trabalho e aumentar a produtividade, gerando mais resultados.

O Scrum parece simples. E de fato ele é. Mas para aplicá-lo bem é preciso foco e disciplina

Muitas implementações do Scrum falham pois acredita-se que basta agendar algumas reuniões recorrentes, “apertar um botão” e começar a ter resultado, o que está longe de ser verdade.

Há diferença entre metodologia ágil e Scrum?

Esta é uma dúvida bastante recorrente. Podemos dizer que Scrum é ágil, mas "ágil" não é Scrum.

Em resumo, o Scrum é considerado um dos métodos ágeis, entre outros do mercado. Devido à sua simplicidade e fácil compreensão, o Scrum acabou se tornando o mais popular entre os métodos ágeis.

Porém, veremos mais adiante que, apesar de sua simplicidade, Scrum não é nem um pouco fácil de ser adotado com maestria.

Quais as diferenças e semelhanças do Kanban e Scrum?

O framework Scrum e o método Kanban são muito eficientes quando se trata de fazer a gestão do desenvolvimento de um produto, ou do trabalho do conhecimento de forma mais abrangente.

Ambos sugerem cadências (ou cerimônias) para tratar diferentes níveis de riscos. Além disso, ambos propõe papéis com responsabilidades distintas.

Os dois trazem valores explícitos, muitos deles em comum e que vão de encontro à transparência, autonomia dos times e máxima geração de valor para os clientes.

Porém, eles se diferenciam principalmente na forma de gerenciar os riscos.

O Scrum gerencia os riscos através dos sprints de duração fixa. Por exemplo, muitos times adota Sprints de 2 semanas. Isso de alguma forma blinda o backlog da sprint, ajudando o time a ter foco no que foi selecionado para ser trabalhado na Sprint.

Já o Kanban gerencia os riscos através do conceito de WIP - Work In Progress, O WIP de um certo fluxo de trabalho representa o trabalho que está em progresso (em andamento) em um dado momento no tempo. 

Desta forma, o Kanban propõe como um de seus princípios sempre gerenciar  o WIP, limitando a quantidade de itens de trabalho que são iniciados simultaneamente. 

Limitar o WIP ajuda muito a minimizar sobrecargas, gerar mais foco, entregar com mais qualidade e inclusive reduzir momentos de burnout nos colaboradores. 

Importante dizer que ambos são complementares. Por exemplo, um time que utiliza o framework Scrum pode inserir práticas do método Kanban para otimizar a eficiência de seu fluxo.

ÚNICO NO BRASIL

Workshop Agility in Leadership (CAL-E)

Formação de líderes ágeis com certificação internacional. Confira o nosso currículo e garanta sua vaga!

Saiba mais

Quem pode se beneficiar da metodologia Scrum?

Apesar de ter nascido na indústria de desenvolvimento de software, o Scrum vem sendo adotado em diversas outras áreas e setores.

Marketing, jurídico, publicidade, aviação, manufatura e educação são apenas alguns exemplos de áreas que têm se beneficiado com a agilidade, organização e produtividade que o Scrum traz. 

Ou seja, se você está inserido em um contexto com algum grau de incerteza, complexidade e volatilidade, e ter rápido feedback durante a evolução do seu projeto ou produto, o Scrum é para você.

Por que utilizar o Scrum?

Scrum é um framework simples de ser compreendido, embora na prática seja complexo de ser dominado. Ele pode ser introduzido em times que precisam estabilizar seu processo de trabalho, gerando mais foco, organização e senso de time.

Trabalhar com Sprints de duração fixa, de 1 a 3 semanas, ajuda muito a priorizar, o que é uma dor de muitos times.

Além disso, o Scrum trará uma frequência maior de conversas com relação às entregas, gerando mais clareza, mais alinhamento entre os membros do time e maior feedback sobre o que está sendo construído.

Como funciona o framework scrum?


A imagem abaixo ilustra o framework Scrum, com seus eventos e artefatos.

framework Scrum

Em síntese, um Product Owner (PO) organiza o trabalho a ser feito em um Backlog de Produto. O Time Scrum seleciona itens do Backlog do Produto e o transforma em um Incremento do Produto durante uma Sprint.

Tanto o Time Scrum quanto os stakeholders (demais envolvidos) inspecionam os resultados e fazem os ajustes necessários para a próxima Sprint.

O Scrum define cinco eventos (também chamados de cerimônias). São elas:

  • reunião de planejamento (Planning Meeting)
  • reunião diária (Daily Scrum)
  • reunião de revisão da Sprint (Sprint Review)
  • reunião de retrospectiva da Sprint (Sprint Retrospective
  • a Sprint em si, a qual engloba os demais eventos acima

Conforme veremos a seguir, cada um desses eventos tem seus objetivos específicos, a fim de tornar o desenvolvimento do produto produtivo e eficaz. 

Quais os pilares do Scrum?

O Scrum tem seus pilares provenientes do controle empírico de processos. São eles:

  • Transparência
  • Inspeção
  • Adaptação

O pensamento enxuto (lean thinking) também é considerado um grande influenciador do Scrum. De fato,  um Time Scrum busca a todo momento reduzir desperdícios de todos os tipos e agregar o maior valor possível através do produto sendo construído.

Durante o desenvolvimento do produto, fazemos frequentes inspeções, de tempos em tempos, não somente do produto sendo construído, mas também na maneira como estamos construindo, ou seja, o processo de trabalho.

Para que essa inspeção aconteça de forma eficaz, é necessário transparência. Todas as informações necessárias para a construção do produto devem estar disponíveis para todas as pessoas envolvidas nessa empreitada. 

A transparência torna a inspeção possível, e consequentemente a adaptação. Como consequência temos uma melhor comunicação e alinhamento entre as pessoas, aumentando a confiança da equipe.

Esse é o espírito da melhoria contínua tão presente nos métodos ágeis. Porém, para que as melhorias aconteçam rapidamente, um time Scrum precisa conseguir se auto-gerenciar e deve ser capacitado e empoderado para isso.

Agile Scrum Pilares

Quais os valores do Scrum?

Como todo bom framework, o Scrum é baseado em valores.

Compreender profundamente os valores do Scrum é importante pois eles ditam a maneira como as decisões são tomadas, gera clareza em momentos de ambiguidade e comunicam porque o time faz o que ele faz. 

Os valores do Scrum são:

  • foco
  • respeito
  • comprometimento
  • coragem
  • abertura.

Os valores são grandes direcionadores para o trabalho, as ações e comportamentos do time. 

Quando esses valores são incorporados pelo Time Scrum, os pilares transparência, inspeção e adaptação ganham vida. Vejamos o significado de cada um dos valores.

Foco

Focar significa direcionar a atenção para algo. No contexto do Scrum, o foco significa evitar trabalhar em uma quantidade de itens ao mesmo tempo de forma a minimizar as mudanças de contexto e reduzir retrabalhos. 

O time precisa fazer o que for preciso para manter o foco durante toda a Sprint e concentrar-se na entrega a ser feita, evitando interrupções, reuniões desnecessárias, mensagens ou qualquer interrupção que não seja relevante para entregar o trabalho na Sprint corrente.

Respeito

Respeito entre os membros de um time Scrum é fundamental para o sucesso de um projeto. Neste sentido, sua falta pode levar o projeto para o fracasso. 

Em um time Scrum, não existe “nós contra eles”. Já vi diversos times de desenvolvimento de produtos que diziam ser ágeis, nos quais um grupo de programadores conflitava o tempo todo com o grupo de testadores, muitas vezes perdendo o respeito uns pelos outros. 

Em contrapartida, um time Scrum é uma unidade celular com objetivos em comum. Os membros do time mantém a confiança uns nos outros sempre com respeito. 

Assim, quando alguém do time se compromete com uma tarefa, o time confia e o apoia. Da mesma forma, o respeito permite que seja possível expor quaisquer dificuldades e obstáculos de forma objetiva e transparente.

Comprometimento

Comprometimento pode ser traduzido como juramento, promessa ou dever em entregar algo. 

Certamente comprometimentos não devem ser superficiais. A cada Sprint, por exemplo, o time Scrum define de forma bastante clara e transparente o que se compromete a entregar no Sprint. 

Esse comprometimento é compartilhado dentro do time e também para a empresa. Uma vez comprometido com as entregas, é obrigação do time Scrum fazer tudo o que estiver a seu alcance para fazer acontecer.

Coragem

Coragem é a habilidade de encarar desafios e dificuldades, apesar do medo. Todos sentimos medo. A questão é o que fazemos com ele. 

Já vi muitos profissionais excelentes, mas que simplesmente paralisam diante do medo. Nem todos os membros de um time conseguem lidar com o medo sem congelar. 

Por isso, eles devem ajudar uns aos outros, aliviando o medo e fazendo com que o time todo saiba lidar melhor com as maiores dificuldades. 

Desta forma, o time precisa de coragem para discutir dificuldades ou notícias ruins de forma aberta, respeitosa e produtiva, sem julgamentos desnecessários.

Problemas não podem ficar debaixo do tapete, senão mais cedo ou mais tarde a situação fica pior.

Por que a coragem é tão importante? É simples. Quando times não têm coragem para fazer o que eles acham que é o certo, provavelmente a coisa certa não será feita. 

Abertura

Em um time Scrum existe abertura para colocar verbalmente quaisquer pontos relevantes para o desempenho do time e do projeto. 

Em síntese, o time Scrum procura sempre estar aberto para novas ideias, percepções, e diferentes formas de pensar. Isso é combustível para a criatividade e ajuda a construir times de alto desempenho e organizações de aprendizagem.

Quais os papéis do Scrum?

Em um time Scrum existem apenas três papéis distintos, os quais representam responsabilidades específicas: o Product Owner, o Scrum Master e os Desenvolvedores.

Product Owner

O Product Owner (também chamado de PO) é orientado ao negócio, sendo o principal responsável por direcionar o rumo do produto a ser construído. 

Ele deve compreender muito bem o mercado no qual está inserido, as necessidades e prioridades da empresa, dos clientes e dos usuários do produto, comunicando claramente o Objetivo do Produto

Durante todo o desenvolvimento do produto e sua evolução, o Product Owner toma ações baseadas em análises de custo-benefício envolvendo escopo, datas, orçamento e critérios de qualidade, benefícios gerados para o usuário, entre outros. 

É o Product Owner quem define, em última instância, as prioridades do time a cada Sprint. Um PO eficaz é aquele que gerencia o dinheiro destinado ao projeto como se fosse dele, priorizando sempre aquilo que tiver a maior probabilidade de gerar valor para os clientes e retorno sobre o investimento.

Além disso, ele sabe se comunicar bem com os clientes e todos envolvidos na construção do produto, ajudando a maximizar o valor de negócio do produto. 

Além de avaliar os fatores econômicos e estratégicos do produto, o Product Owner também auxilia nos testes e na validação daquilo que o time constrói, auxiliando na definição dos critérios de aceitação.

Diferente de modelos tradicionais de gestão, no Scrum o Product Owner tem atuação intensa e constante junto ao negócio, colaborando com os envolvidos ou stakeholders (olhar para fora do time) e atua também muito próximo ao time de desenvolvimento do produto (olhar para dentro do time). 

Os melhores PO’s que já conheci não tinham somente grande conhecimento do negócio e estratégia de produto, mas também tinham grandes habilidades para lidar com pessoas, para se comunicar, além de saber negociar.

Scrum Master

A principal missão de um Scrum Master é ajudar todos do Time Scrum (incluindo o Product Owner) a compreenderem e adotarem os valores e práticas do Scrum da melhor maneira possível. Por isso dizemos que o Scrum Master é, entre outras coisas um facilitador.

Enquanto o PO é direcionado ao negócio, o Scrum Master é orientado às pessoas e ao processo, ajudando o time a implementá-lo.

De fato, trata-se de um líder-servidor, pois mesmo não tendo autoridade hierárquica junto ao time, ele está a todo momento verificando como servir melhor ao time, ao mesmo tempo que fornece coach, treinamento e mentoria para sempre manter o desempenho de todo o time o melhor possível. 

O Scrum Master atua como facilitador durante os eventos do Scrum, facilitando para que os objetivos de cada reunião sejam cumpridos no tempo definido. 

Além disso, ajudar o Product Owner a compreender técnicas de priorização e facilitação também é uma missão deste papel tão importante, além de gerenciar interferências externas que possam atrapalhar o andamento do time. 

Porém, acredito que uma das responsabilidades mais nobres de um Scrum Master é fomentar os comportamentos para gerar agilidade em toda a empresa. 

Uma vez que um time tem sucesso usando o Scrum, é possível que outros times da empresa queiram utilizar o mesmo processo.

Neste caso, o Scrum Master pode atuar como um grande porta-bandeira, de forma colaborativa e auxiliar diretamente na aplicação de mudanças de processos em outros times.

Desta forma, conforme a auto-organização do time aumenta, o Scrum Master passa a ter sua atuação reduzida com o passar do tempo.

Este é um bom indicador de que o time como um todo está fazendo um bom trabalho. 

Desenvolvedores

O terceiro papel do Scrum são os desenvolvedores. O termo “desenvolvedor” remete à indústria de tecnologia (desenvolvimento de software) mas podemos enxergar os membros do time de desenvolvimento como pessoas que constroem o produto.

Em um projeto para desenvolver um novo software, o time de desenvolvimento tipicamente é composto por programadores, designers, testes entre outros profissionais. 

Por outro lado, um time de marketing digital, por exemplo, os “desenvolvedores” são os especialistas em gestão de anúncios, SEO, geração de conteúdo, etc. 

Portanto, não importa a natureza do trabalho a ser feito. O Scrum define o time de desenvolvimento como as pessoas que efetivamente realizarão as atividades de construção do produto.

De fato, times Scrum são mais eficazes quando são pequenos, em geral compostos por 3 a 9 pessoas.

Isso facilita a comunicação entre todos os membros do time, ajudando a manter o foco e estreitando o relacionamento. 

Todas as habilidades necessárias para construir o produto estão presentes em um ou mais membros do time. Por isso dizemos que um time Scrum é multifuncional. 

Além disso, outra característica é sua auto-organização. São os membros do time quem definem as práticas, ferramentas e formas de trabalhar.

Eles têm autonomia para fornecer as melhores soluções e grande responsabilidade para estar sempre melhorando seus processos de trabalho.

Certamente uma das principais características de um time Scrum é que ele é focado no problema a ser resolvido e no atingimento do Objetivo do Produto.

O foco não está em entregar horas de trabalho ou aumentar porcentagens de avanço em cronogramas, mas sim resolver um problema, através de algum resultado gerado. 

De fato, o time gerencia seu próprio trabalho e têm autonomia para definir como trabalhar juntos e como fazer o trabalho, estando sempre alinhados com os objetivos da empresa e do produto que estão construindo.  

Todos do time são mutuamente responsáveis pelo resultado do time como um todo e monitoram o andamento do seu próprio trabalho. 

Quais os eventos do Scrum?

A forma como o Scrum aplica na prática seus pilares de transparência, inspeção e adaptação é através dos eventos.

Cada evento no Scrum é uma oportunidade formal para inspecionar e adaptar os artefatos do Scrum. 

Mas você pode estar se perguntando: “Por que tantas reuniões??”

A resposta é clara…

Na verdade, esses eventos são projetados dentro da Sprint de forma estratégica para gerar a transparência necessária.

Desta forma, os eventos criam regularidade e minimizam a necessidade de reuniões extras e paralelas. 

O ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade. Todos os eventos do Scrum são “timebox”, ou seja, têm uma duração fixa de tempo. 

Ferramenta Scrum Eventos

Então vejamos a seguir quais são os eventos do Scrum e como funcionam.

A Sprint

A Sprint é considerada um evento do Scrum. Vejamos o porquê...

Imagine que você está prestes a iniciar uma viagem de automóvel até uma cidade que você nunca foi antes e que está a 400 quilômetros de distância. 

A estrada está com bastante neblina e você não sabe exatamente o que te espera durante o percurso, apesar de estar usando seu aplicativo de navegação por GPS.

Você somente enxerga alguns metros de distância e a cada pequeno trecho precisa re-planejar mentalmente como conduzirá o veículo. 

Você também não sabe exatamente onde irá parar para abastecer, ir ao banheiro ou se alimentar, mas sabe que irá fazer entre 2 e três paradas, ajustando o plano da viagem algumas vezes…

Ou seja, podemos dizer que o planejamento desta viagem é feito com princípios ágeis.

Mike Cohn, um dos maiores especialistas em desenvolvimento ágil, diz que “um projeto está em risco se o seu planejamento vai além do horizonte de visibilidade do planejador e se o plano não prevê tempo para o time levantar a cabeça, olhar para o novo horizonte e fazer ajustes”.

Ao construirmos um produto de forma ágil, o planejamento é elaborado progressivamente durante o projeto e não somente no início. 

O Scrum é um framework ágil, portanto, o produto é desenvolvido de maneira iterativa e incremental. O trabalho é realizado em diversas iterações (ou ciclos) que têm duração fixa. Chamamos uma iteração de Sprint. 

A Sprint define a pulsação, a cadência durante o desenvolvimento do produto. Cada Sprint é considerada um evento “timeboxed”, ou seja, tem duração fixa de tempo e, portanto, tem datas de início e término definidas. 

Qual o tamanho ideal para a Sprint? 

Em geral é mais comum encontrar times Scrum que utilizam Sprints de uma a três semanas. Não existe uma fórmula mágica para definir o tamanho da Sprint.

Porém, existem alguns critérios que podemos levar em consideração:

Avalie a duração esperada do projeto

O tamanho da Sprint deve levar em consideração a duração estimada do projeto (caso você esteja trabalhando em um projeto específico), porém sugerimos que nunca seja maior que quatro semanas. 

Imagine um projeto de três meses para desenvolver um novo produto. Se adotarmos um Sprint de 4 semanas (1 mês), teremos apenas três ciclos de feedback para mitigarmos os riscos e absorvermos possíveis mudanças durante o projeto. 

Neste caso, talvez seja interessante adotar Sprints de duas semanas, o que dobraria a quantidade de ciclos de feedback com o cliente.

Por outro lado, para projetos muito pequenos (um a  dois meses), podemos pensar em Sprints semanais. 

Portanto, avalie a duração estimada do projeto e a quantidade de ciclos de feedback necessários para reduzir o risco do projeto.

Verifique a disponibilidade do Product Owner e stakeholders

É importante compreender a disponibilidade daqueles que irão avaliar e validar as entregas feitas pelo time a cada Sprint.

Essa validação é realizada pelo Product Owner, muitas vezes juntamente com o cliente ou demais stakeholders do projeto. 

Um Sprint semanal pode ser desgastante para times cujos Product Owners e stakeholders não estão tão disponíveis. 

Obviamente é responsabilidade do  Product Owner estar presente junto ao time para esclarecimentos e apoio, porém, em algumas organizações nas quais ele é um representante do cliente final, pode ser necessário inicialmente adequar o tamanho do Sprint à disponibilidade do cliente. 

Analise a natureza das atividades

Outro fator a ser considerado na definição do tamanho da Sprint é a natureza das atividades realizadas pelo time do projeto. 

Em um dos times de marketing que trabalhei, as atividades realizadas eram curtas, variando de poucas horas a alguns dias. 

Desta forma, ao final de uma semana existia uma quantidade de trabalho considerável que justifica a coleta de feedback e, portanto, esse time adotou Sprints de 1 semana. 

Em contrapartida, em um outro time de desenvolvimento de software que atuei, era necessário um tempo um pouco maior para construir um incremento de software possível de ser submetido à validação do cliente.

Neste caso, adotou-se Sprints de duas semanas.

Avalie o grau de estabilidade do escopo

Em ambientes extremamente voláteis, o escopo do projeto pode mudar com muita frequência, o que nos leva a adotar Sprints menores para que o risco seja melhor absorvido. 

Da mesma forma, em projetos cujo escopo é razoavelmente estável, pode-se pensar em Sprints maiores.

Por que não Sprints maiores que 1 mês? 

No livro “Agile Project Management with Scrum”, Ken Schwaber responde essa pergunta desta forma: 

A Sprint tem duração fixa até 30 dias corridos consecutivos. Este é também o tempo máximo que pode ser alocado sem que o time realize muito trabalho que exige artefatos e documentação para suportar sua compreensão.

É também o tempo máximo que a maioria dos stakeholders vão esperar sem que percam o interesse pelo progresso do time e sem perder a sua crença de que o time está fazendo algo significante para eles”

No início de cada Sprint o time define qual o trabalho que se compromete a fazer dentro da Sprint, baseado nas prioridades definidas pelo Product Owner. Isso acontece na reunião de planejamento da Sprint, conforme veremos mais adiante. 

São os membros do time que planejam e definem o que acreditam que conseguem entregar em uma Sprint. Assim, é possível limitar a quantidade de trabalho em progresso (o trabalho que foi iniciado, mas não terminado), reduzindo riscos. 

Quanto mais curto um Sprint, mais simples será o seu planejamento, pois o time discutirá menos trabalho a ser feito. 

E quando a Sprint precisa sofrer um replanejamento?

Toda a Sprint pode sofrer impacto. Nunca sabemos, por exemplo, quando alguém do time ficará doente, pedirá demissão ou terá algum problema pessoal que necessite de alguns dias de afastamento. 

Além disso, por mais que o time tenha feito um bom trabalho de planejamento na Sprint, problemas de diferentes naturezas podem acontecer no meio da Sprint, fazendo com que o time identifique que será impossível cumprir o planejado se a situação continuar como está. 

Toda iniciativa precisa de procedimentos de emergência, desde um voo sobrevoando o Atlântico até uma Sprint no meio de um projeto. 

Possíveis “procedimentos de emergência” de uma Sprint ameaçada são listados abaixo. Abrir mão desses procedimentos, nesta ordem, pode ajudar o time a minimizar o impacto no projeto.

  1. O time analisa rapidamente as causas-raiz do problema e discute possíveis soluções utilizando os conhecimentos de todos.
  2. Se o time não conseguir resolver os problemas, ele solicita ajuda de alguém fora do time. Se houver alguém disponível em outro time que saiba como resolver o grave impedimento do time, essa ajuda será muito bem-vinda.
  3. Se as alternativas acima falharam, o time avalia com o PO quais entregas de menor prioridade podem ser removidas da Sprint, replanejando o que pode ser entregue até o final da Sprint atual de forma mais realista. 
  4. Se a situação do Sprint é tão grave que as três opções acima não surtiram efeito, é preciso apertar o botão vermelho e cancelar a Sprint. Somente o Product Owner pode autorizar o cancelamento de uma Sprint, porém isso deve ser uma decisão coletiva envolvendo os membros do time, Scrum Master e stakeholders. 

O cancelamento da Sprint pode também ocorrer quando um concorrente lança um novo produto ou nova funcionalidade no mercado que nos obriga a mudar as prioridades imediatamente. 

Além disso, o mesmo pode ocorrer quando ocorre algum incidente grave na empresa e as únicas pessoas que têm o conhecimento para estabilizar a situação estão trabalhando na Sprint em questão e precisam ser realocados. 

Ao cancelar uma Sprint, o time se reorganiza e reagenda todas as reuniões, planejando a nova Sprint imediatamente e comunicando os stakeholders.

Não existe intervalo entre duas Sprints. Quando uma termina, a próxima inicia imediatamente.

Em resumo, a Sprint é uma espécie de contêiner para todos os outros eventos.

Planejamento da Sprint (Sprint Planning)

O objetivo da reunião de planejamento da Sprint é determinar o que pode ser entregue na Sprint que se inicia, e como o trabalho será feito. 

Nessa reunião, todos os membros do time Scrum (Product Owner, Scrum Master e Desenvolvedores) participam. A duração sugerida para a reunião é de 2 horas para cada semana de Sprint. 

Portanto, caso a Sprint seja de 2 semanas, a reunião de planejamento poderá levar até 4 horas. Assim como em todo evento timebox, essa é uma duração máxima para a reunião, a qual pode terminar antes. 

Para que a reunião de planejamento seja produtiva, é importante que o backlog do produto esteja organizado e priorizado antecipadamente. 

Apesar do Product Owner ser o responsável pela priorização dos itens do backlog, somente o time de desenvolvimento (desenvolvedores) podem decidir a quantidade de itens selecionados. 

Por isso, todo o time deve ter clareza quanto a capacidade projetada do time para a Sprint. 

Quantos developers estarão trabalhando em tempo integral nesta Sprint? Alguém vai sair de férias? Alguém irá trabalhar em tempo parcial? 

A disponibilidade atual do time irá direcionar o volume de trabalho comprometido na Sprint.

A reunião de planejamento da Sprint deve responder a três tópicos importantes, as quais podem ser consideradas etapas da reunião.

  1. Por que essa Sprint tem valor?
  2. O que conseguiremos fazer nessa Sprint?
  3. Como o trabalho escolhido será feito?

Vejamos com mais detalhes o que acontece em cada uma dessas etapas.

Tópico I - Por que essa Sprint tem valor?

Inicialmente, o Product Owner compartilha de que forma o produto pode gerar valor através da Sprint que está se iniciando. 

O time todo colabora para definir uma meta do Sprint. Essa meta pode ser refinada durante a reunião de planejamento da Sprint.

Tópico II - O que conseguiremos fazer nessa Sprint?

Em seguida, o Product Owner compartilha os itens prioritários do backlog. Então, o time de desenvolvimento verifica quais itens são possíveis de serem concluídos durante a Sprint, de acordo com a sua capacidade atual. 

Como veremos mais adiante, a cada Sprint o time define (na reunião de retrospectiva) quais melhorias serão realizadas em seu processo de trabalho na próxima Sprint. 

Portanto, além de novas funcionalidades, é preciso alocar ao menos uma melhoria como parte do trabalho a ser feito durante a próxima Sprint.

Tópico III - Como o trabalho escolhido será feito?

Em terceiro lugar, o time define como irá construir os itens selecionados, gerando um plano de trabalho para a Sprint. Os itens selecionados e o plano de trabalho para a Sprint definem o Backlog da Sprint. 

O trabalho planejado para os primeiros dias da Sprint é decomposto em tarefas de trabalho menores (tipicamente até dois dias de trabalho cada tarefa). 

Durante o planejamento da Sprint, o Product Owner oferece esclarecimentos quanto às regras de negócio e às prioridades. 

Caso o time perceba que se comprometeu com muito ou pouco trabalho, ele renegocia os itens do backlog com o Product Owner, para que o montante de trabalho alocado na Sprint seja o mais realista possível. 

O time também pode convidar outras pessoas para esclarecer dúvidas técnicas pertinentes ao produto.

Certamente decompor itens do backlog em tarefas menores não é trivial, mas é um trabalho essencial para que o planejamento da Sprint seja realista. 

De fato, times que não fazem a decomposição em tarefas menores correm o risco de assumirem lotes grandes de trabalho e não conseguem terminá-los na Sprint, gerando frustração no time. 

Não existe uma regra única para fazer essa decomposição.  É preciso que o time procure o seu nível de granularidade ideal e esteja mais confortável e com mais visibilidade do trabalho após a decomposição do que antes dela. 

Evitar grandes lotes de trabalho decompondo-os em tarefas menores é uma boa prática para reduzir riscos durante a Sprint.

O objetivo não é atingir 100% de precisão nas estimativas (o que é praticamente impossível), mas sim obter um grau de acurácia que deixe o time confortável durante a Sprint. 

Após a reunião de planejamento, o time de desenvolvimento inicia os trabalhos para executar o plano criado, de forma auto-organizada, rumo à entrega do próximo incremento do produto.

Reunião diária (Daily Scrum)

Durante a Sprint o time trabalha nos itens selecionados. Diariamente, realiza-se uma reunião de no máximo 15 minutos (Daily Scrum), idealmente no mesmo horário. 

Nesta reunião o time inspeciona rapidamente seu trabalho e planeja o trabalho a ser feito para as próximas 24 horas

De fato, a reunião diária é uma oportunidade de inspecionar a Sprint atual e verificar o seu progresso, além de identificar os gargalos e as dependências que possam estar ameaçando a meta da Sprint atual. 

Durante os 15 minutos, os membros do time relatam rapidamente em que estão trabalhando e se têm algum impedimento (algo que esteja bloqueando ou desacelerando seu trabalho). 

Mais importante do que relatar “em que trabalharam ontem” e “em que irão trabalhar até a próxima reunião diária”, o time relata de forma transparente qual a sua real confiança em cumprir o planejado para a Sprint atual. 

Se o nível de confiança for alto, ótimo! Se for baixo, é preciso discutir possíveis ações depois da reunião.

Após a reunião os membros do time podem se reunir em grupos menores para tratar mais a fundo problemas que possam ter aparecido. 

É importante que o timebox de 15 minutos seja respeitado, para que a reunião diária não se torne uma reunião de trabalho ou de status report (este não é o objetivo desta reunião).

A presença do Product Owner e do Scrum Master é opcional, dado que a reunião diária é dedicada aos demais membros do time. 

Para os times que estão iniciando na adoção do Scrum, é importante que o Scrum Master esteja presente nas reuniões diárias até que os membros do time tenham condições de fazê-la sozinhos de forma produtiva.

Apesar de ser algo simples, a reunião diária muitas vezes se torna extremamente improdutiva. Pessoas atrasadas, falta de participação, discussões que extrapolam os 15 minutos e conflitos são características de reuniões diárias improdutivas. 

A verdade é que todos os times conseguem fazer reuniões diárias produtivas. Basta trabalhar com foco para melhorar a eficácia da reunião. 

Não desista da reunião diária se ela não funcionar nas primeiras vezes e sempre reforce a importância da reunião. Quando o time menos esperar, a reunião diária será parte natural do processo.

Revisão da Sprint (Sprint Review)

A reunião de revisão da Sprint (Sprint Review) ocorre tipicamente no último dia. Ela tem como objetivo inspecionar as entregas feitas pelo time durante a Sprint e adaptar o backlog do produto se necessário. 

Essa reunião tem duração de até 1 hora por semana de Sprint. Assim, para Sprints de 2 semanas, a revisão pode durar até 2 horas

Nesta reunião, o time compartilha o que foi construído na Sprint. O Product Owner (e stakeholders que podem ser convidados para a reunião) fornece feedback e o time todo discute sobre as entregas realizadas e realiza projeções para as próximas entregas, baseado no que foi construído até o momento. 

Parece simples, não? 

A reunião de revisão da Sprint pode ser extremamente produtiva ou super caótica. A diferença será o quanto você se prepara para ela! Certamente a qualidade de todo evento do Scrum é proporcional à sua preparação.

Antes da reunião, é importante coletar informações como os itens que foram entregues e que não foram, as decisões que foram tomadas durante a Sprint, as mudanças de prioridade que ocorreram e as métricas do projeto que o time julgue importantes. 

Além de coletar as informações previamente, definir em que sequência os itens serão revisados ajuda o time a ser mais eficaz. 

Dependendo do tipo de produto que o time está construindo, pode ser necessário preparar instalações, configurações e ambientes para fazer a revisão. 

O ideal é alocar um tempo para deixar tudo preparado evitando desperdícios de tempo e energia durante a reunião.

Alocar, por exemplo, 1 hora dos membros do time preparando a reunião de revisão da Sprint é um investimento que costuma valer a pena.

Retrospectiva da Sprint (Sprint Retrospective)

Se eu tivesse que escolher um único evento do Scrum, eu escolheria, sem dúvidas, a Retrospectiva. Vejamos porque...

O time fez o planejamento da Sprint, trabalhou para entregar o que se comprometeu, fez as reuniões diárias para sincronização e alinhamento e fez a revisão da Sprint  com o Product Owner e stakeholders...

Chegamos na reta final da Sprint! É hora de fazer a última reunião, chamada de retrospectiva da Sprint (Sprint Retrospective).

A retrospectiva, que acontece logo após a reunião de revisão (em geral após um pequeno intervalo de alguns minutos). 

Assim como a reunião de revisão, todo o time deve participar da retrospectiva (Scrum Master, Product Owner e desenvolvedores). 

A retrospectiva da Sprint é uma oportunidade para o time scrum se inspecionar e criar um plano de melhorias para ser executado durante a próxima Sprint.

A retrospectiva tem duração de até 1 hora por semana de Sprint, e é fundamental para a melhoria contínua

Nesta reunião, o time expõe de forma bastante transparente o que está funcionando e o que deve ser melhorado na maneira que o time está trabalhando. 

De fato, este é o momento de inspecionar o trabalho e fazer as devidas adaptações. O resultado de uma reunião de retrospectiva é uma lista de melhorias a serem feitas no processo de trabalho, já na próxima Sprint. 

É muito comum vermos times adotando Scrum e ao primeiro sinal de dificuldade, eliminam a reunião de retrospectiva do seu processo, como se ela fosse perda de tempo.

Se esse é o sentimento do time, então ele ainda não compreendeu a real importância da retrospectiva. 

Reuniões de retrospectivas não são fáceis. Elas demandam tempo, comprometimento e energia do time, além de coragem, mas são parte fundamental do ciclo de inspeção e adaptação do time. 

Todas as outras partes da Sprint (planejamento, reuniões diárias e reunião de revisão) tem como foco entregar o trabalho. 

A retrospectiva é a única oportunidade que o time tem (e, portanto, não deve ser desprezada) para avaliar como eles estão trabalhando juntos, como podem melhorar, como podem ser mais eficientes como um time e como podem aumentar a sua velocidade e qualidade

É um momento único na Sprint para pensar em melhoria contínua e garantir que o time sempre esteja seguindo em frente e não esteja estagnado (o que na verdade significaria estar caindo em termos de produtividade).

Além dos fatores descritos acima, a retrospectiva é uma oportunidade para que os membros do time ajustem seu comportamento e seu mindset diante do projeto. 

É um momento onde a confiança e a transparência devem prevalecer para que os pequenos problemas sejam endereçados rapidamente e não virem uma grande dor de cabeça no futuro.

Quais os benefícios da retrospectiva?

Ao perguntar para diversos colegas que fazem retrospectivas em seus times sobre quais são os benefícios desta reunião, frequentemente escutamos as seguintes respostas:

  • Aumento da qualidade do produto que é criado;
  • Aumento na produtividade do time;
  • Aumento na confiança entre os membros do time;
  • Maior engajamento das pessoas pelo projeto.

Problemas podem se tornar oportunidades quando o time tem o mindset de melhoria contínua. 

Deste modo, a retrospectiva é uma oportunidade fundamental para isso. Ela é parte do ciclo de inspeção e adaptação. 

O time que faz retrospectivas frequentes e procura melhorar seus processos sempre, certamente irá deixar seu legado na organização em que atua. 

Ainda mais se eles compreenderem que um time não é um grupo de pessoas que trabalha junto, mas um grupo de pessoas que confiam uns nos outros.

Para saber mais sobre técnicas de facilitação de retrospectivas, leia “Agile Retrospectives - Making Good Teams Great”.

Os artefatos do scrum

Backlog do produto

O ponto de partida do Scrum é o Backlog do Produto. Ele é uma lista ordenada e emergente com tudo aquilo que é necessário para construir ou evoluir um produto, podendo representar semanas ou meses de trabalho. 

Porém nem todo o trabalho deve ser detalhado antecipadamente. Os itens de maior prioridade ficam sempre no topo da lista e, portanto, devem estar mais detalhados do que os itens de menor prioridade, abaixo na lista. 

O Backlog do Produto é uma lista “viva”, sendo atualizado durante toda a construção do produto.

Meta do Produto

Em sua última versão (2020), o Scrum Guide introduziu o conceito de Meta do Produto (Product Goal).

Um produto é um veículo para agregar valor, não importa se ele é digital ou físico. Ele tem stakeholders, usuários ou clientes bem definidos. 

Assim, a Meta do Produto define um estado futuro para o produto. Trata-se do objetivo de longo prazo para o Time Scrum, com um olhar para o produto como um todo. 

Backlog da Sprint

O Backlog da Sprint (Sprint Backlog) é formado pela Meta da Sprint (o propósito da Sprint), o conjunto de itens do Backlog do Produto selecionados para a Sprint e um plano de ação para entregar o Incremento do produto.

Definitivamente o Sprint Backlog é um plano feito por e para os desenvolvedores e é atualizado ao longo do Sprint conforme o time faz novas descobertas. 

Esse plano deve ter detalhes suficientes para que eles possam inspecionar seu progresso no Daily Scrum.

Incremento do Produto

Um incremento é a soma de todos os itens do backlog construídos durante a Sprint adicionados aos incrementos construídos nas Sprints anteriores.

Cada incremento realizado é um passo a mais em direção à meta do Produto. Para gerar valor, o incremento deve ser utilizável, ou seja, deve ser possível que o usuário consiga de fato utilizar o produto com o incremento gerado.

Vários incrementos podem ser criados em uma Sprint. A soma dos incrementos é apresentada na Sprint Review. No entanto, um incremento pode ser entregue antes do final da Sprint. 

Qual é a importância da metodologia ágil Scrum para os times?

Ao observarmos times que fazem a transição de métodos tradicionais de gestão para o Scrum, fica claro que a jornada não é fácil. 

O Scrum propõe uma nova forma de trabalho, novos papéis, uma cadência diferente de reuniões e valores que nem sempre estão presentes na cultura da empresa.

Porém, se os times demonstram persistência e disciplina, e se os líderes, além do Scrum Master, fazem um bom trabalho, os resultados aparecem.

Alguns dos benefícios do Scrum que podemos observar em times que buscam a melhoria contínua de seu processo são:

  • redução nas taxas de retrabalho
  • maior qualidade na entrega
  • maior satisfação dos colaboradores
  • melhores resultados para o negócio
  • clientes ou usuários mais satisfeitos com o produto
  • redução de time-to-market
  • maior retorno sobre o investimento

Scrum: exemplo prático para implementar em uma empresa

Certa vez ajudei uma agência de marketing digital a introduzir o Scrum para a gestão do seu trabalho

Essa empresa estava sofrendo muito com a organização das tarefas, definição de papéis e responsabilidades, comunicação e necessidade de manter o foco nas principais entregas para os clientes.

Antes de começar a utilizar o Scrum, conversamos sobre quais problemas precisávamos resolver e que acreditávamos que o Scrum poderia ajudar.

O time queria muito reduzir o caos no qual eles se encontravam. Os membros do time tinham listas de tarefas individuais, e dificilmente havia colaboração entre eles. Isso gerava muitos atrasos e problemas de qualidade.

Inicialmente, fizemos um treinamento de Scrum para dois times selecionados como pilotos. Esta é uma dica importante.

Sempre procure introduzir algo novo na empresa aos poucos. Isso não quer dizer que será lento, mas o aprendizado e feedbacks serão acelerados.

Em seguida, mapeamos o processo de trabalho dos times, e criamos um quadro de tarefas para organizar o Backlog da Sprint. Esse quadro tinha as colunas:

  • A fazer
  • Próximas demandas
  • Em andamento
  • Em revisão
  • Aguardando publicação
  • Feito

Observação: A estrutura do quadro de tarefas deve refletir o processo do time em específico. Portanto, é natural que cada time tenha um quadro diferente.

Uma pessoa assumiu o papel de Product Owner e ajudou a organizar o Backlog do Produto. Ela era a maior especialista no negócio da empresa.

Outra pessoa passou a atuar como Scrum Master, entendendo a fundo o Scrum e ajudando o time a ser cada vez mais produtivos.

Eles começaram a adotar Sprints de 2 semanas, e após 2 meses, decidiram reduzir para 1 semana, pois a volatilidade no negócio deles era muito alta. 

Desta forma, toda semana eles priorizavam o que iriam fazer na semana seguinte, com base no que existia de mais importante no Backlog do Produto, que era organizado pela PO.

As reuniões diárias ajudavam muito a agilizar a comunicação e antecipar problemas, enquanto as retrospectivas ajudavam a melhorar o processo.

No primeiro trimestre de adoção do Scrum, os times conseguiram sair do caos e tornar seu processo mais previsível.

O sucesso dos dois times pilotos fez com que outros times passassem a se organizar da mesma forma também.

Quais as maiores dificuldades na adoção do Scrum?

Certamente a falta de transparência é um dos principais vilões da aplicação do Scrum. 

Embora o Scrum seja um framework simples de ser compreendido, ele não é tão fácil de ser aplicado. Obter mestria no Scrum exige disciplina e transparência (um dos pilares deste framework). 

O Scrum não vai resolver todas as disfunções organizacionais da empresa, mas certamente irá mostrar onde estão os problemas que impedem o aumento do desempenho do time e dos projetos. 

Isso somente é possível caso haja transparência e coragem para que os problemas sejam colocados na mesa para serem endereçados e para que o processo de melhoria contínua aconteça a cada Sprint.

Um outro fator que frequentemente inviabiliza a implantação do Scrum é o desejo de grandes resultados a curtíssimo prazo.

Muitas vezes vemos empresas sofrendo muito com o modelo comando-controle de gestão e que adotam o Scrum acreditando que em menos de um mês terão todos os seus problemas resolvidos. 

Obter resultados com o Scrum implica em dar algum tempo para que as equipes se acostumem com a mudança e construam o novo mindset de agilidade e melhoria contínua. 

Alguns Sprints são necessários para os resultados começarem a aparecer. Quanto tempo é necessário? Não existe uma resposta pronta para esta pergunta. 

Tipicamente vemos que são necessários pelo menos de 3 a 6 meses para que um time, após treinado, se acostume e domine o Scrum. Portanto, dê tempo para a sua equipe.

Outra dificuldade que empresas enfrentam na adoção do Scrum é quando o time decide alterar o framework logo no início da sua adoção. 

Decidir, por exemplo, não realizar uma das reuniões do framework em nada ajudará a aumentar a eficácia  do time. 

A sugestão é primeiro dominar o framework e todos os seus componentes para então pensar em adaptar algo para o seu contexto específico.

Por fim, vemos que algumas empresas tentam aplicar o Scrum de forma autoritária, utilizando de poder (comando-controle) para ditar como o framework será adotado e como o trabalho será realizado. 

Esta abordagem dificilmente dará certo a longo prazo. O Scrum é um framework ágil e, portanto, tem em suas raízes a autonomia e colaboração das equipes. 

Portanto, se as equipes não forem envolvidas desde o início do processo e não tiverem autonomia para decidir como eles farão seu trabalho, a auto-organização dificilmente será atingida. 

Por outro lado, se a empresa fornece claro direcionamento dos objetivos estratégicos e deixa por conta das equipes as definições sobre como o trabalho será organizado, a auto-organização e a agilidade organizacional tem caminho aberto para crescer.

OKR e Scrum: É possível combiná-los?

Assim como aconteceu com o Scrum anos atrás, OKR está sendo cada vez mais adotado por empresas em todo o mundo. 

Mas como OKR e Scrum se relacionam? Como é possível combinar esses dois frameworks?

O que são OKRs

OKR é um framework extremamente eficaz que ajuda a trazer foco, alinhamento e engajamento nas equipes e em toda a empresa.

O principal princípio de OKR é o planejamento baseado em resultados (ou outcomes, em Inglês), e não em atividades, projetos ou iniciativas. 

Neste sentido, "resultado" significa algum benefício mensurável para o negócio, clientes e/ou colaboradores. 

Como OKR complementa Scrum

De fato OKR tem muita sinergia com métodos ágeis como o Scrum, pois ele trabalha em ciclos curtos de definição de metas, gerando mais agilidade para o negócio.

Scrum sugere Sprints de curta duração para realizar a entrega de itens do Backlog do Produto e obter feedbacks frequentes sobre os incrementos do produto.

Por outro lado, OKR propõe ciclos curtos, tipicamente de 3 meses para a definição de objetivos e resultados chave (os Key Results). 

Um objetivo representa algo que queremos melhorar ou atingir, enquanto os Key Results representam como iremos medir se estamos caminhando rumo ao atingimento do objetivo.

Conheça 10 Exemplos de OKR que você NÃO deve seguir e Quais Usar
método scrum e okr: é possível combiná-los?

Certamente o uso correto de OKR irá ajudar o time a priorizar o seu Backlog de Produto. Isso acontece pois, ao pensar em bons OKR, você irá definir quais benefícios mensuráveis quer gerar para os clientes e para o negócio.

Aliás, um dos principais erros que times cometem ao adotar OKR é definir atividades em seus Key Results. Essa não é a proposta de OKR. Para gerenciar atividades já temos o próprio Scrum!

Além disso, OKR ajuda a trazer disciplina e aprendizado, através do check-in - reunião de curta duração para acompanhamento dos resultados. 

Times Scrum podem utilizar uma parte da reunião de Revisão da Sprint (Sprint Review) para fazer seu check-in.

Quais as diferenças entre OKR e Scrum?

Em resumo, quando pensamos nas diferenças entre OKR e Scrum, três coisas se destacam.

Objetivo

Em primeiro lugar, o Scrum é voltado para desenvolvimento de software ou outros projetos complexos como já citado. 

OKR, no entanto, fornece a base para a definição de metas ambiciosas mais amplas, como aumentar o impacto que um produto ou empresa gera.

Tempo

Em segundo lugar, um ciclo de OKR é geralmente definido para um período entre 3 a 12 meses, enquanto o Scrum se concentra em um período de 1 a 4 semanas.

Adaptabilidade

Finalmente, OKR é um framework universal e se adapta em qualquer modelo de negócio ou estrutura organizacional.

O Scrum, por outro lado, requer uma equipe com papéis prescritivos, artefatos e eventos definidos conforme o Scrum Guide.

Não existe o “guia de OKR” e nem a “certificação” oficial de OKR. O que existem são práticas e princípios de adoção que foram emergindo a partir da experiência prática de empresas, a maioria delas do Vale do Silício.

Quais são as semelhanças entre OKR e Scrum?

OKR e Scrum têm alguns princípios em comum. Vejamos quais são.

Transparência

Ambos possuem a transparência como pilar fundamental. Quando definimos OKR para um time ou uma empresa, eles devem ser compartilhados abertamente. 

Critérios de sucesso

Além disso, a importância de ter uma imagem clara do que significa sucesso é forte em ambos os frameworks. Com OKR, por exemplo, o sucesso é definido pelo fato de os principais resultados terem sido alcançados. 

No Scrum, um item de trabalho ou incremento de produto é finalizado quando se torna “pronto”, e cabe a cada time definir a sua própria definição de “pronto”. Isso também aumenta a transparência entre a equipe.

Eficácia

OKR e Scrum podem ser adotados em conjunto de forma bastante eficaz. Os OKRs, quando bem definidos, ajudam as equipes a articular as metas gerais de uma organização, produto ou time. 

Já o Scrum traz um processo de execução e entrega em projetos complexos. Eles funcionam muito bem juntos.

Mas para isso acontecer, os itens priorizados no Backlog do Produto devem ser definidos de forma a ajudar a atingir os OKRs definidos. 

Aliás, é muito comum times Scrum começarem a adotar OKR, e perceberem que boa parte do seu backlog não gera nenhum valor.

Conclusão

Concluindo, o framework Scrum é o mais popular entre os métodos ágeis. Ele fomenta o trabalho em equipe de forma transparente, com autonomia e alinhamento.

Porém, OKR pode ser seu grande aliado para evitar um mergulho excessivo em projetos, features, roadmaps e backlogs sem nenhuma medição e resultados mensuráveis.

Mais importante do que entregar algo com eficiência, é definir e medir os benefícios mensuráveis para o negócio, clientes e colaboradores. Esta é a missão de OKR.

Read More
o que é employee experience
Agile

Employee Experience: O Que É, Benefícios e Como Adotar?

O Employee Experience é um dos pilares para o sucesso das empresas. Confira, neste artigo, o que significa o termo em pauta, quais são os benefícios e como adotá-lo!

O sucesso de qualquer empresa é representado não só pela satisfação dos clientes.

A experiência dos colaboradores também é fundamental para alcançar bons resultados.

É por isso que o termo Employee Experience Management tem sido cada vez mais comum nas organizações.

Dito isso, pare e pense: o que você faz para garantir as melhores vivências e experiências aos profissionais?

Se faltam ideias realmente efetivas, é hora de entender mais sobre o conceito em pauta, além dos benefícios e o modo de operação dele. 

Confira todas as informações por aqui!

O Que É Employee Experience?


Employee Experience (Gestão da Experiência do Funcionário) é o conjunto de ações pensadas e executadas para melhorar a experiência dos colaboradores. 

Mas, atenção: cuidar da vivência dos profissionais não significa, somente, criar uma sala de descanso ou, ainda, oferecer um happy hour toda semana.

O conceito vai muito além disso. 

Um bom exemplo de Employee Experience é o caso da Cervejaria Ambev. No fim de 2020, a empresa anunciou a contratação de uma diretora de saúde mental. 

O papel da profissional é fazer com que as pessoas possam pensar em novas ideais constantemente, mas sem prejudicar o lado psicológico e o bem-estar delas. 

A Ambev também conta que, há tempos, já tinha a intenção de criar um ambiente com atenção para a vulnerabilidade, empatia e escuta.

Qual a Importância da Experiência do Colaborador?


Ao olhar com mais cuidado para os colaboradores, você garante um dia a dia mais saudável para eles. 

Com isso, todos podem se sentir mais à vontade para trabalhar, realmente vestir a camisa da empresa e, assim, alcançar grandes resultados. 

Outro ponto importante é a oportunidade de ajudar a construir e destacar carreiras profissionais.

Como Adotar a Estratégia de Employee Experience?


Mas, afinal, como apostar no Employee Experience e suas ideias? 

De antemão, saiba que é imprescindível fomentar uma cultura empresarial com base em  valores mais humanos e, consequentemente, atentos às relações com as pessoas. 

Depois, vem as seguintes tarefas: 

Conheça os Seus Colaboradores

Não há como implementar o Best Employee Experience sem conhecer quem faz parte das suas equipes.

Sendo assim, dedique-se ao máximo para conhecer verdadeiramente os colaboradores, ou seja, saber quais são suas ambições, talentos, habilidades e desafios que possuem. 

Tenha Um Alinhamento Entre Employee Experience e Customer Experience

O Customer Experience é aplicado para marcas garantirem que seus clientes tenham a melhor experiência em relação a produtos e serviços.

Essa estratégia também precisa andar lado a lado com o Employee Experience. 

Muitas vezes, a falta de satisfação e fidelização de consumidores pode ter origem em um local de trabalho tóxico e insalubre. 

É fundamental criar um ecossistema positivo para que nasçam grandes ideias e soluções sobre produtos e serviços

Ofereça um Ambiente de Crescimento e Valorização

Como dissemos, a experiência do colaborador também garante a construção e aperfeiçoamento da carreira profissional. 

Por isso, ofereça cursos, feedbacks, projetos e tarefas para que as pessoas realmente possam crescer. Além disso, ajude a formar planos de carreira claros, objetivos e que empoderam aqueles que se dedicam

Quais São as Principais Vantagens do Employee Experience?

employee experience: principais vantagens

Não tenha dúvidas: ao apostar nas ideias de Employee Experience, é possível garantir condições mais humanas, justas e prazerosas de trabalho. 

Dentre elas, vale ressaltar as seguintes:

  • Maior Engajamento e Produtividade
  • Aumento na Retenção de Talentos
  • Melhora na Qualidade de Vida do Colaborador
  • Aumento na Satisfação do Cliente

Quais São os 5 Elementos Para Um Bom Employee Experience?


Para que o conceito fique ainda mais claro, vamos ver o resumo de pontos-chave do Employee Experience? 

Confira como você pode ajudar a empresa para a qual trabalha e, claro, todos os outros profissionais:

1. Confiança e Respeito

Líderes e profissionais de RH devem se colocar como um grande exemplo.

Ou seja, ter pessoas com uma postura madura, colaborativa e sempre prontas a ajudar outros funcionários.

Só assim é viável conquistar a confiança das equipes e, consequentemente, receber o devido respeito.

2. Feedbacks

Os feedbacks precisam fazer parte da rotina da empresa. 

Mas, lembre-se de que este momento é muito mais do que falar sobre metas e resultados dos projetos.

A conversa com o gestor precisa pautar a saúde e o bem-estar do funcionário, diante das demandas. 

Além disso, é fundamental saber ouvir e estar aberto a sugestões. 

3. Desenvolvimento e Crescimento

Além de propor cursos, palestras, workshops, saiba quais são os desejos das pessoas.

Ajude a desenhar um bom plano de desenvolvimento para elas. 

Mais uma ótima ideia é separar as tarefas por habilidades e, então, delegá-las conforme o tipo de talento e motivação de cada profissional. 

4. Reconhecimento

É claro que estabilidade e um ótimo salário são fatores importantes. Mas a satisfação na carreira não depende só disso.

As pessoas também desejam e precisam ser valorizadas.

Então, constantemente, ajude a empresa a virar a chave, e passar a reconhecer mais o esforço e sucesso das pessoas, seja em tarefas, projetos como todo, metas mensais ou trimestrais, etc. 

5. Liderança

Em todas as empresas, a liderança é muito importante para orientar as equipes, fazer a ponte entre diretoria e operacional, além disso, motivar todos os funcionários. 

Como especialista na área de Recursos Humanos, ajude a desenvolver e aprimorar líderes.

Eles precisam saber passar orientações, fazer correções de forma positiva, acompanhar o desenvolvimento de seus times, entre outras ações. 

Como OKR (Objectives and Key Results) pode Complementar o Employee Experience?

OKE e employee experience

OKR ajuda gestores a traduzir as estratégias da empresa em benefícios mensuráveis e, também, alinharem o trabalho entre as equipes. 

Tudo isso, sem dúvidas, soma ao foco e bem-estar dos colaboradores. Primeiro, porque eles conseguem ter a noção de quais resultados é preciso buscar. 

Fora isso, atuar com o apoio e colaboração de outros colegas agrega muito mais valor ao trabalho.

Dependendo do resultado, também fica mais simples saber se é necessário mudar as estratégias ou mantê-las.

Conclusão


Você imaginava, então, que o Employee Experience fosse tudo isso? 

Agora que você já conhece a teoria, não perca mais tempo! 

Com uma visão muito mais preocupada e atenta ao bem-estar dos funcionários, fica mais fácil colher bons frutos.

Aliás, como diria uma célebre frase: “Se você não entende de pessoas, você não entende de negócios.”

Só não se esqueça de que, além da atenção e apoio no dia a dia, é essencial focar nos OKRs.

Afinal, eles são a bússola que guia equipes para o sucesso.

No mais, aproveite outras informações e excelentes dicas aqui no blog Thomaz Ribas!  

Read More
metodologia agil
Agile

O que é metodologia ágil e como aplicar na empresa

A metodologia ágil é uma filosofia de gestão que ajuda a empresa a entregar valor aos clientes, em um ambiente dinâmico, com incerteza, volatilidade, mudanças e adaptação constante. É um verdadeiro presente que a indústria de tecnologia trouxe para todas as empresas, inspirado na filosofia Lean.

O termo “ágil” está cada vez mais presente no dia a dia das organizações. Mas o que é agilidade? Vejamos a definição de Jim Highsmith:

“Agilidade é a habilidade de criar e responder às mudanças para lucrar em um turbulento ambiente de negócios.”

Phillipe Kruchten, referência em processos de desenvolvimento de software, define “agilidade” da seguinte forma: 

“Agilidade é a habilidade que uma organização tem de reagir e se adaptar a mudanças no seu ambiente de forma mais rápida do que a taxa dessas mudanças.”

Agilidade, em outras palavras, é a habilidade de entregar valor aos clientes, em um ambiente dinâmico, com incerteza, volatilidade, mudanças e adaptação constante. 

Atuar de forma ágil não significa fazer de forma rápida. Tem mais a ver com uma abordagem por meio da qual se compreende como as pessoas trabalham, como se relacionam e se comunicam entre si e como geram valor aos clientes. 

É isso que dificulta a adoção do modelo ágil em muitas organizações, pois não existe uma prescrição detalhada de como fazer. Não existe um “passo a passo” pronto para ser utilizados em todas as situações. 

Existem, porém, algumas práticas que podem ser adotadas para começar a gerenciar os  projetos, produtos e serviços de forma mais eficaz.

O que é e como surgiu a metodologia ágil?

Na realidade não existe uma “metodologia ágil”, mas sim um conjunto de frameworks e métodos. 

No ano de 2001, um grupo formado por 17 grandes especialistas em desenvolvimento de software se reuniu em Utah, nos Estados Unidos, em uma estação de ski, para discutir uma nova forma de gerar melhores resultados em seus projetos. 

Eles buscavam uma alternativa ao modelo sequencial de desenvolvimento de software (também chamado de cascata ou waterfall) vigente até então, o qual somente dava resultados em ambientes extremamente estáveis e sem incerteza. 

Desse encontro, nasceu o manifesto ágil. Os representantes daquele grupo já haviam concebido anteriormente diferentes métodos para gerenciar o desenvolvimento de produtos de forma mais eficaz e produtiva, os quais seguiam valores e princípios semelhantes.

Quando falamos de metodologia ágil, as mais populares são Scrum, Extreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM), Lean Development, e Feature-Driven Development (FDD). 

Entre eles, o Scrum é o framework mais amplamente utilizado, embora o método Kanban que surgiu a partir de uma outra vertente e fundamentos vêm crescendo rapidamente (falaremos mais deles adiante).

O que é o Manifesto Ágil?

O manifesto ágil contempla quatro valores essenciais:

1 - INDIVÍDUOS E INTERAÇÕES MAIS QUE PROCESSOS E FERRAMENTAS

Esse valor tem especial importância, uma vez que destaca como a interação entre as pessoas é mais significativa do que qualquer processo ou técnica. 

Ao invés de uma abordagem de linha de produção (onde a comunicação é escassa), as equipes atuam em um ambiente criativo para solucionar problemas por meio de uma cadência sustentável de trabalho e comunicação frequente.

Por meio de um ambiente aberto com liberdade para exposição de ideias, o time toma as decisões e rapidamente dá o próximo passo.

Os líderes passam a ter um papel de facilitador, removendo impedimentos organizacionais para o sucesso das equipes em vez de controlar e distribuir tarefas de forma centralizada.

2 - SOFTWARE EM FUNCIONAMENTO MAIS QUE DOCUMENTAÇÃO ABRANGENTE

Com a ampla adoção do modelo ágil em diferentes áreas de negócio, a palavra “software” utilizada neste valor tem sido substituída por “produto” ou “solução”, de acordo com o contexto. 

Esse valor nos inspira a desenvolver equipes que sempre criam versões enxutas de seus produtos no mercado em intervalos curtos de tempos em vez de fazer um longo planejamento e construir o produto tardiamente. 

Isso possibilita aprender rápido e agregar o maior valor possível aos clientes. Documentar é necessário, mas apenas o suficiente para gerar clareza e entendimento por parte daqueles que construirão o produto.

Conforme disse Steve Blank, empreendedor e especialista em startups, o cliente sabe o que quer somente quando você mostra o produto funcionando. 

Portanto, devemos trabalhar para que nossas ideias cheguem às mãos dos clientes o mais rápido possível e de forma frequente para podermos avaliar sua viabilidade e aderência ao mercado.

3 - COLABORAÇÃO COM O CLIENTE MAIS QUE NEGOCIAÇÃO DE CONTRATOS

Esse valor não significa que não devemos assinar contratos. Obviamente que, em uma relação comercial cliente-fornecedor, em geral, é preciso conceber alguns contratos formais. 

Porém, esse valor diz respeito à importância da colaboração com o cliente e entre os participantes do projeto. O escopo e as especificações do que será construído devem evoluir ao longo do tempo. 

Contratos que impõe uma série de regras limitam o processo evolutivo de descoberta da melhor solução para o produto. Mesmo entre áreas da mesma empresa, comumente encontramos contratos internos ou prazos pré-definidos e inegociáveis que dificultam muito o andamento dos projetos.

Portanto, contratos são necessários, contanto que sejam flexíveis o suficiente para abraçar mudanças da maneira mais natural possível. Colaboração entre pessoas gera resultados infinitamente mais rápidos do que documentação escrita extensiva.

4 - RESPONDER A MUDANÇAS MAIS QUE SEGUIR UM PLANO

Em um mercado com constantes mudanças, as equipes geram mais resultados atuando em um ambiente de aprendizado constante que permita alterações durante o projeto, mesmo que tardiamente. 

É importante ter uma visão do produto, uma direção. Porém, deve-se apenas planejar com maior nível de detalhes o trabalho a ser executado em curto prazo (dias ou semanas), permitindo que mudanças ocorram e sejam absorvidas ao longo do projeto.

Times ágeis já pressupõem que o produto inicial não será ideal e, por isso, fazem com que essa primeira versão chegue no mercado o mais rápido possível, para que, após o feedback coletado, possam melhorá-lo.

Quais as metodologias ágeis mais utilizadas?

O framework Scrum

Antes de falarmos o que é o Scrum, vamos definir o que não é. Scrum não é uma metodologia ou um conjunto de práticas de engenharia de software. Não é uma técnica para criar produtos.

É um framework leve e simples criado para gerenciar o desenvolvimento de produtos. Com base no framework Scrum, você pode adicionar as práticas, técnicas ou ferramentas que julgar mais adequadas de acordo com o seu ambiente (desenvolvimento de software, marketing, recursos humanos, educação etc.).

O ponto de partida do Scrum é o “backlog do produto” (product backlog). Trata-se de uma lista priorizada com tudo aquilo que é necessário construir para evoluir, podendo representar semanas ou meses de trabalho. 

Porém, nem todo o trabalho deve ser detalhado antecipadamente. Os itens de maior prioridade ficam sempre no topo da lista e, portanto, devem estar mais detalhados do que os itens de menor prioridade, abaixo na lista. 

O backlog é uma lista viva e dinâmica, podendo ser atualizada conforme necessário. O scrum prescreve cinco eventos que acontecem diversas vezes durante a construção do produto: 

  • reunião de planejamento (sprint planning)
  • reunião diária (daily scrum)
  • reunião de revisão da sprint (sprint review)
  • reunião de retrospectiva da sprint (sprint retrospective) 
  • a sprint em si, a qual engloba os demais eventos citados. 

Cada evento tem seus objetivos específicos, a fim de tornar o desenvolvimento do produto produtivo e eficaz.

Uma sprint é um ciclo de trabalho que pode durar de uma a quatro semanas. Ao término de cada sprint, o time gera um novo incremento do produto, isto é, a soma de todos os itens do backlog construídos durante a Sprint, adicionados aos incrementos construídos nas sprints anteriores.

O método Kanban

O Kanban é uma ferramenta extremamente poderosa não somente para a organização do fluxo de trabalho, mas também para aumentar a visibilidade, a previsibilidade e a vazão de entrega da sua empresa.

Para que a equipe do projeto entregue o produto com qualidade, aderência ao que o cliente precisa e baixo nível de desperdício de tempo e dinheiro, é preciso uma abordagem para criar e manter um fluxo de trabalho eficaz e para visualizar possíveis gargalos que interferem no fluxo. 

Essa abordagem chama-se Kanban. Kanban não é considerada uma metodologia ágil. É um método para definir, gerenciar e melhorar serviços que entregam trabalho do conhecimento

O método Kanban pode ser utilizado independentemente se a equipe adotou outro framework, como o Scrum. Isso mesmo! Você pode adotar as práticas do método Kanban junto com o framework Scrum. 

Kanban foi concebido por David Anderson em meados de 2007. David se inspirou fortemente na filosofia Lean de gestão de origem na Toyota, popularizando o método em seu livro "Kanban: Successful Evolutionary Change for Your Technology Business". Recomendo fortemente a leitura deste livro caso você queira aprofundar seus conhecimentos no método Kanban.

Ao adotar o método Kanban, o fluxo de trabalho é mapeado em uma sequência de passos que representam as etapas pelas quais os itens de trabalham passam.  Cada projeto, equipe ou serviço terá um conjunto de etapas específico, de acordo com o seu processo.

Essas etapas são representadas visualmente por um quadro Kanban, como no exemplo da figura abaixo que sistema de fluxo no qual os itens de trabalho fluem da esquerda para a direita, passando por diversas etapas. Cada projeto, equipe ou serviço deve ter seu fluxo mapeado de acordo com a sua realidade.

Metodologia Ágil Kanban

As práticas do Kanban

O método Kanban define algumas práticas de gestão que quando seguidas, aumentam a eficiência do fluxo de trabalho. Todas essas práticas giram em torno da clara visualização do fluxo e do trabalho sendo realizado.

Vejamos a seguir as principais práticas do Kanban:

VISUALIZAR O TRABALHO

A visualização é fundamental no trabalho do conhecimento, pois gera clareza para todos os envolvidos sobre o andamento do trabalho em progresso. A forma mais adotada para tornar o trabalho visual é o quadro Kanban.

LIMITAR O TRABALHO EM PROGRESSO

Limitar o trabalho em progresso é outra prática do método Kanban. Seguindo essa prática, novos itens de trabalho não são iniciados até que algum trabalho tenha sido finalizado. 

Isso evita um dos maiores ladrões da eficiência: o acúmulo de itens de trabalho em andamento e não finalizados, gerando filas de espera. Quanto mais itens são iniciados e não finalizados, maior o trabalho em progresso (WIP) e  consequentemente maiores são as filas entre as etapas do fluxo.

Como resultado temos o aumento no tempo de entrega de cada item, o que significa perda de agilidade. Como o quadro Kanban pode nos ajudar a limitar o trabalho em progresso? Definindo políticas explícitas de limites para o fluxo ou para cada etapa do fluxo.

GERENCIAR O FLUXO

Um fluxo de trabalho deve ser gerenciado a todo o momento. A cada dia, itens de trabalho podem ser bloqueados devido a algum problema. Além disso, gargalos podem surgir em uma ou mais etapas do fluxo.

Por isso uma das práticas do Kanban é o constante gerenciamento do fluxo. Atos de liderança devem ser permitidos para que membros dos times (não somente gestores) possam contribuir na gestão do fluxo, endereçando e resolvendo bloqueios e dependências que impedem a entrega de valor.

As diferenças entre metodologia ágil e as tradicionais

Uma das grandes inspirações para as metodologias ágeis é a filosofia Lean de gestão. Os valores e princípios Lean, quando adotados em uma empresa, se tornam o grande diferencial em relação às abordagens tradicionais de gestão.

Mas o que é Lean?

Na década de 1980, um grupo de profissionais do Instituto de Tecnologia de Massachusetts (MIT), liderado pelo Dr. James Womack, realizou um estudo da indústria automotiva internacional. 

Métodologia ágil - Toyota

Ao analisarem a fundo como funcionava o modelo de produção da fábrica da Toyota, o grupo se deparou com características bem diferentes da tradicional produção em massa até então presente na maioria das grandes indústrias do mundo. 

As principais características observadas na Toyota foram:

  • em cada passo da produção, precisavam de menos estoque armazenado;
  • executavam seus processos principais (da concepção do produto até a entrega ao cliente) em menos tempo e com menos esforço;
  • utilizavam menos fornecedores;
  • havia menos colaboradores com acidentes trabalhistas;
  • havia menos devolução de produtos por problemas de qualidade.

Uma empresa como a Toyota é uma organização lean. Organizações lean utilizam menos esforço das pessoas para operar e menos material, energia e espaço para criar seus produtos e serviços, além de serem orientadas à demanda do cliente e desenvolverem produtos com maior qualidade, da forma mais eficaz e econômica possível. 

As práticas do lean se aplicam a toda a organização, influenciando não somente os processos da empresa, mas também as pessoas e a cultura organizacional.

Quais conceitos Lean influenciaram os métodos ágeis?

A seguir os principais conceitos do lean que influenciam diretamente a abordagem ágil de gestão:

Foco no cliente

Uma organização lean existe para atender o cliente da forma mais eficiente possível. Quaisquer atividades ou processos criados para a construção do produto ou serviço devem adicionar valor diretamente ao cliente.

Fluxo contínuo

Em uma organização lean não há interrupções nos processos nem acúmulo de produtos parcialmente prontos. As equipes fazem de tudo para eliminar multitarefas, interrupções para realizar inventário e grandes lotes de trabalho. 

Assim, o produto não é interrompido em sua caminhada por meio dos sucessivos passos da concepção inicial até chegar ao consumidor.

Sistema puxado

Em um sistema puxado de trabalho, quando uma tarefa é concluída, uma próxima tarefa que já esteja preparada pode ser “puxada” para ser trabalhada. As tarefas em andamento são endereçadas por ordem de prioridade e, conforme vão sendo finalizadas, dão lugar às próximas tarefas selecionadas (puxadas).

O sistema puxado (pull) é diferente do sistema empurrado (push). Primeiro porque um sistema empurrado permite que os membros do time trabalhem em diversas tarefas ao mesmo tempo, na maioria das vezes dando a falsa impressão de produtividade com paralelismo. 

Segundo porque em um sistema empurrado, a qualquer momento mais atividades são designadas ao time e inseridas em uma lista massiva de tarefas já existente.

No sistema puxado, os membros do time iniciam novas tarefas somente quando tarefas mais antigas forem finalizadas. Desse modo, quando há alguma mudança no projeto que impacte as necessidades e o escopo, o time consegue se adaptar mais rapidamente. 

Além disso, um time que trabalha de forma puxada se sente menos sobrecarregado, uma vez que sempre trabalha em atividades importantes naquele momento, em vez de se comprometer com listas intermináveis de tarefas.

Em um sistema puxado, gestores e membros de times mantém o foco nas tarefas certas, no momento certo, reduzindo desperdício de tempo e esforço.

Melhoria contínua

Melhoria contínua (kaizen, em japonês) é uma estratégia usada para identificar melhorias incrementais em um processo, reduzindo desperdícios. Em uma organização que adota melhoria contínua, todos trabalham juntos para identificar oportunidades de melhoria de forma colaborativa. 

Kaizen

Essa é a mentalidade padrão em todos os níveis, do CEO ao chão de fábrica. Por meio da melhoria contínua, as pessoas passam a pensar diferente sobre seu trabalho, muitas vezes com um olhar criativo, pois são incentivados a criar soluções e ideias para melhorar cada vez mais seus processos.

Pare a linha

Em um processo lean, quando alguém da equipe identifica um problema em seu processo ou no produto sendo construído, a linha de produção é interrompida imediatamente para análise. 

De forma colaborativa, a equipe avalia as possíveis causas do problema, chegando na causa raiz e eliminando-o. Uma vez que o problema foi tratado, a linha volta a operar. Essa prática se chama “pare a linha”, ou em inglês, stop the line.

Por que parar a linha imediatamente? Por que não tratar o problema mais tarde ou no dia seguinte? A resposta a essa pergunta é de ordem econômica. Quanto mais tempo um problema demora para ser resolvido maior o custo da solução. 

Isso vale também para uma empresa de tecnologia ou inovação? Sim!

Imagine uma equipe de desenvolvimento de software que identifica um bug durante a construção de um aplicativo. Corrigir o erro no mesmo instante provavelmente exigirá menos tempo de análise e menos alterações no código-fonte do aplicativo uma vez que as informações relacionadas ao problema (bug) são recentes. 

Postergar a correção para o mês seguinte, por exemplo, economiza tempo em curto prazo, mas certamente o custo de correção no futuro será muito maior. Após um mês, o aplicativo estará mais complexo e a equipe já não terá todas as informações frescas em sua mente para resolver o problema com velocidade.

Gestão visual

Organizações lean expõe informações relevantes de forma visual pelas salas e corredores. Isso chama-se gestão visual e seu propósito é melhorar a efetividade da comunicação e principalmente da reação a informações importantes.

Itens expostos de forma visual transmitem a comunicação de forma mais rápida e interativa do que comunicação escrita. 

E isso não significa que apenas boas notícias são expostas de forma visual. Quando defeitos e problemas são visualmente exibidos, a tendência é que sejam endereçados mais rapidamente.

Respeito pelas pessoas

James Womack, fundador do Lean Enterprise Institute, ao estudar o modelo de produção da Toyota, perguntou aos gerentes de que forma demonstravam respeito pelos colaboradores, dado que esse era um dos principais valores da organização.

A resposta foi a seguinte:

Primeiro o gestor pergunta ao colaborador qual é o problema que identificou. 

Em seguida, o gestor desafia a resposta do colaborador por meio de um diálogo sobre qual é o real problema (em geral, o problema é mais profundo do que o apresentado na superfície da análise). Então, o gestor pergunta qual a causa do problema, iniciando um diálogo sobre as possíveis causas raízes. 

Durante essa análise de causa raiz, os colaboradores precisam coletar evidências do seu local de trabalho (chamado de “gemba”, local onde o valor está sendo gerado). O gestor pergunta o que deve ser feito com relação ao problema e o por que o colaborador escolheu determinada solução em vez de outra. 

Isso faz com que uma série de possíveis soluções sejam consideradas. Em seguida, gestor e colaborador definem como saberão que o problema foi resolvido, por meio de um diálogo transparente. 

Por fim, uma vez que obtêm um acordo quanto às medidas de sucesso, o colaborador se prepara para iniciar a implementação.

O que a resposta acima tem a ver com o respeito pelas pessoas? Não foi uma resposta com frases motivacionais do tipo “bom trabalho!” ou “confio em você!”. 

Em vez disso, o que vemos é que, em uma organização lean, os gestores desafiam seus colaboradores, incentivando-os a fazer mais análise, coletar mais dados e gerar mais diálogo antes de simplesmente implementar sua solução favorita apenas porque acha que vai dar certo. 

A resposta fornecida acima pelo gestor também poderia ser traduzida como: “Eu, gestor, não consigo resolver esse problema sozinho, pois não estou tão perto do problema para conhecer bem os fatos”. 

Isso é respeito pelo conhecimento do colaborador e por sua dedicação em encontrar as melhores respostas. Esse respeito mútuo entre as pessoas de todos os níveis torna mais fácil a solução de problemas, faz com que o trabalho seja menos dolorido e mais prazeroso e leva a organização a níveis cada vez mais altos de produtividade.

Um resumo dos métodos

A Figura abaixo mostra que ágil e lean englobam os diversos frameworks e métodos, os quais compartilham dos valores e princípios do manifesto. 

Metodologia ágil - métodos

Todos eles compartilham diversos conceitos do lean, como focar a geração de valor para os clientes, trabalhar em pequenos lotes de trabalho, eliminar desperdícios, transparência, respeito pelas pessoas, melhoria contínua e adaptação às mudanças.

Outro método bastante utilizado para o gerenciamento de trabalho do conhecimento é o método Kanban, que, com forte influência do lean, mais especificamente do sistema de manufatura, é um método para gerenciar o desenvolvimento de produtos com ênfase na visualização do fluxo de trabalho e na entrega contínua de valor sem gerar sobrecarga de trabalho no time.

Livros sobre metodologia ágil

A seguir eu compartilho com você livros que eu gosto sobre métodos ágeis:

Benefícios e resistências de uma transição para métodos ágeis

A transição de uma abordagem tradicional e preditiva de gestão para uma abordagem ágil pode gerar resultados extremamente compensadores.

Organizações que navegam em ambientes complexos e que investem em práticas de design thinking, concepção ágil de produtos, Scrum e Kanban com a devida capacitação de seus líderes e equipes têm gerado benefícios marcantes para seus clientes e para seu negócio. 

Um deles é o aumento de produtividade e redução de desperdícios e de custos (maior eficiência). Outro benefício é maior eficácia e velocidade ao construir e disponibilizar seu produto no mercado, aumentando o grau de satisfação de seus clientes.

Toda transição implica em algum grau de mudança. A forma como gerenciamos mudanças em uma organização é fundamental para se obter resultados de sucesso. Mudanças bruscas (revolucionárias) geram um impacto muito grande no status quo dos processos e das pessoas envolvidas na mudança. 

Consequentemente o grau de resistência tende a ser igualmente grande. David Anderson, em seu livro "Kanban Maturity Model", cita os principais motivos que fazem com que as pessoas em uma empresa resistam à adoção de novas práticas. 

São elas:

  • Alteração ou ataque à identidade
  • Medo de ser visto como incompetente
  • Falha ao compreender a relação entre uma prática e o resultado
  • Falha ao avaliar escala
  • Falha em reconhecer um mercado em maturação e alinhar corretamente a maturidade da organização ao mercado

Por que então não adotar uma abordagem mais evolucionária, não linear de mudanças que gere mais resultados com menos resistência? Acredito que, assim como a própria abordagem ágil, mudanças organizacionais devem ser baseadas em experimentos, ciclos curtos e direcionadas a feedback frequentes.

Treinamento de OKR introdutório e gratuito
Como obter alinhamento, foco e agilidade com OKR

Como aplicar a metodologia ágil em sua empresa

A seguir, apresentamos algumas abordagens que podem ser úteis durante a transição do modelo de gestão em uma organização.

COMEÇAR PEQUENO

Adote as novas práticas e ferramentas somente em algumas equipes ou serviços inicialmente, para obter feedback, aprendizado e lições aprendidas a serem utilizadas em outras partes da empresa. 

Em geral esta abordagem é menos custosa pois não requer alto volume de treinamento e coaching. Além disso, o risco é menor pois qualquer erro que ocorra devido à adoção das novas práticas não prejudicará toda a empresa. 

Tom Gilb, um dos primeiros a adotar práticas ágeis, dizia: “Se você não sabe o que está fazendo, então não faça em larga escala”.

ESCOLHER O PROJETO CERTO

Selecionar o projeto e as pessoas certas para os primeiros experimentos das novas práticas é fundamental. Os primeiros projetos servirão para adquirir conhecimento para os próximos. 

Escolha algum projeto que tenha uma razoável probabilidade de sucesso, tenha visibilidade na organização e ao mesmo tempo não seja o projeto de maior risco da empresa.

Com isto as chances de obter sucesso logo no início aumenta, o que servirá como combustível para a continuidade da transição.

APOIO DOS EXECUTIVOS

Mesmo começando pequeno, comunique e alinhe a iniciativa nos diversos níveis da organização. Obtenha apoio do nível executivo. A transição será mais eficaz se feita de forma transparente envolvendo não somente as equipes dos projetos, mas também os tomadores de decisões estratégicas na organização.

EXPERIMENTAR E TESTAR HIPÓTESES

Alex Osterwalder em Value Proposition Design sugeriu a adoção de testes de hipóteses para validar hipóteses de um negócio. 

Inspirado no trabalho de Osterwalder, podemos adotar a mesma ideia para criar hipóteses a serem testadas através de mudanças evolucionárias no modelo de gestão da organização.

Imagine, por exemplo, que existe uma hipótese de que estamos perdendo tempo nos projetos devido a comunicação não estar fluida e clara e estamos sem visibilidade. 

Para endereçar esta hipótese específica podemos listar alguns experimentos possíveis a serem feitos como:

  • começar a fazer uma reunião diária;
  • adotar gestão a vista das tarefas do projeto;
  • sugerir às pessoas que leiam livros sobre Kanban;
  • compartilhar artigos sobre comunicação com as equipes;
  • mudar a estrutura das equipes para quebrar os silos e criar times multifuncionais.

Uma vez que temos alguns possíveis experimentos para endereçar a hipótese, podemos escolher o(s) experimento(s) com melhor custo-benefício (aquele que acreditamos que trará mais resultado com menor custo). 

No exemplo acima, poderíamos selecionar, por exemplo, os seguintes experimentos:

  • começar a fazer uma reunião diária;
  • adotar gestão a vista das tarefas do projeto.

Assim, após alguns dias executando esses dois experimentos coleta-se feedback e gera-se aprendizado. Uma vez testados os experimentos, registre e compartilhe os resultados e insights gerados. 

O experimento não trouxe o resultado desejado? Abandone-o. 

O experimento gerou algum resultado, mas poderia ter sido melhor? Evolua. 

O experimento foi comprovado e teve sucesso? Torne essa mudança parte do seu modelo de gestão.

TENHA UM GRUPO COESO PARA AJUDAR NA TRANSIÇÃO

John Kotter coloca em seu livro O Coração da Mudança, que “os agentes de mudança mais bem-sucedidos constituem uma equipe de orientação, cujos membros desfrutam de credibilidade, habilidades, ligações, reputação e autoridade formal, fatores imprescindíveis ao exercício da liderança da mudança.”

Todo processo de mudança precisa de apoiadores dentro na organização. Encontre as pessoas que estão dispostas e motivadas a aprender e a se tornarem agentes de mudança. O engajamento dessas pessoas irá contaminar positivamente as pessoas ao redor e ajudará a reduzir as resistências. 

Como saber se a empresa está se tornando ágil?

Concluindo, como podemos saber que a sua organização está se tornando realmente ágil?

Avalie se você está entregando realmente o que o negócio (cliente, usuário) mais precisa. Coloque o cliente no centro de tudo. Ele é a pessoa que precisa utilizar o produto.

Sem ele, não há negócios e não faz sentido que exista uma equipe. Com que frequência você está entregando algo de valor e com qualidade para seu cliente? 

Com que velocidade você e suas equipes se adaptam às mudanças que ocorrem fora e dentro da empresa? Esses são ótimos indicadores. Avalie se o seu processo está melhorando continuamente. 

Não existe um estado final e certo de alto desempenho ou máxima agilidade. Sempre proponha e aplique pequenas melhorias por vez no seu processo e envolva as equipes o máximo que puder. 

Segundo John Holland, uma organização é uma rede dinâmica composta de diversos elementos e agentes que atuam em paralelo, constantemente agindo e reagindo ao que outros agentes fazem. O comportamento geral desse sistema é o resultado de uma enorme quantidade de decisões tomadas ao longo do tempo pelos vários agentes.

Temos, portanto, que enxergar as organizações como sistemas adaptativos complexos. Evite adotar as “melhores práticas” de mercado de olhos fechados.

Ao invés disso, procure sempre inspecionar e adaptar os seus processos. Transparência, inspeção e adaptação. Essa é a essência da agilidade.

Seu cliente talvez não se importa se você utiliza Scrum, Kanban, design thinking, canvas ou outros métodos. O que eles querem são produtos e serviços eficazes que resolvam seus problemas. 

Se ajudarmos a direcionar as energias das equipes de projetos para a resolução dos problemas e necessidades dos clientes, incentivando a colaboração entre as pessoas e a melhoria contínua dos processos, o resultado será consequência.

Read More
Mundo VUCA
Agile

Como o mundo VUCA impacta na gestão

Mundo VUCA é um termo que até pouco tempo atrás era frequente em palestras sobre inovação. Leia neste artigo o que é o mundo VUCA e como repensar a gestão para navegar com sucesso nesta nova era.

Anos atrás, a velocidade de mudança no mercado era infinitamente menor que a atual. Segundo uma pesquisa do Boston Consulting Group, demoramos 49 anos para atingir um bilhão de usuários de televisores em todo o mundo. Sabe quantos anos levou para atingir um bilhão de usuários de smartphone? Apenas oito. 

Até um passado recente, eram as empresas que definiam como o mercado se comportaria e qual deveria ser o grau de inovação. O poder de escolha estava ao lado das organizações, mas o cenário mudou e a era industrial ficou para trás. 

Estamos vivendo um momento muito especial da história - novas economias surgem e até uma pandemia chega para transformar a forma como vivemos e trabalhamos.

É uma era de disrupção contínua, em que modelos de negócio completamente inovadores surgem a todo o momento, substituindo modelos anteriores considerados estáveis até então. 

Por exemplo, temos o clássico caso do Whatsapp, presente hoje em bilhões de dispositivos móveis, que gera um prejuízo de bilhões de dólares para o segmento de SMS das empresas de telefonia. O Uber e o Airbnb são outros exemplos bastante conhecidos de empresas frequentemente citadas em palestras de inovação.

Portanto, o poder de escolha mudou de lado e está nas mãos do consumidor, o qual possui uma quantidade de opções de consumo cada vez maior. A velocidade de mudança no mercado atual é gigantesca.

Hoje, devido ao efeito rede, o sucesso de um novo produto pode chegar aos ouvidos de bilhões de pessoas em poucos dias, como também pode destruí-lo rapidamente com o poder da internet e das redes sociais. 

O que é mundo VUCA

O mundo está mudando cada vez mais rápido. Existe um adjetivo que vem sendo cada vez mais usado para descrever esse novo mundo: VUCA.

No início da década de 1990, a Universidade do Exército Norte-Americano (United States Army War College) introduziu um conceito que descreve bem o mundo atual em que vivemos. Trata-se do acrônimo VUCA (volátil, incerto, complexo e ambíguo, do inglês volatile, uncertain, complex, ambiguous). 

Esse conceito nasceu após o término da guerra fria, representando as características do mundo multilateral que emergia naquela época, e ficou ainda mais presente após a crise financeira de 2008 e 2009.

Hoje manifesta-se de forma intensa no mundo dos negócios e dos projetos, pois descreve um ambiente caracterizado por ter exatamente essas quatro características, descritas a seguir.

Volátil

A velocidade das mudanças no ambiente atual é brutalmente alta. Desafios e novidades emergem a todo o momento.

Quando menos esperamos, surge um novo modelo de negócio no mercado, uma nova oportunidade ou um novo concorrente que nos obriga a sermos mais ágeis e flexíveis o suficiente para não perdermos competitividade. 

Incerto

O ritmo acelerado do mundo atual, proveniente da volatilidade, gera também uma incerteza muito grande sobre o futuro. Torna-se cada vez mais difícil avaliar as ameaças e os desafios nas organizações.

Ferramentas tradicionais de gestão estratégica (concebidas no século passado) já não funcionam mais. Em um mundo incerto é preciso ter flexibilidade para absorver mudanças. Planos detalhados são necessários em alguns casos, mas em muitos outros não.

Como dizia Dwight D. Eisenhower, o 34º presidente americano: “Nenhum plano sobrevive ao primeiro contato com o inimigo (...). É preciso lutar contra o inimigo, e não contra o plano”.

Planos e tomada de decisões cada vez mais curtos e frequentes têm gerado mais resultado, pois ajudam a conviver com a incerteza.

Dwight Eisenhower

Dwight D. Eisenhower

"Nenhum plano sobrevive ao primeiro contato com o inimigo (...). É preciso lutar contra o inimigo, e não contra o plano."

Complexo

Em um ambiente complexo é preciso pensar de forma não linear, uma vez que não é trivial identificarmos uma relação direta entre causa e efeito.

Eventos não relacionados entre si afetam os resultados a todo o momento. Portanto, não podemos querer adotar soluções pré-definidas para os problemas, apenas baseados em experiência adquirida e "feeling".

É preciso divergir com relação às possíveis soluções, testar e aprender rapidamente. Uma das maiores habilidades dos líderes passa a ser a gestão do risco para permitir erros e aprender rapidamente com eles.

Ambíguo

Em um mundo altamente diversificado e ambíguo, é preciso avaliar as oportunidades e desafios sob diferentes aspectos. Está cada vez mais difícil alcançar precisão nos modelos de negócio e planejamento de projetos, pois há sempre múltiplas estratégias possíveis de implementação.

Ambiguidade gera ineficiência, perda de oportunidades, conflitos, insegurança e incapacidade de compreender algumas ameaças a tempo para reagir.

Para enfrentar a ambiguidade, é preciso atuar com clareza de propósito e objetivo, além de colaboração e divergência de ideias para chegar às melhores soluções.

É preciso adquirir habilidades para aprender o novo. O futurista Alvin Toffler disse: 

“O analfabeto do século 21 não será aquele que não lê ou escreve, mas aquele que não consegue aprender, desaprender e reaprender”. 

Repensando gestão e liderança no mundo VUCA

Nesse mundo VUCA, o futuro não é mais previsível como anos atrás e, para encará-lo, é necessário muitas vezes mudar as abordagens de gestão que adotamos nas empresas. Para enfrentar a nova economia, a taxa de evolução e adaptação interna nas empresas deve acompanhar a taxa de mudanças do mercado. 

É preciso um modelo que perceba e reaja rapidamente às mudanças e não fique refém de antigos processos e “melhores práticas” enraizadas na cultura da empresa.

Um modelo que permita às empresas e às equipes ter espaço para experimentar e errar, de modo que aprendam rapidamente com seus erros para poderem ajustar, crescer e criar produtos e serviços de maneira eficaz. 

Eficiência, a palavra de ordem na velha economia da revolução industrial, deixou de ser a única coisa a ser conquistada. Agora, mais que eficiência (fazer bem feito, fazer mais com menos), é preciso buscar eficácia, ou seja, fazer a coisa certa, no momento certo, para as pessoas certas.

É preciso foco em buscar soluções criativas para problemas complexos. Foco no entendimento da necessidade dos clientes, na experiência gerada para ele e na interação entre as pessoas.

Modelos como o tradicional planejamento estratégico, Total Quality Management (TQM), Total Productivity Management (TPM), Business Process Reengineering que focam em sua essência na melhoria linear do que já existe e na obtenção de previsibilidade do futuro, precisarão ser re-pensados.


A natureza humana em busca de certezas

Nós, humanos, almejamos a certeza e é por isso que mudanças constantes no ambiente nos deixam muitas vezes desconcertados.

Em meio a tanta incerteza e complexidade, muitos líderes tem dificuldade em exercitar a leitura do seu ambiente e a percepção de situações complexas. Eles ainda acreditam que uma estratégia preditiva e prescritiva é a única abordagem possível. A capacidade de resposta não faz parte de seu vocabulário, pois estão apegados à ferramentas baseadas em previsão, comando e controle.

Então qual é uma forma diferente de pensar estratégia?

Muito prazer, OKR

OKR (Objectives and Key Results) é uma ferramenta concebida pela Intel Corp na década de 1970 por seu lendário CEO Andy Grove.

Após seu sucesso na Intel, esta ferramenta ágil de gestão foi adotada por empresas como Oracle, Google, Spotify e Microsoft. Atualmente a adoção de OKR vem crescendo fortemente, não somente em empresas de inovação e tecnologia, mas também em diferentes setores incluindo governo.

Quer saber mais sobre OKR? Confira o meu mini-curso gratuito de OKR abaixo.

Concluindo, estamos em uma era na qual é preciso repensar a forma como fazemos gestão. O mundo VUCA está nos obrigando a fazer isso.

Muitas vezes o futuro estará meio embaçado, assim como na imagem deste post. Somente iremos enxergar o possível para caminhar alguns pouco quilômetros e precisaremos mudar o modelo mental de excesso de análise para agir e aprender e agir de forma eficaz durante a caminhada.

Read More