Logo Agile SchoolLogo Agile School
Logo Agile SchoolLogo Agile School
0
R$0.00 0 item

Nenhum produto no carrinho.

Como o líder ágil pode facilitar sua equipe até a alta maturidade?

Neste texto,  vou compartilhar algumas experiências e apresentar uma Matriz de Maturidade que descreve a evolução de uma equipe Scrum. E como o líder ágil pode facilitar sua equipe até a alta maturidade

Esta matriz é baseado em experiências pessoais e percepções da Spiral Dynamics.

Você pode usar esta matriz como referência para liderar equipes Scrum em direção a mais maturidade.

Como acompanhamento, apresentarei 4 exemplos, cada um deles descrevendo a transição entre os níveis de maturidade descritos.

Esse conteúdo faz parte do treinamento PAL-e, oficial da Scrum.org, que ajuda líderes a serem líderes ágeis, ajudando os times a entregar mais valor.

Se Scrum for bem feito…

Se o Scrum for bem feito, uma equipe Scrum se auto-organiza, cria valor regularmente e é altamente eficiente:

Se o Scrum for bem feito, muitas responsabilidades tradicionais serão transferidas para o time Scrum. Para aqueles que são novos no Scrum, muitas vezes é difícil acreditar que essa transferência ocorrerá. E para ser sincero, não os culpo!

A maioria das organizações não foi construída sobre princípios de auto-organização. Eles prosperaram em uma época em que a gerência possuía os planos e as equipes de desenvolvimento possuíam apenas a execução.

Mas os tempos estão mudando … O mundo se tornou tão complexo que a responsabilidade precisa ser assumida por aqueles que fazem o trabalho. Só então eles podem ser rápidos, flexíveis e criativos.

E eles não podem fazer isso sem a ajuda de um líder que lhes mostra o caminho.

Se o Scrum for bem feito, você precisará de uma boa Liderança Ágil! Essa é a chave de uma boa organização.

Liderança e Scrum

Muitas pessoas entendem o Scrum hoje em dia, mas falham em extrair o melhor dele.

Isso geralmente é resultado de:

A ideia de uma equipe auto-organizada é relativamente nova no mundo da TI, mas provou ser mais bem-sucedida em esportes e situações militares. Nos militares, existe um ditado famoso que afirma “Não existem equipes ruins, apenas líderes ruins”.

E também há esperança para as organizações de TI!

O melhor elogio que um gerente fez uma vez a uma das minhas equipes Scrum: “Não preciso mais me preocupar com você. Eu só me preocupo com o meio ambiente ao seu redor, então você pode fazer o que tiver que fazer. ”

E se você pudesse aprender com o que essas equipes fizeram para conseguir isso? Qual é o padrão de crescimento que leva a essa maturidade?

E como você, como líder ágil, pode usá-lo para guiar suas equipes para o sucesso?

Uma matriz de maturidade de 5 níveis

A chave para liderar equipes Scrum de sucesso é focar no crescimento da maturidade das funções Scrum, proporcionando-lhes um ambiente onde possam florescer.

Muitos líderes focam nos processos e regras no Scrum, enquanto são as pessoas e as funções que fazem a diferença.

Uma equipe só pode ser tão grande quanto as pessoas que nela trabalham!

Nunca conheci um time Scrum maduro que reivindicasse seu sucesso por sua habilidade de seguir regras. Os créditos vão sempre para a grandeza das pessoas, a maturidade das funções e os valores que compartilham.

As equipes mais bem-sucedidas compartilham um padrão, com base em 4 funções importantes: Scrum Master, Dono do Produto, Membro da Equipe de Desenvolvimento e Líder.

Embora o Líder Ágil não seja uma Role oficial no Scrum, ele desempenha um papel crucial no sucesso das equipes na organização.

A Matriz de Maturidade:

O Líder é responsável por definir as condições de limite para um time Scrum aumentar sua maturidade.

Sobre a Matriz de Maturidade

A maturidade é evolutiva

Evolução

Os treinamentos sobre Scrum ensinamos o framework no seu nível 5 da Matriz de Maturidade.

A maioria das pessoas tem dificuldade em descobrir como fazer isso porque acabaram de chegar ao nível 1 ou 2 da maturidade. Nunca vi ninguém pular para o nível mais alto depois de terminar um treinamento. Você terá que percorrer o caminho através de todos os níveis. Requer muito trabalho, perseverança e boa liderança para atingir o nível 5!

Como Líder Ágil, é sua responsabilidade orientar os papéis do Scrum de um nível para outro.

Estruturas rígidas determinam mentalidade

Times Scrum de sucesso atuam como células autônomas dentro dos limites da organização. Essa mentalidade de nível 5 de maturidade, não pode ser alcançada quando as estruturas rígidas das organizações (comando, processos, regras, edifícios, organizações, KPI’s, etc.) ainda estão no nível 1.

A maneira como as pessoas pensam e agem é determinada por suas condições de trabalho. Como cada papel do Scrum age e pensa em cada nível é determinado pela estrutura rígida fornecida pelo Líder.

Como Líder Ágil, é sua responsabilidade moldar a estrutura rígida de sua organização de forma que as pessoas possam fazer uma mudança em seu sistema de pensamento.

Líderes Ágeis vão primeiro!

Muitos times Scrum ficam presos nos primeiros 3 níveis da Matriz de Maturidade. Todas as equipes que observei nos níveis 4 e 5 tinham uma coisa em comum: o Líder apoiava e orientava as pessoas até lá. Os líderes precisam criar um ambiente onde as pessoas possam trabalhar com comprometimento e foco, sem medo de cometer erros.

Se um líder não for capaz de guiar sua equipe para o próximo nível, haverá atrito, expectativas erradas e Scrum disfuncional.

Como Líder Ágil, é sua responsabilidade dar o exemplo e liderar o caminho.

O elo mais fraco

O sucesso de uma equipe inteira é determinado pelo elo mais fraco. Uma equipe Scrum só mostrará os resultados esperados em cada nível quando todas as funções estiverem pelo menos no mesmo nível de maturidade.

Como Líder Ágil, é sua responsabilidade facilitar o crescimento de cada função em uma equipe para fazer com que toda a equipe cresça.

Como usar a matriz de maturidade?

A matriz de maturidade fornece insights sobre como os papéis do Scrum amadurecem.

Aviso: a matriz deve ser usado como orientação para ajudar as pessoas a determinar seu caminho de crescimento pessoal. Não o use como incentivo, pois impedirá que as pessoas percorram o caminho!

Texto traduzido do blog do Ron Eringa, Professional Scrum Trainer pela Scrum.or. Clique aqui e leia o post original.

Aprimore suas características como líder ágil e aprenda técnicas que te ajudarão gerar mais sucesso na sua carreira e nos seus times, através do treinamento PAL-E da Scrum.org, o Professional Agile Leadership Essentials. Saiba mais sobre esse curso!

Moral do Time x Sucesso do Produto

Segundo o último relatório Chaos Report, em média, 18% dos projetos complexos são bem sucedidos.

Problemas complexos não têm a sua relação de causa e efeito definida/conhecida, e portanto, a resolução desses problemas surgem de práticas emergentes, onde é necessário provar, sentir e responder, ou seja, verificar se a solução proposta resolve problema inicial.

A solução de problemas complexos dificilmente estará na mão de uma única pessoa, assim necessitam que a solução surja da inteligência coletiva, onde, por meio da colaboração surjam soluções inovadoras que também aumentam o engajamento.

Tela de computador com jogo

Descrição gerada automaticamente

Contudo, para que a inteligência coletiva seja maximizada e atinja o seu propósito, precisamos entender que propósito é esse. Simon Sinek, em seu livro “Start With Why” coloca o porquê no centro da questão, ou seja, Por que estamos fazendo o que estamos fazendo? Para quem estamos fazendo? Quais as dores dessa pessoa? Na prática, estamos buscando entender quem são as personas do nosso produto. O que elas sentem? O que elas pensam? O que elas veem? O que elas fazem? O que elas escutam?

Uma imagem contendo relógio, flor

Descrição gerada automaticamente

Estamos buscando por uma solução customer centric, onde o cliente é colocado no centro das atenções. Atualmente, diante de tantas opções de concorrência, é necessário entendermos e estreitarmos laços cada vez mais com os nossos clientes, ou seja, entender quais são suas necessidades. Quais são os seus desejos? Como podemos nos relacionar cada vez melhor com eles? No final, estamos aqui em busca do que é valor para o cliente.

Uma imagem contendo desenho

Descrição gerada automaticamente

O cliente tem necessidades e desejos e os produtos entregam uma experiência que muitas vezes está distante daquela desejada por ele. É nesse gap entre desejo e experiência que reside o valor. É nesse gap que o produto precisa se posicionar e o time trabalhar, mas pra chegarmos nessa proposição, é necessário que as personas e seus desejos estejam claros para todos.

Uma imagem contendo desenho

Descrição gerada automaticamente

Contudo, o que se vê é a velha dicotomia entre negócio e TI, uma barreira entre eles, onde de um lado negócio diz que TI não faz uma entrega com qualidade, que existem muitos bugs, que o cliente está insatisfeito. Do outro, TI diz que negócio não sabe o que pede, não escreve os requisitos direitos, muda a prioridade toda hora…

Uma imagem contendo desenho, quarto

Descrição gerada automaticamente

Até que surgiram os Squads, para reduzir esse distanciamento. Agora Negócio e TI trabalham debaixo do mesmo teto e os problemas de comunicação de outrora foram minimizados, contudo ainda existe uma zona nebulosa entre essas partes. Existem diversas razões para isso, mas nesse artigo vou falar da principal deles, ou pelo menos daquela que é a base de qualquer relacionamento: a confiança, no caso aqui, a falta dela.

Uma imagem contendo quarto, desenho, relógio

Descrição gerada automaticamente

O Scrum Guide diz que quando os valores são incorporados e vividos pelo Time Scrum, os pilares de Transparência, Inspeção e Adaptação tornam-se vivos e constroem confiança entre todos.

Patrick Lencione, em seu livro, “Os 5 Desafios Das Equipes”, mostra que justamente o 1º desafio, a base para que um time possa alcançar a Alta Performance, é justamente a ausência de confiança, que sem ela, é impossível de um time chegar a sua melhor performance e entregar melhores resultados.

Kenneth Rubin, no livro Scrum Essencial, aponta que aspectos como: ausência de confiança, feedbacks raros, mudanças constantes de backlog, super utilização da capacidade do time, entre outros, impactam diretamente no engajamento e motivação do time, caindo continuamente ao passar do tempo. Por outro lado, quando a confiança está presente, existem um ambiente de feedbacks constantes, entregas contínuas de valor, validação constante do propósito (por que) e eficiência e eficácia andam lado a lado, a motivação e engajamento são renovados frequentemente, uma vez que existe uma sensação de dever cumprido, de trabalho bem realizado, ou seja, de atingimento de propósito.

Uma imagem contendo desenho

Descrição gerada automaticamente

Conclusão

Num mundo cada vez mais dinâmico há menos certeza quanto ao o quê temos que fazer ou como fazer para solucionar as dores dos usuários. Nesse ambiente complexo, para que um produto possa ter seu valor potencializado, práticas emergentes devem surgir, catalizando a inovação.

Para isso, é necessário que haja uma atenção dedicada à moral da equipe, assim como um ambiente de trabalho seguro, no qual temos confiança e colaboração verdadeira entre os envolvidos. Essas características são requisitos para que a transparência, inspeção e adaptação possam acontecer de modo a culminar numa maior geração de valor para os clientes.

E se quiser saber mais sobre esse assunto, assista aqui a uma super aula gratuita com o trainer Rodrigo Pinto!
Uma imagem contendo equipamentos eletrônicos

Descrição gerada automaticamente

Estrutura de Times

Por que estruturar times?

A forma como seu time está estruturado tem um impacto significativo no sucesso do negócio. Quando falamos em modelos de equipe, estamos buscando a estrutura mais otimizada e que nos leve a melhores resultados. 

Se você está numa iniciativa de pequeno porte, uma equipe multifuncional provavelmente é suficiente para dar conta do recado. Contudo, à medida que sua empresa ou produto vai ganhando corpo, naturalmente surge o desejo de criar novos times, de crescer a estrutura, de acelerar a entrega de valor.

Porém, como essas equipes devem se estruturar de modo a alcançar coordenação, comunicação e performance?

Equipe de Componentes x Equipe de Feature 

times

Equipes de Componentes têm a responsabilidade sobre determinado componente, tornando mais fácil sua padronização e manutenção. Todo o foco do time está voltado à tecnologia e não ao negócio. Portanto, equipes de componentes não possuem todas as habilidades necessárias para entregar uma feature de ponta-a-ponta, ou seja, estão mais voltadas a práticas waterfall atendendo a diversas demandas porém de uma única fase.

São compostas por especialistas e possuem referência técnica dentro do próprio time, onde é comum haver ver uma certa segregação do conhecimento, onde geralmente o mais sênior é o líder/gerente da equipe.

Por não responder a uma feature em específico, precisam lidar com diferentes prioridades que podem acabar por impactar a entrega de outros times e consequentemente no desenvolvimento, lançamento ou respostas à mudança daquela feature. Prática comum é a famosa fila de demandas (first in, first out). 

incremento

Equipes de Feature são mais utilizadas em uma abordagem ágil por estarem focadas na entrega ao cliente de ponta-a-ponta, promovendo um menor tempo de resposta ao usuário final. Dessa forma equipes de feature tendem a criar funcionalidades mais user-centered, pois vivem mais a dor do cliente.

Essa entrega mais rápida é possível, pois times de features devem possuir todas as habilidades para entregar a feature por completo, reduzindo assim a dependência externa. Contudo, os códigos de componentes estarão distribuídos pelas features, ou seja, sua manutenção dependerá de maior comunicação entre os desenvolvedores, podendo contribuir para o aparecimento de débito técnico, subotimização ou inadequação de padrões arquiteturais.

Imagine a seguinte situação:

Existem 3 times de componentes (UX, Front, e Back) responsáveis por um único produto. A feature “Catálogo de Produtos” é então dividida para cada time, que ao final da Sprint deverá entregar um incremento integrado com os demais componentes. Até aqui tudo ok. A chance de dar algum problema é baixa, mas pode acontecer, caso algum time de componente não consiga entregar a sua parte, então todo o incremento estará em risco.

Agora imagine que esses mesmos 3 times de componentes, precisam trabalhar em 2 demandas diferentes: “Catálogo de Produtos” e “Pagamento”. Ao final da Sprint, os 3 times devem entregar sua parte de componente integrada ao incremento. Caso algum time não entregue, aquele incremento estará em risco, certo? A mesma coisa que aconteceu no exemplo anterior, mas dessa vez, há um detalhe a mais: E se o time de componente 1 priorizar a demanda de Catálogo de Produtos e os demais times priorizarem a demanda de Pagamento? Pode acontecer de, no final da Sprint, nenhum dos dois produtos terem um incremento entregue! Conseguem imaginar se tivermos 5, 10, 15 demandas para esses 3 times de componentes? A probabilidade de falha nessa entrega é enorme!

Para solucionar esse problema, podemos estruturar a equipe, como equipe de features, assim, todas as habilidades necessárias para criar uma feature estará dentro de um único time e não precisaríamos terceirizar uma parte de um componente.

Equipes de features reduzem a dependência externa e focam na feature como um todo enquanto equipes de componentes tem um foco mais individual e aumento de dependência externa

Uma forma de melhorar a comunicação entre os desenvolvedores de um mesmo componente cross-feature é adotar a estrutura representada abaixo, onde, na linha vertical temos a disposição de equipe de features, e na horizontal, os desenvolvedores organizados em componentes distribuídos nas features.

Essa é uma forma de alinhar padrões, tecnologias, conhecimentos e compartilhar problemas do dia a dia com os pares. Portanto, a estrutura horizontal é composta por desenvolvedores que possuem um mesmo domínio técnico – por exemplo UX – disposta em um nível hierárquico o qual geralmente é representado por um líder técnico.

Na vertical estamos otimizando a entrega de valor, na horizontal estamos otimizando a qualidade da camada/componente.

times

Fechamento

Embora pensando em escalabilidade a adoção de times de features seja mais adequada, não existe um veredicto em que a escolha pela abordagem de equipes de componentes não deva ser realizada. Muito depende do atual momento de transição da organização, de como as habilidades técnicas estão distribuídas e como a arquitetura técnica das features estão desenhadas.

É natural para empresas que estão fazendo transformação digital, haver uma transição de times de componentes para times de features. Já para startups, ainda em processo de amadurecimento da sua estrutura, os times de features acabam ocorrendo naturalmente pois geralmente começam com um ou poucos times multi-funcionais.

De forma geral, é comum encontrar os 2 tipos de estrutura em uma organização. Cabe analisar qual é a melhor configuração e distribuição de estrutura dentro do seu contexto.

quadro estrutura
menu