Estivativas vs. Lead Time: fazendo previsões

Sempre que navego nas redes sociais, principalmente no Linkedin vejo alguns posts e até mesmo artigos que abordam a estimativa por meio da sequência de Fibonacci tendo uma baixa, ou baixíssima correlação com o lead time das atividades.

Realmente essa correlação é baixa, o que demostra nossa baixa capacidade de tentar mensurar o trabalho criativo. Tarefas que são estimadas em 8 pontos são finalizadas em 3 dias, enquanto tarefas que estimamos em 3, levam 12, 15 dias. Você pode ser perguntar por que isso acontece, porque erramos tanto nessa tentativa ineficaz de tentar prever algo.

Eu escrevi dois artigos sobre isso que vocês podem encontrar nestes links:

Correlação pontos de história e lead time!

Lidando com outliers nas medições de lead time

Eu ainda estou tentando descobrir uma maneira de prever com mais acurácia quanto tempo de fato vai levar uma tarefa estimada em 8 pontos, ou estimada em 5 talvez. Como resultado temporário e busca constante por respostas apresento mais um resultado que obtive com o estudo dos dados de um time Scrum que tem pouco mais de 6 meses trabalhando juntos e que fazem as estimativas das histórias de usuário por meio da Sequência de Fibonacci.

Além de coletar as estimativas, também coletei o tipo de demanda (bug, melhoria, nova feature) e se esses itens tinham ou não dependências conhecidas. O resultado está aí!

Introdução

Em 2011 o professor de Oxford Bent Flyvbjerg e o consultor da Mckinsey Alexander Budzier escreveram parta a Harvard Business Review um artigo intitulado “Why Your IT Project May Be Riskier Than You Think” que em tradução livre seria “Por que seu projeto de TI pode ser mais arriscado do que você pensa”. No artigo os autores explicam que os projetos de TI agora são tão grandes e afetam tantos aspectos de uma organização que representam um novo risco singular (FLYVBJERG e BUDZIER, 2011).

Sistemas de Tecnologia se tornaram um importante elemento competitivo em muitas indústrias (BLUMBERG e LAARTZ, 2012). A Universidade de Oxford, sugere que metade de todos os grandes projetos de TI — definidos como aqueles com preços iniciais superiores a US$ 15 milhões — estouraram enormemente seus orçamentos. Em média, grandes projetos de TI são executados 45% acima do orçamento e 7% acima do tempo, enquanto entregam 56% menos valor do que o previsto (BLUMBERG e LAARTZ, 2012).

São muitos riscos associados aos nossos projetos. Riscos muitas vezes desconhecidos que podem minar o nosso desempenho. Um aspecto importante do gerenciamento de riscos é a capacidade de prever, em qualquer etapa de um projeto, quais tarefas estão em risco de sofrer atrasos. Prever esses riscos permite que os gerentes de projeto tomem medidas prudentes para avaliar e gerenciar os riscos e, consequentemente, reduzir a chance de seu projeto ser atrasado.

Cumpre ressaltar que quanto mais tempo um projeto leva para ser concluído, mais valor ele perde. O sucesso geral percebido de um projeto de software depende fortemente da pontualidade de sua entrega (CHOW e CAO, 2008). Portanto, prever um risco deve ser uma habilidade dos times e em se tratando de projetos tradicionais, dos gerentes.

Ambientes modernos de desenvolvimento ágil exigem diferentes abordagens para o planejamento devido à sua natureza iterativa e voltada para equipes (KULA, VAN DEURSEN e GOUSIOS, 2021). Prever quando uma atividade vai acabar pode ser útil para planejamento futuros, aumento da confiança da equipe e diminuição do risco.

Existem algumas maneiras de evitar falhas em projetos de TI. Uma abordagem é criar equipes integradas de negócios e TI que trabalhem em conjunto desde o início do projeto até a conclusão, definindo requisitos e testando o produto final. Isso ajuda a evitar mal-entendidos durante as transições de estágio e garante clareza na responsabilidade e propriedade do projeto. Além disso, é importante analisar os riscos antes de iniciar um grande projeto de TI, especialmente os riscos imprevisíveis (black-swan risk). Outras práticas recomendadas incluem definir metas claras, estabelecer um plano realista e gerenciar cuidadosamente o escopo do projeto para evitar mudanças excessivas.

Explicando os dados

As pesquisas nessa área ainda são limitadas. Não temos também muitos datasets públicos disponíveis, talvez por se tratar de dados que contenham certo sigilo. Os dados par este estudo foram coletados e autorizados a serem tratados de forma anônima. São dados coletados ao longo de 3 meses, mas que correspondem a 4 semanas de trabalho, pois compreendem desde o planejamento por pontos de histórias até o completo ciclo de desenvolvimento. Um resumo dos dados de ser encontrado na tabela abaixo:

Neste resumo, temos 36 observações, sendo que a tarefa de menor lead time foram 2 dias e a tarefa de maior lead time foram 32 dias. A média de lead time foi de 8,72 dias com desvio padrão de 5,54 dias. Temos ainda neste dataset uma coluna com o tipo de atividade que o time estava realizando distribuídas em três categorias: bug, melhoria e nova feature. Para complementar também foi coletado se a atividade tinha dependência ou não.

Na amostra, temos 6 atividades consideradas pelo time como bug, 12 atividades de melhoria, ou seja, melhorar e aprimorar o que já havia sido feito e entregue e 18 eram novas features para o sistema. 24 atividades não tinham dependências e 12 eram dependentes de alguma outra atividade presente ou não no backlog.

O objetivo do estudo era saber se, com o acréscimo de duas variáveis ao dataset: tipo de atividade e se existe ou não dependência da tarefa, nós conseguiríamos aumentar a capacidade preditiva do nosso modelo em comparação quando coletamos apenas estimativa de pontos de histórias e lead time.

A previsão de quanto tempo uma história de usuário vai levar para ficar pronta pode ser feita com base em outros fatores, mais difíceis de se coletar, tais como a carga de trabalho do desenvolvedor, a experiência da equipe, a estabilidade da equipe e as estimativas de esforço anteriores. Além disso, o treinamento em histórias recentes de usuários pode levar a previsões mais precisas. Como não estamos prevendo as histórias de usuários em dias, não será possível calcular o atraso médio.

Sucesso no desenvolvimento de projetos

Um dos desafios na gestão de projetos de software é fazer previsões confiáveis ​​de atrasos no contexto das mudanças constantes e rápidas inerentes aos projetos de software (CHOETKIERTIKUL, M. et al, 2015). Novas abordagens surgem com certa frequência para diminuir a lacuna entre o que foi previsto e o realizado. Com base nessa diferença, novas medidas deveriam ser tomadas para maximizar a performance do time. Entretanto, estamos mais preocupados em medir, do que trabalhar com o time em busca de melhorias.

De acordo com REEL (1999), As organizações têm tentado melhorar seus processos de desenvolvimento de software de várias maneiras. Ele enfatiza a importância de construir a equipe certa, obtendo pessoas boas e alertando que as empresas geralmente querem colocar as pessoas em vários projetos simultâneos. É importante fazer a gestão do produto, mais do que a gestão das pessoas.

Aprimorar a gestão do produto significa aumentar a satisfação das partes interessadas. Há literatura sugerindo que as partes interessadas podem ter diferentes percepções do que constitui sucesso do projeto, tanto em termos da importância dos critérios quanto do desempenho do projeto em relação aos critérios (DALCHER e DREVIN, 2003; Turner et al., 2009). Não há clareza absoluta na teoria que garante o que é um produto ou projeto de sucesso, mas aumentar a nossa acurácia em relação as previsões não nos trará efeitos negativos.

Outros fatores que podem influenciar no sucesso dos projetos e no desenvolvimento dos nossos produtos, além de uma previsão satisfatória das nossas atividades foram descritas por MCLEOD e MACDONELL (2011), são eles: a qualidade da equipe de desenvolvimento, a comunicação efetiva entre os membros da equipe, o gerenciamento adequado do projeto, a definição clara dos requisitos do projeto e a utilização de metodologias ágeis.

Sucesso ou fracasso de um projeto de desenvolvimento de sistemas de software é um conceito multidimensional e complexo, com dimensões técnicas, econômicas, comportamentais, psicológicas e políticas inter-relacionadas (MCLEOD e MACDONELL, 2011).

Evolução do Modelo

A primeira análise realizada com o nosso dataset foi a correlação entre as estimativas e o lead time. O valor obtido foi de 0.30, sendo uma correlação baixa entre estas duas variáveis. O gráfico abaixo ilustra o resultado.

O coeficiente de determinação, ou R², é uma medida que indica a proporção da variabilidade em y que é explicada pelo modelo de regressão linear. O valor de R² varia entre 0 e 1, sendo que valores próximos a 1 indicam que a maioria da variabilidade em y é explicada pelo modelo. No entanto, é importante lembrar que é possível aumentar artificialmente o valor de R² adicionando mais termos ao modelo, o que não necessariamente significa que o modelo é superior. Além disso, o valor de R² depende da amplitude da variabilidade na variável regressora x.

Obtemos um valor de R² = 0.0913, considerado baixo para explicar a variável lead time pelas estimativas. Valores de R² próximos a 1 implicam que a maioria da variabilidade em y é explicada pelo modelo de regressão (MONTGOMERY; PECK; VINING, 2012). Neste caso, um R² de 0,091 significa que apenas 9,1% da variação no lead time pode ser explicada pelas estimativas. Os restantes 90,9% da variação no lead time são atribuídos a outros fatores não incluídos no modelo. Isso sugere que pode haver outras variáveis ou fatores que influenciam o lead time e que não foram considerados no modelo atual.

O primeiro modelo de regressão linear tem o seguinte resultado:

Conforme resultado do modelo, a variável “estimado” apresenta uma relação pouco significativa, p-valor entre 0,05 e 0,1.

O teste de Shapiro-Francia é um teste estatístico utilizado para verificar a normalidade de uma amostra. Ele é uma variação simplificada do teste de Shapiro-Wilk, considerando apenas a assimetria e curtose da distribuição. As hipóteses para o teste são:

• Hipótese nula (H0): A amostra segue uma distribuição normal. Ou seja, não há evidências suficientes para afirmar que a distribuição da amostra é diferente de uma distribuição normal.

• Hipótese alternativa (H1): A amostra não segue uma distribuição normal. Isso significa que há evidências suficientes para afirmar que a distribuição da amostra é diferente de uma distribuição normal.

O teste de Shapiro-Francia calcula um valor-p, que é comparado com um nível de significância pré-determinado (geralmente 0,05). Se o valor-p for menor que o nível de significância, rejeitamos a hipótese nula e concluímos que a distribuição não é normal. Se o valor-p for maior que o nível de significância, não podemos rejeitar a hipótese nula e concluímos que a distribuição pode ser normal.

Dessa forma concluímos que a distribuição dos resíduos não segue uma distribuição normal. O que irá nos ajudar neste caso é transformar a variável via transformação de Box-Cox.

A transformação de Box-Cox é uma técnica utilizada para transformar dados que não seguem uma distribuição normal em dados que se aproximam de uma distribuição normal (BOX e COX, 1964). A transformação é feita através da aplicação de uma fórmula matemática que envolve um parâmetro lambda (λ). A escolha do valor de lambda é feita através da análise da superfície gerada pela fórmula para diferentes valores de lambda. A transformação pode ser aplicada tanto na variável dependente quanto nas variáveis independentes. A escolha da melhor transformação pode ser feita através de uma combinação de investigação direta da variável dependente e do método de Box e Tidwell aplicado às variáveis independentes. A técnica pode ser aplicada em diferentes áreas, como análise de variância, modelos de efeitos aleatórios, análise multivariada e análise de séries temporais. No entanto, é importante lembrar que a técnica depende de certas suposições e deve ser usada com cautela.

Após a transformação, estimamos um novo modelo:

Note que a variável “estimado” apresenta relação uma relação estatisticamente significativa. Dessa f orma nosso modelo de previsão considerando apenas as variáveis lead time e as estimativas é:

Y = 1.83341 + estimado*0.16653

Fazendo algumas previsões obtemos:

Para uma história de usuário prevista com esforço 5:

Para uma história de usuário prevista com esforço 8:

Eu vou encerrar esse post por aqui para não ficar muito extenso. Nos próximos artigos vamos acrescentar mais duas variáveis ao modelo continuar as previsões. Até lá!

 

Para escrever este artigo eu utilizei as seguintes referências:

 

ATKINSON, A. C. Plots, transformations, and regression: an introduction to graphical methods of diagnostic regression analysis. Oxford : New York: Clarendon Press ; Oxford University Press, 1985.

B. FLYVBJERG E A. BUDZIER, “Why Your IT Project May Be Riskier Than You Think,” Harvard Business Review, vol. 89, no. 9, pp. 601– 603, 2011 – https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think

B. MICHAEL, S. BLUMBERG, AND J. LAARTZ, “Delivering large-scale IT projects on time, on budget, and on value,” 2012 – https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value

BOX, G. E. P.; COX, D. R. An Analysis of Transformations. Journal of the Royal Statistical Society: Series B (Methodological), v. 26, n. 2, p. 211–243, jul. 1964.

CHOETKIERTIKUL, M. et al. Predicting Delays in Software Projects Using Networked Classification (T). 2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE). Anais… Em: 2015 30TH IEEE/ACM INTERNATIONAL CONFERENCE ON AUTOMATED SOFTWARE ENGINEERING (ASE). Lincoln, NE, USA: IEEE, nov. 2015. Disponível em: <http://ieeexplore.ieee.org/document/7372024/>. Acesso em: 8 maio. 2023

CHOW, Tsun; CAO, Dac-Buu. A survey study of critical success factors in agile software projects. Journal Of Systems And Software, [S.L.], v. 81, n. 6, p. 961-971, jun. 2008. Elsevier BV. http://dx.doi.org/10.1016/j.jss.2007.08.020.

DALCHER, D.; DREVIN, L. Learning from Information Systems failures by using narrative and ante-narrative methods. 2003.

KULA, Elvan; VAN DEURSEN, Arie; GOUSIOS, Georgios. Modeling Team Dynamics for the Characterization and Prediction of Delays in User Stories. 2021 36Th Ieee/Acm International Conference On Automated Software Engineering (Ase), [S.L.], p. 991-1002, nov. 2021. IEEE. http://dx.doi.org/10.1109/ase51524.2021.9678939.

OSBORNE, J. Improving your data transformations: Applying the Box-Cox transformation. [s.d.].

MCLEOD, L.; MACDONELL, S. G. Factors that affect software systems development project outcomes: A survey of research. ACM Computing Surveys, v. 43, n. 4, p. 1–56, out. 2011.

MONTGOMERY, D. C.; PECK, E. A.; VINING, G. G. Introduction to linear regression analysis. 5th ed ed. Hoboken, NJ: Wiley, 2012.

REEL, J. S. Critical success factors in software projects. IEEE Software, v. 16, n. 3, p. 18–23, jun. 1999.

SAKIA, R. M. The Box-Cox Transformation Technique: A Review. The Statistician, v. 41, n. 2, p. 169, 1992.

TURNER, J. R. The handbook of project-based management: leading strategic change in organizations. 3rd ed ed. New York: McGraw-Hill, 2009.

 

Gerenciamento de Projetos como diferencial competitivo

Uma das saídas do processo de Planejamento Estratégico realizado nas organizações é uma lista de ações, iniciativas e projetos para buscarmos o que foi definido nas metas dos indicadores referentes aos objetivos estratégicos.

Estes projetos passam então por um filtro de critérios e obtemos dessa forma o portfolio que será executado pelas equipes.

Há um risco considerável em manter este processo inflexível. Nos dias de hoje precisamos aprender a responder as mudanças mais do que seguir um plano. Isso vale para os processos extensos de planejamento e para os projetos no âmbito de diretorias e gerências.

Entregar valor é diferente de entregar projetos. Essa mudança de mentalidade ainda não está completa. Planos de projetos rígidos que não permitem mudança são mais cômodos. Muitos gerentes têm a falsa expectativa de que o mundo a sua volta permanecerá o mesmo desde o início ao fim do projeto e prefere fracassar abraçado a um plano do que mudar para favorecer seu stakeholder e consequentemente entregar valor. Valor é atender a necessidade do seu cliente. Quem mede o valor entregue é justamente quem vai usar o produto. Gerentes de projetos vivem em função de entregar o que o cliente precisa e não entregar o que está no plano perfeito, muitas vezes elaborado por uma ou duas pessoas.

Um diferencial também está na identificação dos requisitos e nas especificações. O cliente não sabe o que quer na maioria das vezes. Tornar claro o que precisa ser feito em um projeto ou produto é um forte indicativo que quando as equipes estiverem produzindo, os erros decorrentes entre o que precisa ser feito é o que de fato está sendo feito será menor.

Essa habilidade irá minimizar o retrabalho, ajudará a localizar as dependências e aumentará o valor entregue pelas equipes. Para que isso possa acontecer, o dono do produto precisa ouvir com atenção os stakeholders chaves e documentar o necessário para que a equipe possa entender o que deve fazer.

Outro ponto importante aqui é o nível de detalhamento dos requisitos que farão parte do seu backlog. Este nível de detalhe está diretamente ligado a priorização. Itens que estão priorizados para entrarem nas próximas sprints vão requerer um nível de detalhamento maior. Itens que estão mais atrás no backlog não precisam ser refinados, pois estão muito distantes de entrarem ou não em desenvolvimento. Você desperdiçará seu tempo ao fazer o detalhamento de itens que talvez nunca venham a ser produzidos.

Para que possamos evoluir enquanto times de produtos, devemos nos atentar para alguns pontos. O primeiro deles, um pilar do Scrum é a transparência. Todos devem saber o que cada um está fazendo. Essa prática irá ajudar a formação de profissionais do tipo T, mais versáteis e que poderão atuar em diversas etapas do processo, e aos poucos vamos eliminar a figura do especialista, ou pelo menos minimizar. Talvez não seja a mesma performance, mas poderá ser muito útil na identificação dos problemas e na substituição dos integrantes dos times caso ocorra algum problema.

As organizações também devem incentivar os times a serem mais autônomos. Dizer aos times a forma como eles devem trabalhar é contra produtivo. Medir as pessoas e criar métricas que não vão ajudar a melhorar o processo também não é recomendado. Um diferencial aqui é dar espaço aos times e acreditar na competência das pessoas. Não há meios de medirmos o trabalho criativo. Ele não é linear.

Ainda na parte das soluções é importante manter nos projetos um escopo flexível. Você começa o projeto com o que você já tem definido sobre o produto e utiliza a abordagem iterativa e incremental para diminuir os riscos e eliminar as incertezas. Com o desenvolvimento iterativo, nós reduzimos os ciclos de feedback, prática essencial para entregarmos valor no final de cada iteração. Encurtar os ciclos de feedback nos aproxima da solução e evita os desperdícios de se fazer itens desnecessários.

E em se tratando de itens, o ideal é que possamos manter o sistema sempre estável. Com a demanda ajustada a capacidade das pessoas. Isso vai evitar sobrecarga e acúmulo de itens. Colocar muita coisa em processo vai aumentar o lead time e diminuir a qualidade. Quanto mais tempo uma tarefa fica no quadro, mais valor ela perde. Vamos parar de começar e começar a terminar.

Para finalizar, estamos vivendo a era das métricas. Nossa facilidade em coletar dados aumentou. Praticamente todas as áreas da empresa estão abertas para a coleta de dados. Essa ampla disponibilidade de dados nos levou ao aumento da busca por métodos que nos facilite a extração de conhecimento úteis. Explorar dados se tornou uma vantagem competitiva.

Data Science é um conjunto de princípios fundamentais que norteiam a extração de conhecimento a partir dos dados. Envolve princípios, processos e técnicas para compreender fenômenos por meio da análise (automatizada de dados). O objetivo primordial de data Science é o aprimoramento da tomada de decisão, uma vez que isso geralmente é de interesse direto para os negócios. Tomada de decisões orientada por dados (DOD) refere-se à prática de basear as decisões na análise dos dados, em vez de apenas na intuição. Quanto mais orientada por dados, mais produtiva uma organização é. Lembre-se que os dados são um ativo do negócio. Obter os dados requer investimento.

Agilidade em tempos de pandemia!

Como será daqui pra frente ao nos relacionarmos com nossos clientes? Aqueles que conhecíamos antes da crise da pandemia, são os mesmos? Digo não as mesmas pessoas, mas em relação aos hábitos de consumo e poder aquisitivo.

Para se ter uma ideia, a bolsa brasileira saiu dos seus 120 mil pontos para 80. Uma queda de quase 40%. Praticamente todos os setores foram afetados, com destaque para o turismo, varejo e aluguel de veículos.

Se está difícil para as grandes empresas, imagine para organizações menores que dia após dia captava e fazia o possível para reter a atender as necessidades dos seus clientes em um ambiente cada vez mais competitivo e volátil.

As organizações que têm planejamento de longo prazo, certamente terão que fazer uma revisão profunda. Quando planejamos para um horizonte muito distante, corremos o risco de errar mais, sem contar o tempo e esforço que despendemos para pensar a longo prazo. Planejamentos com horizontes muito longos tem grande probabilidade de darem errado.

Após essa grave crise sanitária passar, estas empresas basicamente começarão do zero seus esforços de planejamento, pois dificilmente algo pensado e planejado antes da crise, será concluído. Não sabemos ainda quando ela, a crise, vai terminar. Nestes casos a resiliência e a capacidade de adaptações rápidas são fundamentais para superar este momento.

Outro problema é a capacidade financeira que foi em grande parte afetada pelos baixos níveis de consumo e produtividade. As organizações que estavam um pouco à frente conseguiram remanejar suas equipes para o trabalho remoto, entretanto a grande maioria ainda está buscando uma solução.

Acontece que neste cenário passamos por uma mudança abrupta. Muitas organizações tinham projetos em execução que foram interrompidos ou sofreram drásticas mudanças, principalmente em relação a stakeholders e aquisições. Garanto que nem o melhor plano de riscos tinha a previsão de uma pandemia.

Em relação ao backlog dos projetos, muitos itens foram, estão sendo ou serão revistos. A transparência ao se gerir um backlog é fundamental. Cabe a todo o time scrum conhecer e conversar sobre os itens que estão listados ali. O time se compromete então, ao final de cada sprint, converter os itens do backlog em um entregável.

A questão aqui é que muitas sprint foram prejudicadas e não terminaram por assim dizer. À medida que o desenvolvimento do produto avança,o backlog deve ser atualizado, todavia será preciso identificar e adaptar o backlog ao cenário atual. Uma empresa é mais ágil do que outra quando consideramos a capacidade desta convergir para as necessidades do mercado atual.

Com a crise, o budget foi profundamente afetado, e uma boa gestão do backlog garante que se o dinheiro acabar, você o terá usado nos itens mais importantes. No seu backlog o mais importante vem primeiro. Cabe ao Product Owner manejar os itens para maximizar o retorno do investimento.

Outro ponto chave é em relação ao planejamento. É mais barato e menos arriscado você planejar os próximos passos à medida que obtém feedback do produto em produção, do que usar a sua bola de cristal para planejar lotes muito grandes. O que é diferente em uma abordagem empírica é que você mede os resultados de seus experimentos para determinar se sua hipótese está correta. Se não estiver correto, você pode querer mudar seu foco para uma oportunidade diferente.

Para finalizar, busque oportunidades, em vez de projetos ou programas. Concentre-se em entregar valor aos clientes.

Confiança – ativo fundamental para a agilidade

Um dos ativos que você precisa construir com os times que você costuma trabalhar é confiança! Difícil de ser mensurada e demorada em se estabelecer, a confiança é uma qualidade fundamental em times altamente produtivos. Entretanto, o tempo que levamos para construir esse sentimento é inversamente proporcional ao que se leva para desconstruí-lo.

Fazendo um paralelo com o Manifesto Ágil, a questão da confiança é um fator chave para colocarmos seus valores em prática. A forma mais eficiente de comunicação é quando você levanta da sua mesa e vai até o seu colega de time para conversar ou solicitar algo. Indivíduos e interações mais que processos e ferramentas demanda confiança, pois no final, quando você acerta tudo com o seu colega, vem aquela famosa frase: “será que você poderia me mandar um e-mail para deixar isso que nós conversamos estabelecido?”.

Hoje, a maior vantagem competitiva que você deve priorizar entre todas as demais é o trabalho em equipe.

Voltando ao Manifesto Ágil, a confiança mostra-se essencial nos demais valores. Um ambiente que você colabora com o cliente e confia que terá o seu produto entregue, elimina a excessiva burocracia para negociar contratos. Da mesma forma que você terá o seu produto funcionando e suas mudanças serão respeitadas sem extensa documentação para alterar requisitos. Em suma, um ambiente de total confiança elimina o excesso de burocracia.

O consultor americano Patrick Lencioni no seu livro Os 5 desafios das equipes coloca a confiança na base da pirâmide para o trabalho de uma equipe. Lencioni diz que as disfunções são sistêmicas sendo que a confiança limita o desenvolvimento de todas as demais qualidades. As pessoas, quando fazem parte de um time, tem uma necessidade oculta de não demonstrar suas fraquezas, mostrando-se invulneráveis aos demais. Confiando uns nos outros, os membros de uma equipe vão se envolver mais em conflitos produtivos, que por sua vez aumentará o comprometimento com as decisões do grupo, que permitirá chamar atenção dos próprios colegas para o que foi acordado. Um time com essas características passará a ter foco no coletivo, e não no próprio ego.

Lencioni afirma que:

A falta de confiança entre os membros da equipe, em essência vem da vontade de cada um de se mostrar invulnerável dentro do grupo.

As características de times com baixa nível de confiança, dentre outras são:

  • escondem suas fraquezas e seus erros uns dos outros
  • hesitam em pedir ajuda ou dar feedbacks
  • hesitam em oferecer ajuda a pessoas que atuam fora de suas áreas de responsabilidade
  • tiram conclusões precipitadas sobre as intenções e aptidões dos outros, sem tentar esclarecê-las
  • não reconhecem nem exploram as experiências e habilidades uns dos outros
  • perdem tempo e energia controlando o próprio comportamento para causar boa impressão
  • guardam mágoas
  • temem as reuniões e encontram motivos para evitar passar algum tempo junto dos colegas

Para concluir, no contexto da construção de uma equipe, Lencioni define confiança como:

É a certeza, entre seus membros, de que todos têm boas intenções e de que não há motivos para ficar na defensiva ou ter reservas em relação ao grupo. Essencialmente, os colegas de equipe devem se sentir à vontade para se permitirem ser vulneráveis na frente dos outros.

Simon Sinek, outro autor que uso sempre como referência neste tema, afirma que você não pode ensinar as pessoas a confiarem uma nas outras. Confiança é um sentimento, tal como lealdade. E como todo sentimento eles devem ser conquistados e precisam de uma série de ações para provar que nós somos merecedores.

Quando começamos a fazer parte de um time, ou mesmo quando formamos um time novo, nós não nos sentimos parte dele logo no início. Você não conhece os clientes, as tradições, as políticas e pouco a pouco as pessoas vão se mostrando com pequenas e frequentes ações. Depois de 8 ou 10 meses você começa a se sentir parte dele. Confiança não é algo que pode ser ordenado: Confie em mim, ou confie no seu colega de equipe. Também não podemos estabelecer um prazo para isso acontecer: Daqui a 8 meses eu começo a confiar em você! Simon ainda ensina que é a liderança da organização que é a responsável por criar um ambiente de confiança.

Para Simon:

Quando não confiamos em alguém que trabalhamos juntos, nós nos tornamos cínicos, egoístas e paranoicos. Fazemos as coisas para nos proteger, o que causa sérios danos a cultura e a organização.

Construa Confiança

O título desta seção do artigo é o mesmo de um livro escrito por Robert Solomon e Fernando Flores. Basicamente um livro que se tornou referência no tema pra mim. Os autores afirmam que uma vez que a confiança é perdida nas relações de trabalho, entre membros do time, tendemos a desistir dela. Os autores colocam que nos dias atuais as pessoas concordam que a confiança é essencial para fortalecer a cultura corporativa, entretanto essas mesmas pessoas não conseguem definir o que é ter ou não confiança. Os autores ainda definir a pior situação, a qual chamam de hipocrisia cordial:

A forte tendência das pessoas nas organizações, por lealdade ou medo, fingirem que existe confiança onde nenhuma há, mostrando-se educadas em nome da harmonia quando na verdade o cinismo e a desconfiança são venenos ativos, corroendo a própria existência da organização.

Bom, e como podemos definir confiança? Para Solomon e Flores, este sentimento significa:

Uma opção, uma escolha . É uma parte ativa ativa de nossas vidas, não algo que tem de existir desde o início, ou que pode ser considerado como garantido. Envolve habilidade e compromisso, não apenas sorte ou entendimento mútuo. A confiança é em geral evidente somente quando de seu colapso. Confiança não é algo que temos, é algo que exercemos.

Custo 

Falta de confiança é um custo invisível e um dos grandes desafios para os líderes é trazer o invisível para a mesa de decisão e para o dia-a-dia das pessoas, pois o foco da gestão está  fortemente vinculado ao visível, ao concreto e quantificável. Os custos invisíveis não aparecem nos balanços da organização e são de difícil identificação e mensuração. Em geral, os custos invisíveis, isoladamente, são de pequena importância e significância em relação ao total dos gastos, mas no conjunto podem se tornar representativos. Os custos invisíveis podem corresponder a uma fatia entre 20% e 30% dos dispêndios totais das companhias conforme escreveu Antônio Augusto Moreira em 2011. Para moreira, outras fontes de custos invisíveis são:

  • Excesso de burocracia;
  • Alta rotatividade de pessoas;
  • Falta de rigidez no controle de gastos realizados pela alta gestão;
  • Paternalismo na seleção de funcionários;
  • Uso de tecnologia e equipamentos ultrapassados;
  • Baixa criatividade entre os colaboradores.

Henrique Santana no Curso de Liderança Sistêmica promovido pela Software Zen, afirma que:

O visível orienta. O invisível move.

Conclusão

A desconfiança limita nossa capacidade de agirmos e atuar como um time. O Glenn Parker no livro “O Poder das Equipes” afirma que uma equipe concordam que eles tem uma meta, e que a única forma de chegaram a esta meta e trabalhar em conjunto, ou seja, de forma colaborativa. A falta de confiança vai tornar isso mais difícil, mais lento, mais caro e o fator que torna isto tudo ainda mais complexo: os problemas não ficarão, aparentes, visíveis.

A confiança proporciona mais liberdade para as pessoas trabalharem juntas, sem o peso de para todas e quaisquer decisão se perguntarem se podem ou não confiar nela.

Referências:

Livro: Construa Confiança – Robert Solomon e Fernando Flores

Livro: Os 5 desafios das equipes: Uma história sobre liderança – Patrick Lencioni

Vídeo: Simon Sinek –  https://www.youtube.com/watch?v=lwuouSVtWAE

Custos Invisíveis –  https://www.amcham.com.br/noticias/pme/custos-invisiveis-das-companhias-representam-de-20-a-30-do-total

Livro: O Poder das Equipes – Glenn Parker

Henrique Santana no Curso de Liderança Sistêmica promovido pela Software Zen

 

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

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/

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/

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

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

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.