Journey to Agile: como a Braze reinventou seu processo de gerenciamento de projetos de software

Fazendo um plano

Após alguma reflexão, decidimos adotar uma metodologia testada e comprovada para equipes de engenharia – decidimos que queríamos nos tornar mais Ágeis.

Para abordar esse novo desafio, queríamos reunir um grupo que representasse e alavancasse o conhecimento de toda a nossa organização de produtos e engenharia, por isso criamos um comitê com oito membros representando gerenciamento de produtos, design e engenharia. Incluímos gerentes e colaboradores individuais, bem como pessoas com diferentes níveis de experiência, antiguidade e experiência em Agile.

Este Comitê Ágil, como o apelidamos, abordou a situação com alguns princípios-chave em mente:

• Queríamos usar soluções comprovadas sempre que possível, tanto em metodologias quanto em software. É preciso muito esforço para ser único e queríamos ser únicos apenas em áreas necessárias e estratégicas. Também queríamos que as pessoas pudessem usar as práticas recomendadas do Google sobre como gerenciar seu trabalho ou, melhor ainda, que as pessoas se juntassem ao Braze já sabendo principalmente como fazê-lo.
• Queríamos que as equipes de engenharia de produto da Braze fossem amplamente consistentes em como operam, porque ser capaz de falar o mesmo idioma é valioso.
• Não queríamos fazer nada dogmaticamente, ou sem pensar. Apenas escolher um método e seguir o livro não era bom o suficiente; era importante para nós que o bom senso e a interação ponderada dominassem o dia.

Armados com essas diretrizes, decidimos fazer uso do Scrum, que é uma estrutura Agile comprovadamente eficaz para muitas organizações. É amplamente conhecido, é escalável e é a escolha padrão segura quando você deseja implementar um processo Agile.

Em seguida, enfrentamos duas decisões principais: (1) quais ferramentas devemos usar para apoiar nosso novo processo e (2) como devemos implementar as mudanças em nosso processo. Conversamos, avaliamos e demonstramos vários softwares e, por fim, o Jira da Atlassian provou ser a escolha certa para nós. É uma solução comprovada, várias pessoas em nossa equipe já tinham experiência em usá-la e outras equipes da Braze já a usavam, abrindo uma oportunidade para uma melhor colaboração entre equipes porque todos trabalharíamos em um sistema.

Quando chegou a hora de selecionar um plano de implementação para o Agile, tivemos que tomar algumas decisões importantes. Primeiro, como treinamos/habilitamos a equipe? Poderíamos contratar um coach ágil, fazer com que pessoas com experiência na equipe fizessem o trabalho de treinar os outros ou obter consultores para ajudar. Segundo, devemos fazer com que as equipes de engenharia que tenham alguma experiência com o Agile esperem pelo treinamento antes de implementá-lo?

No final, decidimos deixar as equipes familiarizadas com o Jira e o Scrum começarem na medida em que se sentissem capazes e contratamos um consultor para ajudar na transição em toda a organização. Não estávamos interessados ​​em ter pessoas em nossa equipe ou um jogador independente como principal responsável por treinar os membros da equipe durante a transição porque:

• Não queríamos que nenhuma equipe individual fosse dona de como fazemos Agile e sentimos que o treinamento seria mais bem recebido e as sugestões seriam mais inclusivas se viessem de terceiros
• Achamos que uma empresa de consultoria seria mais estável e confiável do que um Agile coach individual
• Queríamos ter um treinamento básico para toda a organização de engenharia e começar sem fazer suposições sobre o conhecimento que os membros individuais da organização tinham sobre Agile
• Por fim, queríamos que os treinadores saíssem em um determinado momento, para deixar claro que todos em nossa organização eram responsáveis ​​​​por manter o processo daqui para frente

Executando o Plano

Após alguns meses de planejamento, tínhamos um grande documento que detalhava tudo o que pretendíamos fazer e o compartilhamos com a organização em geral para feedback. Então, depois de avaliar vários fornecedores, selecionamos Eliassen para fazer parceria conosco na jornada para o Agile. Essa jornada começou com um treinamento Agile de dois dias ministrado por Eliassen, seguido por três meses de treinamento Agile de um especialista com quem Eliassen nos conectou.

Desde o início, fomos bastante cautelosos ao mudar para Jira e Scrum. Tanto a internet quanto as experiências pessoais de nossa equipe estavam cheias de histórias de advertência sobre os perigos de abordagens excessivamente dogmáticas, de como o Jira pode funcionar como um “antipadrão” e todas as maneiras pelas quais o Scrum pode dar errado nas organizações. Fomos fortemente avisados ​​por pessoas que consultamos que essas mudanças provavelmente levariam tempo e que poderia haver dores de crescimento antes de vermos os benefícios reais do Agile.

Felizmente, instantaneamente encontramos valor no novo processo. Uma das coisas boas dessa transição é que nunca sentimos nenhuma pressão para seguir cegamente qualquer aspecto particular do Scrum; para fazer as coisas funcionarem melhor, fazíamos uma retrospectiva de como as coisas estavam indo a cada duas semanas e depois modificávamos o que precisava ser modificado. E ao longo dos três meses de coaching, implementamos mudanças radicais em toda a organização de engenharia:

• Todos aprenderam a escrever, preparar, apontar, dividir e pegar histórias de usuários
• Standups encontraram um foco renovado quando se tratava de terminar o trabalho em mãos
• Produto, Design e Engenharia todos aprenderam a falar as mesmas linguagens, e as interfaces foram cada vez mais bem projetadas

Os resultados

Agora que estamos do outro lado desse esforço de aproximadamente seis meses, as mudanças são claras — e dramáticas. Vimos uma redução significativa nos problemas que levaram a esse esforço. Com o Agile, agora temos mecanismos claros e fáceis de entender para aprovação, colaboração, criação de pendências e preparação, e realizamos retrospectivas regularmente sobre o que melhorar.

Também temos localizações significativamente mais consistentes para artefatos de design, bem como expectativas mais alinhadas sobre o que realmente é “feito” para um determinado projeto. Ver no que outras equipes estão trabalhando tornou-se fácil e mais simples do que nunca para as pessoas entenderem como trabalhar bem juntas.

Algo que notei no final dessa transição é que o número total de solicitações de pull abertas na organização em um determinado momento diminuiu, mesmo quando estávamos fazendo mais e aumentando o tamanho de nossa equipe. Trabalhando em incrementos menores e concentrando-se em terminar as coisas, o número de itens em voo diminuiu significativamente.

O sucesso que tivemos em nossa organização também inspirou outros. Estamos começando a ver equipes em outros departamentos da Braze iniciando suas próprias transformações Agile, então em breve mais pessoas falarão a mesma linguagem e terão as ferramentas necessárias para definir e melhorar a colaboração.

Aprendizado

Dois elementos principais do nosso esforço garantiram o seu sucesso.

Primeiro, o fato de ter sido conduzido por um comitê representativo foi essencial para obter informações de toda a organização de engenharia e de uma variedade de perspectivas diferentes. Em toda a empresa, as pessoas se sentiram ouvidas e representadas em uma questão que afetaria seu trabalho diário. A criação posterior de um documento completo apresentando as motivações e planos para uma transição Agile que poderia ser compartilhado com a equipe também foi bastante útil. Acreditamos em mostrar como as decisões são tomadas e na introdução de caminhos claros para feedback, porque fornece contexto e estabelece um artefato sobre o qual dar feedback.

Em segundo lugar, a decisão de contratar um terceiro para ajudar a treinar nossa equipe foi essencial. Ter um parceiro objetivo e experiente nos deu a capacidade de fazer inúmeras melhorias rapidamente em nosso processo. Nosso treinador sabia o que era bom e foi capaz de fazer recomendações sem preconceito, várias vezes fomos capazes de perguntar: “Como as equipes normalmente fariam X?” e obtenha uma solução imediata e viável. Se, por outro lado, tivéssemos usado recursos internos, correríamos o risco de que o feedback que recebemos viesse de uma parte tendenciosa e aumentaria a contenção de recursos com as responsabilidades existentes.

Algo mais?

Se você quiser saber mais sobre como pensamos sobre nosso produto e o trabalho que é necessário para fazê-lo, confira Building Braze. Interessado em se juntar à nossa equipe? Confira nossas vagas de emprego atuais.