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.

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

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.

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.

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

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. 

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. 

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! 

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.

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! 

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!

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:

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

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. 

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. 

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! 

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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. 

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. 

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. 

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. 

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. 

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?

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:

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):

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.

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.

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.

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. 

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

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.

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!

Quais São as Principais Vantagens do Employee Experience?

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?

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.

“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”. 

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.