Marcel Fleming

 

“Aqueles que não podem lembrar o passado estão condenados a repeti-lo”.

George Santayana, filósofo e poeta espanhol.

 

Às vezes, nem me dou conta disso, mas já se vão por aí quase 30 anos de carreira, começando como analista/programador, analista de sistemas, dono de software-house, analista de negócio, gerente de projetos.

Na área de TI (não sei dizer das outras), de vez em quando surge alguma nova tecnologia ou método que passa a ser considerado a panaceia para todos os males de projetos (principalmente a malfadada, mal compreendida, mal interpretada disciplina da Gestão de Requisitos).

Imediatamente surgem os radicais de extrema esquerda (os favoráveis à novidade) e os de extrema direita (os contrários à novidade). E claro, há sempre o pessoal de centro, centro-esquerda, centro-direita…  

A briguinha do momento (já há algum tempo) é “Ágil vs waterfall”… com seus vários desdobramentos mais específicos como “Scrum vs PMBoK (r)”.

Não vou nem entrar no mérito dos enganos conceituais que muitos cometem, sendo o mais comum deles chamar PMBoK de “metodologia” (argh…) – só isso já vale um post.

Escreverei sobre os erros que tenho visto na adoção de métodos ágeis, em especial o framework  Scrum.  Vamos lá, joguinho dos Sete Erros.

 

1-      Sair usando a metodogia sem se preparar.

2-      Começar projeto sem escopo definido.

3-      Achar que nenhum planejamento é necessário.

4-      Confundir “seguir a metodologia” com “aproveitar o que a metodologia traz de bom”.

5-      Não rever a forma de contratação.

6-      Achar que Scrum Master é o mesmo que Gerente de Projetos.

7-      Não praticar a essência do Scrum: rituais (meetings), gestão coerente do “Product Backlog” e alocação das pessoas certas aos papeis de “Product Owner” e “Scrum Master”.

 

Hoje vou falar do Erro n.1. Nos próximos dias, postarei os demais erros…

Erro 1: Sair usando a metodologia sem se preparar.

Migrar de um processo tradicional (baseado em práticas do PMBoK, RUP, Prince2 ou outro modelo) para um modelo Scrum-like tem que ser entendido, antes de qualquer coisa, como um processo de mudança cultural. Não basta a equipe entender o funcionamento dos elementos Scrum, mas entender que não só o tradicional GP, ou o usuário da área de negócio devem se adequar ao novo modelo. A equipe (e principalmente ela) também terá que se adequar.

Vejo muita gente falando de “boca cheia” a respeito de equipes “autogerenciadas”, mas não param para pensar que numa equipe assim, a qualidade do trabalho, o grau de conhecimento, o nível de comprometimento e as atitudes de cada membro da equipe estarão expostos, escancarados para os demais membros, para o Product Owner e para o Scrum Master.

Aquele “geniozinho” que acha que sua opinião é sempre a melhor, ou que não gosta que opinem sobre seu trabalho, ou não gosta que outros vejam que ele está tendo uma dificuldade técnica, terá que um reset em seu comportamento.

Na outra ponta, aquele usuário que nunca se compromete com nada, que não se compromete a definir o que quer e a validar o que pediu, que fica sempre na defensiva culpando “aquele pessoal de TI”, terá que entender que no Scrum ele é um parte essencial da equipe, corresponsável pelo produto e, portanto, terá que se dedicar de fato ao projeto.

Assim, a empresa tem que escolher a dedo um projeto adequado, equipe adequada do ponto de vista técnico e comportamental (RH, help us!), capacitar a equipe, o Scrum Master e um candidato a Product Owner antes de iniciar um projeto.

De preferência, não só através de curso, mas expondo-os como observadores a situações reais de outros projetos bem sucedidos, preparando-os para os tipos de situações que enfrentarão, possivelmente, em um projeto Scrum.

Os executivos envolvidos no projeto também são parte dessa mudança cultural. É preciso que eles entendam que a maneira como se mede o progresso e o sucesso de um projeto Scrum é diferente de um projeto tradicional. Em vez de focarem em datas e percentual de progresso, eles devem aprender a enxergar o valor para a organização de cada entrega parcial.

Conheço o caso de uma empresa reconhecida no mercado, que foi uma das pioneiras na adoção de Scrum. Antes dela adotar o método para todos os seus projetos, passou mais de 2 anos fazendo diversos projetos-piloto com um cliente só, até entender bem como o processo deveria funcionar.

Naquela época havia muito menos casos no mercado em que a empresa pudesse se espelhar. Hoje, não seria necessário passar tanto tempo “pilotando” o processo. De qualquer forma, a ideia de pilotar o processo, dentro de uma situação de menor risco, com um cliente mais “próximo”, com uma equipe menor continua valendo.

Infelizmente, como sempre acontece quando um novo método surge, alguém diz a um diretor ou gerente que com essa nova metodologia, os projetos serão entregues com mais rapidez e qualidade, utilizando menos gente (portanto com menos custo), montam uma apresentação em PPT (lembrem-se: PPT aceita tudo), pagam um curso de Scrum (online, de preferência) para algumas pessoas, providenciam post-it e quadro branco e começam um projeto Scrum…

No caso do Scrum, a simplicidade da ideia e das ferramentas me parece ser um convite sedutor para “sair fazendo Scrum”.

Aí, na primeira reunião com a equipe, aquela de kickoff – perdoem-me meu conservadorismo, mas todo projeto TEM que ter uma reunião de kickoff – o Diretor pergunta: “ué, mas não tem um cronograma?”….