Escalando o Scrum para a empresa inteira!

Mesmo pequenos, já viamos necessidade de um método de gestão eficiente: por essa razão, decidimos iniciar nossa jornada escalando o Scrum na empresa inteira

Começamos a rodar a metodologia em um único time, no qual eu era o Product Owner (PO), mas nosso grande desafio era conseguir escalar isso para a empresa inteira. Ainda éramos pequenos, com cinco times e um total de vinte pessoas, mas já viamos necessidade de um método de gestão eficiente. Por essa razão, decidimos iniciar nossa jornada escalando o Scrum na empresa inteira. Como a empresa não era grande, todos já sabiam do que estava acontecendo no time de Marketing e já estavam por dentro do que era o Scrum. Estávamos animados com o que tínhamos proposto, então, o caminho já estava mais fácil. Finalizamos os dois primeiros Sprints no Marketing para depois ir escalando o Scrum para o restante da empresa.

Como começamos

Convidamos o time de Marketing para nos ajudar na disseminação do conteúdo e fizemos o primeiro treinamento com outros dois times, seguindo a lógica de começar aos poucos e não apenas introduzir em toda a empresa de uma vez. Além de explicar os principais benefícios do Scrum, os papéis, responsabilidades e o porquê estávamos nos propondo implantá-lo, inserimos no treinamento uma parte ainda mais rica. O time de marketing apresentou seu feedback com a metodologia: um feedback real, de pessoas reais, ajudando na nossa tese, o que nos era importante pois o Scrum precisa ser uma mudança cultural. Depois do treinamento, agendamos o primeiro Sprint Planning dos times e iniciamos o trabalho com os Product Owners. Como no Marketing eu era o PO, treinar outras pessoas para esse papel seria um novo desafio na nossa jornada de implantação. Eu já havia errado bastante nessa função e conhecia o básico dos times. Por isso mesmo, acompanhei de perto o trabalho deles em nossos primeiros ciclos de trabalho. Durante essa jornada, descobrimos uma das coisas mais importantes para que o Sprint funcione bem: o trabalho do PO. Esse trabalho é essencial ao funcionamento do ciclo, portanto deve ser feito com muito esmero. É fundamental comprometimento com o Backlog e o engajamento com a metodologia, pois contribui muito com o desempenho do time. Exatamente por isso, o acompanhamento de perto dessa função se mostrou um dos nossos maiores acertos.

Nossos erros e acertos

Iniciamos os Sprints nos dois times, e vimos que os erros e falhas de cada foram bem próximos próximos dos que aconteceram no Marketing, por isso mesmo já começamos a observar padrões de dificuldade de implantação da metodologia. Com isso mapeado, repetimos a nossa fórmula nos outros times que faltavam. Em pouco tempo, já tínhamos uma empresa inteira rodando com as mesmas metodologias, escaladas e adaptadas à necessidade de cada um. Nossos resultados também eram os mesmos: ainda não tínhamos maturidade e não conseguimos entregar todas as tarefas do Sprint logo no início. Além disso, chegávamos ao fim do Sprint com tarefas que não estavam 100% claras para o time e justamente por isso não eram executadas. Somado isso, alguns times tinham sim uma demanda imprevista muito grande e por isso mesmo o comprometimento do time com o Sprint acabava prejudicado.

Lembre-se: cada colaborador tem sua própria visão

As pessoas eram diferentes, cada uma delas tinha a sua percepção da metodologia, então logo percebemos que tínhamos um Product Owner desengajado, que não preenchia o Backlog e acabava atrapalhando todo o seu time, impactando em seus resultados de maneira negativa. As entregas não aconteciam e o caos do passado era presente no dia a dia. Percebi que para esse PO, manter o comprometimento com a metodologia era mais difícil, e hoje já entendo que deveria ter buscado compreender muito mais o porquê dos outros enxergarem tanto valor e ele não. Tentamos de muitas formas engajá-lo, mas sem sucesso algum. Na época, implantar o Scrum era o objetivo da empresa, por essa razão fui bem claro; ou seguimos da forma que  definimos ou você não estará dentro da Cultura do time. Precisei tomar essa decisão difícil, afinal, a mudança tem que ser cultural. A empresa precisa deixar claro quais serão os comportamentos aceitos e também o que não será tolerado. No nosso caso, deixamos claro que teríamos o comprometimento com a metodologia e buscaríamos nos aperfeiçoar para melhorar a cada novo ciclo, desenvolvendo os indivíduos e também os times como um todo.

Melhorias que ocorreram escalando o Scrum

O microgerenciamento do passado já não existia mais: estávamos rodando nossos Sprints e melhorando a cada novo ciclo, corrigindo nossos erros como Scrum Masters, acompanhando os Product Owners nesse meio tempo e oferecendo o suporte necessário para o time. Fizemos treinamentos constantes com todos, mantendo nosso compromisso em dia. Nossos resultados melhoraram muito, e com sucesso: passamos de vinte para sessenta pessoas no time logo no primeiro ano. O Scrum foi a nossa base, por essa razão vemos tanto valor nessa metodologia e acreditamos que ela pode alavancar o que temos de melhor. Ir aos poucos, entender onde acertávamos, em que devíamos melhorar e, principalmente, onde podíamos avançar foi o segredo para tudo funcionar.

Inscreva-se na nossa newsletter

Vamos te enviar os melhores insights
Oops! Something went wrong.
Não se preocupe, não vamos te mandar SPAM!