Por que é tão difícil educar um gestor de projetos Waterfall para assumir uma funcao numa equipe de Scrum?

(Praia de Cabanas, Portugal) Muito já foi escrito neste blog sobre as vantagens da metodologia Agile. A verdade é que, no momento em que uma organização decide iniciar uma Transformação Agile, particularmente, adoptar a prática do Scrum, educar recursos pode ser um desafio aterrorizante. A experiência necessária para uma função de Scrum Master ou Product Owner, é muito diferente do que normalmente se encontra num recurso experiente atuando como gestor de projectos Waterfall.

O background de um gestor de projecto Waterfall

Em Waterfall, o principal objetivo de um gestor de projecto é entregar o projecto dentro do tempo, orçamento e qualidade previamente acordados. O projecto Waterfall segue um processo sequencial em V, partindo da fase de requisitos, e seguindo para desenvolvimento, testes, treinamento, suporte e manutenção. O gestor de projecto tem um papel de facilitador, organizando todos os recursos necessários, condições e materiais, respeitando o roadmap acordado, informando os stakeholders e sponsors do projecto, atenuando os riscos, se necessário, e desenvolvendo planos de contingência. Ele sente-se mais comprometido com o “fazer acontecer” do que com “o que é entregue”.

Eu já ouvi na minha carreira gestores de projecto Waterfall dizerem com algum orgulho: “Eu fiz um projecto SAP sem nunca ter aberto uma aplicacao SAP”. Para mim isto é completamente inconcebível…

Um gestor de projecto de Waterfall tem uma perspectiva de comprometimento temporário: ele está de passagem até ao lançamento do projecto, depois parte para outro projecto. Esta é a abordagem do projecto e não a abordagem do produto. Na abordagem do produto, temos um compromisso de longo prazo e um compromisso com o valor a ser entregue permanentemente ao cliente.

O gestor de projectos Waterfall tem o seu foco em satisfazer sponsors e stakeholders: entrega no tempo certo, escopo, orçamento e qualidade. Não observamos aqui um papel importante para usuários/utilizadores e clientes. Usuários e clientes são levados em consideração em 2 momentos diferentes:

• 1º momento: durante a fase de requisitos.
• 2º momento: durante testes, validação e aceitação do projecto, treinamento e suporte.

Neste segundo momento, os usuários/utilizadores ou clientes estão expostos a uma versão completa do produto, a um conjunto de funcionalidades. O feedback coletado é acumulado e não tão detalhado funcionalidade por funcionalidade, como no fundo se faz a cada Sprint Review.

Tenha em mente, em Waterdall, a presença do gestor de projecto nesses 2 momentos de interaçao não é obrigatória. Essas tarefas geralmente são delegadas a especialistas, nao havendo obrigatoriamente contribuição directa por parte do gestor de projecto.

Outras tarefas normalmente não consideradas pelo gestor de projectos Waterfall: retrospectiva e melhoria continua. O gestor do projecto Waterfall normalmente não organiza reuniões retrospectivas com a equipe de desenvolvimento, ele não sente como sua a responsabilidade a satisfação, a gestao de capacidade e velocidade da equipe. Tal como também não sente como sua responsabilidade ter uma atitude permanente de procurar a melhoria em tudo o que está relacionado com o produto, equipa e processos.

Qual a razao para que a experiência do gestor de projectos Waterfall não traga tanto valor para a prática Agile

Os tipos de competencias e experiências que desenvolve um gestor de projecto Waterfall sao normalmente as seguintes:

• Identifica recursos especializados necessários para executar tarefas de projecto;

• Guarda e atualiza orçamento e Roadmap;

• Regularmente requer atualizações sobre estado, riscos e dependências da equipe de implementação e resume-os em reuniões de direção para sponsors e stakeholders;

• Organiza o escalonamento de assuntos se necessário;

• Competencias de comunicação e negociação são fundamentais: Organiza reuniões e modera discussoes em diferentes níveis hierárquicos: a nível inferior com especialistas, de nível superior para atualização executiva e escalonamento de problemas.

Essas competencias são apreciadas em qualquer projecto, mas em Agile as equipes e as funcoes estao organizadas de uma forma diferente e parte das tarefas descritas acima são distribuídas por diferentes funcoes.

Uma equipe Agile é autoorganizada, cada membro da equipe conhece sua área de especialização e assume responsabilidade de implementacao voluntariamente sobre as stories ou tarefas que acredita ser competente para se comprometer com a entrega. Com o tempo, a equipe geralmente seleciona “naturalmente” quem é o expert no que: quem é o test manager, o arquitecto, o programador backend, etc.

A atribuição de stories é feita pelo Scrum Master ou por cada membro da equipe, reconhecendo suas áreas de especialização individuais, assumindo espontaneamente sua própria responsabilidade.

Escalonamento, mitigação de riscos e o desbloqueio de impedimentos é uma tarefa Scrum Master. Mas é também tarefa do Scrum Master, procurar a melhoria continua de desempenho, motivação e satisfação da equipe, o que nunca observamos num gestor de projecto Waterfall.

O Product Owner traz a visão do produto, funcionalidades, é a voz do cliente. Tráz essencialmente requisitos, comprometimento para construir o melhor produto, consolidando a estratégia em valor para o cliente.

Como podem ver, esta é uma mudanca radical de mindset entre os actores da metodologia Waterfall e Agile mas, essencialmente, trata-se de um grande desafio para um gestor do projecto da Waterfall especializar-se tecnicamente e comprometer-se com o produto e os utilizadores mais do que com os stackholders.