Além de cerimônias e artefatos

Como criamos uma equipe Ágil de alta performance em Tecnologia Global.

por Hiren Patel, gerente sênior de gerenciamento de projetos

Até 2022, a equipe de produtos e engenharia de restaurantes em tecnologia global construía painéis usando a metodologia cascata. Isso aconteceu em parte porque o McDonald's terceirizou o desenvolvimento, e pode ser tentador definir todos os detalhes do escopo e as entregas finais antecipadamente no contrato.

Sem surpresa, a equipe enfrentou os mesmos problemas frequentemente associados a projetos em cascata em todos os lugares e, em última análise, menos eficazes. Além disso, havia grandes lacunas de design entre o produto que foi construído e o que era compatível com o ecossistema do McDonald's.

Este post fala sobre como o desempenho, bem como a percepção, de nossa equipe melhorou em 2022, uma vez que a equipe mudou sua abordagem. A equipe implementou a estrutura scrum da metodologia Agile, mas dizer isso não diz tudo.

Equipes em muitas empresas em todo o mundo assumem que são equipes ágeis uma vez que implementam cerimônias e artefatos de scrum. Olhando mais de perto, fica claro que, embora muitas dessas equipes adotem a mecânica do scrum, elas não têm a mentalidade certa para serem bem-sucedidas. Na verdade, eles geralmente recebem escopo fixo, prazos fixos e um orçamento fixo, que eles decompõem nas chamadas histórias de usuários e agrupam em sprints. Em essência, são times em cascata disfarçados de times Agile, mesmo que não seja intencional.

Nossa equipe de liderança nos apoiou na adoção da mentalidade certa e abaixo estão alguns destaques de como criamos uma equipe Agile de alto desempenho.

Concentre-se em produtos em vez de projetos
Quando as pessoas pensam em projetos, elas assumem que os projetos têm um fim finito. Na verdade, muitas das principais organizações profissionais de gerenciamento de projetos definem explicitamente um projeto como tendo um fim finito. Superficialmente, a ideia de projetos parece muito prática no mundo corporativo. Os contratos são aprovados mais rapidamente quando as entregas finais e os prazos firmes são definidos antecipadamente; o planejamento orçamentário é mais simples quando o escopo e o cronograma já estão definidos; e gerenciar expectativas com liderança parece mais fácil quando as restrições triplas são firmes.

No entanto, a presença do fim finito do projeto tem algumas consequências não intencionais: os prazos exercem pressão sobre a equipe e orientam as decisões ao longo do projeto, que nem sempre são produtivas no longo prazo. As decisões podem ser tomadas com viés em relação ao cronograma, em vez de fazer o que é necessário para obter os resultados ideais; À medida que o prazo arbitrário estabelecido vários meses antes se aproxima, as equipes de projeto se concentram mais em fazer as coisas do que em fazer as coisas direito.

Por outro lado, quando as pessoas pensam em produtos, aceitam o fato de que os produtos sempre podem ser melhorados. O foco em projetos leva as pessoas a tomar decisões com base em prazos, enquanto o foco em produtos leva as pessoas a tomar decisões com base no que é melhor para as partes interessadas.

Quando nossa equipe estava focada no projeto, construímos um painel que marcava algumas caixas em uma declaração de trabalho, mas o produto não teria sido muito útil para nossas partes interessadas no mundo real. Nos seis meses após mudarmos para uma mentalidade centrada no produto, lançamos uma versão modificada desse painel, que é mais adequada para nossos stakeholders.

Uma mentalidade centrada no produto não significa necessariamente que cada iteração de um produto será perfeita, mas leva a produtos melhores ao longo do tempo em comparação com a mentalidade centrada no projeto. E, para ser claro, o foco centrado no produto não é mutuamente exclusivo da preocupação com orçamentos, cronogramas e velocidade de lançamento no mercado.

Entregue valor com frequência
Nossa equipe adotou o conceito de grau de produto quando se trata de painéis, para que possamos entregar produtos funcionais rapidamente. Um típico sedã familiar e um supercarro de luxo podem ser produtos funcionais de alta qualidade, mas devem ser de qualidades diferentes. Em outro exemplo, uma chave de fenda manual e uma chave de fenda elétrica de impacto podem ser produtos de trabalho de alta qualidade, mas também são de diferentes graus.

Da mesma forma, nos concentramos em como podemos fornecer um painel de notas mais baixas, mas de alta qualidade para nossas partes interessadas rapidamente e, em seguida, melhorar continuamente a nota durante cada sprint. Por exemplo, podemos entregar um painel que contém uma tabela no primeiro sprint; em seguida, adicione recursos de classificação e filtragem no próximo sprint; em seguida, adicione um esquema de cores e recursos detalhados no terceiro sprint. Em qualquer nível de ensino, o painel é sempre um produto totalmente funcional e de alta qualidade que nossos stakeholders podem usar.

Essa abordagem nos permite fornecer painéis de trabalho para nossos interessados ​​mais rapidamente, em vez do caminho alternativo no qual não teríamos fornecido nada aos nossos interessados ​​até que os painéis fossem de alta qualidade e alto grau, simultaneamente.

Confie nos desenvolvedores
Como toda boa equipe Agile que usa scrum, usamos gráficos de burndown, mas não penalizamos os desenvolvedores com base nos gráficos. Mesmo quando uma equipe tem os desenvolvedores mais talentosos, os gráficos de burndown normalmente não devem parecer perfeitos. Se os gráficos de burndown parecerem consistentemente perfeitos, é provável que seus desenvolvedores estejam mais focados em fazer com que o gráfico de burndown pareça bom, em vez de se esforçarem para fazer o melhor. Isso ocorre porque as estimativas são aproximadas em vez de exatas e as surpresas são inevitáveis ​​a cada sprint.

Pressionar por um gráfico de burndown perfeito é uma expectativa irreal e desnecessária, que geralmente diminui o moral e encoraja os desenvolvedores a burlar o sistema. As equipes que se apoiam demais nos gráficos de burndown como a principal ferramenta para medir a produtividade podem ser bem-sucedidas em conduzir comportamentos que resultem em gráficos de burndown de aparência perfeita, mas isso não necessariamente resultará em uma equipe de alto desempenho. Em vez disso, usamos os gráficos de burndown para nos informar sobre o que aconteceu, onde nos desviamos do plano do sprint, por que nos desviamos e o que podemos fazer melhor. Em resposta à confiança que damos aos desenvolvedores, eles confiam em nós com seus comentários sinceros, em vez de nos dizer o que parece bom. Responsabilizamos os desenvolvedores com base nos painéis de trabalho que eles fornecem, em vez dos gráficos de burndown.

Seja flexível para mudar
Às vezes, os requisitos, prioridades e necessidades mudam. Às vezes, os desenvolvedores recomendam alterações para nós e, às vezes, pedimos aos desenvolvedores que alterem as coisas. Sempre há uma consideração cuidadosa e um bom diálogo quando ocorrem mudanças para que todos na equipe entendam o que é a mudança e por que ela é necessária. Mas o mais importante é que nossa equipe se esforça para abraçar as mudanças em vez de evitá-las, mesmo que surjam em momentos inconvenientes. Evitar mudanças pode parecer a melhor escolha no curto prazo, porque pode ajudar a manter os gráficos de burndown com boa aparência, pode permitir que a equipe entregue algo no final do sprint ou pode ajudar a evitar um impacto de custo. No entanto, a dívida de não aceitar mudanças se acumula com o tempo, e o custo de pagar essa dívida pode ser muito maior no futuro.

Concentre-se na comunicação em vez da documentação
A documentação é útil, mas tem retornos decrescentes além de uma certa extensão. Temos histórias de usuários com critérios de aceitação, documentos de design e outras documentações que nos ajudam na comunicação. No entanto, colocamos a maior ênfase na comunicação constante e na garantia de que os desenvolvedores entendam claramente os requisitos. Eles não insistem que escrevamos todos os detalhes no tíquete e não esperamos que eles descubram tudo simplesmente lendo os tíquetes.

Conclusão
Em 2022, a equipe de produtos e engenharia para restaurantes apresentou vários painéis de trabalho durante os três primeiros trimestres, juntamente com várias rodadas de aprimoramentos para cada um. Esta foi uma grande melhoria em relação ao ano anterior. Além disso, as partes interessadas estão começando a reconhecer a equipe por sua capacidade de transformar ideias em painéis funcionais que são realmente úteis para os usuários. Um ciclo virtuoso se formou dentro da equipe que leva a um melhor desempenho e moral, graças à mentalidade que adotamos.