6 Mitos do Desenvolvimento de Produtos

6 anos de uns dos artigos mais tops que já li. Duas conclusões: 1ª extremamente atual e 2ª muitas organizações não aprenderam ainda!!

Mito 1 – A alta utilização dos recursos irá aumentar a performance – Tem chefe que acha que knowledge worker é manufatura. Na indústria aumentar 5% de uma máquina, obviamente aumenta 5% na produção. Para trabalhadores do conhecimento, aumentar 5% poder significar um aumento incalculável na produção. Precisamos entender mais de filas e variabilidade.

Mito 2: Processar o trabalho em grandes lotes melhora a economia do processo de desenvolvimento – Sua produção está condicionada ao tamanho dos lotes. Um lote menor vai te possibilitar colher feedbacks mais rápidos e se errar, erra pouco. Diminua o tamanho do seu lote. Isso pra mim é o cerne da agilidade.

Mito 3: Nosso plano de desenvolvimento é ótimo; nós só precisamos nos ater a isso – Já dizia o Manifesto Ágil: Responder a mudança, mais que seguir o plano. As mudanças se forem para agregar e maximizar o ROI do seu cliente são muito bem vindas. Os planos mudam, isso é natural. O que você precisa medir é a velocidade com que se adequa a eles.

Mito 4: Quanto mais cedo o projeto for iniciado, mais cedo será concluído – Pura mentira!! Se uma empresa embarcar em um projeto antes de ter os recursos para seguir em frente, ele tropeçará lentamente no processo de desenvolvimento. Quanto mais lento um projeto progride, maior a probabilidade de que ele seja redirecionado. Esqueçam esse mito que na agilidade não há planejamento.

Mito 5: Quanto mais recursos colocamos em um produto, mais os clientes vão gostar – Esse não precisa comentar, mas precisamos ampliar nossa capacidade de dizer “não”. Olhe atentamente os desperdícios e saiba que o seu cliente não está disposto a pagar pelo que ele não vai usar.

Mito 6: Seremos mais bem-sucedidos se acertarmos na primeira vez – Muitos chefes querem que suas equipes acertem na primeira vez. Isso causa uma enorme pressão. Para evitar cometer erros, as equipes seguem um processo linear no qual cada estágio (especifique, projete, construa, teste, escala, lançamento) seja cuidadosamente monitorado na revisão “portões”. O trabalho na próxima etapa não pode começar até que o projeto passe pelo portão. Com o que isso se parece?

Segue o link do artigo: https://hbr.org/2012/05/six-myths-of-product-development

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

A Retrospectiva GameStorm

GameStorm é uma técnica de brainstorming desenvolvida por Bart Hufen da  BrandNewGame. Utiliza gamification com o objetivo de identificar áreas para melhoria e tornar seu impacto transparente. Nós fizemos uma adaptação para uso em Retrospectivas Sprint e melhoria contínua nas equipes. Este formato é excelente para uma série de Retrospectivas de Sprint focados em um desafio recorrente e torna muito transparente o que precisa ser melhorado e como.

Os créditos completos para a forma do game vão para  BrandNewGame  – nós apenas o simplificamos para uso em Retrospectivos Sprint. Você pode obter todos os materiais oficiais do GameStorm (e muitas técnicas de jogo e ferramentas digitais), tornando-se membro da Gamification Academy. Junte-se ao seu  próximo treinamento nos dias 21 e 22 de março ou em setembro para aprender a aplicar este jogo a mudanças organizacionais e obter mais jogos. Ele se encaixa perfeitamente com o Scrum.

Material

  • Uma sala com uma grande mesa no meio e espaço para se mover;
  • Um GameStorm-canvas (modelo abaixo) por grupo;
  • Post-its laranjas e rosas;
  • Pincéis ou canetinhas;
  • Dois relógios para marcar o tempo;

O canvas do GameStorm

Abaixo, compartilhamos um canvas do GameStorm vazio. Este não é o oficial que a BrandNewGame usa, é uma versão personalizada que usamos para as  Retrospectivas.

No final da Retrospectiva, a tela deve conter o seguinte:

  • Post-it azul: o desafio global que a equipe quer abordar;
  • Post-it’s amarelos na parte superior: os três maiores obstáculos que precisamos abordar;
  • Post-it’s rosas (no canvas eles estão em vermelho): ações para manter o obstáculo no lugar ou fortalecê-lo;
  • Post-it’s laranjas (no canvas eles estão em verde): ações que são necessárias para remover ou reduzir o obstáculo;
  • Post-it’s amarelos na parte inferior: uma definição de sucesso por obstáculo;

Começando

Jogue este jogo com até 12 pessoas. Divida em grupos paralelos se você tiver mais;

Configure a sala com uma grande mesa no meio, com o canvas nela. Crie ainda dois espaços para as duas equipes;

Parte 1 – 30 minutos

  • Identificar coletivamente um desafio abrangente . Alguns exemplos podem ser: “Expandir a coluna “concluído” para incluir a versão testada em produção”, “O Time de Desenvolvimento se manter estável por pelo menos 3 meses” ou “Definir e alcançar os Objetivos da Sprint para as próximos 3 Sprints”. Escreva o desafio no post-it azul no topo;
  • Identificar coletivamente os três maiores obstáculos que precisam ser abordados e escrevê-los nos post-it´s amarelo, diretamente abaixo do post-it azul. Você pode fazer um brainstorming ou usar 1-2-4-ALL  para identificá-los;
  • Peça ao time que determine o valor relativo dos obstáculos. A ideia é dividir 1.000 reais nos três obstáculos: “Quanto é economizado ou obtido pela remoção desses obstáculos?”. Escreva os valores nos três post-it’s amarelos na parte inferior do canvas. Não estamos tentando voar para a lua com esses valores, então não se preocupe em ser preciso;

Parte 2 – 30 minutos

  • Crie duas equipes com tamanhos iguais (4 a 8, sendo 6 o número ideal): Os terroristas identificarão ações ações concretas que a equipe (já) executa e que mantêm os obstáculos no lugar ou os fortalece. Os contra-terroristas identificarão ações concretas que são necessárias para remover ou reduzir o obstáculo;
  • Ambas as equipes tem 15 minutos para identificar as ações dentro de cada obstáculo.  Escreva-os em post-it´s individuais e guarde-os com o seu time, agrupado por obstáculo. Você pode usar 1-2-4-ALL para ser democrático dentro dos grupos e evitar que membros dominantes ou mais extrovertidos influenciem demais os resultados;

Parte 3 – 30 minutos

  • Peça às equipes para mudar fisicamente de lado, o que significa que os Terroristas agora conseguem ver o que os contra-terroristas elaboraram e vice-versa;
  • As equipes tem 10 minutos para  votar nas três principais ações por obstáculo. Os terroristas votam nas três melhores ações sugeridas pelos contra-terroristas, e vice-versa. Peça às equipes que considerem a viabilidade, o impacto e a forma como os itens serão executados.
  • Ambos os times  escolhem as 3 principais ações  por obstáculo e movem para o canvas. O canvas resultante agora deve ter dezoito ações; Nove ações que mantêm obstáculos no lugar, e nove que podem ajudar a removê-los;

Parte 4 – 30 minutos

  • Peça ao grupo que  divida o valor por obstáculo nas seis ações identificadas (laranja e rosa). Então, se os obstáculos na coluna 1 tiverem um valor de 400, a equipe pode dividir 400 reais nas seis ações acima;
  • Determine uma definição de sucesso por obstáculo. Como você pode medir o progresso? Quando você pretende resolver este obstáculo? Faça isso da forma mais tangível possível. Escreva no post-it amarelo na parte inferior do canvas.
  • Agora você tem uma tela com dezoito atividades acionáveis para começar ou parar de fazer, endereçar com soluções os obstáculos e resolver o desafio abrangente. Decida quais itens o time irá pegar primeiro (por exemplo, durante o próximo Sprint). Você pode revisitar e atualizar o Canvas durante a Sprint ou durante as próximas Retrospectivas Sprint – até que o desafio seja resolvido;

Dicas

  • Forneça dinheiro de mentira para a equipe, para tornar o jogo mais divertido;
  • Crie uma tabela  de classificação para promover a competição amigável entre membros ou equipes. Quem completar uma ação laranja ou impedir que uma ação rosa aconteça novamente (conforme decidido por toda a equipe) ganha os pontos atribuídos por essa ação;
  • Crie avatares  para os membros da equipe, ou as próprias equipas se você jogar com mais equipes;
  • Acompanhe os desafios superados pela (s) equipe (s)  criando uma linha de tempo . Você pode até tratá-los como “conquistas” que desbloqueiam as equipes;
  • Para um pouco de diversão,  decorar os cantos para os terroristas e contra-terroristas com os atributos apropriados;

De uma chance!

Nesta forma simplificada, o GameStorm é um formato muito divertido para a série de Retrospectivos Sprint. Isso cria uma concorrência amigável estabelecendo um quadro simples de melhoria. Isso ajuda as equipes a trabalhar desde grandes desafios a atividades pequenas e executáveis ​​que contribuem para resolver o desafio. Também ajuda a criar transparência no que a equipe está melhorando atualmente.

Quer saber mais sobre GameStorm? Junte-se ao seu próximo treinamento nos dias 21 e 22 de março ou em setembro para aprender a aplicar este jogo a mudanças organizacionais e obter técnicas.

Artigo original: https://www.linkedin.com/pulse/gamestorm-retrospective-barry-overeem/

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

1-2-4-Todos – Uma poderosa técnica para melhorar seus eventos Scrum

Liberating Structures são 33 microestruturas que permitem envolver as pessoas em um grupo. Desde extrovertidos a introvertidos, e de líderes até seguidores. Nesta série de postagens, vamos mostrar como o uso das “Liberating Structures” podem ser aplicadas para aprimorar os seus eventos Scrum. Deixe de lado os post-its e os quadros brancos por um momento, e explore novas ideias de facilitação.

1-2-4-Todos é uma das técnicas de facilitação mais aplicadas da coleção Liberating Structure. Em 12 minutos você pode envolver todos simultaneamente na geração de perguntas, ideias e sugestões. Independentemente do tamanho do grupo, você envolverá todos os indivíduos na busca de respostas. Utilizamos esta técnica para nossos treinamentos com 12 participantes, mas também durante seminários com mais de 100 pessoas. A técnica desenvolve conversas abertas e levanta idéias e soluções de forma rápida. O importante são as ideias geradas pelos participantes, que tornará mais fácil o acompanhamento e a implementação.

Nenhuma estratégia de adesão é necessária, simples e elegante!

Neste post, explicaremos o conceito de auto-reflexão e compartilharemos exemplos de como aplicamos 1-2-4-Tudo dentro dos treinamentos Scrum.

Auto-reflexão silenciosa

Uma das partes mais poderosas de 1-2-4-Todos é capturada no 1 minuto de auto-reflexão silenciosa. Durante este minuto, os participantes são convidados a refletir sobre um desafio compartilhado enquadrado como uma questão, por exemplo:

  • Que oportunidades você vê para fazer progresso nesse desafio?
  • Como você lidaria com essa situação?
  • Que ideias ou ações você recomenda?

Tomar tempo para a auto-reflexão silenciosa não é uma prática muito comum em reuniões ou workshops. Muitas vezes uma ou duas pessoas estão falando e o resto está ouvindo. Ou grupos menores estão trabalhando uns com os outros e conversando continuamente, o que também está certo. No entanto, antes de mergulhar em uma conversa sobre um determinado desafio, levar algum tempo para uma auto-reflexão silenciosa é muito útil.

Dá tempo de você se decidir. O que você acha? Como você lidaria com esta situação.

A auto-reflexão silenciosa deve ser feita com todo o grupo, simultaneamente. Como facilitador, esse é um desafio. As pessoas podem considerar o silêncio um pouco estranho e começar a fazer barulho ou a rir nervosamente, o que distrai os outros. Portanto, separe um bom tempo para explicar o propósito e a importância da primeira parte de 1-2-4-Todos. Se você fizer isso bem feito, você criará um silêncio confortável em que a auto-reflexão silenciosa levará às primeiras ideias para lidar com o desafio em questão!

Usos com o Scrum

Utilizamos 1-2-4-Todos para uma série de aplicações, dentro e fora do Scrum:

  • Como parte de um treinamento Scrum para ajudar a definir as metas de aprendizagem. Use o primeiro minuto de auto-reflexão para pensar em objetivos de aprendizagem pessoal. Compartilhe seus objetivos de aprendizagem em pares e posteriormente em um quarteto. Após 10 minutos, os objetivos já refinados são discutidos em grupo, como um todo.
  • Durante a Daily Scrum. A maioria das equipes Scrum usam a Daily Scrum para compartilhar o que fizeram ontem para ajudar a equipe de desenvolvimento a atingir o objetivo da Sprint. O que eles farão hoje e se tem algum impedimento para o desenvolvimento do trabalho. Embora o uso dessas perguntas seja apenas uma recomendação, a maioria das equipes se apega a isso. Eu trabalhei com uma Equipe Scrum que simplesmente respondeu a pergunta “qual seria o melhor resultado que conseguimos alcançar hoje?” e seguindo as etapas 1-2-4-Todos, definiram um plano para as próximas 24 horas.
  • Durante uma Retrospectiva em toda a empresa com participantes que costumavam ser excessivamente influenciados por seu líder. Com 1-2-4-Todos nós asseguramos que todos os envolvidos, as vozes e opiniões sejam ouvidas e apreciadas.
  • Como parte da Sprint Review para reunir comentários sobre o incremento, adaptar o Backlog do produto, inspecionar as prováveis datas de conclusão e analisar as mudanças do mercado e o potencial uso do produto.
  • Durante a Retrospectiva da Sprint para inspecionar como foi a Sprint em relação a pessoas e relacionamentos, também para descobrir como tornar o próximo Sprint mais agradável e adaptar a definição de “Pronto” para aumentar a qualidade do produto.
  • Como um exercício de abertura de um grande seminário. Convidamos mais de 250 pessoas para refletir sobre a questão “Como é um Scrum Master no cargo de gerência?”. Depois de ter discutido todos os resultados em pares e no grupo de quatro pessoas, discutimos os principais pontos com o grupo. Em poucos minutos, todo o grupo estava comprometido e energizado!
  • Para obter feedback (perguntas, comentários e idéias) após uma apresentação. Não faça as “perguntas” usuais, em vez disso use 1-2-4-Todos para obter feedback mais rico.
  • Para redesenhar uma reunião semanal chata com a administração.
  • Para resolver um problema ou uma oportunidade de inovação; 1-2-4-Todos oferece uma estrutura clara para discutir o desafio em questão.

Passo para usar essa estrutura

  1. Comece com 1 minuto de auto-reflexão silenciosa por parte de indivíduos em um desafio compartilhado, enquadrado como uma pergunta;
  2. Utilize 2 minutos para gerar ideias em pares, baseando-se em idéias de auto-reflexão;
  3. Crie grupos de quatro pessoas e use 4 minutos para compartilhar e desenvolver ideias que você tenha discutido com seu par. Observe semelhanças e diferenças.
  4. Utilize 5 minutos para compartilhar as idéias se perguntando “Qual a idéia que se destacou em sua conversa?”. Cada grupo compartilha uma idéia importante. Repita o ciclo conforme necessário.


Figura extraída de: http://www.liberatingstructures.com/1-1-2-4-all/

Utilizar junto com outras estruturas

Uma das principais características das Liberating Structures é que eles podem ser facilmente combinados para criar programas para workshops ou treinamentos inteiros. As opções são infinitas:

Dicas

  • Seja firme na auto-reflexão antes das conversas em duplas;
  • Convide todos a escrever suas idéias durante a auto-reflexão silenciosa;
  • Use um sinal para anunciar as transições;
  • Seja preciso no tempo, faça outras rodadas se necessário;
  • Em grandes grupos na hora do “TODOS”, limite o número de ideias compartilhadas para 3 ou 4;
  • Convide cada grupo para compartilhar informações únicas;
  • Faça idéias visuais; use sua imaginação;
  • Durante a fase do grupo, mantenha apenas uma conversa por vez;
  • Experimente essa variação: passe de 4 para de 8 pessoas nos grupos com o consenso em mente.

Fechamento

Neste artigo, compartilhamos exemplos de como aplicar o 1-2-4-Todos dentro dos nossos compromissos e cerimônias do Scrum. Estamos sempre felizes em ouvir suas experiências de sugestões.

Tradução: Rodrigo Zambon
Texto Original: https://www.linkedin.com/pulse/powerful-technique-improve-your-scrum-events-barry-overeem/

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Como ter sucesso com o Zombie Scrum!

Alguns anos atrás, Christiaan Verwijs e Johannes Schartau inventaram o termo “Zombie-Scrum”. Ele se tornou popular desde o início. Especialmente quando criamos o Blog: blog.zombiescrum.org. Nossa caixa de correio explodiu com solicitações de informações e o Workshop Zombie-Scrum se tornou um fenômeno.

Deixe me dar uma breve explicação sobre o Zombie-Scrum para aqueles que ainda não estão familiarizados com o este tema. À primeira vista, Zombie Scrum parece ser um Scrum normal. Mas falta um coração batendo. As equipes Scrum fazem todos os eventos do Scrum, mas raramente temos um entregável ao final da Sprint. As equipes zumbis tem uma definição pouco ambiciosa do que o “feito” significa e não tem um direcionamento para expandir isso. Eles se veem como uma engrenagem na roda, incapazes de de mudar e causar impacto: estou aqui para codificar! As equipes zumbis não assumem a responsabilidade pela falha ou pelo sucesso de uma Sprint, e também não tem a intenção de melhorar essa situação. Na verdade, ninguém se importa com esse time. As partes interessadas já esqueceram esse time há muito tempo.

Claro que isso parece muito atraente. A popularidade do Zombie-Scrum não é nenhuma surpresa. Esta publicação no blog irá focar em como ter sucesso com equipes de zumbis. O que você precisa realmente ter? Quais são as dicas e truques para iniciar o trabalho com essa equipe? Como tornar isso sustentável? Este artigo irá lhe oferecer algumas recomendações.

Como começar a ter sucesso com as equipes Zombie-Scrum?

Feche as cortinas e apague a luz. As equipes zumbis prosperam na escuridão. Quanto menos transparência e visibilidade melhor. Isso torna a inspeção e a adaptação mais difíceis e desanima a melhoria contínua; o que é ótimo.

Crie a rede entre as equipes zumbis. É difícil entregar valor comercial com apenas uma equipe. Você criará dependências com outras equipes e surgirá a necessidade de mais coordenação. Todos sabemos que mais coordenação significa mais gerenciamento. É uma situação ganha-ganha.

Considere os eventos do Scrum opcionais. Conduza a Daily Scrum duas vezes por semana, o Sprint Review apenas quando houver algo para demo e a Retrospectiva quando houver algum tempo. As equipes zumbis consideram os eventos como reuniões chatas e demoradas.

Gire o Scrum Master a cada Sprint. Crie um item recorrente no Sprint Backlog de 4 horas para cumprir isto.

Comece a usar o objetivo da Sprint. Sim, isso pode parecer “Scrum saudável, mas não se preocupe, se o Sprint Goal for “fazer tudo que está no backlog”, você estará fazendo o Zombie-Scrum perfeitamente!

Promova “a nova forma de trabalhar”. Quem precisa de um espaço para a equipe? A agilidade verdadeira está em trabalhar em um local diferente todos os dias. Sentar-se como uma equipe só irá causar distração.

Contrate novos membros com vagas atraentes. Certifique-se de usar termos populares como “Framework Ágil”, “SCRUM”, ou “Agilidade corporativa”. Você definitivamente atrairá zumbis para sua organização.

Altere continuamente a duração da Sprint. As equipes Zombie-Scrum gostam da falta de um ritmo claro.

Certifique-se de ter um Dono do Produto. Mas isso não é Scrum saudável? Não, porque será um PO sem a visão do produto, sem conhecimento do Scrum, e sem a capacidade de fazer o gerenciamento das partes interessadas. O sucesso do Zombie-Scrum é garantido.

Configure uma ferramenta digital com fluxos de trabalhos complexos para gerenciar o Backlog do Produto. Nomeie o Scrum Master como administrador.

Não use o time-box nos eventos. Nada supera 8 horas de Sprint Planning ou uma Daily de 45 minutos.

Incentive o trabalho em vários projetos. Quem precisa de foco? Lembre-se: quanto mais dependências, melhor.

Configure uma ferramenta de rastreamento de tempo. Registre o tempo individual gasto por tarefa e otimize a utilização dos recursos. Essas ferramentas realmente ajudam você a culpar os membros mais lentos da equipe e promover a cultura do medo.

Ignore e reunião de kick-off. Prometa ter uma, mas cancele um dia antes alegando motivos de economia de tempo. O desapontamento dará um grande impulso ao Zombie-Scrum.

Crie uma equipe pronta. Esta equipe consistirá no Product Owner, Analista de Negócio, Analista de Informação, Arquiteto, etc. Eles prepararão o trabalho para os desenvolvedores. Eles não precisam estar cientes da intenção de cada item do backlog. Eles só precisam construí-lo e não fazer perguntas.

Evite ter alguém de teste nas equipes Scrum. Essa pessoa só aumentará a oportunidade de entregar um incremento “feito”, algo que as equipes zumbis desejam evitar a qualquer custo.

Use sempre o formato padrão para histórias de usuário. Como uma equipe Scrum, sempre queremos usar o formato da história do usuário, mesmo quando não faz sentido.

Incentive o débito técnico. Isso diminuirá a qualidade do incremento e terá impacto “negativo” na velocidade e valor comercial fornecido. As partes interessadas ficarão desapontadas e deixarão de participar da revisão da Sprint. Outra razão para ignorar o Sprint Review.

Promova as transferências. Quanto mais melhor. Diminuirá drasticamente o tempo de execução e aumentará a quantidade de coordenação. Adicionar uma outra camada de gerenciamento é, portanto, uma opção válida.

Incentive o Product Owner a aceitar mais trabalho durante a demonstração. Isso permite que o Product Owner não esteja presente durante a Sprint. Além disso, você não precisa das partes interessadas durante a demonstração. Eles não estão interessados mesmo.

Comece a usar a velocidade como KPI principal para o gerenciamento. A velocidade é um instrumento útil para o gerenciamento para controlar e monitorar a equipe de desenvolvimento. Trabalhando com várias equipes? Não há problema, basta comparar a velocidade das equipes entre si

Estime o backlog do produto em horas. Quem se preocupa com o valor do negócio? É o tempo que importa. O tempo é dinheiro certo?

Não envolva o time na composição do próprio time. Isso apenas incentivará a colaboração e a auto-organização. Isso não é Zombie-Scrum, isso é Scrum saudável.

Respeite os líderes na equipe Scrum. Você precisa de um Desenvolvedor Líder, Arquiteto Líder e Design Líder.

Promova o gerente gaivota. Os gerentes gaivotas voam, fazem muito barulho, bagunçam tudo, depois voam de novo deixando toda essa bagunça para trás. Ele é ótimo para as equipes Zumbis.

Esqueça sobre ter um propósito e uma visão. Estes são conceitos altamente valorizados, apenas promovidos por consultores externos caros.

Você já tem tudo isso? Ótimo! Você está pronto para começar com o seu time zumbi, com uma implementação sustentável.

Vamos começar o primeiro Sprint eterno, mais conhecido como Sprint 0!

Conclusão

Nesta publicação, descrevi como começar o time zumbi. Mais importante: eu dei algumas dicas e truques sobre como torná-lo sustentável. Com certeza, existem muitos outras maneiras de começar a ter sucesso com os times zumbis. Ative sua mentalidade cínica / sarcástica / cética e eu acredito que você encontrará mais dicas e truques.

Você pode se perguntar porque eu escolhi este formato. Bem, às vezes é útil pensar “negativo” em vez de “positivo”. Faça perguntas como “como podemos tornar esta situação ainda pior?”. Uma perspectiva diferente pode levar a insights que você não teria pensado.

Se você tem outras ideias para “ter sucesso” com o Zombie-Scrum, sinta-se à vontade para compartilhá-las. Se você está interessado na oficina de Zombie-Scrum de 4 horas, oferecemos: me avise!

PS: Christiaan Verwijs e Johaness Schartau estão atualmente escrevendo um livro sobre Zombie-Scrum! Se você gosta do tópico e deseja se juntar à resistência Zombie-Scrum e manter-se informado sobre o progresso do livro: inscreva-se no site do Zombie-Scrum.

Texto Original: https://www.linkedin.com/pulse/how-succeed-zombie-scrum-barry-overeem/

Publicado por: Barry Overeem

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Por que “quase” todo mundo vai ter que sair do waterfall?

sair-waterfall-300x205Essa foi a conclusão que chegamos, depois de uma longa conversa que eu tive com os amigos gerentes de projetos: quase todo mundo vai ter que sair do waterfall.

Na verdade queria ter colocado todos, mas para quem é da PNL e conhece um pouco do metamodelo de linguagem, sabe que a palavra “todos” refere-se a uma generalização, sendo um quantificador universal, ou seja, temos que ter cautela em usarmos. Mas deixando de lado a PNL, vamos as possíveis respostas para esta pergunta.

Em 1986, Takeuchi e Nonaka escreveram que o desenvolvimento de novos produtos estava mudando e que na nova fase a ênfase era em velocidade e flexibilidade. Eles ainda completam e dizem que ao invés de trabalhar com métodos antigos, devemos criar interação com a equipe para alcançar o objetivo como uma unidade.

A competição não deve ser encarada apenas em relação a diferenciação dos produtos e a redução de custos, mas o que estava sendo buscado era diminuir o tempo que levava entre a hipótese e a validação, e o tempo de desenvolvimento.

Waterfall

Pensando didaticamente vamos falar um pouco do waterfall, ou o famoso cascata. O projeto neste caso segue fases bem definidas, onde precisamos acabar uma para começar a outra. No modelo tradicional a saída de uma fase é o input da fase seguinte. A teoria diz que devemos planejar o projeto todo de uma vez, fazer o levantamento e o detalhamento de todos os requisitos do projeto no início e montar um extenso cronograma com atividades sucessoras e predecessoras bem definidas.

O maior risco de conduzir o seu projeto desta forma é chegar no final dele e entregar um produto obsoleto, e mesmo com a extensa descrição dos requisitos no início, você pode entregar o que o cliente não quer mais, pois o que foi detalhado é bem diferente das expectativas de hoje. Neste caso você só entrega valor no final do projeto.

Outro ponto são os ajustes periódicos, tanto no time, quanto no processo de desenvolvimento do produto. Melhorar continuamente é papel de todos em uma equipe de projeto. As reuniões para que sejam analisadas a melhor forma de se trabalhar são fundamentais para o bom andamento e motivação da equipe.

Scrum

Os frameworks ágeis adotam a mudança como um diferencial competitivo. Nos modelos tradicionais onde seguir o plano é o objetivo, no mindset ágil o objetivo é entregar valor mais cedo, e neste cenário, as mudanças mesmos que tardias são bem vindas quando falamos de maximizar o ROI dos clientes.

O Scrum é o framework escolhido por duas a cada três pessoas* que adotam metodologias ágeis aderentes ao Manifesto Ágil e estabelece justamente o oposto do método tradicional, onde o produto é desenvolvido em sprints, de forma iterativa e incremental.

Um processo iterativo é aquele que faz progresso através de tentativas sucessivas de refinamento. A cada iteração seu produto ou serviço é melhorado. Um processo incremental é aquele em que o produto é construído e entregue por pedaços. Cada pedaço ou incremento representa uma parte completa do seu produto.

Sendo assim, os dois gráficos abaixo são verdadeiros, o primeiro representa a diminuição drástica do risco e de estarmos fazendo a coisa errada. Os ciclos curtos de feedbacks, dão maior segurança a equipe, tranquilidade ao cliente e minimiza resultados indesejados. O segundo porque entregamos o que gera mais valor primeiro, e nosso cliente começa a usar o produto o quanto antes. O retorno sobre o investimento acontece logo no início do projeto.

grafico

Procurei escrever de forma bem simples para explicar as principais diferenças. E antes de terminar vou justificar o porquê da palavra “quase” no título do artigo. Nas discussões waterfall x agile me deparo frequentemente com a pergunta: “mas e aquele cara que está construindo uma plataforma de petróleo, dá pra usar ágil”, eu respondo que é possível usar nos times, mas este é um cenário previsível e o modelo tradicional se encaixa bem. Em dezembro de 2014 a Petrobras operava 45** plataformas flutuantes e se você foi ou ainda é um destes gerentes, pode continuar no waterfall!

* (VersionOne, 2016).

** https://www.conversaafiada.com.br/economia/2015/01/15/petrobras-tem-o-maior-numero-de-plataformas-no-mundo

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Distanásia em Projetos

Eu e minha esposa temos o hábito de conversar sobre o trabalho um do outro quando chegamos em casa. Certo dia conversa vai, conversa vem e eis que surge o termo: distanásia! Na hora parei, pois não conhecia o significado e obtive a seguinte definição: distanásia é uma prática de prolongar a vida de um paciente considerado pela medicina incurável ou sem chances de recuperação. Inevitável para mim não associar isso a projetos! Quantos projetos conhecemos que estão em fase terminal e mesmo assim continuamos a investir nele?

Pesquisando um pouco mais sobre o termo, o Wikipédia apresenta a seguinte definição:

Distanásia é a prática pela qual se prolonga, através de meios artificiais e desproporcionais, a vida de um enfermo incurável.

No mundo dos projetos o que mais vemos por aí são projetos inúteis que nem sequer sabemos por que e para quem estamos fazendo aquilo. Projetos obsoletos ou que já foram superados por uma tecnologia mais avançada, continuam em nossas carteiras. Projetos com desvios de cronograma em 70, 150, 250% que mesmo assim continuam sendo repactuados, com a intenção de que um dia ele seja concluído.

A pergunta é: para que prolongar projetos desta natureza? Se já não faz mais sentido entregar tal projeto, por que continuar investindo?

Nestes casos a mudança de mindset é fundamental e obrigatória, e passa pela célebre frase de Peter Drucker: “Não há nada tão inútil quanto fazer com grande eficiência algo que não deveria ser feito”, ou pela citação de Russel Ackoff “Quanto mais certo fazemos a coisa errada, mais errados nos tornamos”. Precisamos, antes de investir maiores esforços nos projetos, validar a nossa hipótese, ou seja, mudar o paradigma da eficiência para a eficácia e saber de fato se aquilo é o certo a se fazer.

O fato é que as pessoas são resistentes a mudança e o excesso de otimismo atrapalha um pouco. Trocamos o time, contratamos consultoria, pedimos mais recursos e fazemos de tudo para não deixar aquele projeto morrer, sendo que nada mais adianta. Ainda há o apego emocional a determinados projetos até mesmo pessoal quando ao invés do cliente, são os gerentes que julgam se aquele projeto deve ou não ser feito.

E como vamos fugir dessa armadilha? Vou trazer três boas práticas aqui que entendo como essenciais para não chegarmos a esse ponto:

Fail fast: se você tem que falhar, que falhe logo e aprenda com isso. No Brasil essa cultura ainda é pouco explorada, pois errar aqui é muito caro. Outra observação é que ninguém gosta de errar, mas é melhor perder pouco e aprender do que investir demais e perder muito lá na frente.

Ciclos de feedback: trabalhe constantemente com o seu cliente. Peça a ele feedbacks do avanço do seu trabalho, essa pratica diminui o risco. É muito melhor já ir fazendo o certo desde o começo. Imagine um projeto com apenas uma entrega final, o risco do erro é muito maior.

Validar hipóteses: Temos muitas ideias de novos projetos, novos requisitos. Uma extensa lista no backlog. Será que tudo que está ali precisa ser feito? No Software Zen a fórmula é a seguinte: ? min(t) !, onde o ponto de interrogação é a sua hipótese, o ponto de exclamação é a sua hipótese validada e entre um e outro está o tempo. Quanto antes validar, melhor.

Evite o desperdício, não prolongue a vida de um projeto fadado ao fracasso. Quantos milhões são gastos anualmente para corrigir falhas ou repactuar projetos? Você não vai acertar sempre, mas pode aumentar muito este percentual.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Por que somos tão apegados a estimativas?

A pergunta do título remete a uma realidade presente em 100% dos projetos. Digo 100% com toda certeza e se você tiver um projeto que tenha visto ou participado em que uma estimativa de prazo não tenha sido cobrada por favor me mande um e-mail, eu gostaria muito de conhecer esta equipe.

A verdade é que ficamos até mais calmos quando um gerente ou alguém da equipe nos dá um prazo. É tudo que queremos não é mesmo? Ufa! É uma sensação de alívio, até que aquele dia chega e as expectativas são frustradas.

Vamos pensar no seguinte exemplo: hoje é segunda e a estimativa é que determinada tarefa leve três dias para ficar pronta. Isso significa que estará pronta na quinta? Não, pois tendemos a dar apenas o tempo que vamos permanecer na tarefa, e muitas vezes não levamos em conta o waiting time.

Ao perguntarmos as estimativas a um gerente ou alguém da equipe sobre quando um projeto ou mesmo uma tarefa vai ficar pronta, podemos entender essa resposta como um compromisso, uma promessa? É claro que não! Vamos as explicações.

Pelo dicionário Houassis, mais famoso da língua portuguesa temos a presente definição para a palavra estimativa:

  avaliação ou cálculo aproximado de algo

Nesta definição a palavra aproximado representa muita coisa. Ora, se é aproximado, não significa que precisamos acertar e não vamos acertar mesmo! E ainda, podemos dar um intervalo de tempo que certamente não irá atender a necessidade do cliente, ou patrocinador.

No livro que estou lendo atualmente “No Estimates – How to measure Project progress without estimating”, o autor Vasco Duarte expõe três razões claras que explicam porque estimativas não funcionam:

Lei de Hofstadter

Sempre levará mais tempo do que você espera, mesmo quando se leva em conta esta lei.

Hofstadter observou que mesmo considerando um determinado período de tempo para alguma tarefa, e se você acrescenta um determinado acréscimo por segurança, ainda assim, se levará mais tempo que o previsto. Isso se aplica aos seus projetos?

Lei de Parkinson

O trabalho irá se expandir até completar todo o tempo disponível para ele.

Ele completa dizendo que se você deixar o seu trabalho para o último minuto, ele levará apenas 1 minuto para ser concluído. Agora você me diz: quando você termina sua apresentação para um congresso? Ou quando sua monografia ou tese ficou pronta? Vejo pessoas em congressos terminando as apresentações que vão fazer minutos antes de subir ao palco.

Complicações acidentais

Qualquer item a mais adicionado a um projeto existente, tem dois elementos de custo:

Complicações essenciais: O quão problemático é por si só está adição de escopo?

Complicações acidentais: Decorrentes da burocracia em nossas organizações. Por exemplo: quanto tempo vai levar para obtermos a aprovação dessa adição de escopo? Temos know how para desenvolver ou teremos que contratar? E sobre o orçamento, tem disponível? Certamente esse novo requisito do projeto vai acarretar atrasos e consequentemente custos.

E ainda posso acrescentar mais uma:

Síndrome do Estudante

Tendemos a deixar as coisas para a última hora. Postergamos até o limite para iniciarmos uma determinada atividade.

Quantos estudantes deixam para estudar na véspera de uma prova? Nossa cultura infelizmente ainda funciona assim. A boa notícia é que isso vem mudando gradativamente.

Bom, mas isso significa que não devemos estimar? Não vamos ter estimativas mais nada? Opa!! Não se trata disso. A dica é: não gaste muito tempo com estes exercícios de futurologia. Comece a observar seu time. Veja como foi o trabalho no passado e trace alguns indicadores para medir sua produtividade.  Verifique se seu time está alternando entre projetos e o que está desviando o foco (caixa de entrada, telefone, rede social, slack são ótimos para nos distrair).

Para saber mais:

Accidental Complication: https://vimeo.com/79106557
Lei de Hofstadter: https://pt.wikipedia.org/wiki/Lei_de_Hofstadter
No Estimates: Vasco Duarte: https://www.amazon.com.br/NoEstimates-Measure-Project-Progress-Estimating-ebook/dp/B01FWMSBBK/ref=sr_1_1?s=books&ie=UTF8&qid=1476118235&sr=1-1&keywords=no+estimates+vasco+duarte

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Scrum, Lean, Agile, Kanban: como eles estão relacionados?

Com frequência recebo perguntas de pessoas sobre como o Agile, Lean, Scrum e Kanban estão relacionados entre si. Para aqueles que não gastaram tempo lendo as histórias de origem, estes termos são apenas palavras soltas. Recentemente me deparei com esta imagem que conta muito bem a história e as relações existentes.

Aqui está com eu interpreto essa figura.

Na área de software, na década de 90 eles estavam buscando novas formas para se trabalhar. Os mais conhecidos são o Scrum e a Extreme Programming. Em 2001, 17 pessoas se reuniram para debater as questões que tinham em comum e foi assinado o Manifesto Ágil, momento em que foi cunhado o termo desenvolvimento ágil de software.

Antes, a indústria de transformação no Japão, fortemente influenciada por Edwards Deming, começou a enxergar diferentes formas de se trabalhar. Isto levou ao Sistema Toyota de Produção (TPS), e depois ao Lean Manufacturing.

O sistema de produção do Japão inspirou o artigo “New New Product Development Game”. Este artigo é considerado o ponto de partida do desenvolvimento do framework Scrum, influenciando fortemente os trabalhos de Jeff Sutherland e Ken Schwaber.

O Desenvolvimento Enxuto de Software é exaustivamente escrito por Poppendiecks. Ele utiliza princípios do Lean da indústria da transformação e aplica no desenvolvimento de software. O resultado desta junção influenciou também o desenvolvimento ágil de softwares.

Kanban tem raízes no Lean, no entanto ele também é influenciado pelo Ágil.

Então o que tudo isso significa? Muitas vezes as pessoas querem saber se você trabalha com Ágil, Lean ou kanban? A partir da imagem acima você pode perceber que não há apenas uma resposta. Estas ideias surgiram basicamente ao mesmo tempo com uma grande movimentação de pessoas, o que, sem dúvida, nos levaram a ideias comuns.

Pessoalmente eu acho que vale a pena ler amplamente sobre Lean e Ágil (bem como as outras ferramentas, a inspiração pode vir de qualquer lugar), e em seguida aplicar o que funciona para você.

Basta manter o básico da inspeção e adaptação:

• Mudar uma coisa de cada vez;
• Dê a mudança uma chance (as vezes às coisas pioram antes de melhorar);
• Meça as coisas importantes para verificar se a mudança ajudou ou não;
• Repita

Autora:

Artigo originalmente escrito por Karen Greaves. Tradução: Rodrigo Zambon

Link original do post: http://www.growingagile.co.za/2013/12/scrum-lean-kanban/?utm_source=ReviveOldPost&utm_medium=social&utm_campaign=ReviveOldPost

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

O que é ser ágil?

o-que-e-ser-agil-rodrigo-zambon-mundo-agilRecebo frequentemente algumas dúvidas dos meus alunos e de outros colegas na organização me perguntando o que é ser ágil. E é interessante porque na mesma organização temos culturas locais diferentes que tentam se sobressair frente a cultura geral, aquela adotada pela maioria e já internalizada pelo público externo e sociedade. É claro, estas boas práticas setorizadas aos poucos vão aparecendo e sendo compartilhadas com os demais.

Ágil não é uma prática, em que você vai empregar algumas técnicas e esperar que as coisas aconteçam. Implantar o kanban ou fazer as reuniões diárias ou mesmo de retrospectiva ajudam, e podem sim melhorar o processo, porém não nos tornamos ágeis de uma hora para a outra, aliais essa expressão “tornar ágil” é extremamente perigosa.

Uma organização precisa constantemente rever seus processos, e renovar o ciclo de aprendizado com certa frequência. Os indivíduos precisam se adaptar as mudanças de trabalho e dos cenários. Ser ágil é um processo evolutivo, de continuo aprendizado.

Ao contrário do que muitos pensam, ágil não é entregar rápido, ou que a execução estará livre de defeitos e que a qualidade do produto será alta. Se não gerenciarmos estas variáveis, nosso projeto terá os mesmos problemas se comparado a outros métodos.

Sendo ágil você vai responder a mudanças, ou melhor, não se apegar aos planos como se fossem o certo a se fazer. É se adaptar mais rapidamente as necessidades do cliente. Entender que você, sua equipe são um meio para que o cliente possa crescer e obter valor no investimento que está fazendo. Você e sua equipe foram a melhor escolha que aquele cliente poderia fazer e tinha disponível no momento da contratação. É fundamental a parceria e principalmente entregar o que de fato ele precisa.

Uma outra questão associada a mudança é o custo. Não vamos aprovar ou descartar sem se fazer uma análise ou negociar com o cliente. Se nosso foco é entregar cedo o que representa maior valor, será que as mudanças que vão aparecendo no decorrer do projeto compensam ser entregues? Se o que tem mais valor é entregue no início, o que vem depois teoricamente trará menos benefício. Pode ser que em determinada fase do seu projeto, o cliente alcance o valor pretendido e tudo que venha depois agregue pouco ou nada ao negócio.

Sendo ágil você vai entregar valor continuamente, mas o mais importante desta afirmação é o como você entregará e como seu time está integrado com o cliente e com a organização a que ele pertence. A velha concepção de comando e controle também não irá funcionar aqui. A administração, o cliente e a sociedade precisam acreditar na equipe que está trabalhando no projeto. A autonomia do time na tomada de decisões é fundamental para manter a motivação e o engajamento.

Por último, sendo ágil você trará as lições aprendidas para dentro do projeto. Conforme descrito no manifesto ágil “Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.” Isso vai ajudar seu time a melhorar continuamente, sendo de fato um grupo unido, e qual o lugar deste grupo dentro da organização.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.

Iterações: qual o tamanho?

iteracoes-qual-o-tamanho-rodrigo-zambon-mundo-agilAntes de falar de iterações, vou falar um pouco de escopo e começar com um dado publicado pela Standish Group que diz respeito ao uso das funcionalidades em softwares. Apenas 20% das funcionalidades são utilizadas com frequência, sendo que 80% foram poucas ou nenhuma vez utilizadas1.

A pergunta aqui é: por que isso acontece?

Não só em software, mas em diversos projetos, percebemos que entregamos coisas desnecessárias para o cliente, itens que agregam tão pouco valor que se não estivessem ali, ninguém sentiria falta.

A definição do escopo na abordagem tradicional é feita no início do projeto, e procura-se esgotar o processo. Muitos stakeholders, classificados em uma longa planilha, são ouvidos. As expectativas são levantadas e muitos imaginam que fazendo uma boa definição de escopo o projeto será um sucesso.

Porém na prática isto é um pouco diferente, ou seja, o mapa não é o território2. O quanto antes você encarar a sua realidade melhor. Por isso, no início do projeto, determinar o tamanho das suas iterações pode ser crucial para o sucesso de todo projeto. Pense sempre em primeiro lugar no retorno sobre o investimento do cliente e em segundo, na mitigação dos riscos.

Abraçar cegamente o plano e só ter contato com o cliente no final do projeto certamente é uma estratégia ultrapassada por vários motivos, e como exemplo posso citar os dois principais: só entregar o produto no final e ainda correr o risco de entregar um produto obsoleto.

As iterações mais curtas permitem a equipe do projeto obter feedback mais cedo e consequentemente revisões periódicas com os clientes. Isso irá permitir, primeiro saber se estamos indo para o lugar certo e em segundo se estamos de fato atendendo às necessidades de nossos clientes. A abordagem tradicional atrasa esse tipo de vantagem, até quase sempre, serem irreversíveis. E mais fácil mudar no início onde os custos são mais baratos.

Uma outra vantagem de se ter iterações curtas e adaptadas a realidade do seu projeto é aumentar o foco da equipe. Na abordagem tradicional, faz-se um esforço imenso para se definir é documentar todo o escopo do projeto. Produz-se uma extensa documentação, muitas vezes em processos alucinatórios. Já participei de times que tentavam planejar prazos 5, 6 anos depois da data atual. Acredite 5 ou 6 anos do momento presente em que estamos. Sem dúvida um exercício de futurologia.

Tentar definir todo o escopo antes de se quer iniciar o projeto é um erro. Precisamos levar em consideração no mínimo a premissa que o mundo dos negócios está em constante transformação, muda-se muito rápido. Os cenários que temos hoje, certamente não serão os mesmos que teremos daqui a 5 anos. As necessidades poderão ser outras, mas nós ainda esperamos que os planos não mudem, ou que mudem pouco.

Por isso, empenhe-se nas duas ou três primeiras iterações a estabelecer um período adequado para as iterações restantes. Lembre-se de seguir com o período estabelecido até o final do projeto. Uma boa dica é reservar um tempo para o não planejando e ir ajustando esse tempo com o time. A tendência é que este tempo diminua com a evolução do projeto e com a maturidade do time.

1. Para saber mais sobre este dado leia o post publicado pelo Mike Cohn em https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used

2. O Mapa não é o território é um dos 5 principais pressupostos da Programação Neurolinguística. O Mapa que no caso é o nosso plano de projetos dificilmente corresponderá ao campo em que vamos executar nosso projeto. O cenário é incerto. Contém riscos, cultura organizacional, mudanças tardias e outras causas que podem tirar o projeto do trilho. Para Robert Dilts os melhores mapas são aqueles que nos oferecem mais escolhas.

Servidor Efetivo do Governo do Estado do Espírito Santo. Hoje eu sou Gerente de Processos de Projetos da Secretaria de Gestão e Recursos Humanos. Integro o time de Transformação Digital do Governo e sou responsável pelo Escritório Central de Processos. Sou agilista de coração e de profissão.