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!

O Time de Desenvolvimento no Scrum é composto por desenvolvedores cujo propósito é realizar todo o trabalho criativo de projetar, construir, integrar e testar os Itens do Backlog do Produto. A partir da necessidade do cliente refletida no Backlog do Produto, o Time de Desenvolvimento tem a missão de transformar os Itens do Backlog do Produto em Incremento "Pronto" ao final de cada Sprint, para ser inspecionado na Sprint Review.Web development free icon

Para isso, é necessário que o Time contenha todas as habilidades necessárias para realizar esse trabalho de ponta a ponta, sem depender de times externos. Assim, o Time de Desenvolvimento é estruturado e autorizado pela organização para constituir e gerenciar seu trabalho de modo a otimizar todo o trabalho necessário.

Características do Time de Desenvolvimento:

Aqui, não existe aquela história de que o Incremento não foi entregue porque o Time de QA atrasou ou o Time de iOS estava com outra prioridade!

Uma imagem contendo objetoDescrição gerada automaticamente

Qual o tamanho ideal de um time?

Essa é a pergunta de 1M de dólares. Idealmente um Time de Desenvolvimento não deve ser pequeno que não consiga entregar um incremento de ponta-a-ponta e nem tão grande que torne a comunicação entre os membros muito complexa. A figura abaixo mostra como a comunicação se torna exponencialmente complexa à medida que o time aumenta de tamanho:

Porém, isso não quer dizer que times grandes não funcionem bem. 

O Scrum Guide sugere que o Time de Desenvolvimento seja composto por no mínimo 3 e no máximo 9 pessoas. Outras literaturas dizem que o Time ideal é composto por 5 a 7 pessoas, o fato é que não existe um número mágico. Contudo, tenha em mente que o time deve ter um tamanho suficiente de modo a trazer fluidez na entrega e que tenha todas as (ou a maior parte das) habilidades necessárias para entregar um incremento de ponta-a-ponta com nenhuma (ou pouca) dependência externa.

Conclusão

O Time de Desenvolvimento é responsável por ajudar o Product Owner durante o planejamento da Sprint, onde se compromete de forma auto organizada a transformar os Itens do Backlog do Produto em Incrementos funcionais que serão apresentados na Revisão da Sprint. 

Além disso, é de responsabilidade do Time de Desenvolvimento apontar dependências técnicas e garantir que o Incremento atenda a Definição de Pronto. 

Para reduzir o risco de uma entrega falhar e melhorar o planejamento, o Time de Desenvolvimento deve apoiar o refinamento do Backlog do Produto junto ao PO, alocando até 10% de sua capacidade durante a Sprint.

Leia este outro artigo que tem tudo a ver com o assunto: Moral do time x Sucesso do produto

Uma imagem contendo equipamentos eletrônicosDescriçã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