BLOG

É possível quebrar algumas regras do Scrum e permanecer ágil?

Autora: Isabela Ferreira, PMP, PSM

Analista PMO e Scrum Master do Grupo Neoenergia/Iberdrola

Pois é… Às vezes a única saída que temos para entregar valor para nossos clientes depende da coragem de quebrar algumas regras do SCRUM e encarar o desafio imposto.

Eis o desafio: Entregar em 1 mês e 2 Sprints um Dashboard para monitoramento das operações dos serviços de campo, integrado com 4 sistemas de diferentes tecnologias – com 4 distintos fornecedores trabalhando remotamente.

Mas como assim! Como posso garantir a entrega de algum valor de um produto novo a ser construído em apenas 1 mês? Qual a ferramenta eficiente para geração de Dashboards que eu possa ter agilidade nas entregas? Esse time de desenvolvimento não tem gente demais? Afinal são 4 fornecedores… Podemos dividir o time em dois sem perder produtividade? Em um projeto de “tiro curto” como posso garantir que um time tenha produtividade trabalhando remotamente?

No início, muitas incertezas. Mas estas questões foram respondidas em uma fase anterior a execução da Sprint denominada “Design Sprint”. Foi um momento muito valioso onde a TI junto com a área de negócio interessada desenharam o protótipo do produto a ser desenvolvido, definiram regras de negócio e o Backlog do Produto. Outras iniciativas importantes da fase de Design:

  • Definição da ferramenta de Dashboard a ser utilizada e que nos traria um ganho elevado de produtividade: #Tableau;
  • Além de protótipos foi construída também a arquitetura física do banco de dados antes da execução da Sprint (opa! Uma regra quebrada. Esta prática não é nada ágil e ainda delimita o escopo da solução…. Bom, foi a única saída possível para entregar o Dashboard em 1 mês);
  • Envolvimento de pessoas da TI com bastante experiência em ferramentas de Dashboard e especificamente no Tableau;
  • Alocação de um time de alta performance, pessoas com muita experiência nos sistemas legados que devem gerar os dados para o Dashboard;

Após mitigar os riscos na fase de Design Sprint em relação ao curto período de desenvolvimento imposto e do escopo desconhecido, vamos falar agora de pessoas: Notaram na imagem publicada 12 participantes na reunião diária? Neste caso, aplicar os princípios ágeis incansavelmente está sendo a forma de driblar essa situação e alcançar o sucesso. A regra diz que uma Sprint deve ter time de desenvolvimento com no máximo 9 participantes para não comprometer os “times box” e a comunicação assertiva. Como em qualquer metodologia de gerenciamento de projetos a comunicação e entendimento do escopo continuam sendo os fatores críticos de sucesso, em um projeto ágil com mais de 9 participantes estes fatores se tornam a maior preocupação do projeto e a atenção deve ser redobrada principalmente do Scrum Master. Seguem as medidas tomadas:

  • Formamos pares para cada frente de trabalho (são 4 frentes correspondentes aos 4 sistemas legados). Cada desenvolvedor teria um respectivo analista funcional local mais próximo ao Product Owner, Líder técnico e Scrum Master, para facilitar o entendimento da solução, realizar testes, ser um facilitador;
  • Exigimos que o time estivesse presencial pelo menos na primeira semana e na reunião de planning. Para que? Para se conhecerem, estreitar o relacionamento dos pares: desenvolvedores e analistas funcionais, facilitar o entendimento do escopo e entendimento dos conceitos ágeis que seriam exigidos;
  • Apresentação da metodologia ágil da empresa assim como papéis e responsabilidades dos envolvidos antes da reunião de planning;
  • Uso de ferramentas para auxiliar a gestão das atividades e a comunicação entre os times de desenvolvimento tais como: #Kanban, #Scrumboard, #Trello, #Zoom, #Sharepoint, #Smartsheet, #Burndown.
  • Total disponibilidade do Product Owner para esclarecer as questões funcionais;
  • Total disponibilidade do líder técnico nas reuniões diárias e na execução da Sprint para esclarecer as questões técnicas;

Respondendo a questão se é possível quebrar algumas regras do Scrum e permanecer ágil? Sim. É possível se você cumprir todos os eventos propostos pelo framework, não ultrapassar a duração máxima desses eventos, aplicar todos os princípios ágeis e seus valores, decompor as atividades e priorizar as mais importantes, sempre com o foco na entrega de valor. Também, vai depender de um estudo preliminar para identificar todos os riscos e a viabilidade de execução do projeto junto com um plano de mitigação a ser cumprido. Vai depender da sua capacidade e agilidade de contornar os problemas que ocorrer durante as Sprints. Em resumo, o risco é alto e não é uma tarefa fácil.

No momento estamos na última Sprint e já foi apresentado na Sprint anterior parte do produto funcionando. No próximo post informarei os problemas enfrentados e o resultado dessa experiência!

Compartilhe nas Redes Sociais

Outros Artigos

Nuvem

CE | RN | PE | SE | BA | MG | SP - Telefone: (85) 3119.5969

Golden Technologia © 2018 - Todos os direitos reservados.
Termos de Uso | Política de Privacidade

Nunan