Café com o Scrum Master Um bate papo sobre, Scrum, Produtos, Projetos e… Agile Project Manager
Olá Pessoas,
Antes de mais nada eu gostaria de agradecer o WordPress, por ceder este espaço para que a gente possa, em alto nível, discutir a gestão de projetos no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)
No mês passado, participei de um workshop (muito interessante diga-se) voltado para concepção enxuta de produtos, imersos em ambientes adaptativos. Foi uma experiência bastante agregadora pois, além da experiência trocada entre os participantes e das técnicas que aprendi e revisitei no WS, pude rever alguns amigos do mundo ágil e fortalecer o networking.
Foram 8 horas bastante produtivas onde, entre uma pausa e outra para o café, evoluímos uma hipótese a qual se expandiu da concepção da hipótese (MVP, visão, objetivos e etc) até um canvas que definiu o escopo do produto a ser desenvolvido. E numa dessas “pausas pro café”, aconteceu um episódio bastante enriquecedor.
Em meio a um bate papo descontraído e alguns convites para conexão no LinkedIn, fui, cordialmente “advertido”, por um colega que lá estava, acerca da utilização do termo Agile Project Manager verificada por ele, em uma de minhas experiências. Na visão respeitosa deste colega, a denominação Agile Project Manager não é coerente aos métodos ágeis, uma vez que tais métodos tem como foco principal a construção de produtos complexos e não o gerenciamento de projetos, não fazendo sentido, portanto, um gerente de projetos ser ágil.
Como discordei (e discordo) peremptoriamente desta visão e, porque não dizer, desta divisão brusca e nonsense entre produtos e projetos… e, como este colega e eu, apresentamos, modéstia a parte, argumentos bem fundamentados no debate que contou, inclusive, com a “audiência” ativa de alguns participantes que se entusiamaram pelo tema; resolvi estruturar minha visão sobre este assunto neste singelo post. 😀
Scrum Guide
Se a ideia é discutir se o Scrum é para produtos, projetos ou ambos, nada mais justo e prudente que recorrermos ao Scrum guide — o corpo de conhecimento do Scrum — para sanar eventuais dúvidas remanescentes e/ou fundamentar esta ou aquela tese.
Scrum Guide
Segundo o guia, o framework Scrum foi criado para desenvolver e manter produtos complexos imersos em ambientes complexos. Até aqui está claro pra mim que o foco é sim o produto, e não o projeto. Entretanto, pergunto aos meus botões, é possível desenvolver e manter produtos complexos (principalmente os produtos de software) sem que haja, como pano de fundo, um sólido projeto, com começo, meio e fim, estruturado com práticas e técnicas necessárias para garantir, desta feita, a construção e a entrega do valor de negócio?
Mais além… se o Scrum guide apresenta, em suas 18 páginas, um conjunto de regras, que vis à vis a outros guias, também nos prescreve um planejamento, uma reunião diária, um entregável e uma melhoria contínua… porque não podemos afirmar, então, que o Scrum é sim uma ferramenta extremamente poderosa e eficiente que tem auxiliado no gerenciamento de diversos projetos que visam construir produtos complexos? Aqui está posta uma reflexão para ser feita como lição de casa. 
Em época de rivalidade aflorada — ágil vs cascata, java vs .net, coxinhas vs mortadelas — o encaminhamento destas polêmicas se torna compreensível, porque há uma necessidade quase que incontrolável de ser diferente a tudo que aí está e, modernamente, os “deuses” da agilidade têm se mostrado extremamente eficientes nesta tarefa.
PMBOK® Guide
Por falar em gerenciamento de projetos, repare na definição do que é projeto segundo o PMBOK® guide:
PMBOK® Guide 6ª Edição
Se projetos servem para criar produtos, e produtos precisam de projetos para aumentar suas chances de sucesso, pra mim não faz o menor sentido levantarmos um muro entre produtos e projetos. Dito isto, é preciso registrar que o ágil tem como foco principal a entrega contínua de valor… e por intermédio dos ciclos frequentes de feedbacks, os métodos ágeis conseguem agregar, incrementalmente, alto valor de negócio. Isto é importante pontuar porque, existem projetos (não ágeis) que — pelo simples fato de terem cumprido as restrições de escopo, prazo e custo, mesmo entregando produtos com baixo (ou nenhum) valor de negócio — são considerados de sucesso, apenas por terem mantido aderência entre o planejado e o realizado.
Como o Ken Schwaber poderia enriquecer o debate?
Se Gerente de Projetos Ágeis, ou Agile Project Manager fosse incoerente aos métodos ágeis… não soaria meio estranho Ken Schwaber — o pai da criança — escrever um livro de nome Agile Project Management with Scrum? Ou ainda Jim Highsmith — um dos signatários do manifesto ágil — ter escrito um livro bastante conhecido, que já está em sua segunda edição, de nome Agile Project Management? Ora, se no título do livro do Schwaber, é possível fazer gerenciamento de projetos ágeis com Scrum, porque então não poderíamos afirmar que o Scrum também é uma ferramenta para gerenciamento de projetos? Compreende? Por outro lado, a salada fica ainda mais temperada quando o PMBOK®, em sua 6ª edição, passa a referenciar alguns estilos de liderança que o gerente de projetos pode e deve exercer… sendo uma delas justamente o estilo de liderança servidora. Hum? Como assim? Liderança servidora não é coisa de Scrum Master? 😕
Nestes termos, porque então polemizar com o nome de um cargo? Porque um gerente de projetos não poderia ser ágil? O que impediria um gerente de projetos de ser ágil… se ele resolvesse refletir, internarlizar e por em prática os 12 princípios e o manifesto ágil?
Em particular, ao longo de minhas experiências, vi alguns gerentes de projetos que exerciam com maestria a liderança servidora, auxiliando, inclusive, tecnicamente, o time de desenvolvimento quando era preciso… e por outro lado já vi alguns Scrum Masters que o time, nas conversas de bastidores, se referia a eles como Scrum Monster ou Scroto Master. Pois é, percebe como a vida é dura?! 🙂
Como o Jeff Sutherland poderia enriquecer o debate?
No livro Scrum – The Art of Doing Twice the Work in Half the Time, Jeff Sutherland, um dos criadores do Scrum e chairman da Scrum Alliance, escreveu:
Scrum – The Art of Doing Twice the Work in Half the Time
“Scrum tem se tornado muito bem sucedido no gerenciamento de projetos de software e hardware no Vale do Silício…”. — Veja que aqui temos novamente a confirmação de que o framework pode e deve ser utilizado para gerenciar projetos, que visam construir produtos complexos. Note que é extremamente ilógico fazer uma desconexão entre uma coisa e outra… produtos e projetos devem sim caminhar juntos até porque, projetos estrategicamente bem concebidos, muito provavelmente resultarão em produtos valorosos. Ou será que produtos fantásticos como um aplicativo que te conecta a um motorista particular… ou ainda um outro, que lista na tela de um smartphone residências e cômodos para locação, foram desenvolvidos do nada? Sem um projeto? Sem uma pesquisa de mercado? Sem uma orçamentação? Sem um mapeamento de risco? Ou enfim… sem uma definição do que é valor de negócio? Muito provavelmente não.
Por fim caros…. se nos pusermos a analisar, seja de qual ângulo for, com um olhar cuidadoso e não apaixonado, constataremos que existem N práticas de gerenciamento de projetos contidas no Scrum guide, nos permitindo, portanto, afirmar tranquilamente que o Scrum é tanto para produtos, quanto para projetos.
Saudações. Ψ
Em tempo: no dia 07/11 (terça-feira) às 11:00AM EST (16h UTC), Jeff Sutherland e Ken Schwaber farão um webinar gratuito para apresentar as últimas atualizações do Scrum guide. Mais informações neste link.
Café com o Scrum Master 
Pingback: Um bate papo sobre, Scrum, Produtos, Projetos e… Agile Project Manager | Café com o Scrum Master – Blog pessoal
Pedro, muito bom.
Parabens pelo artigo e sintetização do assunto.
Ele me lembrou muito um artigo do Jorge Audy, que demonstra um posicionamento controverso de alguns pessoas da comunidade agil.
CurtirCurtido por 1 pessoa