À medida que as organizações avançam com as suas soluções de software do ambiente local para a computação em nuvem, frequentemente estabelecem o propósito de se tornarem mais “ágeis”. Este objetivo, idealmente, deveria abranger toda a estrutura empresarial, em todas as áreas e simultaneamente.
A reformulação dos processos poderia ser alcançada com relativa facilidade, pelo menos em teoria. É possível definir os encontros de scrum e atribuir novas funções aos colaboradores, como scrum masters, product owners, gestores de entrega e membros de equipas scrum.
Também é possível implementar ferramentas como Jira, Azure ADO e quadros Miro, e torná-las de uso obrigatório. Mas o que acontece com os processos que conectam essas ferramentas? E a transformação das mentalidades, comportamentos e métodos de trabalho das pessoas? É evidente que essas mudanças não ocorrerão de forma suave nem rápida. Vamos explorar as razões por trás disso.
O que é uma iniciativa de transformação de entregas e por que as empresas a adotam?
Uma grande parte das empresas atualmente ainda opera sob o modelo de entrega em cascata, que se caracteriza por:
- Primeiramente, o planeamento do objetivo final ou produto, juntamente com uma estimativa dos custos envolvidos.
- Em seguida, o início da fase de levantamento de requisitos, onde se detalham todos os aspectos do produto final, com debates, questionamentos e a busca por consensos.
- Posteriormente, a elaboração de um orçamento completo e a confirmação das expectativas financeiras.
- O desenvolvimento da solução, com reuniões com as partes interessadas, criação de documentos e a aprovação final do projeto funcional e técnico.
- A implementação da solução, que inclui o desenvolvimento completo do produto.
- A fase de testes, com testes unitários, de sistema, funcionais, de integração, de desempenho, de regressão e de aceitação do usuário, entre outros, acompanhados pela documentação e aprovação das partes interessadas.
- A implantação da solução no ambiente de produção, onde os usuários finais começam a utilizar o produto.
- A fase de suporte, durante a qual a equipa de desenvolvimento corrige quaisquer erros identificados na solução.
Todo este processo pode durar de meses a anos, e os resultados só são visíveis no final do processo. Após a longa espera, chega o momento da verdade. Se durante esse tempo houver alterações e o produto final não corresponder às expectativas, surge um pedido de alteração, o que implica reabrir o projeto, retrabalhar e reaprovar, prolongando o cronograma.
É evidente que este modelo não é ágil. Qualquer alteração implica reiniciar todo o processo.
A Transição para o Modelo Ágil
Como podemos superar esta situação e adotar uma abordagem ágil? As pessoas trabalham no modelo em cascata há muito tempo, com funções e responsabilidades com as quais se sentem confortáveis, e hesitam em abandonar o status quo. A principal razão é que a mudança pode significar a perda de parte do poder que detinham anteriormente.
Esta é a principal razão pela qual este tipo de transformação gera uma forte resistência por parte das pessoas envolvidas.
#1. Reestruturação da Equipa
O primeiro passo, e relativamente mais simples, é a reorganização das pessoas em equipas scrum, dividindo-as por áreas funcionais ou qualquer outra divisão lógica.
Embora a divisão ocorra sem grandes problemas, as dificuldades começam quando se percebe que as pessoas ainda estão presas às estruturas originais. Mesmo integradas nas novas equipas scrum, continuam a operar na antiga configuração, pois as suas responsabilidades não foram redefinidas no processo de reestruturação da equipa. A liderança está mais focada no que deve ser iniciado, e não no que precisa ser finalizado.
Assim, acabamos com uma equipa scrum que não é totalmente dedicada, mas sim um grupo de pessoas com mais trabalho. Não há tempo suficiente para o trabalho da equipa scrum, como a gestão espera. Ao mesmo tempo, espera-se que as pessoas concluam as suas tarefas originais e as novas dentro das equipas scrum. Esta configuração está destinada ao fracasso desde o início.
#2. Agendamento das Cerimónias Scrum
Ordenar que as equipas agendem diversas reuniões regulares (cerimónias de sprint) é fácil de definir e implementar, pelo menos se as equipas não forem compostas por pessoas em mais de três fusos horários diferentes, o que é comum.
O problema surge quando as pessoas não participam regularmente nessas cerimónias. Dependendo de quem falta e com que frequência, isto pode levar a vários tipos de problemas. Por exemplo:
- Se os proprietários do produto não estiverem presentes nas reuniões de planeamento e refinamento, a equipa não terá histórias para desenvolver ou a descrição das histórias será tão vaga que o resto da equipa não conseguirá começar a trabalhar.
- Se os scrum masters não participarem, a equipa perderá a orquestração básica do scrum e poderá perder o rumo.
- Se os membros da equipa de desenvolvimento faltarem com frequência, terão dificuldades em sincronizar uns com os outros, dificultando a comunicação interna e exigindo mais reuniões para atualizar a todos, o que consome mais tempo da equipa.
Em última análise, a ausência nas cerimónias nem sempre é culpa das pessoas, mas sim da configuração que impede a participação devido a tarefas anteriores paralelas.
#3. Estabilidade da Equipa
Uma equipa scrum com estrutura e cerimónias definidas, mas sem estabilidade ao longo do tempo (pelo menos seis meses, idealmente um ano) não conseguirá evoluir e melhorar. É improvável que se torne uma equipa scrum totalmente independente e capaz de gerir os sprints com normalidade, pois será necessário educar e integrar continuamente novos membros na mentalidade e nos processos scrum. Este é um problema que gera muita exaustão.
Este problema é frequentemente subestimado pela liderança da empresa, que se refere às equipas como “recursos” e planeia a sua “utilização” de trimestre a trimestre, um caminho direto para o fracasso.
#4. Novas Funções para as Mesmas Pessoas
Outra barreira é a realocação de pessoas para novas funções diferentes. Aqueles que antes geriam equipas com total poder podem agora assumir o papel de Product Owners. Embora seja uma posição forte numa equipa scrum, pode ser vista como menos influente em comparação com a configuração anterior.
Os product owners têm agora de se coordenar com o scrum master ou com os gestores de programa. Embora ainda sejam responsáveis pelo conteúdo, têm menos controlo sobre os processos de entrega. Esta situação exige que abdiquem de algumas responsabilidades anteriores, o que dificulta a aceitação.
#5. Métodos de Trabalho
Este é um tema recorrente: a necessidade de adotar novas formas de trabalho para nos mantermos relevantes num mercado em constante evolução onde a agilidade é fundamental. Mas o que significa exatamente “novas formas de trabalhar”?
Para a administração, isto significa conseguir mais resultados em menos tempo. Após a configuração das equipas scrum, espera-se que cada membro apresente resultados incrementais documentados diariamente. Caso contrário, a liderança questionará a eficácia do processo ágil.
De repente, a liderança espera que cada hora seja aproveitada ao máximo e que as equipas não tenham tempo de inatividade, apenas porque alguns processos diários foram modificados. Esta é a definição de “novas formas de trabalhar” na perspetiva da liderança.
Esta expectativa não se baseia na realidade. É irrealista esperar que as pessoas trabalhem mais no mesmo período de tempo, apenas porque alguns processos mudaram. Embora alguns possam conseguir fazê-lo, o grupo torna-se menor ao sobrecarregar as pessoas com mais tarefas simultaneamente.
Diferença entre o Objetivo e a Realidade
A descrição do objetivo final geralmente faz muito sentido, com os seguintes princípios:
- Equipas scrum estáveis, com backlogs independentes e KPIs e OKRs claros.
- Product owners a desenvolver roteiros sólidos e a planear o conteúdo prioritário para entrega em prazos definidos.
- Conteúdo do backlog definido, com as funcionalidades relevantes detalhadas antes do início do trabalho.
- Processos de teste confiáveis, executados em paralelo com o trabalho de desenvolvimento regular.
- Lançamentos regulares para produção, pelo menos uma vez por mês, ou de preferência após cada sprint.
- Monitorização de riscos e problemas, e comunicação entre as diferentes equipas scrum em caso de dependências.
No entanto, na realidade, nenhum dos pontos acima é fácil de alcançar:
- As equipas scrum são formadas, mas mudam constantemente, obrigando a um investimento contínuo na formação e integração das equipas nos processos scrum. Os roteiros são alterados ou cancelados.
- Os proprietários dos produtos não têm uma ideia clara dos detalhes do roteiro e atribuem as tarefas de criação do backlog diretamente à equipa. A equipa, por sua vez, não tem tempo para desenvolver o conteúdo, pois precisa primeiro descobrir o que desenvolver.
- Os processos de teste são manuais, exigem várias etapas e aprovações e são complexos. Isto significa que o teste não é concluído no mesmo sprint que o desenvolvimento.
- Como consequência, o lançamento para produção atrasa-se vários sprints.
- A comunicação entre as equipas scrum é caótica e ineficaz, pois cada equipa tem várias atividades para realizar em cada sprint. Os proprietários dos produtos tendem a atribuir muito conteúdo a cada sprint, o que gera stress nas equipas por não conseguirem cumprir os prazos.
Corrigindo os Erros
Com base na experiência em projetos de transformação ágil, resumo os maiores erros e ofereço algumas sugestões subjetivas sobre como superá-los.
#1. Responsabilidades Adequadas para as Funções Certas
Distribuir as responsabilidades de forma diferente da estabelecida pelo scrum/ágil conduz a iniciativa ao fracasso.
- Os product owners são responsáveis pelo conteúdo e pelo backlog. Devem garantir que as histórias do backlog estão bem definidas. Não devem ter influência nas atribuições das pessoas da equipa scrum ou nas decisões sobre o orçamento do projeto.
- Os scrum masters não têm responsabilidades sobre o conteúdo do backlog, mas sim sobre a orquestração das cerimónias e a educação da equipa na metodologia ágil. Não devem ser secretários dos product owners, mas sim proteger a equipa de desenvolvimento do product owner e das partes interessadas externas.
- Cada equipa scrum deve ter um gestor de entrega que conecte o product owner, o scrum master e a equipa de desenvolvimento, definindo processos de entrega e resolvendo riscos, problemas ou conflitos. O gestor de entrega deve decidir sobre questões de pessoal e orçamento, e criar um ambiente onde a equipa possa ter o melhor desempenho.
- A equipa de desenvolvimento deve desenvolver as histórias do backlog, auxiliando o product owner na construção do conteúdo, mas não sendo responsável pela criação do roteiro.
#2. Equipa Estável
Investir na formação da equipa é essencial. Perder esse conhecimento a cada poucos meses é uma perda de tempo.
Os primeiros cinco sprints podem ser usados como curva de aprendizagem para a equipa conhecer e praticar as atividades básicas do scrum. Após este período, o processo de melhoria contínua pode começar. Se as pessoas dentro da equipa mudam regularmente, inicia-se um ciclo constante de transferência de conhecimento e educação.
É improvável que uma equipa instável atinja o seu potencial máximo, o que leva a liderança a questionar a eficácia da transformação ágil.
Forme a equipa, invista no conhecimento, e quando a equipa estiver confiante com os novos processos, mantenha-a e desenvolva-a. Assim, inicia-se o caminho rumo à melhoria contínua.
#3. Matriz RACI
Criar e acordar uma matriz RACI (Responsável, Autorizado, Consultado, Informado) com todas as equipas antes do início do trabalho é uma boa prática que pode eliminar muita confusão.
É fundamental, especialmente no início das iniciativas de transformação. Caso contrário, as pessoas começarão a questionar quem deve fazer o quê e em que situação, especialmente nas áreas não abordadas explicitamente através da comunicação da equipa.
Segue um exemplo de matriz RACI para algumas responsabilidades. O seu projeto poderá ter uma matriz diferente:
| Tarefa | Solicitante | Líder de Entrega | Proprietário do Produto | Scrum Master | Equipa de Desenvolvimento |
| Sessões de planeamento de sprint | C/I | A/I | R | C/I | I |
| Entregar incremento de lançamento | N/A | I | A/I | C/I | R |
| Revisão de Sprint | C/I | I | R | I | C/I |
| Retrospectiva de Sprint | I | I | A/I | R | C/I |
| Refinar o Backlog | I | A/I | R | C/I | I |
Conclusão
Há muito mais para escrever sobre as várias formas e áreas em que a transformação ágil pode descarrilar. O objetivo foi apontar alguns problemas frequentes.
A iniciativa em si é uma boa ideia, mas pode rapidamente tornar-se um pesadelo se não forem seguidas algumas regras básicas. Ao usar o bom senso, tudo ficará bem. 🙂
Para saber mais, procure bons recursos de aprendizagem sobre certificação Agile.