Blog da Knowledge21

4 práticas Ágeis para o desenvolvimento de produtos enxutos

As organizações têm experimentado diversos métodos e processos para desenvolver produtos enxutos mais aderentes às necessidades dos seus clientes. Existem aspectos valiosos em cada um dos vários processos experimentados. O grande desafio é escolher as práticas ágeis que funcionam melhor para suas equipes e para os valores que a marca deseja transmitir.

Independente das ferramentas escolhidas, as quatro práticas abaixo são indispensáveis para o desenvolvimento de qualquer produto: Produtos Enxutos

  1. Ciclos curtos – dê pequenos passos, tente algo novo e veja como ele funciona. Se falhar, ao menos investiu muito pouco e pode descartar facilmente. Se tiver êxito, continue fazendo e melhorando.
  2. Retrospectivas regulares – no final de cada ciclo, avalie o que ocorreu bem, o que não ocorreu bem e foque em coisas importantes que podem melhorar no próximo ciclo.
  3. Colocar o cliente no centro de tudo – todos devem ser obcecados por gerar valor para os clientes. Qual problema dos nossos clientes estamos resolvendo? Como avaliamos se estamos entregando algo que os clientes precisam? Como isso afeta o que priorizamos?
  4. Simplicidade – a simplicidade é a tendência na era digital. A forma mais fácil de simplificar um software consiste em eliminar funcionalidades. Concentre-se no que é fundamental.

Seus clientes não se importam com qual processo ou ferramenta você utiliza. Eles se preocupam com produtos e serviços que resolvem problemas significativos para eles de maneira eficaz.

Você curtiu este post? Lembrou-se de outras práticas importantes? Deixe um comentário neste texto e compartilhe a sua opinião e as suas ideias sobre o assunto!

BDUF: A arte de fazer coisas que não deveriam ser feitas

BDUF é um acrônimo (Big Design Up Front) usado para indicar que todo o desenho da solução é feito antes da execução. Isso é algo bem típico no modelo tradicional de desenvolvimento de software, onde há explicitamente uma etapa de Análise que antecede a etapa de implementação. Assim, no final das contas, BDUF é arte das coisas que não deveriam ser feitas.

Nos anos 90, os sucessivos fracassos em projetos BDUF impulsionaram a criação de novos métodos de desenvolvimento, tal como o Scrum. Com o surgimento do Movimento Ágil em 2001, a crítica a essa grande antecipação do planejamento passou a ser mais contundente. O Chaos Report de 2002 foi acompanhado da constatação de que, mesmo em projetos considerados de sucesso (prazo e custos cumpridos de acordo com o planejado), o percentual de itens úteis era extremamente baixo.

Hoje em dia, com a expansão dos métodos ágeis, não há mais uma longa etapa de análise, porém, ainda vemos muitas atitudes BDUFeiras nas empresas.

Exemplos de BDUFagens:

Em desenvolvimento de produto:

  • Design Thinking de 6 meses.
  • User story mapping com dezenas de histórias.
  • Desenho de todas as telas do sistema para só então implementá-lo.

Em desenvolvimento de software:

  • Criação de toda uma API de serviços para depois pensar na aplicação.
  • Pensar na melhor arquitetura possível, às vezes chegando ao absurdo de nem olhar mais para o objetivo daquele produto.
  • Parametrização de todas as variáveis, antes mesmo de existir tal demanda.

 Em outras áreas:

  • Marketing BDUFeiro é aquele que faz grandes lançamentos de uma campanha em diversas mídias simultâneas, sem fazer nenhuma experimentação da aceitação do público. No marketing mais moderno, a propaganda está cada vez mais se direcionando para ser uma ação continuada com o uso de mídias digitais.
  • UX (User eXperience ou experiência do usuário) também é uma atividade que se não ficar atenta, pode facilmente BDUFar. Por exemplo, há empresas que passam meses traçando todos os perfis de usuário, considerando exceções e padrões que nem representam 1% do público de interesse ou do valor do produto. Hoje em dia, Design Thinking que dura 6 meses, ao final tem que começar tudo de novo, porque o mundo em volta já mudou. Nós acreditamos no Agile Desighn Thinking!

BDUF na vida: 

Às vezes vemos pessoas que planejam em excesso ou com muita antecedência na ilusão de que podem ter o controle sobre tudo o que irá acontecer. Por exemplo:

  • pessoas que planejam todos os detalhes de uma viagem a lazer, mas que se frustram com situações imprevisíveis;
  • pessoas que decidem que para encontrar um par amoroso precisam, no primeiro ano, entrar na academia, no ano seguinte aprender a dançar, para depois começar a frequentar boates.

Como deixar de ser BDUFeiro:

Antecipe resultados!BDUFeiro

  • Evite o Jaque. É o famoso “já que”: já que estamos criando esse novo campo na tabela de dados, vamos aproveitar para colocar outros possíveis campos. Já que vamos mexer nesse código, vamos então fazer o refactoring completo. Toda vez que alguém invocar o “já que”, reflita se não é uma atitude BDUFeira.
  • Planejamento respeitando a analogia do horizonte.
  • Fatiar. Diante de um grande problema, ao invés de quebrar em pedaços técnicos, devemos fatiar. Ou seja, dividir algo a ser feito em pedaços menores que ainda agregam valor. Além de evitar o BDUF, há inúmeras vantagens em fatiar, por exemplo, o aumento do foco onde realmente está o valor.
  • Construa soluções incrementais e arquiteturas emergentes.

Experimente na prática!

  • A cultura da experimentação é uma das mudança mais impactantes quando as empresas passam a implementar Métodos Ágeis. Quando se entende que sempre estamos fazendo experimentos, há menos pressão para a solução perfeita no início de qualquer iniciativa.
  • “Não existe reuso sem uso”. Várias vezes as pessoas querem justificar o BDUF para evitar um futuro “retrabalho”. Porém, antecipam um trabalho antes mesmo que haja algum benefício daquilo que está sendo feito. Ter uma boa arquitetura é importante, mas ela deve ser enxuta, focada nas próximas entregas de valor, no que chamamos de arquitetura emergente. Recomendamos a prática de “refactoring” para aumentar o reuso de código, mas primeiro se deve focar no uso.
  • 1,2,N. O padrão 1,2,N se aplica para quando resolvemos o problema para uma situação, depois para uma segunda e então para N. Este assunto merece um post por si só.

Planning com backlog prematuro? Que tal um refinamento?

Em alguns times que estão começando a usar Scrum é comum perceber que o refinamento do backlog acontece durante a planning, ou seja, todas as histórias da sprint são explicadas, entendidas, iteradas, estimadas e fatiadas durante a cerimônia.

Isso pode trazer alguns problemas.

Product Backlog

Planning muito longa ou rasa: Deixar todo o entendimento das novas histórias para uma única reunião pode estender muito o tempo da reunião, caso:

  • Muitas dúvidas precisem ser tiradas.
  • Critérios de aceitação serem combinados.
  • Histórias grandes precisem ser fatiadas.
  • O time ainda não conheça o real valor de negócio para cada história.

Em um cenário pior, o tempo da planning não é comprometido, mas sua qualidade sim, e os itens acima são feitos de forma muito rasa ou completamente ignorados.

Algumas histórias travarem com indefinições: Como uma consequência de uma planning rasa, o time pode sofrer com isso durante a sprint. Descobrindo grandes buracos na definição das histórias, que caso dependam de uma decisão externa travam o fluxo de desenvolvimento de uma forma que comprometa o objetivo da sprint.

Uma pré-seleção ser feita sem a visão de ROI: Para ter uma noção clara de ROI (Return on Investment) para cada história é preciso saber o quanto estamos investindo nela. É comum que o valor do investimento seja o esforço estimado pelo time, mas se o time não conhece ainda as próximas histórias no backlog significa que o PO precisou fazer uma pré-seleção do backlog sem olhar o ROI, e trazer esses itens para a planning. Com isso temos poucas garantias de que não teria algum outro item no backlog com o ROI mais alto do que essas que o PO trouxe. 

Backlog desestruturado: Outro risco seria não ter um backlog bem estruturado, com as histórias no topo sendo fatias finas, conforme visão do horizonte para o backlog. Na pré-seleção do PO pode acontecer que uma das histórias tenha um esforço enorme, incompatível com o tamanho da sprint por exemplo.

Refinamento do Backlog (Grooming)

Uma prática que muitos times utilizam como solução é fazer um refinamento (ou grooming) durante a sprint sempre que necessário. Ela não é uma regra oficial no scrum guide, mas é uma reunião que ajuda a ter uma planning eficiente e um backlog bem mantido e priorizado.

A frequência desta reunião não precisa estar casada com o ciclo do scrum, e idealmente é feita sob demanda para que o time não caia no caso de refinar itens a menos e nem itens a mais. O número ideal de itens refinados certamente vai depender do seu contexto e a experimentação deve prevalecer.

Se existem algumas dessas disfunções no seu time, você acha que vale experimentar fazer um refinamento separado da planning?

Retrospectiva – Removendo as pedras do caminho

Quando o Time fica pronto? A resposta é: Nunca! Um Time Ágil está em constante formação. Entretanto,  ao longo desta jornada, alguns problemas surgem e atrapalham o desenvolvimento do grupo e a harmonia do trabalho. Removendo as pedras do caminho é uma dinâmica de retrospectiva na qual o Time expõe os problemas por ele percebido, priorizando quais desafios devem ser vencidos e traçando planos de ação para solução dos problemas mais relevantes. 

A dinâmica de retrospectiva

Retrospectiva Pedras no Caminho

Desenhe em um quadro uma linha bem irregular. Esse será o caminho. No final do caminho, desenhe uma linha de chegada. Em seguida, mais ou menos no meio do quadro desenhe o Time. Desenhe algumas pedras no início do caminho e outras entre o Time e a linha de chegada.

As pedras ultrapassadas são todos os problemas que o time já teve e já foram superados. Elas não são o foco da dinâmica, mas ajudam na motivação das pessoas e evitam a Síndrome do Patinho Feio (o Time percebe tudo como problema e tem a sensação de que nunca conseguiu resolver nada).

Já as pedras no caminho são todos os problemas que atrapalham o time a chegar ao objetivo do Time de altíssima performance.

Peça para o time, em duplas ou trios, preencherem post-its dizendo quais são estas pedras. Um item por post-it. Deixe as pessoas escreverem livremente todos os problemas que elas acham relevantes.

Leia os post-its e tente agrupá-los por similaridade para que as pedras mais citadas se transformem em montanhas.

Em seguida, peça para as pessoas escolherem qual o problema mais importante na perspectiva delas. Gostamos de utilizar o Dot Voting para tal. O problema mais votado será o problema tratado.

Desenhe uma britadeira sobre a pedra mais votada e peça para o Time descrever o que é a britadeira. Esse será o plano de ação que removerá a pedra. Em seguida pergunte quem irá segurar a britadeira para quebrar a pedra (responsáveis pelo plano de ação). Deixe bem claro que estes voluntários não precisam necessariamente resolver o problema sozinhos. Eles devem, em um curto intervalo (1 Sprint), buscar entregar um incremento real que solucione um aspecto significativo do problema.

Caso o time seja grande, é possível escolher dois ou mais problemas. Todavia, perceba que quanto mais frentes forem abertas, maiores são as chances de desperdício de esforço e de não obtenção da solução. Pare de começar e comece a terminar.

Todos precisam conhecer o Design Thinking

O Design Thinking já ultrapassou o status de termo da moda. O fato é que ele não é nada novo para quem trabalha com produtos e inovação, muito menos para designers que aprenderam a atuar como MacGayver no dia-a-dia das empresas. Design Thinking virou um termo guarda-chuva, cobrindo técnicas, métodos, conceitos e os mais variados aparatos para auxiliar pessoas e empresas que precisam inovar de forma sustentável e focada no indivíduo mais importante para seu negócio, também conhecido como: seu cliente.

Para ampliar ainda mais o entendimento sobre este último, são trazidos elementos de diversos campos, inclusive da psicologia. Tais elementos, associados a todo o poder de síntese do design, possibilitam identificar através de rápidas tentativas qual será a melhor forma de solucionar um problema.

Você não é seu cliente e seu cliente não sabe o que quer.

De que adianta produzir muito se o que você produz é interessante apenas para você? Muitas vezes, o idealizador da ideia não é o consumidor do produto. Como você poderá sozinho validar a aderência dele para o público? Feeling? É mais seguro você sair de seu escritório e falar com quem usa seu produto.

O Design Thinking deixou de ser uma matéria só para especialistas que estudam a melhor forma de criar produtos. Hoje é uma questão de sobrevivência dos negócios. Com cada vez mais concorrentes, cria-se consumidores mais exigentes, em um mercado em que tudo é fácil de ser desenvolvido ou copiado. Acerte o coração do consumidor ou se junte aos 90% dos produtos que não sobrevivem após o primeiro ano no mercado.

Design Thinking e Ágil.

Agile Design Thinking Se aceitarmos o fato que as empresas cada vez mais estão adotando Ágil como cultura, os times tenderão a ser cada vez mais multidisciplinares. Consequentemente, as decisões estratégicas dos produtos, que antes eram tomadas apenas pelo dono da empresa ou por um superior seu hierarquicamente, agora será compartilhada e até delegada aos times.

Uma vez que as decisões estratégicas de um produto sejam compartilhadas com o time, é preciso que todo trabalhador saiba identificar as necessidades do cliente, além de saber discutir sobre o próximo incremento no produto. Ou seja, não saber o mínimo sobre Design Thinking pode fragilizar seu currículo como trabalhador do conhecimento atualmente, que dirá em um futuro próximo.

É preciso evitar a frase: “o PO (ou o chefe) que mandou assim”. Toda ideia é uma hipótese a ser validada, que deve derivar de um problema real, de um cliente real. Afinal, melhor não acreditar na bola de cristal para desenvolver produtos 🙂

Até que ponto detalhar o backlog?

Como estruturar um backlog ainda tem sido uma questão em alguns times ágeis, e um dos pontos recorrentes tem sido o detalhamento excessivo de todos os item do backlog.

Para ajudar neste assunto utilizamos a metáfora do Horizonte para guiar o trabalho do PO.Backlog

Alguns problemas encontrados

Quando trabalhamos num backlog, podemos cometer o equívoco de detalhar e decidir sobre itens que estão muito longe de serem atacados e, considerando os princípios e valores ágeis, isso pode trazer os seguintes problemas:

1- Alto nível de desperdício no caso de mudarmos de direção.
2- O esforço para detalhar itens distantes é maior.
3- É preciso tomar decisões pequenas muito antes do necessário.
4- Dificuldade de gerenciar um backlog gigantesco.

Backlog na perspectiva de Horizonte

Imagine que você está na rua de uma cidade grande e que o backlog seria uma sequência de passos que vão na direção que hoje acreditamos que o produto vai seguir. Para os próximos passos temos mais detalhes sobre o caminho que vamos percorrer, o nome das ruas está claro, conseguimos ver detalhes dos prédios, das pessoas que estão passando ou se o sinal mais próximo está aberto.

Porém, na medida em que olhamos mais a frente os detalhes não são tão precisos. Conseguimos ver que existem prédios mais altos e outros mais baixos, um prédio branco e outro azul, e a medida que levamos a visão mais perto do horizonte temos menos detalhes sobre o caminho que imaginamos que vamos seguir.

Parte do trabalho do Product Owner é olhar para esse caminho constantemente. Encare seu backlog pensando nos próximos passos e dando o devido foco para o que está no seu horizonte. Sempre vale lembrar que se adaptar a mudanças é mais importante do que seguir um plano.

Você tem sentido que o seu time está sofrendo algum destes sintomas? Compartilhe com a gente nos cometários 😉

NPS – Medindo a satisfação do cliente

Net Promoter Score, ou simplesmente NPS, é uma técnica bastante utilizada para medir o quanto o cliente está satisfeito com um produto oferecido por você ou sua empresa. É uma forma prática e de cálculo simples. Assim, como o próprio nome já diz, o resultado é a porcentagem de pessoas que promovem a sua marca/produto, ou seja, que estão inclinadas a indicá-la(o) para outros consumidores.

Como usar

Uma pesquisa de NPS sempre começa com uma pergunta padrão:

“Em uma escala de 0 a 10, o quanto você recomendaria
[a Empresa X ou o Produto X] para um [amigo, colega ou parente]?”

Com o resultado da pesquisa é possível classificar seus consumidores como:

Promotores (pessoas que responderam 9 e 10);

Passivos (Pessoas que responderam 7 e 8) ;

Detratores (Pessoas que responderam abaixo de 7 ).

Ao classificar seus consumidores, é possível extrair o NPS através da seguinte fórmula:

NPS = (% de promotores) – (% de detratores)


Perceba que, ao final do cálculo, você terá um resultado que vai variar de -100% (todos podem falar mal do seu produto) a +100% (todos indicariam o seu produto).

Peça feedbacks

Apenas ter o índice de NPS pode não ajudar tanto quanto gostaríamos. Aproveitando que a pergunta primordial do NPS é rápida de responder, é importante fazer uma segunda pergunta para seu consumidor. Entretanto, esta segunda pergunta deve se basear na nota dada pelo cliente inicialmente. Quando aplico NPS aos produtos, costumo perguntar logo em seguida:

  • Para os Promotores: “Obrigado! Você já nos indicou para alguém?”
  • Para os Passivos: “Obrigado! Como poderíamos ser nota 10 para você?”
  • Para os Detratores: “Sua opinião é importante. Pode nos dizer como melhorar?”

É essencial que a pergunta de feedback seja um campo aberto para resposta. Um erro comum é tentar prever as respostas trazendo frases já escritas para o consumidor escolher. Ao fazer isso você estará induzindo a resposta e não terá um feedback rico.

Margem de erro e ferramentas

Uma dúvida comum é não saber quantas respostas é preciso ter para considerar o índice confiável. Costumo dizer que alguma resposta é melhor que nenhuma. Vale lembrar que, ao se prender ao índice, é importante você saber sua margem de falha na pesquisa. Ferramentas e fórmulas para entender o tamanho da sua margem de falha podem ser facilmente encontradas na internet.

Outra forma de não se perder na quantidade de respondentes, é fazer a pesquisa de forma cíclica e aberta por um período específico de tempo. Exemplo: você pode ter instalado uma enquete de NPS que a cada 2 meses fica disponível por 1 semana no seu site. Isso lhe trará métricas comparativas suficientes para entender o seu nível de atendimento.

O que é um NPS bom?

Depende do segmento que você está e de quanto é o NPS dos seus concorrentes. Neste caso, comparar é melhor do que se ater a um número absoluto.

Para alguns mercados, NPS acima de 20 já é ótimo. Para outros, abaixo de 60 já vai lhe deixar para trás dos concorrentes. Contudo, um NPS positivo já mostra que você tem um produto minimamente saudável, diferente de um NPS negativo que, provavelmente, indica que em pouco tempo não terá mais ninguém usando o produto, afinal, quem terá prazer em comprar em um lugar onde a maioria não indica o seu produto/serviço/marca?

Quer saber mais?

Caso você deseje ir mais a fundo, tem o próprio artigo da Bain & Company, empresa que desenvolveu esse modelo de pesquisa e muitos outros sobre NPS na internet.

Curtiu? Quer que a gente escreva mais sobre modelos de pesquisa? Então deixe sua sugestão nos comentários 😉

Dot Voting – Colaboração para priorização de decisões

Você já esteve em uma reunião em que os assuntos iam surgindo durante a discussão e depois de muita falação nada ficou decidido? Em situações de tomada de decisão é comum que existam muitos tópicos para serem debatidos. Discuti-los um a um faz com que as reuniões se tornem longas, chatas e desgastantes para os envolvidos. Dot Voting é uma técnica de facilitação baseada em  cumulative voting utilizada para priorização colaborativa.

Utilizando o Dot Voting

Esta dinâmica deve ter uma duração curta. Se a reunião for de duas horas, ela deve durar entre quinze a vinte minutos.

  1. Comece listando todos itens de discussão no quadro. Se necessário, faça apresentações sucintas sobre aqueles que forem pouco conhecidos do público participante.
  2. Cada pessoa tem direito a três votos (marcas) que podem ser distribuídos nos itens da forma que elas quiserem. É possível que a pessoa coloque todos os seus votos em um único item. Também é possível que alguns itens não recebam nenhum voto.
  3. Conte os votos recebidos para cada item. Aqueles que receberam mais votos são os mais prioritários.

 A Figura abaixo apresenta um exemplo de Dot Voting realizado em uma reunião com cinco pessoas.

Exemplo de Dot Voting para priorização de assuntos em uma reunião com 5 pessoas.

Neste exemplo, os participantes da reunião colaborativamente decidiram que prioridade de assuntos é:

  1. Contratação de novos desenvolvedores
  2. Cotação de treinamentos
  3. Avaliação 360º
  4. Resultado das reuniões de Feedback
  5. Trabalho remoto

As discussões devem começar do item mais importante para o menos importante, pois caso o tempo da reunião acabe, você garante que  os assuntos mais importantes foram tratados. E mesmo que ainda haja tempo para discutir todos os assuntos, como eles foram priorizados em ordem de importância por todo o time, pode ser que ao final se perceba que os deixados por último não sejam assim tão importantes e, portanto, nem precisem ser discutidos.

NÃO como estratégia para eliminar desperdícios

Desenvolvimento de software é uma atividade complexa que pode se tornar ainda mais se não evitarmos desperdícios. Várias decisões precisam ser tomadas ao longo do caminho tais como:

  • Qual problema estamos resolvendo?
  • Quem é o usuário final?
  • Que linguagem de programação utilizar?
  • Quais frameworks?
  • Layout próprio ou templates bootstrap?
  • Qual banco de dados?

E como impedir que o nível de complexidade sempre aumente?

Elimine Desperdícios. Diga NÃO!

Embora temos aprendido a fazer escolhas sobre as tecnologias e formas de trabalho, ainda sentimos frio na barriga quando precisamos dizer NÃO.

Blog-2

É muito fácil dizer sim. Dizer não exige perder o medo do confronto. Ao invés disso, dizemos sim para um prazo irreal, sim para uma nova funcionalidade um dia antes da entrega, sim para uma contratação mediana. Você sabe aonde isso vai parar, não é?

“As pessoas evitam dizer não para fugirem de confrontos, mas a alternativa é pior ainda. As tarefas se arrastam, as coisas se complicam e trabalhamos com base em ideias nas quais não acreditamos.Jason Fried & DHH

Somos bombardeados por prazos apertados, demandas em que não acreditamos e, ao invés de nos posicionarmos profissionalmente, evitamos o desconforto do NÃO e sofremos construindo coisas que ninguém quer e trabalhando em algo que não enxergamos valor. Achamos que dizer NÃO demonstra falta de comprometimento ou desinteresse. Mas dizer SIM para tudo atrapalha o foco no trabalho que realmente precisa ser feito.

Dizer Não é, antes de tudo, um exercício de priorização!

Por maior que seja o desconforto é importante exercitar o NÃO. Como disse nosso amigo Rodrigo de Toledo “o mal do século XXI é que a demanda é sempre muito maior que a nossa capacidade de entrega”. O NÃO é o meio para garantir que foquemos nossa capacidade nas principais demandas. Ele gera discussões importantes para o amadurecimento do produto e dos profissionais envolvidos.

Desenvolver produtos de software exige muitos “NÃOS” e eles são necessários para desenvolver produtos enxutos e evitar desperdícios!

P.O. surpreso na Review? E agora?

Frequentemente nas minhas aulas, tenho ouvido a seguinte frase: “na reunião de Sprint Review, o Product Owner aceita ou rejeita o incremento de produto desenvolvido pelo time na Sprint”.

Sempre que ouço essa frase, paro tudo e começo uma boa conversa com os alunos para colocar as coisas no devido lugar.

Trabalhando como Product Owner desde 2008, acho muito estranho que essa frase ainda seja dita por aí como se o papel do time na reunião de Sprint Review fosse conseguir a Aprovação do Product Owner para os itens desenvolvidos. Esse pensamento ainda revela algumas outras disfunções que normalmente ficam ali escondidas no time.

Então vamos por partes:

  • Para começo de conversa, é preciso lembrar que, P.O. que se preza, senta junto com o time durante a Sprint. Então, se o P.O. está ali junto do time, por que cargas d’água a criatura resolve dar uma olhadinha no que o time produziu apenas na Sprint Review? Por que o P.O. não aproveita a proximidade com o time e colabora ao longo da Sprint para ver como as coisas estão ficando e aproveitar para ajudar o time a promover pequenos ajustes no rumo? Mas atenção: P.O. tá ali pra colaborar! Não para cobrar, exigir, mudar tudo, dar uma de chefe e ser cri-cri;
  • Outro ponto é a Definição de Pronto (Definition of Done). Definition of Done (DoD) é um acordo entre os membros do Time de Desenvolvimento e o Product Owner sobre o que Pronto significa. Se você tem uma DoD bem construída e que foi fruto de muita conversa entre todos, ela deveria bastar para que o Time de Desenvolvimento possa dizer que algo está pronto. Por que então o Product Owner teria que fazer um double check? Isso não faz o menor sentido! E tem mais: se a definition of Done não está boa o suficiente, que tal usar a Retrospectiva para inspeção e adaptação?
  • O último ponto é: na Sprint Review o Product Owner convida os stakeholders mais importantes/relevantes para que seja possível dar visibilidade sobre o andamento do trabalho e principalmente coletar seu feedback (veja no nosso post “Aprovação ou Feedback?”). Assim, que sentido tem esperar o cliente aparecer para na frente dele dizer que algo não está bom? Não teria sido muito melhor ajustar as coisas ao longo do desenvolvimento e mostrar ainda mais valor entregue na Review?

O fato é que Product Owner que só aparece na Sprint Review e ainda critica o trabalho do Time na frente do cliente acaba demonstrando que não fez a sua parte ao longo da Sprint.  Então, meu amigo P.O., se você quer saber se anda fazendo seu trabalho direitinho ou não, eu proponho um rápido teste: se você está numa Sprint Review e o que está sendo apresentado pelo Time é uma surpresa para você, bingo! Você é um Product Owner ausente e isso pode gerar uma série de disfunções que acabam por atrapalhar a vida de todo mundo.

Product Owner Surpreso

E para fechar quero deixar bem claro: Product Owner é parte do Time sim. Product Owner de verdade senta junto, almoça junto, comemora e sofre junto com o Time e é claro, participa da Retrospectiva já que a melhoria contínua é para todo o Time de Scrum e não apenas para o Time de Desenvolvimento como muita gente ainda prega por aí. Mas opa! Isso é assunto para um próximo post! 🙂

Click here to read this post in english.

Coaching the agile coach

Aprendi na K21 a entender que, para atingir resultados na transformação ágil “, é necessário estar atento aos quatro domínios da agilidade: Negócio, Cultural, Organizacional e Técnico. Então, para ser um bom agile coach, preciso saber quais são minhas competências em cada um destes domínios. Mas como saber isso?

O Rodrigo de Toledo respondeu a essa pergunta através da ferramenta Coaching the Coach. Apresento a ferramenta a seguir.

Coaching the coach

Os quatro domínios da agilidade precisam ser trabalhados em todos os níveis da organização, separando o trabalho do coach em:

  • individual: coach com pessoas da organização;
  • time: coach em time ou subtimes;
  • empresa: coach na organização como um todo.  

Então, monta-se uma matriz que permita a autoavaliação, ligando a atuação em cada um dos domínios e o nível empresarial, como na figura abaixo.  

Coaching the coach

Preenchendo a matriz

Olhar e entender os quatro domínios é importante na hora de preencher. Um exemplo sobre eles:

A legenda foi montada baseada em como usamos na K21 e gostamos de separar em formas de conhecimento:

  • domino sozinho: conheço dos assuntos e já fiz isso antes;
  • prefiro em par: conheço do assunto, já pratiquei, mas não estou seguro de fazer sozinho;
  • em par para aprender: nunca fiz mas quero aprender;
  • não conte comigo: não tenho interesse neste momento.

Exemplo:

Coaching the coach exemplo

Lendo o resultado

Considerando a matriz:

  • quais conhecimentos ou práticas faltam para ficar mais seguro para atuar nos campos em azul?
  • No amarelo, o que preciso estudar antes de parear? O que vou fazer para criar oportunidades de entrar nesse tipo de cenário para aprender?
  • Não quero mesmo conseguir atuar na parte técnica em nível empresarial?

Outra forma de ler, que gosto muito, é:

  • estou atuando fortemente nos itens que estão verdes?
  • Será que a organização que estou precisa que eu faça isso e não estou fazendo?

Usando a ferramenta em coach com colegas

Usei ela com alguns colegas. Eis alguns resultados:

  • um descobriu que o conhecimento dele na área de negócios não estava de acordo com o esperado por ele e pela empresa. Sendo assim, esse colega traçou um plano de ação para evoluir neste domínio;
  • outro caso foi a descoberta de que o coach era muito bom em mudança organizacional. Porém, ele não visualizava isso. O mais interessante é que a organização atual em que ele trabalha precisa muito desse tipo de ajuda. Ou seja, é só colocar o conhecimento em prática.

E aí, bora bater um papo sobre Agile Coaching?

Deixe seu comentário.

Liquidando a dívida técnica

A expressão “tech debit” ou dívida técnica foi utilizada pela primeira vez por Ward Cunningham criando a analogia de que as vezes podemos fazer dívidas, como por exemplo tomar algum dinheiro emprestado do banco, o que acumula juros e faz a dívida naturalmente crescer, mas que em algum momento precisaremos nos planejar pagá-la.

Pra quem nunca teve contato com essa expressão, Martin Fowler escreveu esse post em 2003.

Toda dívida gera juros (vide dívida técnica e juros composto) e existem algumas formas de lidar com a dívida. Aqui vou listar algumas delas.

Parking Lot

Reserve uma área no quadro físico com uma quantidade limitada de espaços. Cada nova dívida deve ser registrada em um postit e colocado em um destes espaços. Quando acabarem os espaços o time não poderá fazer novas dívidas. O time precisa resolver algum dos itens antes de criar novas dívidas.

parking lot

Lane para dívidas

Crie uma nova lane no quadro físico do time. Apenas postits de dívidas técnicas devem caminhar por esta lane. Estimule o time a sempre ter pelo menos um item caminhando nesta lane.

Esta abordagem torna fácil de perceber visualmente se o time está trabalhando em suas dívidas técnicas.

Esta forma ajuda a evitar que as dívidas se acumulem, porém o time pode acabar trabalhando em dívidas que não são tão valiosas.

Sprint de reforço

sprint-reforco

Sprint de reforço, ou Hardening Sprint, é uma sprint onde nenhuma feature nova é desenvolvida. O time trabalha apenas em melhorias no software como por exemplo refatoração, testes automatizados e melhorias de performance. O post “Do We Need a Hardening Sprint? na Scrum Alliance aborda um pouco sobre este tópico.

Eu diria que uma sprint de reforço é como usar o 13º pra pagar as dívidas, você sabe que as dívidas estão lá, mas você espera uma oportunidade e gasta uma boa grana para quitá-las.

Limite de crédito

Imagine que o time tem um cartão de crédito com limite definido. Cada nova dívida técnica é uma compra neste cartão. Sempre que tiver uma oportunidade, “sobrar uma grana”, o time pode quitar uma parte desta dívida, como se adiantasse o valor do cartão de crédito. Se o time extrapolar o limite do cartão de crédito ele não poderá mais fazer compras. Neste caso o time precisa pagar o valor mínimo da fatura para voltar a usar o cartão de crédito.pagamento-minimo

Realizar apenas o pagamento mínimo vai deixar o time eternamente pagando juros, ou seja, para cada nova feature vários ajustes serão necessários, retardando o time.

Assim como no cartão de crédito que precisa ser pago mensalmente, o time pode definir uma periodicidade para zerar a dívida.

Trabalhar com valores em dinheiro ajuda a manter a analogia clara. O time deve definir um valor em dinheiro para cada compra, um valor de limite para o cartão e quantos % do limite é o pagamento mínimo da fatura.

Esta forma dá ao time flexibilidade para escolher pagar logo algumas das dívidas usando a capacidade que tem disponível e ainda o mantém constantemente preocupado em não estourar o limite, evitando que as dívidas se acumulem.

Conclusão

Fazer dívidas pode ser uma opção para atingir um objetivo, mas é importante manter a saúde financeira. Pagar esta dívida recorrentemente garante juros menores. Mas não acompanhar as dívidas técnicas pode significar quanto vai pagar de juros ou a morte do seu software.

pagamento-recorrente
E você, está liquidando suas dívidas técnicas ou vai decretar falência?

Retrospectiva “Sentimentos e Caminhos”

É grande o número de pessoas que reclamam da falta de engajamento da equipe nas retrospectivas. O papel do facilitador na cerimônia é guiar os participantes aos resultados desejados. Ajudá-los a criar, entender e aceitá-los. Portanto, também é dever do facilitador ser criativo. O modelo “Pontos Positivos”, “Pontos Negativos” e “Melhorias” não motiva mais nem o próprio Scrum Master. Criemos nós, então, novas maneiras de fazer retrospectivas. É com este princípio que criamos dinâmicas contextualizadas. Neste post apresentarei a retrospectiva “Sentimentos e Caminhos”.

“Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário…” – Manifesto Ágil

Contexto

Estávamos, Lula e eu, em um time que passou por muitas experiências diferentes em um curto período de tempo. Percebi que existiam sentimentos variados no ar, e vi a necessidade das pessoas pensarem no time e em como estas estão se relacionando e lidando com os sentimentos uns dos outros.

“Indivíduos e interação entre eles mais que processos e ferramentas” – Manifesto Ágil

A atividade

Passo 1

O primeiro passo é pedir para todos os participantes colocarem os sentimentos deste período em post-its. Um post-it por sentimento. Conforme os post-its vão sendo colados, nós, facilitadores, vamos agrupando os sentimentos parecidos no topo do quadro.

caminhoparaossentimentos_sentimentos

A facilitação visual é um passo importante para o engajamento dos participantes. Desenhos simples como círculos em volta dos grupos de post-its, ou mesmo um ícone que represente a palavra “sentimentos” são sutis, mas geram uma boa motivação.

Passo 2

No passo seguinte, desenhamos os membros do time na parte de baixo do quadro. Alguns palito-men mal desenhados garantem umas boas risadas. Entre o time e os grupos de sentimentos desenhamos caminhos e pedimos para em duplas ou trios os participantes colocarem em post-its menores quais foram as ações ou eventos que nos levaram àqueles sentimentos.

caminhoparaossentimentos

Os resultados geralmente são interessantes. Aparecem tanto eventos marcantes para todos quanto ações isoladas que afetaram individualmente um ou outro membro do time das quais poucos tinham conhecimento.

Passo 3

Passamos a partir daí a um bate-papo, refletindo em conjunto sobre quais destas ações/eventos foram as mais importantes, e traçando possíveis planos de ação.

Durante a execução da retrospectiva, inspeção e adaptação são as palavras-chave para o sucesso da facilitação.

“Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.” – Manifesto Ágil

Geralmente as pessoas saem energizadas desta atividade e várias fichas caem durante ela. Comportamentos desejados são fortalecidos, e indesejados desincentivados. Uma boa atividade para entender como usar os sentimentos para atingir melhores resultados como equipe.

Agilidade e o Assédio Moral no trabalho

Aqui vamos abordar o tema de ambientes de trabalho hostis para os indivíduos e como a agilidade desempenha um papel forte contra padrões que sustentam o Assédio Moral. 

Mas o que exatamente seria uma ameaça dentro de um ambiente de trabalho? Perder o emprego? Ficar sem salário? Não gostar do trabalho que faz? Receber um tratamento ríspido?

Alguns Exemplos

Alguns exemplos de frases ditas de um gestor para um funcionário:

“Estagiário só faz M****”

“Mas isso é muito fácil, até eu sei fazer!”

“Se você errar não posso confiar em você.”

“Aqui você tem que saber o seu lugar”

Você tirou a empresa da M**** e colocou na lama”

“Você não é nada aqui dentro”

“Não te pago pra pensar”

agilidade-e-o-assedio-moral-no-trabalho-2

Algumas frases são fortes e outras comuns, porém nada que você ache impossível de ser dito em um escritório. É assustador como isso acontece sistematicamente num ambiente tão importante com o ambiente de trabalho. Por isso, vamos falar um pouco sobre este ambiente antes de seguir em frente.

Qual o Valor do seu Trabalho?

O seu trabalho é de fato importante? O que importa nele para você?

Tirando a resposta mais óbvia que seria a manutenção financeira, para você, o que tem no trabalho que te torna humano?

Se procurarmos nas áreas de estudo que focam neste tópico como psicologia, sociologia ou filosofia, existem muitas ideias que sustentam que o trabalho ocupa uma parte fundamental na vida humana e na formação do indivíduo.

Vai muito além do salário, ou de como hoje a nossa sociedade se organiza.Tem a ver com realização pessoal, com sentir-se útil, encontrar sentido para os dias e um propósito para o futuro.

O trabalho constitui uma boa parte da nossa identidade.

Isto é simples de perceber quando somos apresentados a uma pessoa nova, ou quando perguntamos “quem é ele?” Quase sempre a resposta estará relacionada ao trabalho dela: “ele é desenvolvedor na empresa Xpto”, “ela é pediatra”. O trabalho diz muito sobre quem você é.

Max Weber abordou o tema em uma frase simples e bem conhecida: O trabalho dignifica o homem.

Mas o que é exatamente dignidade? A etimologia da palavra resume bem: dignitas: “o que tem valor”

Portanto, o trabalho é uma atividade crítica para:

  • Formar a sua identidade.
  • Fomentar a sua dignidade.
  • Buscar o seu propósito.

Se o trabalho é tão importante assim, o que acontece quando ele não cultiva mas também ameaça esses pilares?

É como se de repente a comida te envenenasse, a água te desse sede ou sua própria casa não lhe protegesse da chuva. Estamos chegando na ameaça na qual gostaríamos de apontar os holofotes.

A Ameaça

Dado este contexto destrutivo, uma pergunta fundamental surge:

O que acontece com um ser humano quando ele perde a sua identidade, valor e propósito?

Os sintomas psicológicos mais conhecidos são estresse, ansiedade e depressão. Levando a argumentação para um lado extremo, podemos dizer que, de certa forma, o indivíduo se torna menos humano. Abaixo, estão alguns comportamentos que são observados:

  • Inércia: Faz com que a pessoa não reaja às situações, não procure ajuda ou, por exemplo, não mude de emprego. Isso pode acontecer inicialmente por algum medo ou segurança em achar que dá pra aguentar a pressão o que no fundo a deixa com uma paralisia moral.
  • Personificação: As ofensas acabam sendo aceitas pelo indivíduo. Ele acaba acreditando que de fato é ruim em determinada atividade ou que nunca está apto para cumprir qualquer tarefa, estimulando-o assim a se anular.
  • Perda de identidade: Juntando os dois itens acima, podemos chegar em um cenário em que o indivíduo e o papel que ele exerce se tornam uma coisa só. É como se ele não existisse fora do contexto de trabalho, sendo exatamente o que faz, faz tudo que lhe é atribuído, não questiona. Ele acaba se tornando um móvel, um recurso, uma máquina para a empresa onde trabalha.
  • Suicídio: O último comportamento em cenários mais graves é recorrer a medidas desesperadas buscando o alívio por trás da ideia de deixar de existir por completo.

Assédio Moral

Todo esse padrão de comportamento prejudicial no ambiente de trabalho são característicos do assédio moral.

Este termo pode ser visto com alguns preconceitos, sendo muitas vezes ignorado por completo ou abordado por uma ótica simplista e prática. Se já aconteceu com você, seria muito simples e ingênuo acreditar que a culpa está exclusivamente no seu agressor, mas ele, assim como você, é apenas um ator na cena que constituiu o assédio.

Em geral não se trata de um problema isolado dentro de uma empresa, mas sim de toda uma cultura deteriorada que dá base para que isso aconteça. Investigando características culturais com mais proximidade é comum encontrar itens como:

  • Lucro a qualquer custo;
  • Prazos rigorosos;
  • Punição por não alcançar meta;
  • Ritmo de trabalho insustentável;
  • Assédio como forma de gestão;
  • Excesso de controle;

Como você deve imaginar esse problema é global e visível em empresas de qualquer setor.

A socióloga Valquíria Padilha tem um caso de estudo no setor bancário que diz:

em 2013, 66% dos bancários relataram sofrer assédio moral no trabalho. 80% destes passaram por situações constrangedoras no trabalho pelo menos uma vez por semana. Em 2009, houve uma tentativa de suicídio por dia no setor bancário.

A maior causa de assédio moral é a pressão por metas.

O maior problema dessa maneira de gerir não é a eficiência baixa, mas sim a morte de pessoas.

Onde entra a Agilidade

A agilidade forma uma cultura inovadora voltada para o trabalho. Seus valores e princípios estão descritos no manifesto ágil e surgiram no contexto de desenvolvimento de software.

Em ambientes de trabalho que já tem um mindset ágil, não deveria existir espaço para casos de assédio moral.

Você acha possível uma empresa ter a cultura ágil mas ainda existir assédio moral dentro dela?

Caso ache possível, será que essa empresa pode estar usando práticas ágeis que são ótimas para o negócio e produtivas para a operação mas estar sendo relapsa em um assunto de igual importância para a agilidade?

Uma ideia comum vista na agilidade é a de que felicidade é mais importante que valor, já que o próprio valor para o negócio, em geral, implica em proporcionar felicidade para algum cliente. E entregar felicidade sem ter felicidade internamente é algo improvável.
agilidade-e-o-assedio-moral-no-trabalho-4

Não deveríamos estar buscando: Individuals and interactions over whatever?

Existe algo mais relevante na agilidade do que eficácia no processo produtivo. Entregar valor é uma otimização local. O maior benefício é como mudamos a relação das pessoas com o trabalho.

Ferramentas ágeis

E agora? O que pode ser feito?

Com algumas ferramentas e práticas ágeis temos soluções diretas contra a cultura do assédio moral.

Management 3.0

Uma coleção grande de práticas de gestão que se contrapõem à cultura de comando e controle e traz diversas práticas como por exemplo: Delegation Board, Moving Motivators e Meddlers.

Kanban

Uma ferramenta que pode evidenciar gargalos no processo, e por ter a cultura Lean no seu core, traz uma visão diferenciada sobre as entregas, e deixam mais claros os propósitos de todos envolvidos na cadeia de valor. Kanban também aborda o tema da alocação 100% e como ela é fortemente desaconselhada.

OKR

Notoriamente usado pelo Google, trata-se de um modelo de como organizar metas de uma forma mais concreta, objetiva e inclusiva, se contrapondo à modelos opressores de cobrança e que em geral não levam a empresa a lugar nenhum.

O tema pode parecer distante da nossa rotina, ou até inexistente, mas por ser ainda um tabu faz dele um problema silencioso. Entendo que agilidade tem proporcionado uma mudança drástica na relação das pessoas com o trabalho e, certamente, é um caminho que deve ser experimentado em todas as empresas que sofrem dessa doença.

Mindset Ágil para o Marketing

Imagine um extenso planejamento de Marketing, detalhado e que levou meses para ser realizado. Páginas e mais páginas de relatório cheio de tabelas e análises. Projeções financeiras e prazos. Tudo exatamente como manda um manual de plano de negócios tradicional.

Pois é. Este é o mindset que foi ensinado a muitos de nós e que ainda hoje é amplamente difundido. Mas hoje em dia, será que esses planos detalhadamente documentados são realmente necessários?

Não, a resposta é não. O Manifesto Ágil já dizia que muito mais vale se adaptar às mudanças do que seguir um plano. E principalmente no caso do Marketing, testar, medir e aprender de maneira iterativa é muito mais importante do que planos extensos embasados em hipóteses e premissas não validadas.

Assim, esse ciclo de testar, medir e aprender gerou um novo mindset dentro do Marketing. E este novo mindset tem sido chamado de Growth Hacking Marketing.design-sem-nome

Como afirmou Aaron Ginn, um escritor e colunista sobre Growth Hacking, “o objetivo final de todo growth hacker é construir uma máquina de marketing auto-suficiente que alcance inúmeras pessoas por conta própria.”

Podemos então definir um growth hacker como alguém que pensa de maneira muito mais objetiva, focada em testes e métricas, buscando sempre  medir, de alguma forma, o alcance de suas ações. Basicamente, o growth hacker é alguém que substituiu as instruções do marketing tradicional somente pelo o que é testável, rastreável e escalável.

Quer uma prova de que isto tem funcionado? Aí vão algumas: Dropbox, Facebook, Twitter, Instagram, Uber, Groupon, Hotmail, entre muitas outras. Já tentou somar o valor atual de mercado dessas empresas? Se for tentar, sugiro que pegue uma calculadora de muitos dígitos.

Todas essas empresas, sem exceção, cresceram sem gastar grandes quantias com propaganda e ações de marketing mirabolantes. Tudo focado apenas em ações específicas, mirando sempre nos chamados “early adopters” e com foco total na qualidade do seu produto e muita criatividade.

O grande diferencial  delas é a concentração do seu tempo, seus recursos e sua energia no ciclo de melhoria contínua de seus produtos, mais especificamente no ciclo de “lean startup”.

lean-startup-blog

Através dessas interações do lean startup, essas empresas geram melhorias reais e incrementais para seus produtos. Com um produto cada vez melhor e direcionado para o público certo, o marketing passa a ser uma consequência.

Praticar o Growth Hacking Marketing então nada mais é do que alcançar o seu público alvo de forma eficiente, extraindo métricas, informações e aprendizados visando melhorar o seu produto e fidelizar clientes.

Existem diversas técnicas muito interessantes de Growth Hacking que vale você conferir. Uma ótima leitura introdutória sobre o tema é o livro “Growth Hacking Marketing” (Ryan Holliday). Rápida, fácil e bem interessante! Além dela, outras fontes muito legais para você beber são Quora – Growth HackingGrowth HackersAndrew Chen (Growth at Uber).

Mas o principal objetivo deste post é mostrar que o Growth Hacking vai muito além de técnicas, testes e métricas. Growth Hacking é mudança de mindset! Em um mundo conectado onde muitas coisas mudam muito rápido, planejamentos engessados, inchados e caros já não funcionam mais. Você precisa ser rápido para se adaptar! Você precisa ser Ágil!

Gastar milhões em planos que não conseguem ser mensurados e rastreados de forma concreta não é eficiente. Argumentos como “adquirimos mind share” sem a apresentação concreta de retorno de valor para o negócio já  não são mais aceitos. Não podemos mais desperdiçar tanto dinheiro, tempo e energia em coisas que não agregam valor para o nosso negócio.

Praticar um marketing eficiente hoje em dia significa interações contínuas com o mercado para testar e validar de seu produto. Muito mais importante do que empurrar um produto para o mercado de massa é investir num produto cada vez melhor para seu público alvo.

Para exemplificar como até empresas muito tradicionais estão revendo sua forma de pensar o marketing, no mês de agosto, o Mc Donald’s trocou sua agência publicitária nos EUA, a agência Leo Burnett pela Omnicon. Pelo acordo, o grupo Omnicom será remunerado unicamente com base em receitas geradas por resultados específicos. Nada de bonificação por volume ou qualquer outra forma de remuneração clássica do mercado publicitário. A mensagem é clara: entregue resultados reais e mensuráveis ou saia sem um centavo.

Esqueça grandes budgets para queimar, grandes planos de marketing ou coisas assim. Get out of the building! Busque sistematizar suas interações com o mercado, colher aprendizados e melhorar o seu produto. Muitas das vezes, investir em seu produto pode ser o melhor investimento de marketing que você pode fazer.