Sumário
Prefácio
Este livro é um consolidado de conceitos e práticas aplicadas e validadas por mim, ao longo da minha experiência ágil. Aqui há uma contextualização inicial do que é ser ágil, além de um grupo de etapas, métodos e métricas para auxiliar na transição de modelos não-ágeis para um modelo ágil.
Lembrando que ser ágil não se resume apenas em desenvolvimento de software, mas também para gestão de produtos e gestão de processos.
Espero que este livro possa auxiliar em sua jornada de transformação, e que habilite em você e na sua equipe um potencial de entregas contínuas de valor.
O que é (ser) ágil?
Por que se tornou tão importante?
Antes de começar a explicar o que é ser Ágil, quero mostrar o por que de tudo isso. Como algo significantemente simples pode estremesser tanto o mundo de Tecnologia e o mundo Corporativo.
As últimas décadas foram bem impressionantes para o mundo, tanto no surgimento de novas tecnologias como a integração global das pessoas e das empresas. Esta integração aumentou exponencialmente a complexidade das relações entre consumidores e fornecedores. Nesta situação, temos que a Beira do Caos torna-se normal.
VUCA
Analizando este ambiente complexo, dois professores Burton Nanus e Warren Bennis escreveram em 1985 o livro Leaders: Strategies for Taking Charge. Neste livro eles descrevem um ambiente global chamado VUCA, que é o acrônimo de* Volatility, Uncertainty, Complexity* e* Ambiguity*, traduzindo para português temos Volatividade, Incerteza, Complexidade e Ambiguidade.
Volatividade
Dinâmico, volúvel e rápido, há muita dificuldade para determinar-se padrões, trabalhoso de se estabelecer uma previsibilidade, por isso, é complexo buscar lições aprendidas no passado para encontrar as soluções de um futuro.
Incerteza
Tudo torna-se instável, pois a convergencia entre pessoas, processos e produtos afeta os planos de curto, médio e longo prazos.
Complexidade
Estamos em um ambiente, onde muitos aspectos afetam as pessoas e as empresas, desta forma, torna-se impossível o controle de todas as variáveis, sendo assim, as soluções mais simples e rápidas são muito mais efetivas do que um planejamento detalhado com todas as situações mapeadas.
Ambiguidade
Esta hiperconectividade, emerge um ambiente onde não existe apenas uma decisão certa, é difícil identificar exatamente uma causa e uma consequencia, sendo assim, a melhor decisão é a que mais faz sentido para a situação atual, resolve o problema de maneira rápida e efetiva.
Como se sair bem neste mundo?
Ao mesmo tempo que VUCA é um problema (* Volatility, Uncertainty, Complexity* e* Ambiguity) é também a solução (Vision, Understanding, * Clarity e* Agility*)
Sendo assim, ter a capacidade de adaptação e trabalhar em um ambiente com mudanças contínuas, exigem características determinantes para manter um nível de competitividade e até de sobrevivência de mercado, que são:
Mover da hierarquia para a auto-organização.
Encaminhe as decisões até a borda da organização, onde as informações são as mais recentes e mais salientes: a caixa registradora, a linha de produção, o call center e os representantes de vendas.
Passe do silo da informação para a democratização da informação.
Para capacitar os funcionários a tomar decisões, torne a comunicação sem atritos. Realize reuniões semanais com todos os envolvidos. Claro, alguns podem ter que ficar acordados até tarde ou acordar cedo para empresas globais, mas o ganho de obter as informações diretamente da boca das pessoas vale a pena.
Acelerar as interações.
Acelere a velocidade de interação tanto quanto possível. Na era do VUCA, a velocidade é mais importante que a perfeição. Defina a expectativa de que todos respondam a e-mails em algumas horas para agilizar e até o final do dia para os mais longos.Use regras simples para tomar decisões rápidas, em vez de análises perfeccionistas.
Cynefin
Em 1999, Dave Snowden propos um framework para auxiliar como podemos ter mais sucesso nas tomadas de decisões, surge então o Cynefin Framework. Este framewors consiste em 5 domínios de decisões, baseados nas caracteristicas dos ambientes:
Obvious - Óbvio
Características
As relações de causa e efeito são recorrentes, visíveis e previsíveis.
Conhecido - Domínio do Real
Ações
Observar - Categorizar - Responder
Melhores práticas
Complicated - Complicado
Características
As relações de causa e efeito se repetem, mas nem sempre são previsíveis.
Conhecível - Domínio do Provável
Ações
Observar - Analisar - Responder
Boas práticas especialistas
Complex - Complexo
Características
As relações de causa e efeito com frequência não são percebidas nem previsíveis, alto nível de erro e incerteza.
Padrões emergentes - Domínio de muitas possibilidades
Ações
Testar - Observar - Responder
Práticas emergentes/adaptativas
Chaotic - Caótico
Características
As relações de causa e efeito não são percebidas.
Padrões não percebidos - Domínio do inconcebível
Ações
Agir - Observar - Responder
Práticas inovadoras
Disorder - Desordem
Características
Não há clareza sobre qual dos outros domínios se aplica. Por definição, é difícil ver quando este domínio se aplica.
Ações
Decompor a situação em partes menores e atribui-las um dos outros quatro domínios. Os líderes podem então tomar decisões e intervir de maneira apropriada.
A agilidade entra neste contexto como uma prática inovadora e adaptativa, trazendo frameworks que possibilitam uma entrega contínua e focada no feedback dos resultados e não no plano de controle das variáveis incontroláveis.
Vamos entrar um pouco mais no conceito do ágil e entender como foi sua origem.
Agile Begins: Um pouco de história!
Vamos começar com um pouco de história e fundamentar de onde vieram os conceitos ágeis. Seguindo a hype hollywoodana, resolvi colocar esta base ágil igual aos filmes de heróis, assim surgiu o Agile Begins.
Qual a origem do Agile?
O conceito ágil surgiu de uma observação de que a velocidade de mudança no desenvolvimento de software não estava aderente com a velocidade necessária para os negócios gerarem Valor.
Você pode pensar: Isto ocorreu nos últimos 10 anos! ERROUUUU.
A jornada se inicia…
Vamos iniciar com algo antes do Agile, o Waterfall, ou método Cascata. Seus primeiros históricos datam de 1956, quando o engenheiro Herbert D. Benington apresentou um modelo de desenvolvimento de software em um Simpósio de métodos de computação avançada para computadores digitais. Seu nome é devido sua sequencia de etapas, e uma vez passada a etapa, não se volta mais.
Mas e o Ágil??
Esta história começa com uma sigla de 4 letras, muito falada/escutada no mundo de gestores. O P.D.C.A. [Inglês:* Plan, Do, Check e Action*, bem traduzida para: Planeje, Desenvolva, Confira e Aja]. Este método iterativo foi proposto por William Eduard Deming, na década de 1960 (Antes do homem pisar na lua, já tínhamos iniciativas ágeis na Terra).
Seguindo esta onda ágil, veio Barry Boehm e propôs “A Spiral Model of Software Development and Enhancement” em 1988. Este modelo cunhava um processo iterativo de planejamento e desenvolvimento de software, temos aí um primeiro rascunho de Entregas Incrementais.
Logo após Boehm, em 1990, temos James Martin, que desenvolve a R.A.D. [Rapid Application Development]. Ela estruturava um ciclo iterativo de Prototipação durante a análise e desenvolvimento.
Em 1995, Ken Schwaber e Jeff Sutherland escrevem a primeira versão do Framework Scrum (irei tratar dele mais a frente) para desenvolvimento de sistemas orientados à objetos. Este framework foi apresentado na Object-Oriented Programming, Systems, Languages & Applications ‘95 (OOPSLA ‘95) em Austin, Texas.
Em 2001, passado o susto do Bug do Milênio, e depois de vermos que a realidade do novo milênio era muito diferente do filme 2001: Odisseia no espaço. Dezessete gurus de desenvolvimento de software se reúnem e escrevem o Manifesto Ágil. Este é um ponto crítico para a história da Engenharia de software.
Ele foi estruturado à partir dos seguintes pilares:
Muito importante:
Acessem http://agilemanifesto.org/ observem os 4 pilares e os 12 princípios
Tempos depois, em 2010, Nasce a Scrum.org, encabeçada por Ken Schwaber, e lança o Scrum Guide, guia do framework scrum, apresentando seus artefatos, ritos e papéis. O Scrum criou uma ruptura na maneira de se pensar e usar Agile. Tornou-se o mais famoso e mais utilizado framework ágil, sendo pesquisado para ser base para outras metodologias.
Mas não é só isso.
A partir do SCRUM, surgiram mais metodos ágeis, exemplo Spotify, tanto para desenvolvimento de software quanto para gestão de produtos e empresas. Além da união de métodos, como o Lean e Scrum ou Design Thinking com Scrum e ainda a escalabilidade de metodologias, como o Framework Nexus ou SAFe.
Com este crescimento, apareceram tambem outras práticas de gestão de pessoas como o Management 3.0.
Todas essas iniciativas tomam como base os pilares do Manifesto Ágil.
Resumindo…
Considerando o ambiente no qual estamos inserido, ele sendo classificado como VUCA ou Complexo (Cynefin), as abordagens ágeis se sobresaem devido a sua entrega rápida (alguns dias ou semanas) e sua adaptabilidade (feedbacks constantes).
Desta forma, considero Ser Ágil é:
“Obter o resultado o mais correto possível, da melhor maneira e no menor tempo, através de entregas e feedbacks constantes e do comprometimento das pessoas”.
Por onde eu começo?
Primeiro passo da jornada é saber em qual ambiente estamos?
Para isso podemos utilizar o Cynefin, e descobrir se estamos em um ambiente complexo, complicado, caótico.
Identificado o ambiente, vamos entender com que estamos trabalhando, é um processo ou é um produto?
É um Processo ou é um Produto?
Esta divisão basicamente serve para escolhermos qual framework nos trará mais resultado.
Para isso, eis a definição que irei seguir neste livro:
Processo
Um Processo é um conjunto de atividades que utiliza recursos humanos, materiais e procedimentos para transformar a matéria-prima (entrada do processo) em um produto (saída do processo). É contínuo, padronizado, logo torna-se repetitível.
Produto
É um entregável, tem objetivos para alcançar, é utilizado por alguém, e internamente executa um ou mais processos.
Tem um ciclo de vida próprio e pode ser entrege incrementalmente.
Em ambos teremos pessoas envolvidas, métricas que devem ser monitoradas e indicadores de resultados.
Quem está comprometido e quem está só envolvido?
Este é um ponto importante, pois ao trabalharmos com um processo ou produto, devemos olhar o todo, ter uma visão sistêmica, uma visão da cadeia de valor, e passar por todos os departamentos (Silos).
É muito importante que as pessoas responsáveis por cada pedaço da cadeia de valor estejam comprometidas. Pois o resultado final, dependerá do compromisso de todos.
Como medimos?
Lagging e Leading Indicators
São tipos de medidas para mensurar a performance de algo. Ambos são indicadores porém com uma diferença:
- Lag Indicators: São indicadores pós-eventos, são utilizados para mostrar progresso, mas inúteis para influenciar algo futuro. Normalmente são fáceis de medir.
- Lead Indicators: São indicadores in-process, são medidor durante a execução, temos como agir sobre eles. Por serem medidos durante a execução, são mais complexos de medir.
Um exemplo simples, Tenho a meta de perder peso.
Logo meu lagging indicator é número de quilos perdidos.
Porém meus leadings indicator são quilometros corridos por dia, calorias ingeridas, calorias gastas, etc.
Desta forma, tenho pouco o que fazer com a medida de peso, ela apenas me mostra se estou ou não tendo o output esperado, porém os outros indicadores, são essenciais para eu avaliar minhas ações.