Blog: Times Cross-funcionais

Squad, Times Cross-funcionais

A evolução da aplicação de Metodologias Ágeis muda não somente como as empresas pensam seu trabalho, mas também como elas moldam seus times. Nesta ideia de equipes cross-funcional e que surgiu o Squad, que ganhou maior visibilidade após ser divulgada de como a Spotify, empresa sueca de streaming de música, organiza e estrutura seus times.

Squads Squads são a unidade básica de organização dos times, geralmente em torno de uma feature, ou subsecção de uma funcionalidade. Podem ter até 10 membros, cross-funcional a ponto de conterem expertise dentro do grupo para desenvolver todos os aspectos do produto e definir suas prioridades alinhadas com o objetivo da empresa.

No modelo de Squad, não há uma figura de liderança formal. As lideranças são mais orgânicas, já que os times são auto-geridos. Eles se baseiam em aspectos técnicos e funcionais do trabalho e de seus projetos.

Não há também uma divisão funcional constituída de papéis tradicionais. Todos os envolvidos em determinado projeto trabalham conjuntamente e complementarmente, cocriando soluções.

Esses times são organizadas multidisciplinarmente, de acordo com as necessidades dos projetos da empresa.

Times Cross-funcionais Porque voltar a este ponto? Porque os times cross-funcionais estão mais presentes nas organizações que desejam contar com equipes de alta performance. Elas diferenciam-se da concorrência por meio de serviços, produtos e atendimento inovadores.

Esses times tornam as organizações menos hierárquica e vertical do que as estruturas mais tradicionais e precisam ser compostos por colaboração profissionais com diferentes competências e perfis que atuem em diferentes atividades, onde não há espaço para a mentalidade do “a minha parte eu entreguei” e/ou “eu fiz o meu trabalho” . Todos trabalham para atingir um objetivo comum.

O impacto na comunicação é grande, pois ela exige mais dedicação, já que a interação é continua com pessoas de diferentes funções e expertises.

Quanto mais unido e sensibilizado em relação aos objetivos o squad for, maior será o benefício para a empresa e para a agilidade de seus processos.

Desvantagens dos times cross-funcionais Nem tudo é somente vantagens, encontrei descrito em diversas postagens, questões relacionadas a autonomia, já que esse tipo de estrutura permite que os membros definam as prioridades. O alinhamento com os demais membros e a empresa deve ser muito afinada.

Acho que muito também deve se pensar em harmonia e formas de incentivar este afinamento. Isso passa muito pelo desenvolvimento das lideranças. Mesmo que não se pense neste papel, alguém tem que comunicar para fora, representar o Squad em algum momento e ele deve realizar uma gestão bem diferenciada para dentro do sistema burocrático da empresa.

Enfim… Squad é uma nova forma de se trabalhar, que pode e deva ser usado nas empresas, mas as empresas precisam ter uma nova visão, pensa no futuro e querer.

Papéis no Scrum: Product Owner, o Dono da Bola, Scrum Master, o Coach Proativo e Scrum Team

Scrum assim como muitas metodologias são formadas por papeis que fundamentam sua aplicação. Os papéis dentro do Scrum são compostos por: O Product Owner, Scrum Master e Team Scrum, que são suficientes para entregar software de alto valor agregado, de acordo com a metodologia Scrum.

Unindo e agregando conhecimento a meus posts anteriormente, temos uma descrição segundo o SBOK.

Product Owner, o Dono da Bola O Product Owner é o dono do produto, é quem define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings, pois fornece o conhecimento do negócio em forma de requisitos para a equipe assim como sua ordem de aplicação. Na prática, o Product Owner é a interface entre a empresa e os clientes.

O Product Owner Trabalha em conjunto com a equipe definindo as necessidades dos usuários, os requisitos técnicos, documentando-os conforme a necessidade, e determinando a ordem de sua execução. Ele gerencia o Product Backlog (que é o repositório de todas essas informações), mantendo-o ao nível de detalhe e qualidade que a equipe necessita.

O Product Owner também define o cronograma para liberação das releases, e faz a validação final para saber se as implementações têm as características e qualidade necessárias para a liberação.

O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint. Estes itens transformam-se no Sprint Backlog.

A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos.

Scrum Master, o Coach Proativo O Scrum Master tem a responsabilidade de assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

As responsabilidades do Scrum Master incluem:

Remover as barreiras entre a equipe e o Product Owner. O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões. Melhorar a produtividade da equipe da forma que for possível. Melhorar as práticas de engenharia e ferramentas para que cada incremento de funcionalidades seja potencialmente entregável. Manter as informações sobre o progresso da equipe visível a todos de uma forma clara e organizada. Em termos práticos, o Scrum Master precisa ter em mente a vivência do Scrum para treinar e orientar os outros papéis, e educar e ajudar as outras partes interessadas que estão envolvidas no processo.

Ele deve manter atenção constante ao status do projeto em relação ao progresso esperado. Investigar e facilitar a resolução de quaisquer obstáculos que imobilizam o progresso e, geralmente, ser flexível o suficiente para identificar e lidar com quaisquer problemas que surjam. Ele deve proteger a equipe de perturbações externas.

O Scrum Master não atribui tarefas aos membros da equipe, isso é uma responsabilidade da equipe. Sua abordagem geral para a equipe é incentivá-la e facilitá-la na capacidade de tomada de decisões e resolução de problemas relacionados ao desenvolvimento, de modo que eles possam trabalhar com maior eficiência sem a necessidade de supervisão. Seu objetivo é ter uma equipe auto-organizável.

E finalmente, Scrum Team O Scrum Team é a equipe de desenvolvimento sem a necessidade de uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

O Scrum Team é auto organizável, ou seja, quem decide quem faz o que, quais as funções de cada membro e o que cabe ou não na Sprint é o time.

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de “Scrum of Scrums“.

Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá frequentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrums, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações.

Veja a importância efetiva de cada grupo definido no SBOK. Oportunizando a todos o mesmo grau de importância e compreensão do todo.