Topper's e Gamificação (ou "Como usar a vaidade de uma pessoa para engajar um time")

Quem acompanha as tiras de Dilbert deve estar imaginando do que vou falar hoje. Aos que são fãs de Top Gang, sinto muito, não falarei de Topper Harley.

O Topper

Topper é um personagem que aparece casualmente nas tiras de Dilbert. Sempre que alguém relata ter conseguido executar alguma tarefa difícil, Topper se intromete na conversa, diz "Isso não é nada" e relata uma situação semelhante a do indivíduo, mas com maior grau de dificuldade e/ou sucesso.

E geralmente o "grande feito" sequer é verdadeiro, ou sem lógica.
(original em http://dilbert.com/strip/2001-01-03)

Pessoas com o Complexo de Topper não são de uma geração específica, mas, na minha experiência, geralmente são oriundos na Geração Z. Talvez por serem pessoas mais conectadas a redes sociais, terem hábitos mais saudáveis (praticam mais esportes, fumam menos, alimentam-se melhor) e assimilar novas tecnologias e tendências mais rápida e facilmente, consideram-se mais capacitados.

O Topper gosta de mostrar superioridade, adotando práticas expansionistas ou ilusionistas.

Expansionista é aquele que busca todos os espaços para si. Possui hábitos inconvenientes tais como interromper os colegas para expor suas ideias (ou pior - apenas dizer o que o colega ia dizer), serem os primeiros - de maneira afoita - a se voluntariar para tudo. Além disso, não se preocupa em estimular a participação de seus colegas.

O ilusionismo se resume a atitudes que, vistas fora de um amplo contexto, são consideradas positivas para o indivíduo. Um exemplo típico: aquele e-mail ou Whatsapp enviado pelo às 21 horas que surpreende qualquer um, exceto aqueles que sabem que ele chegou para trabalhar às 11 horas (mesmo em ambientes com horários altamente flexíveis, ainda vejo pessoas que são facilmente iludidas por qualquer sinal de presença fora do horário comercial convencional)

O problema

O time passa a evitar toda e qualquer ação que venha a estimular o envolvimento do Topper em qualquer situação. Os integrantes do time desistem de tentar expor seus pensamentos e dificuldades, predominando a desmotivação. Além disso, o sentimento de trabalho em equipe desaparece, pois ninguém quer fazer nada para que uma pessoa roube a cena.

Desunião, desmotivação e falta de comunicação... não preciso dizer aonde isso vai chegar, não é mesmo?

A solução

Se você pensou "Feedback", errou rude. É bem provável que você já tenha tentado algumas vezes e não funcionou. O feedback, por mais direto que seja, é uma ferramenta efetiva para pessoas minimamente engajadas. É preciso uma ferramenta que faça surgir na pessoa o engajamento para eliminar o problema: gamificação.

A gamificação consiste na aplicação de mecânicas e técnicas de design de jogos para a engajar pessoas, gerando insights e motivando-os, para alcançar objetivos. Um famoso exemplo é a campanha The Fun Theory da Volkswagen ( http://www.thefuntheory.com/ ), onde as pessoas passam por situações em que são estimuladas, de maneira divertida, a mudar seu comportamento diante de coisas do dia-a-dia, como por exemplo, troca a escada rolante pela escada convencional:

O apocalipse das escadas rolantes

Mas nem sempre os estímulos geram sentimentos positivos, como neste caso da escada. A gamificação também pode explorar sentimentos negativos que tenham um impacto significativo nas pessoas, para que possam alcançar os seus objetivos, como neste exemplo abaixo, do site Reclame Aqui, onde executivos de grandes empresas passam por situações desagradáveis, onde o objetivo era causar as mesmas sensações que os clientes destas empresas passam:

O elemento lúdico

Nas duas situações, pudemos observar que os elementos lúdicos (a escada piano da estação e o péssimo atendimento do restaurante) não são elementos típicos do nosso dia-a-dia. São elementos que buscam se aproximar do absurdo, o que não é por acaso.

A busca pelo absurdo é um dos pilares da gamificação, pois é ele que é capaz de causar o impacto permanente necessário para engajar a pessoa de maneira efetiva. O feedback, mencionado anteriormente, não causa tamanho impacto em uma pessoa sem engajamento, por isso não funciona nestes casos. Você mal deve se lembrar do que comeu no seu último almoço, mas deve lembrar com clareza de alguma experiência absurda que deve ter passado na infância.

A experiência do indivíduo

Vimos duas experiências do indivíduo: a surpresa da escada que toca notas musicas e o incômodo gerado pelo mal atendimento no restaurante. Na gamificação, estas experiências são distribuídas em vetores:

Agon - experiência de competitividade 

Alea - experiência do inesperado, do aleatório (o mal atendimento no restaurante)

Mimicry - experiência da mimificação, do simulacro de elementos reais (como no caso da escada que imita um piano)

Vertigem - experiência de alto choque emocional 

Usando a gamificação para engajar o time

Como o objetivo, neste caso, é o engajamento do time e não apenas do Topper, a solução envolve uma dinâmica de gamificação que explore o senso de competitividade do Topper e dissemine de forma positiva ao resto do time, para tal, uma dinâmica predominantemente Agon pode ser aplicada. "Predominantemente" pois os vetores de experiência não são exclusivos. É possível misturar elementos dos diferentes vetores, a fim de gerar diferentes experiências aos jogadores - os membros do time.

A diferença da competitividade da dinâmica, comparada ao cenário sem ela, onde o Topper praticamente compete com si mesmo, está em três itens:

• Todos jogam juntos, não apenas o Topper
• Regras são aplicadas, possibilitando controlar excessos
• Um cenário lúdico divertido é aplicado, estimulando todos a continuar no jogo

As regras e a participação de todos em uma dinâmica competitiva, possibilitam explorar o lado positivo da vaidade e ambição de um indivíduo, para melhorar um time como todo.

Vamos jogar?

Cuidado com Lean e o excesso de "Keep It Simple, Stupid"! (ou "Não confunda Lean Thinking com Lean Startup")

Quando ouvi falar em "Lean", pela primeira vez, em alguma conversa qualquer, o foco da discussão era no Produto Mínimo Viável (MVP - Minimum Viable Product) - a importância de fazer um produto simples, com o mínimo de esforço e tempo, agregando o máximo de valor. Em conversas posteriores, com outras pessoas, o foco também estava no MVP. Em um tom de utopia, quando surgia o tópico de Lean Thinking, as pessoas discutiam sobre maneiras de minimizar ao máximo o trabalho de desenvolvimento. Foi aí que fui contaminado (por pouco tempo) pela idéia de reduzir simplificar o valor.

O problema nestas discussões é que focar em MVP não é um princípio de Lean Thinking, mas sim de Lean Startup! E a situação se agrava quando não se está seguindo princípios de Lean Startup nem de Lean Thinking.

Não são raras as situações em que acabamos tirando valor de um produto em nome da do mínimo viável. Deixamos de lado o valor em nome do tempo e esforço
(Figura retirada do post "Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable" de Henrik Kniberg)

Em Lean Startup, o foco é, realmente, no MVP, objetivando a criação de protótipos de maneira rápida, para validação junto ao mercado, levando a uma rápida evolução deste produto.

O Lean Thinking - Pensamento Lean - envolve uma série de princípios, valores e práticas que objetivam o entendimento do valor do produto, e suas dinâmicas - o processo (ou linha) de produção - eliminando qualquer esforço e tempo que não agreguem valor ao produto, buscando a perfeição.

Lean Startup tem como foco o produto, enquanto que Lean Thinking foca na linha de produção

A falta de conhecimento dos valores de Pensamento Lean, misturado a idéias de Lean Startup, gera uma série de propagandas enganosas, que seduzem as pessoas através do foco em produto mínimo e menor esforço. Surge, então, o pensamento distorcido com base nestes dois elementos, resultando em baixo valor em nome da economia de trabalho e tempo e sem melhorias no processo de produção como um todo.

Muito cuidado ao tentarem apenas simplificar o seu trabalhos em projetos, pensando apenas no produto em si. O resultado será convertido em desperdício e frustração. Convido vocês a estudar Lean Thinking. Um bom começo é o livro Tudo que sei sobre lean aprendi no 1º ano da escola, de Robert O. Martichenko.

O livro introduz de maneira simples e muito divertida o pensamento Lean, além de abordar algumas das práticas e princípios por trás dos valores propostos.

Conhecendo melhor os valores do pensamento Lean, você entenderá que menor esforço é apenas o começo, fazendo você refletir não apenas no produto em si, mas em todos os elementos que rodeiam o produto. Aí, então você poderá dizer que PENSA Lean. Vamos começar?

"Desmistificando Pair Programming e TDD" para leigos

Quando eXtreme Programming (XP) foi apresentado ao mundo, uma série de práticas foram propostas para aplicabilidade dos valores e princípios básicos por trás desta metodologia ágil.

Algumas práticas são muito consolidadas na cultura de empresas, tais como entrega frequente de software funcionando (me corrijam, se estou errado, mas nunca vi ninguém defendendo entregas menos frequentes, nem mesmo em times e organizações com cultura waterfall).

Outras práticas, no entanto, ainda encontram obstáculos para se tornarem definitivas em times que almejam se tornar verdadeiramente ágeis. Em minha trajetória, observei duas práticas muito negligenciadas (por mim inclusive): Pair Programming (PP) e Test-Driven Development (TDD).

As justificativas para deixar essas duas práticas de lado apontam sempre para uma dimensão: tempo.

Muitas pessoas acreditam que Agilidade implica em Correria, levando a crer que, deixando pair-programming e TDD de lado, poderão produzir mais, em menos tempo. Após uma breve análise, encontrei nos princípios do Manifesto Ágil uma possível causa desta deturpação:
 "Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos"

"Frequência" não significa "Intensidade"! Abrindo mão de PP e TDD, é possível, mas pouco provável, que você possa entregar mais, porém deixará de lado a qualidade - um dos princípios de XP - e tem como risco não ter um software funcionando (você já leu o Manifesto Ágil e seus princípios? Pois deveria).

Deve-se entregar, com frequência, software funcionando e de alta qualidade, e o tempo consumido em atividades de Pair-Programming e TDD sobre o trabalho como um todo é irrelevante, do ponto de vista ágil.

Se ainda assim, houver obstáculos com tempo (ex: prazos impostos por clientes), negocie o escopo do trabalho. No fim, um trabalho de qualidade, mesmo que com escopo reduzido, terá muito mais valor que um trabalho com escopo mais amplo, mas de menos qualidade.