top of page

Blog

O que diferencia um time que realmente entrega valor, de outro que apenas entrega tarefas? A resposta é simples, o primeiro tem uma definição clara sobre o que é o valor esperado! Porém, a busca por uma Definition of Value (definição de valor) ou DoV ainda é pouco usada e se mostra especialmente crítica quando buscamos agilidade nos negócios, onde as entregas nem sempre compreendem algum componente de tecnologia.

Abaixo um pouco da lógica que vou explorar!


Quando desejamos implementar algo, tudo inicia a partir de várias ideias despretensiosas com uma visão bastante abrangente do que é possível ser executado. Ou seja, nessa fase tudo é possível, pois ainda sabemos pouco sobre O QUE e COMO deve ser feito para transformar aquelas ideias em realidade. Algumas dessas ideias são exploradas e descartadas, mas outras evoluem a ponto de compor um conceito mais concreto do O QUE pode ser feito na realidade. Conceitos possíveis de serem concretizados são então refinados para definir COMO aquela entrega vai ser entregue, chegando na sua visão mais refinada de entrega feita. De todas as ideias que temos no começo do processo, apenas algumas chegam até o final como algo implementado.

ree

Indo de trás pra frente agora! O que define que uma entrega está realmente concluída pode ser bastante subjetivo, porém a prática de Definition of Done (definição de entregue ou feito) ou DoD, alinha quais devem ser os requisitos entregues e parâmetros atingidos para considerar algo está de fato feito, sem pendências e totalmente concluído. Esta prática assegura que todos que estão trabalhando na entrega ou que dependem dela, entendam o que é esperado.


Na mesma linha, acontece algo bastante similar com o conceito, que pode ser uma nova feature (funcionalidade), por exemplo. Ele somente estará pronto para iniciar a sua etapa de implementação se tiver sido refinado o suficiente com as definições, acordos e informações necessárias de acordo com quem irá implementá-lo. Nesta etapa contamos com a prática de Definition of Ready (definição de pronto ou pronto para implementar) ou DoR, que da mesma forma que o DoD, alinha quais são os inputs (entradas) necessários para iniciar uma implementação e garantir a entrega acordada.


Chegando ao início do processo, temos várias ideias candidatas a avançarem para as próximas etapas e é aqui que entra o Definition of Value ou DoV! O DoV serve como um filtro claro sobre quais ideias fazem ou não sentido serem exploradas, ele diz quais são os PORQUÊS que justificam uma implementação, qual o valor e a sua natureza, que esperamos atingir com a entrega ao final do processo. Assim como DoD e DoR, o DoV pode sim ser claramente definido, deixando explícito para todos os envolvidos com a entrega, o que se está esperando atingir.


Lembrando, que valor é sempre valor para alguém! Pode ser que a justificativa para se trabalhar em algo tenha origens diferentes! Por exemplo, uma nova funcionalidade em uma aplicação pode ser justificada por um aumento na satisfação do usuário. Enquanto uma melhoria num processo de backoffice pode ter o valor traduzido em redução de custos decorrente do aumento de eficiência de quem executa a atividade. Por isso, é muito importante ter também estes acordos firmados e claros antes de iniciar todo o processo de implementação. A DoV limita para quem estamos trabalhando e o que é valor na visão dessa persona! Uma boa DoV garante uma melhor quebra de atividades e, além disso, traz satisfação às partes envolvidas e ao time de trabalho. Evita conflitos desnecessários e que todos trabalhem em coisas sem sentido ou sem conexão clara com os objetivos.




 
 
 

Updated: Apr 12, 2021

Em tempos de COVID, fica um pouco mais complexo demonstrar os benefícios da agilidade através de dinâmicas mais participativas. Principalmente se o público alvo for alheio à tecnologia ou estiver tendo seus primeiros contatos com o assunto. Mais e mais as empresas tem buscado por agilidade nos negócios, e nesse contexto tecnologia, digital e desenvolvimento de software são coadjuvantes. A dinâmica da pizzaria tira o conceito de ágil da realidade de TI ou tecnologia, e traz para um contexto mais simples e corriqueiro que conecta com qualquer pessoa. Abaixo o passo a passo de como conduzo e exemplo dos resultados que já obtive ;)


# 1 Storytelling e diferentes rodadas


A dinâmica foi pensada para ter o mesmo enredo aplicado em dois momentos distintos de simulação. Para equipes grandes, divida em grupos, preferencialmente não maiores que 6 pessoas.

  • Enredo 1

Vamos abrir uma pizzaria na cidade!

Vocês são a equipe responsável pela produção das pizzas! Para nossa estreia forneceremos pizza para um grande evento que acontecerá na cidade. A produtora do evento será nossa única cliente da noite.

  • Rodada 1 - Instintivo

Você como facilitador, atuará como cliente. Explique o enredo de simulação e passe as orientações para desenvolverem a dinâmica de acordo com o descrito abaixo.


Para seguirmos com o exercício, temos algumas regras:

1) Eleja alguém para ser a pessoa gestora da pizzaria, que deverá direcionar o que deve ser feito e quem faz, além de receber os pedidos

2) A pessoa gestora nomeará:

1 pessoa responsável por disponibilizar os ingredientes necessários

2 pessoas para montar as pizzas

1 pessoa para fazer as entregas

3) Essas pessoas só poderão executar as tarefas a que foram designadas


Ajude o time a eleger os papéis, mas não passe qualquer recomendação extra sobre agilidade ou sobre como se organizarem.

  • Rodada 2 - Buscando Agilidade

Este momento acontece após haver uma explicação sobre agilidade logo após a primeira rodada. O enredo permanece o mesmo com você na posição de cliente, porém as orientações são ajustadas:


Para seguirmos com o exercício, temos algumas regras:

1) O time se auto organizará nas atividades

2) As pessoas que fazem entregas, não manipulam comida, ou seja, produzem pizzas ou disponibilizam ingredientes.

3) Apenas a mesma pessoa recebe os pedidos


Deixe que os times se auto organizem, porém vá passando dicas para que eles consigam ser mais ágeis nessa rodada, como otimizar a pessoa que tira pedidos também executando as entregas, todos que manipulam alimentos poderem montar e disponibilizar alimentos, etc.

# 2 Pedidos

Os pedidos a serem executados no primeiro e segundo momento são os mesmos, porém na primeira rodada eles são discutidos apenas no começo da simulação, enquanto na segunda rodada o cliente fica disponível todo o tempo para tirar dúvidas. Na primeira rodada, passe os pedidos com a pessoa gestora de cada equipe, mas não passe detalhes caso eles não perguntem nada. Na segunda rodada, instigue o time a ir além de só "tirar" pedido, mas também entender expectativas do cliente com relação aos ingredientes, montagem e condições de entrega, por exemplo.

  • Pedido 1

6 pizzas individuais, 2 calabresa, 2 marguerita, 1 portuguesa, 1 mista calabresa e marguerita. 1 Pizza média com 6 fatias brigadeiro.


Detalhes a serem explorados se os participantes perguntarem:


Ingredientes:

Massa de pizza redondo na cor branca

Molho redondo menor da cor vermelho

Quadrados amarelos para o queijo

Diferenciar calabresa, tomate, cebola, pimentões, azeitonas e manjericão.


Para a pizza de Brigadeiro:

Substuir molho por brigadeiro

Diferenciar confetes


Entrega:

PEDIDO COMPLETO, TUDO JUNTO EM CAIXAS SEPARADAS


  • Pedido 2

5 pizzas grandes de 8 fatias, todas de calabresa. 2 com cebola adicional.


Detalhes a serem explorados se os participantes perguntarem:


Ingredientes:

Massa de pizza redondo na cor branca

Molho redondo menor da cor vermelho

Quadrados amarelos para o queijo

Diferenciar calabresa e cebola


Entrega:

PODE IR ENTREGANDO PIZZAS PRONTAS EM CAIXAS SEPARADAS


  • Pedido 3

2 pizzas grandes de 8 fatias, 1 calabresa , 1 marguerita. 2 Pizzas individuais Portuguesa. 1 pizza média de 6 fatias mista calabresa.


Detalhes a serem explorados se os participantes perguntarem:


Ingredientes:

Massa de pizza redondo na cor branca

Molho redondo menor da cor vermelho

Quadrados amarelos para o queijo

Diferenciar calabresa, tomate, cebola, pimentões, azeitonas e manjericão.


Entrega:

PODE IR ENTREGANDO PIZZAS PRONTAS EM CAIXAS SEPARADAS


A ideia é mostrar na prática que explorar maiores detalhes com o cliente pode nos ajudar a priorizar e antecipar valor. Na primeira rodada os times tem a tendência de iniciar pelo pedido 1, que é mais complexo e requer ser entregue todo de uma vez só. Na segunda rodada eles devem exercitar o conceito de priorização e antecipação de valor para o cliente, dessa forma podem chegar a conclusão que o pedido 2 é mais vantajoso para começar, por exemplo.

# 3 Tempos de dinâmica


Os tempos disponibilizados para as atividades na primeira e na segunda rodada devem ser equivalentes, porém são divididos de formas diferentes para possibilitar a inspeção e adaptação de como estão organizados para aumentar sua eficiência e produtividade na segunda rodada.

  • Rodada 1

2 minutos para explicação dos pedidos

10 minutos de produção

6 minutos de reflexão nos times

10 minutos de reflexão com todo o grupo


  • Rodada 2

2 minutos para explicação dos pedidos

5 minutos de produção

3 minutos de reflexão nos times e ajuste do que for necessário

5 minutos de produção

3 minutos de reflexão nos times

10 minutos de reflexão com todo o grupo

# 4 Preparação


Para cada rodada, deixe a dinâmica pronta com espaços separados para cada time, elementos visuais permitidos para a montagem das pizzas e orientações gerais. Na segunda rodada, crie um fluxo de trabalho baseado em kanban para facilitar a organização do time como um todo, por exemplo, separando entrada de pedido, preparação, pedidos prontos para entregar e entregues. É importante também deixar bem claro na segunda rodada como conceitos ágeis impulsionam melhores resultados.


Também não se esqueça de escolher ferramentas online que auxiliem na facilitação (Mural e Miro são bons exemplos). Para pessoas que tem pouca familiaridade com este tipo de ferramenta, não esqueça de fazer uma breve apresentação sobre como ela funciona e quais funcionalidades serão necessárias para a dinâmica. Há também a possibilidade de executar uma rodada de aquecimento, apenas pedindo que todos montem uma pizza genérica para se familiarizarem com a ferramenta.

O intuito final é fazer com as pessoas entendam os impactos de aplicar conceitos de agilidade num contexto simples. Faça com que todos reflitam sobre como foi a experiência a cada rodada, quais foram as dificuldades e conclusões que chegaram. É importante que você como pessoa facilitadora desse processo saiba conectar as mudanças entre a rodada 1 e 2 com as conclusões trazidas pelo time, assim estará potencializando o seu aprendizado.


Na última vez que rodei essa dinâmica, gravei as interações em ambas as rodadas! Ficou nítida a melhoria de performance na segunda rodada (assista no vídeo abaixo).


Caso tenha gostado, fique à vontade para replicar ou se basear nesse formato :)

Caso utilize outras técnicas ou tenha algum feedback, compartilhe comigo!

 
 
 

No processo de desenvolvimento e evolução de soluções, sempre chega o momento de validar se as ideias, conceitos e hipóteses que temos são realmente válidas. Muitas vezes as pessoas não sabem que existem diferentes formas de se atingir esse objetivos ou até mesmo precisam explicar para outras pessoas mais leigas a estratégia de validação adotada (isso acontece comigo quase que diariamente). Para ajudar, pensei numa analogia simples, que qualquer pessoa pode usar e nunca mais esquecer o que são, quais as diferenças e onde aplicar uma prova de conceito, um protótipo ou um MVP.


Vamos supor que meu objetivo final é ter uma bolaria! Nesse contexto o meu produto final a ser ofertado aos clientes são bolos, que num nível máximo de complexidade podem ser customizados e estilizados.


Agora digamos que eu nunca fiz bolos profissionalmente e que ainda não sei se os custos com ingredientes e preparo serão inferiores a ponto de eu obter lucro com a venda dos bolos. Este é um conceito que eu terei que provar antes de iniciar a produção, logo, testar a receita é uma prova de conceito.


O visual dos bolos, número de camadas e design em geral também são extremamente importantes para validar se as expectativas dos clientes serão atendidas. Uma forma simples de ter essa validação sem ter que preparar e decorar o bolo por completo - correndo o risco de o cliente não gostar e tudo virar perda de tempo e dinheiro - é fazer um protótipo. Neste caso, eu posso fornecer ao meu cliente um desenho de como planejo entregar o bolo, para que ele faça sugestões e modificações antes da produção.


Por fim, digamos que o meu forno atual ainda não tem capacidade para fazer bolos grandes e complexos, porém eu já quero começar a vender versões mais simples de bolo, até mesmo para verificar se na minha região as pessoas compram este tipo de produto. Nesta situação, eu posso adotar um MVP (minimum viable product ou produto mínimo viável), ou seja, vender versões reduzidas e possíveis de executar do bolo, como cupcakes, por exemplo. Quem sabe eu já começo a ganhar algum dinheiro para investir num forno maior, que vai possibilitar a produção de bolos mais complexos?


ree

Ficou mais simples de identificar as diferenças? Recapitulando:


1) Prova de conceito está intimamente ligada ao teste de alguma tecnologia ou conceito que precisará ser utilizado para entregar o produto final. Alguns outros exemplos de outras realidades: É possível desenvolver funcionalidade X na linguagem Y? É possível integrar sistema A com B?


2) Protótipo é uma visão simplificada do produto a ser desenvolvido para validar a aceitação do usuário. Podemos ter protótipos super simples, até os mais tecnológicos e fiéis ao produto a ser entregue, porém, vale ressaltar que o protótipo não é algo funcional e por isso não pode ser comercializado como o produto.


3) MVP é a versão mais simples e possível do produto a ser entregue, sendo um produto funcional e completo por si só. Este conceito pode ser utilizado para validar, com mais rapidez e menor custo, o fit de mercado de um produto e garantir a evolução das próximas versões baseadas no feedback de uso real dos usuários.


Além disso, para todos os casos, vale ressaltar que o nível de complexidade vai aumentando entre a POC, protótipo, MVP e produto final, sendo esse um outro fator importante na decisão da estratégia de validação a ser seguida. É possível também usar técnicas menos complexas para validar componentes de uma entrega mais complexa, como: ter um MVP, protótipo ou POC do produto final; ter um protótipo ou POC do MVP; ou ainda ter uma POC de alguma parte do protótipo.


Para finalizar, independente da estratégia, manter o caráter de experimentação é fundamental. Já que agilidade significa responder às mudanças, estratégias de validação servem para conseguirmos adaptar o plano de execução mais rápido e de maneira mais assertiva a partir desse olhar experimental.

ree

 
 
 
bottom of page