Jogos de inovação - Parte 1, Podando a árvore do produto

English

Recentemente tenho buscado mais ferramentas para tentar ajudar na parte que o Scrum simplesmente trata como "Backlog do Produto" (nenhum demérito, afinal o Scrum é apenas um framework).

Como este Backlog deve ser gerido e priorizado? Como as histórias chegam lá? E se o Product Owner (PO) tiver que atender a vários stakeholders disputando um recurso obviamente finito que é o desenvolvimento, como ele deve fazer?

A idéia dos Jogos de Inovação é ajudar a resolver estes problemas. São maneiras lúdicas de se gerar insumos sobre um produto ou serviço.

Podar a árvore do produto (Prune the Product Tree)

Podar a árvore do produto

Visualizar o produto de forma linear e com representações inorgânicas de road maps parece mostrar o crescimento do produto como algo linear no decorrer do tempo, o que não parece representar a realidade. 

Este jogo melhora o entendimento de que o produto deve crescer de uma forma planejada, permitindo aos stakeholders modelar todos os aspectos do produto e não apenas dar feedback sobre um conjunto de funcionalidades em um road map.
Quando podamos uma árvore normalmente o objetivo é controlar o seu crescimento para que o mesmo seja equilibrado, para que a árvore seja mais saudável e assim possa gerar frutos de melhor qualidade. 

O principal é entender este processo de poda não como um "corte", mas sim como uma "modelagem". Esta metáfora é usada no jogo para ajudar a criar o produto que os stakeholders desejam.

O Jogo

Primeiro é necessário um quadro branco, flip-chart ou qualquer outro lugar em que se possa desenhar uma árvore de um tamanho razoável.

Represente as áreas de funcionalidade do sistema como galhos da árvore e as raízes como o que deveria dar suporte a toda árvore (suporte e infraestrutura). Cada release pode ser representada na copa da árvore com uma tonalidade diferente de verde, por exemplo. Representa-se na parte mais interna o que existe hoje no produto, e nas camadas mais externas, o que precisa ser feito no curto, médio e longo prazo (ver imagem).

Junte um grupo pequeno de stakeholders (de 4 a 15), pois grupos pequenos tendem a se auto-organizar de forma a gerar resultados melhores.

Recorte cartões em forma de folhas/frutos (se você estiver sem paciência, post-its servem) e peça aos stakeholders para escrever as funcionalidades desejadas neles e colar em alguma parte da árvore (você também pode imprimir algumas folhas com sugestões). Isto deve mostrar como seria, a princípio, o crescimento da árvore na próxima fase.

Incentive a discussão entre os stakeholders sobre prós e contras de cada funcionalidade, onde elas deveriam ser colocadas dentro da árvore e ainda se deveriam fazer parte desta release ou de uma próxima.

Peça aos participantes para além de inser, também retirar folhas de versões anteriores, significando funcionalidades que deveriam ser eliminadas do sistema. (Na figura, são as três folhas na parte verde escuro da árvore)

Repare se o crescimento está acontecendo de forma balanceada, pois pode haver algum galho que tenha recebido a maior parte do crescimento, ou então, algum galho anteriormente fraco está crescendo com mais vigor. Repare se as funcionalidades estão bem distribuídas entre curto, médio e longo prazo. Repare também se as raízes são fortes suficientes para aguentar o crescimento do restante da árvore.

Após a sessão, se possível, exponha o resultado em algum lugar de grande visibilidade. É provável que surjam ideias e/ou restrições mais tarde.

Variações

Algumas variações deste jogo não usam as raízes, e cartões no chão (onde na versão tradicional haveriam as raízes) representam funcionalidades consideradas de pouca importância.

Outra variação interessante é criar uma nuvem de dúvida, que serve como uma espécie de "parking lot" para funcionalidades pouco compreendidas ou que os stakeholders não sabem como usar.

Por que funciona?

As funcionalidades variam muito em importância e tendemos a querer colocar nossos esforços nas mais importantes, afinal são as que oferecem o maior valor para os clientes. Infelizmente, é comum que isto resulte em deixar de colocar esforço nas funcionalidades necessárias para completar o produto.

A ideia de se fazer este exercício é proporcionar uma forma de todos verem o produto como um todo, de forma bastante visual, e perceber se o mesmo está em equilíbrio. O resultado do pode inclusive ser mantido em algum lugar visível para servir como um radiador de informação.

---

Se você quer se aprofundar neste assunto, leia o livro "Innovation Games" de Luke Hohmann