Um papo sobre algumas verdades absolutas que circulam pela internet
O Scrum pretende ser uma estrutura simples, mas suficiente para a entrega de produtos complexos. Scrum não é uma solução de tamanho único, uma bala de prata (salve Jefferson Henrique) ou uma metodologia completa. A ideia do Scrum foi apresentada pela primeira vez em um artigo publicado na Harvard Business Review. Mas o que revolucionou a indústria de desenvolvimento de software e iniciou o movimento foi o uso do Scrum como uma estrutura para desenvolvimento de software por Ken Schwaber e Jeff Sutherland em 1995. Desde então, o Scrum revolucionou não apenas a indústria de software, mas encontrou uso em vendas, marketing, bancário, seguros, manufatura, saúde e vários outros setores.
Pessoas que amam Scrum (não sou um deles) geralmente não sentem muito amor por projetos. É como o Lula x Bolsonaro! Várias declarações fortes ditas por aí na comunidade, de equipes Scrum como: “Scrum é sobre produtos, não projetos” ou “Projetos não tem lugar no Scrum”.
Na verdade, a realidade é que muitas organizações trabalham com “projetos”. Inclusive um dos últimos projetos que participei foi usando Scrum. O grande X da questão é o fator, de senso comum, considerado quando analisamos o que é a gestão de produto e o que é a gestão de projetos. De maneira objetiva, a gestão de produtos concentra um trabalho de sustentação, sob a lente de melhoria contínua e sem uma data fim. Já quando tratamos de projeto, o escopo bem delimitado, recursos e datas (principalmente data fim) colaboram com a visão de que o Scrum pode não ser aderente.
O Scrum Framework, que é tão amplamente utilizado na prática ágil, claramente tem um foco no produto e não no projeto. Não há gerentes de projeto no Scrum, e a responsabilidade pelo valor é investida diretamente em um Product Owner. A função de gerenciamento de projetos, tal como é, é refatorada e distribuída por esta função, o Scrum Master e, mais especialmente, os Desenvolvedores.
Projetos e o uso do Scrum
Antes de mergulhar nesse mito, é útil ter uma definição prática do que queremos dizer com “projeto”. No nosso dia-a-dia, percebi que as pessoas tendem a definir projetos como O Scrum possui um grande número de ferramentas que melhoram a colaboração e a coordenação entre as equipes e oferecem melhor visibilidade do andamento dos projetos. Ferramentas como quadros de tarefas, reuniões diárias, revisões de sprint e mais ajudam a executar sprints, alocar tarefas, acompanhar projetos e ajudar os membros da equipe e as partes interessadas a ter uma ideia melhor da alocação de recursos e cronogramas e orçamentos de conclusão do projeto
Curiosamente, o Project Management Institute (PMI) define um projeto como “um esforço temporário empreendido para criar um produto, serviço ou resultado único”. A Wikipédia a define como “Qualquer empreendimento, realizado individualmente ou em colaboração e possivelmente envolvendo pesquisa ou design, que é cuidadosamente planejado para atingir um objetivo específico”. Nenhuma das definições fixa escopo, orçamento e prazo. Nenhuma fonte específica que algo só é entregue no final ou que dura para sempre. Parece que estamos falando de coisas diferentes.
Deixando de lado as definições formais, mesmo o gerente de projeto mais empolgado vai reconhecer que fixar o orçamento, o escopo e a data de entrega de um projeto é uma abordagem muuuuuito otimista para o cenário complexo que ele possivelmente representa. Várias ferramentas Scrum disponíveis comercialmente ajudam no planejamento aprimorado, redução das chances de falha e resposta mais rápida aos riscos, garantindo assim a entrega perfeita de produtos e maior satisfação dos clientes.
E o que podemos dizer do gerenciamento de produtos?
A ideia é definir a estratégia do produto e criar roadmaps de produto em um ambiente ágil. Ele incentiva uma abordagem adaptativa ao planejamento e implementação de produtos para que as organizações possam responder rapidamente ao feedback e criar produtos que os clientes adoram.
Scrum fornece uma abordagem mais flexível do que o planejamento e desenvolvimento de software tradicional. Os produtos são construídos em pequenos incrementos, dando aos gerentes de produto a oportunidade de ajustar o plano ao longo do caminho. Aqui estão alguns dos principais benefícios do gerenciamento de produtos com Scrum:
- Aprenda com os clientes durante todo o ciclo de vida do produto
- Ajustar continuamente o roadmap de curto prazo para atender às necessidades do cliente
- Entregue valor aos clientes de forma incremental
- Responda rapidamente a requisitos novos e em mudança
- Colabore com a engenharia para entregar o trabalho rapidamente
Gerenciamento de projetos com Scrum é adequada para minha equipe?
Uma consideração importante a ser observada ao adotar o Scrum é ter uma ideia dos requisitos para o desenvolvimento do produto. Se você prevê muitas mudanças nos requisitos, o Scrum seria a melhor aposta para você, pois é flexível e permite iterações de última hora.
Os membros da equipe Scrum também devem ter um alto grau de adaptabilidade. Pode haver casos em que os membros da equipe precisem assumir várias funções ou até mesmo trocar de funções para agregar valor e atingir a meta do sprint. Profissionais que são flexíveis se sairão muito bem em uma equipe Scrum.
O que o Scrum Guide diz?
Como alguém que trabalha e estuda agilidade, em especialmente o Scrum nos dois últimos projetos, nada melhor que buscar a informação na fonte primária: o Scrum Guide 2020. Este inclusive teve algumas mudanças para a versão anterior (uma pesquisa rápida você pode conferir as mudanças, mas também posso fazer um post por aqui. Comentem se vale a pena.). Uma olhada no Guia do Scrum já oferece uma perspectiva útil para pensar sobre como os projetos podem ser entendidos dentro do Scrum Framework:
“Cada Sprint pode ser considerado um projeto com horizonte de no máximo um mês. Assim como os projetos, os Sprints são usados para realizar algo.”
Fora isso, o Scrum Guide fala especificamente sobre produtos em vez de projetos. Existe um Product Owner e um Product Backlog, não um Project Owner e um Project Backlog. Existem várias boas razões para isso:
- Os produtos são mais tangíveis. Isso os conecta mais fortemente à ideia de que você está entregando algo de valor aos usuários;
- Os produtos têm um ciclo de vida. Ninguém sabe quando um produto atingirá a maturidade ou quando será encerrado. Pode ser muito curto ou muito longo. De qualquer forma, muitos ajustes serão necessários ao longo do caminho. Isso exige que combinemos o pensamento de longo prazo com o de curto prazo. Se fizermos atalhos agora, teremos que pagar por eles mais tarde. Mas também temos que entregar algo em breve;
Não quero dizer que os projetos não agregam valor aos usuários ou incentivam atalhos. Apenas podemos apontar que ‘Produtos’ evocam uma narrativa mais produtiva, pois necessariamente estão ligados a usuários, mudança contínua e valor.
Legal, mas como eu começo?!
Segundo o Christiaan Verwijs, uma estratégia é começar com o que você tem e fazê-lo funcionar de uma forma que apoie o empirismo. Nada de inventar a roda. Quick wins podem ser a chave para mudanças que envolvem processos e cultura( Dica: história do método Kanban e o conceito Kaizen). Mas é possível sugerir algo:
- Tornar o escopo do projeto transparente no Product Backlog e alterá-lo à medida que surgem novos insights;
- Considere o que seria necessário para garantir um resultado valioso e de alta qualidade do projeto e incorpore isso em sua Definição de Pronto;
- O orçamento do projeto é o que determina quanto trabalho do Product Backlog pode ser concluído. Quando se esgotar, e quando houver valor em implementar mais, poderá ser estendido conforme necessário;
- Cada Sprint resulta em um incremento Concluído que é entregue às partes interessadas como um marco e atinge um importante objetivo de negócios. O feedback é usado para adaptar o Product Backlog conforme necessário;
- Há um Product Owner, um Scrum Master e uma Equipe de Desenvolvimento. E eles tem autonomia total sobre todas as decisões relativas ao projeto (ou parte do projeto) em que estão trabalhando;
- Crie um roadmap para o seu projeto colocando o Product Backlog de lado. Isso pode dizer em que ordem as coisas vão acontecer;
- Se houver um PMO ou Comitê com membros da diretoria, trabalhe com eles para tornar o roadmap possível. À medida que os resultados começam a fluir, a necessidade de planejamento extensivo diminuirá;
- Os gerentes de projeto podem ser um grande trunfo como parte das equipes Scrum. Desde que respeitem o Product Owner e o Scrum Master em suas funções, eles podem ajudar a coordenar com as partes interessadas, lidar com a política organizacional e remover impedimentos;
As conversas que você tiver enquanto estiver fazendo os itens acima serão muito mais produtivas do que lutar contra o uso da palavra “projeto”. Ou alegando que todos “precisam adotar uma mentalidade de produto em vez de uma mentalidade de projeto” (o que quer que isso realmente signifique).
Ao invés de se apegar ao termo ou ao mindset popular que influenciadores querem que você espalhe por aí, se preocupe sempre com seu contexto. Na última semana inclusive, em um curso de Kanban com o André Suman, aprendi que quase tudo que envolve desenvolvimento ágil precisa de contexto. Até nas respostas que parecem mais óbvias. Diante disso, queria provocar você que chegou até aqui com algumas perguntas muito mais importantes do que (projeto ou produto?):
- Como podemos garantir que nossos stakeholders estejam envolvidos desde o início do projeto?
- Como podemos usar cada Sprint para entregar um resultado tangível – o Incremento – que podemos inspecionar com as partes interessadas?
- Como podemos começar a remover os impedimentos que estão tornando isso difícil para nós?
Essas são as perguntas que importam e que provavelmente produzirão efeito imediato a mudança para uma abordagem mais orientada para o produto. Conhecer o ambiente, entender os motivadores, e sugerir mudanças colaborativas vão ser muito mais valorosas que a discussão vazia de onde o Scrum pode ser usado, baseado exclusivamente no significado das palavras produto e projeto.
Referências
- https://medium.com/the-liberators/myth-you-cant-do-projects-with-scrum-f579accfbefa
- https://www.scrum.org/resources/blog/projects-and-products-scrum
