Muitas vezes, as empresas têm como objetivo "ser ágil" antes de realmente entenderem o que isso significa. Problemas começam a aparecer e expectativas são perdidas, fazendo com que todos questionem o valor de "ser ágil" – e diminuindo suas chances de chegar onde deseja.
A verdade é que ser ágil resultará em equipes mais produtivas e entregas mais rápidas de projetos, mas apenas se todos concordarem com as regras do jogo. Junte-se a Heather Fleming e Justin Riservato, do setor de e-commerce da Gilt, em sua discussão sobre por que obter consenso sobre os princípios do método ágil é mais importante do que a implementação de um processo.
Especificamente, Heather e Justin exploram as respostas para as três questões fundamentais que qualquer equipe precisa estar preparada para responder antes de embarcar rumo ao método ágil:
- "Mas quando você terminará?"Por que livrar-se do conceito de prazos é a conversa mais importante (e difícil) ao usar o método ágil?
- "Essa é minha prioridade, mas não poderei me encontrar com você até a próxima semana."O que fazer quando seu parceiro de negócios não pode ser (ou não será) um membro integral da equipe.
- "Apenas quero codificar. Por que tenho que participar de todas essas reuniões?" Por que implementar o Scrum não é a primeira etapa do método ágil?
Assista e aprenda
P & R
Heather e Justin selecionaram algumas das principais perguntas da sessão P & R desta apresentação. Leia para saber mais sobre as táticas de como aplicar metodologias ágeis.
P1: Painel ágil digital ou painel ágil físico? Qual a sua opinião sobre eles?
R1: Isso realmente depende da configuração de sua equipe. Todos estão no mesmo cenário? Quão grande é a sua equipe? Você tem espaço para um grande quadro físico? Já usamos os dois modos na Gilt, mas descobrimos que, à medida que crescemos e nos expandimos para várias equipes, os quadros ágeis no Jira Software são mais práticos do que os quadros físicos. Eles são mais fáceis de configurar e fazer alterações, além de serem mais fáceis de compartilhar com membros da equipe remota. O que adoramos em quadros físicos é que não é possível ignorar, eles estão na sua frente. E são um ótimo local para debates improvisados sobre o trabalho atual ou para fazer reuniões rápidas.
P2: Como trabalhar com um cliente ou gerente que não segue ou entende o processo ágil? Às vezes, me sinto como um treinador de fluxo de trabalho sem sucesso.
R2: É importante pensar sobre sua ordem de operações. Se estiver tentando trabalhar em um processo ágil com pessoas que não acreditam nisso, então você pode estar se precipitando. A parte mais importante de fazer isso funcionar é ter consenso em relação à filosofia antes de executar um processo. Fizemos isso anteriormente ao analisar problemas específicos de uma equipe com o processo atual e solucionando-os de um modo ágil. Você consegue ajudar seu gerente ou cliente a solucionar problemas reais que ele está tentando resolver e como você abordaria isso em uma estrutura ágil? Você consegue ensinar detalhadamente todas as etapas de uso do método ágil em vez de alterar totalmente o processo todo? Você pode começar a mostrar os resultados reais desse modo, gradualmente, à medida que a equipe estiver trabalhando melhor. Ou seja, use uma abordagem ágil para se tornar ágil. ;)
P3: Como você implementar um processo ágil quando o projeto tem orçamento fixo e/ou cronograma fixo com uma lista de requisitos para implementar?
R3: Em primeiro lugar, é impossível concluir um projeto com êxito com uma agenda fixa E uma lista fixa de requisitos a implementar, então há algum modo de fazer com que todos concordem que isso é uma fantasia? A maioria das restrições em relação a prazos e requisitos não são restrições de verdade, são desejos. Comece a discutir o motivo pelo qual está fazendo o trabalho ou qual é o problema que você está tentando resolver. Se realmente entende as metas do projeto e os motivos das restrições, você pode ter certeza de que a equipe está fazendo o trabalho correto na hora certa. Escrever todos os requisitos com as datas ao lado não garante magicamente que tudo aconteça no tempo estabelecido.
P4: A maioria dos projetos tem uma data de lançamento que geralmente é comunicada aos parceiros e aos clientes. Nesse cenário, o único item negociável é o recurso definido (embora a qualidade possa ser um pouco comprometida). Como você trabalha dentro dos limites de um prazo fixo?
R4: Achamos que você mesmo respondeu isso — isso é feito ao negociar o escopo. Se não, você está certo de que a qualidade terá impacto. Pensar assim pode fazer com que você apenas crie obstáculos para o escopo, independentemente de ser um "sonho". Você precisa garantir que suas equipes estejam trabalhando com a realidade, mesmo se não for o que as pessoas querem ouvir. Heather escreveu um pequeno texto no blog sobre isso. Leia o texto aqui.
P5: Como você acha que o modo como o scrum é implementado pode ser alterado?
R5: A rigidez do scrum é nosso maior problema com isso. Pensar que um único processo altamente prescritivo funcionará para todas as equipes, independentemente de em que estão trabalhando e quem são, é pretensioso. Já vimos isso funcionar para as equipes, mas o scrum não é o único modo de ser ágil, e várias equipes falham com o método ágil porque acham que precisam implementar o scrum de um modo específico com todas as funções de trabalho prescritas, histórias de usuário, critérios de aceitação, reuniões e artefatos. Heather também trata dessa questão em “Scrum Master”. ;)
P6: Como evitar que as partes interessadas influenciem diretamente os membros da equipe?
R6: Bem, uma boa parte interessada É um membro da equipe. Idealmente, tenha essas principais partes interessadas em sua equipe para que todos possam trabalhar juntos. Se as partes interessadas forem do tipo que apenas jogam os problemas para sua equipe, ou que entram no meio do projeto e tentam mudar tudo, é importante que toda a equipe entenda o que eles estão fazendo e o motivo. Então, independentemente de com quem as partes interessadas falem, elas terão a mesma resposta. É isso que forma uma equipe e não apenas uma reunião de várias pessoas. É necessário ter comunicação — muita — para garantir que todos estejam atualizados e seguindo o mesmo rumo.
P7: Você estima histórias com base na ordem aproximada de estimativas de magnitude (em horas) ou com base em pontos?
R7: Os dois. E algumas equipes não estimam nada. Pontos são ótimos porque são mais abstratos e não estão vinculados a um calendário específico. As horas podem ser úteis como transição se sua equipe resistir à estimativa, pois são mais tangíveis. Ao usar estimativas é necessário conseguir analisar se seu sprint é muito pesado ou muito leve e ajustá-lo, e elas não têm finalidade nenhuma após o início do sprint. Ao trabalhar com uma equipe durante um tempo, o processo de estimativa se torna desnecessário. Todos conseguimos observar o trabalho e dizer facilmente se a quantidade é a ideal para o sprint.
P8: Quanto valor você coloca em líderes/gerentes de projeto para que tenham habilidades de análise profunda e conhecimento do produto vs apenas coordenar reuniões entre as partes interessadas em tecnologia e negócios para reunir requisitos?
R8: Quase todos os valores :) Coordenar reuniões, tomar notas, etc. não são especialidades. Todos podem fazer isso. Embora sejam importantes, não são, realmente, a maior adição de valor que você pode fornecer para sua equipe. Se tudo o que você está fazendo é trabalho administrativo, então a equipe está certa em questionar o motivo de você fazer parte dela. Todos em PMO na Gilt têm conhecimento amplo sobre os assuntos relevantes e as ferramentas e as técnicas para fazer o trabalho e eles levam isso com eles a todas as equipes nas quais trabalham. Muitos já foram engenheiros ou trabalharam em outros departamentos na Gilt, tendo muito conhecimento em relação a assuntos relevantes.
P9: Geralmente, quão grandes são as equipes e qual o conhecimento que as pessoas têm na Gilt?
R9: Idealmente, queremos que nossas equipes sejam enxutas, mas grandes o suficiente para serem autossuficientes, permitindo que elas possam trabalhar nos projetos sem dependências de outras equipes. Seguimos a regra de "duas pizzas": o tamanho ideal de uma equipe é quando ela consegue ser alimentada por duas pizzas. Também acreditamos que todos da equipe possuem talentos exclusivos e eles devem poder fornecer esses talentos às equipes independentemente do cargo. Então, se, tradicionalmente, o proprietário do produto é responsável por todas as apresentações, mas ele não é bom nisso e, se há um engenheiro muito bom em fazer apresentações e conquistar a atenção do público, deixaremos que esse engenheiro use esse talento na equipe. Você é mais do que seu cargo!
P10: Como consegue gerenciar uma equipe separada de GQ, especialmente onde os testes podem ocorrer em um sprint diferente de desenvolvimento?
R10: Essa é uma das posições mais controversas que tomamos, mas não temos uma equipe de GQ na Gilt. Acreditamos nos testes de automação em todo o processo de desenvolvimento e implantação. As equipes são responsáveis pela qualidade de seu código. Se tem tempo e conhecimento para escrever um código, você tem tempo e conhecimento para escrever testes para ele. Levar isso para uma equipe de GQ nunca nos proporcionou bons resultados, além de exigir muita documentação adicional e tempo para que a equipe de GQ consiga acompanhar o ritmo.
P11: Se você tem equipes que trabalham em vários "produtos" simultaneamente, funcionaria reunir todos os gerentes de produto na sala durante o planejamento de sprint e solicitar que eles determinem as prioridades para os produtos? Outras ideias?
R11> Pare! Claramente isso não funcionará. A equipe deve ter um gerente de produto exclusivo e que não esteja trabalhando em vários produtos para diversos gerentes de projeto fora da equipe. Quem quer que seja o líder da equipe, essa pessoa deverá definir claramente a metodologia da equipe quanto à priorização e estabelecer em qual ordem será feita a execução do trabalho com base nessa metodologia. Isso nos leva de volta ao ponto: você deve estar alinhado com sua metodologia antes de estabelecer um processo.
P12: Estou tentando fazer uma equipe de marketing de serviços criativos usar o método ágil. Temos alguns itens que DEVEM ser entregues em uma determinada data (criar um anúncio para publicação em uma revista). Como encaixamos estes projetos em uma estrutura ágil?
R12: O método ágil consegue lidar com restrições como essa. A equipe deve identificar o que deve ser feito e quando, bem como planejar os sprints de acordo. O método ágil deve ajudar você a atingir esses prazos, pois ele proporciona a capacidade de ajustar suas prioridades e seu trabalho (escopo) planejado a cada sprint. Se começar a monitorar sua velocidade, em breve você será capaz de dizer se conseguirá atingir esses prazos. Cabe a um bom líder de projeto conseguir negociar o que a equipe precisa para ter êxito.
P13: A mudança de objetivos não seria um deslizamento de escopo?
R13: Sim, mas não chamamos de "deslizamento de escopo" porque queremos encorajar a mudança durante um projeto. Uma das maiores vantagens de uma filosofia ágil é que ela permite que você se adapte ao que está fora de seu controle. Se o cenário competitivo mudar, ou as necessidades de seu negócio forem alteradas, ou se houver tecnologia nova disponível, você realmente desejará detalhar novamente a matriz de requisitos que foi estabelecida meses atrás? Se quiser fornecer o melhor produto para seu cliente, aceite a mudança e use-a a seu favor. Não há "deslizamento de escopo" no método ágil (inserir um truque mental Jedi aqui).
