---

O que pode causar caos e frustração antes do framework Scrum? A resposta pode surpreender você!

Para compreender melhor o impacto do framework Scrum nas práticas de engenharia de software e nos negócios, vale observar um dia na vida de um projeto de software.

Por isso, gostaria de falar brevemente sobre um projeto do passado, anterior à adoção do framework Scrum de desenvolvimento e entrega de software em nossas organizações.

Poucos dias antes de escrever estas linhas, almoçamos com um antigo colega com quem trabalhamos há quase 20 anos.

Marcus obteve sua certificação Scrum Master e certificação Scrum Product Owner pela International Scrum Institute™. Atualmente, ele trabalha como Scrum Master numa das principais empresas de software de gestão ágil de projetos.

Como Scrum Master, Marcus apoia uma equipe Scrum ágil cujos membros estão distribuídos por diferentes regiões do mundo.

Durante o almoço, Marcus reconheceu que equipes Scrum ágeis distribuídas enfrentam muitos desafios típicos. Entre os problemas que destacou na configuração de seu projeto estavam:

• Diferenças nos estilos de trabalho dos membros da equipe Scrum,
• Diferenças de fuso horário,
• Incompatibilidades culturais e
• Limitações de idioma.

Apesar dessas dificuldades, Marcus acrescentou que conduzir um projeto de software com o processo Scrum ágil é mais divertido, produtivo e enriquecedor do que trabalhar como fazíamos há 20 anos. Em comparação à época em que trabalhávamos sem os processos Scrum de desenvolvimento e entrega de software.

A declaração de Marcus foi um grande testemunho a favor do framework Scrum, vindo de um gestor, Scrum Master e Product Owner muito competente e experiente.

Obrigado, Marcus!

Depois, contamos a ele sobre um dos nossos projetos de software anteriores à adoção do framework Scrum. Tenho certeza de que muitos Scrum Masters reconhecerão experiências semelhantes em projetos realizados antes de obterem suas certificações.

No final da década de 1990, participávamos de um grupo de engenharia de software que desenvolvia, com cartões inteligentes, uma infraestrutura de chaves públicas. Os cartões inteligentes protegiam com segurança as chaves privadas dos membros da infraestrutura, enquanto as chaves públicas associadas e os certificados que as continham eram distribuídos abertamente, como sugere o nome “pública”.

Na época, esse já era um projeto de TI relativamente complexo, que exigia várias equipes interdependentes de engenharia de hardware e software. Precisávamos realizar um enorme volume de pesquisa e desenvolvimento (P&D) para construir um sistema de hardware e software plenamente funcional.

Lembre-se de que, nesse projeto, ainda não utilizávamos o conceito de produto mínimo viável (MVP) para experimentar, criar, aprender e voltar a experimentar.

Sem Scrum, criar uma infraestrutura tão sofisticada, composta por numerosos elementos de hardware e software, era um verdadeiro desafio.

Veja três grandes obstáculos que enfrentávamos sem Scrum Masters nem pessoas com certificação Scrum Master em nossas equipes.