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

Nenhum produto no carrinho.

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 jogoDescriçã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, florDescriçã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 desenhoDescriçã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 desenhoDescriçã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, quartoDescriçã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ógioDescriçã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 desenhoDescriçã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ô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