5 Perguntas sobre a Introdução do Scrum

Organizações não se tornam ágeis da noite para o dia por mágica. É um processo de transformação significativo, no qual cada pessoa precisa revisar e ajustar seu papel. E tudo começa com a liderança respondendo algumas perguntas bem complexas.

Diante dos desafios que as organizações modernas enfrentam, o Agile é extremamente atraente. Quem não gostaria de ter releases mais frequentes? Quem não gostaria de se adaptar melhor a um ambiente de negócios em constante mudança? No entanto, muitos líderes consideram o Scrum e iniciam uma transformação ágil sem compreender os impactos que o Scrum pode ter na sua organização, na sua carreira e nos seus objetivos.

Scrum não é algo que deve ser introduzido de forma leviana em uma organização, e os líderes devem se fazer algumas perguntas complexas. Scrum não é apenas responsabilidade das equipes de desenvolvimento. Não pode ficar restrito a uma única equipe. A introdução do Scrum representa uma mudança sistêmica na organização e é frequentemente descrita como difícil e disruptiva. Mas o que isso realmente significa? Quais são os possíveis impactos do Scrum?

Aqui estão cinco perguntas que devem ser respondidas para que você possa se preparar para uma introdução bem-sucedida e produtiva do Scrum.

1) Como reajo a mudanças que afetam o meu papel?

Esta pergunta precisa ser respondida por todas as pessoas numa organização e não apenas pelas equipas que vão trabalhar com Scrum. O Scrum tem o impacto mais direto nas equipas, mas não fica por aí. E os superiores? Como é que vão reagir quando o seu papel de liderança for afetado?

Exemplo: Scrum e a gestão intermédia

Estava a tomar o pequeno-almoço com o meu amigo John (nome alterado). John era um gestor de desenvolvimento numa grande empresa de serviços financeiros, onde o Scrum tinha sido introduzido nos últimos anos.

Ele estava preocupado com a forma como o seu papel na empresa seria agora visto. Perguntei-lhe porque estava preocupado e ele respondeu: "No início estava tudo bem. As equipas progrediam rapidamente e um ambiente de trabalho baseado em equipas é mais adequado para as pessoas do que um modelo de serviços partilhados. Mas agora temos equipas que resolvem a maioria dos seus problemas sozinhas e monitorizam o seu próprio desempenho."

Ele queria saber qual seria o seu papel neste novo ambiente auto-organizado.

A função dos gestores intermédios em empresas que seguem o modelo de "Scientific Management" (Taylorismo) gira principalmente em torno do desempenho e eficiência dos colaboradores. Ao Taylorismo é atribuída grande parte do aumento de produtividade do século XX. No entanto, é menos adequado para a criação de produtos modernos e baseados em conhecimento.

Como muda então o papel da gestão intermédia com a introdução do Scrum?

Após uma breve discussão, John decidiu que podia contribuir atuando como mentor e comunicador para as suas equipas, mostrando-lhes o que é necessário do lado da empresa, e mostrando à empresa que as suas equipas podem satisfazer essas necessidades.

2) Como lidas com os teus melhores colaboradores quando não querem embarcar nesta jornada?

Nem toda a gente quer trabalhar com Scrum. Muitas pessoas gostam do Scrum porque lhes permite criar um produto sobre o qual têm influência direta, e isso pode ser muito gratificante. Mas nem todos vão sentir o mesmo.

Exemplo: A estrela irritada

Jack era a estrela da sua equipa e fazia questão de que todos soubessem. Quando a equipa se aproximava de um prazo, Jack trabalhava frequentemente 80 horas por semana para que a equipa atingisse o seu objetivo. Muitas vezes ainda estava no escritório às 22:00 e até enviava emails à direção ao fim de semana. A gestão adorava-o!

No entanto, a qualidade do seu trabalho era questionável. Produzia muito código que não funcionava e exigia revisões significativas. Depois de mais uma noite em claro no escritório, os outros membros da equipa passavam dias a corrigir erros e a integrar o seu código.

Tentaram explicar a Jack que o seu comportamento afetava toda a equipa – mas ele não quis ouvir e disse: "resolvam isso com a gestão."

A situação mudou quando o Scrum foi introduzido nesta equipa. O progresso e a transparência na equipa eram discutidos todos os dias durante o Daily Scrum – o progresso diário era assim constantemente medido pela equipa. Como a equipa podia decidir por si mesma quanto trabalho completaria numa iteração, conseguiam trabalhar a um ritmo mais sustentável ao longo de todo o projeto.

Durante uma retrospetiva, a equipa questionou a criação de código não totalmente testado, que roubava tempo a toda a equipa.

Jack não reagiu bem à introdução do Scrum. A boa transparência no Daily Scrum destacou claramente que Jack não entregava código regularmente, mas adiava o trabalho até ao último dia do Sprint. Quando a equipa apresentou sugestões para resolver o problema, Jack queixou-se de microgestão.

Ele não conseguia trabalhar a um ritmo constante e sustentável, e em vez de se focar no maior valor para o cliente, queixava-se de que o seu trabalho era "aborrecido" ou "não era um desafio".

Quando a equipa se comprometeu durante uma Retrospetiva a melhorar a qualidade do código através de testes regulares, Jack ameaçou deixar a equipa e até a empresa. Cinco Sprints após a introdução do Scrum, Jack deixou a empresa voluntariamente. O desempenho da equipa melhorou continuamente e três anos depois ainda produziam um produto de alta qualidade.

Na introdução do Agile, as empresas precisam de pensar no que acontecerá se os seus melhores colaboradores não quiserem trabalhar numa Scrum Team. Deixá-los-ias ir? Ou devem ficar na empresa e possivelmente perturbar outras Scrum Teams? Se estiveres disposto a deixá-los ir, como justificas essa decisão?

3) Que mecanismos vais usar para provocar mudanças de comportamento?

O Scrum requer mudanças de comportamento; isso inclui auto-organização, maior colaboração e transparência. Mudar comportamentos é extremamente difícil, especialmente para colaboradores de longa data que foram treinados para se comportar de determinada maneira. Agora que a mudança é necessária, como garantes que ela realmente acontece?

A formação contínua desempenha aqui um papel importante.

Como líder na gestão, podes apoiar os colaboradores com formações, coaching e conferências e ajudá-los a compreender e aplicar os métodos modernos de desenvolvimento de software. E ao demonstrar compromisso com os colaboradores, a moral e satisfação dos empregados e da empresa podem melhorar.

Uma parte essencial desta mudança de comportamento tem a ver com a confiança na equipa. Se trabalho com alguém e essa pessoa compreende o meu trabalho, isso é um risco para a minha avaliação de desempenho? É um risco para o meu emprego? Como se constrói confiança quando uma das duas perguntas pode ser respondida com "Sim"?

Uma abordagem comum é mudar as responsabilidades e métricas pelas quais os colaboradores são avaliados. Para promover comportamento cooperativo, dá-se mais peso ao trabalho em equipa do que ao desempenho individual. Isso pode ser feito através de feedback baseado na equipa ou 360°.

Dar menos valor ao desempenho individual questiona as responsabilidades individuais. Ninguém quer ser responsável por uma área específica se for avaliado pelo desempenho de toda a equipa. Por isso, os membros das Scrum Teams devem naturalmente receber responsabilidade por diferentes áreas. Isso significa que devem entregar parte de um produto potencialmente entregável em cada Sprint.

Isto pode parecer insignificante, mas tem grandes implicações na forma como uma empresa opera. Como afeta a tua estrutura organizacional se as equipas são responsáveis por trabalhar em várias áreas temáticas diferentes?

4) O que vai pensar o departamento de suporte sobre as mudanças provocadas pelo Scrum?

O Scrum é introduzido na maioria dos casos nas organizações através de equipas de desenvolvimento de software. As equipas de suporte e arquitetura raramente são consideradas antecipadamente. Isso acontece porque muitas organizações assumem que "Scrum é algo que os programadores fazem".

Mas a verdade é que o Scrum definitivamente também afeta outras equipas. Como vão reagir as equipas de suporte, por exemplo, quando há pontos de fricção com as Scrum Teams? Como serão resolvidos esses problemas?

Exemplo: Desacordos entre diferentes departamentos

Sarah era uma arquiteta sénior de Java Messaging Service (JMS) e responsável pela visão empresarial de um Enterprise Service Bus (ESB). Ela estava cada vez mais frustrada porque as Scrum Teams "ignoravam as diretrizes da empresa, contornando o ESB ou adicionando novas funcionalidades que não estavam alinhadas com a estratégia da empresa".

Quando lhe perguntaram porque achava que as equipas se comportavam assim, ela disse que as equipas precisavam de mais disciplina e melhor formação sobre a estratégia ESB. E depois acrescentou: "mas talvez também não estejamos a satisfazer as necessidades deles."

Após mais discussão, Sarah decidiu que seria melhor juntar-se a uma Scrum Team para compreender os seus desafios e ajudá-los a compreender melhor os objetivos da empresa.

5) Quanto está a empresa disposta a gastar nesta transformação? E que valor será entregue por esse esforço?

Poucas empresas têm antecipadamente uma ideia clara de quanto vão ganhar aproximadamente com o Agile. Há pouca informação disponível sobre quanto retorno se pode esperar. No entanto, há evidências constantes de que com o Scrum se conseguem lançamentos mais frequentes, melhor qualidade do produto e contacto mais direto com os clientes.

Uma boa solução para isto é um orçamento anual fixo para formação e coaching contínuos dos colaboradores. Isto torna-se problemático, no entanto, quando a introdução do Scrum avança mais rapidamente do que o orçamento permite. Também é difícil de justificar quando não se consegue dizer claramente quanto retorno será gerado.

Uma solução melhor seria medir algumas métricas importantes, como por exemplo:

• Receita por colaborador
• Satisfação do cliente
• Satisfação dos colaboradores
  Quando os líderes observam se estas métricas melhoram com o Scrum, podem ver quão eficaz é a introdução do Scrum e se algo precisa de ser mudado.

No entanto, há algumas coisas interessantes nesta abordagem que vale a pena destacar:

Primeiro, este método é independente do framework utilizado e também poderia medir o desempenho de uma empresa que não trabalha com Agile. Segundo, podes descobrir que o Scrum não é a melhor abordagem para a tua empresa ou que existem frameworks mais eficazes do que o Scrum. Isso é raro, mas claro que é possível.

Esta mesma abordagem de medição foi recentemente adotada por Ken Schwaber no seu "Evidence-Based Management" (gestão baseada em evidências). Ainda é cedo para dizer que impacto esta abordagem terá no desenvolvimento de software, mas é uma solução muito interessante e tem o potencial de fornecer às empresas provas concretas da sua melhoria.

A conclusão

Introduzir o Scrum não é algo que deva ser feito de ânimo leve. Há riscos tanto para a organização como para as pessoas individuais. Quando compreendes as perguntas que as pessoas fazem, consegues compreender melhor as suas motivações, medos e dúvidas. E com esse conhecimento podes formar uma abordagem muito mais abrangente que responde às necessidades da empresa e dos colaboradores.

"A capacidade de pensar logicamente é uma das coisas que nos torna humanos. Num mundo de informação omnipresente e ferramentas de análise sofisticadas, no entanto, a lógica por si só não é suficiente. O que vai destacar as pessoas bem-sucedidas é a sua capacidade de se colocar no lugar dos outros, construir relações e cuidar dos outros."
– Daniel H. Pink, autor bestseller de Drive

(Anmerkung: Dies ist ein Gastbeitrag von Scrum Trainer und Coach Kane Mar, dem Gründer von Scrumology.com und Scrum101.com.) Este texto vem do blog da Openview e foi traduzido por nós para português.