A essência do Agile

Tem cerca de 20 anos que surgiram os primeiros métodos ágeis do jeito que os conhecemos hoje, em frameworks e “receitas prontas”. No meio de tantas transformações ágeis e digitais acontecendo em empresas ao redor do mundo, muito da essência do agile tem se perdido em prol de corridas desenfreadas por estar na dianteira do mercado em termos de produtos e resultados.

No entanto, rodar Scrum ou SAFe à risca não é garantia de agilidade e nem o objetivo da agilidade é formar times que apenas sabem executar uma receita. O objetivo dos métodos ágeis é formar times de alto desempenho para resolver os mais variados desafios, respondendo às mudanças inerentes ao cenário moderno e inovador das empresas, em especial as digitais. A capacidade de um time em responder a mudanças, entregando valor contínua e ininterruptamente é o real sentido de ser ágil, embora muitas empresas acreditem erroneamente que agilidade é apenas outro nome para velocidade.

Mas afinal, se rodar XP, Kanban, etc não garante que o seu time é realmente ágil, quais seriam as características que dizem se o seu time é ou não ágil?

Para responder a esta pergunta temos de voltar no tempo e entender a essência da agilidade…

Manifesto Ágil: 2001

Em 2001, 17 dos mais renomados profissionais de tecnologia do mundo se reuniram para discutir a forma como estavam tocando os seus projetos de software. Todos eles discordavam da forma tradicional de gerir projetos à época, extremamente burocratizada e que mais destruía do que entregava valor aos clientes.

Desta reunião em que estavam os criadores de frameworks famosos como Scrum, XP, Crystal e muitos outros, surgiu o chamado Manifesto Ágil: um documento composto por quatro premissas e doze princípios que norteariam tudo o que se criou sobre métodos ágeis daí em diante.

As quatro premissas são:

Manifesto Ágil de Software
Manifesto Ágil de Software

Atente à frase que fecha o manifesto, ela é muito importante: mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

O manifesto é complementado por 12 princípios:

12 Princípios Ágeis
12 Princípios Ágeis

Note que o Manifesto Ágil foi criado por profissionais de TI e para profissionais de TI, mas que se você trocar a palavra software pelo produto do trabalho do seu time, verá que muita coisa faz sentido até mesmo fora da área de TI. Isso se deve ao fato de que estas ideias não surgiram exatamente aqui e nem exatamente por estas pessoas, o que nos leva um pouco mais atrás na história da agilidade…

O Novo Jogo de Desenvolver Novos Produtos: 1986

Em 1986, 15 anos antes do Manifesto Ágil ser assinado, dois professores da Harvard Business School, Hirotaka Takeuchi e Ikujiro Nonaka, escreveram um famoso artigo intitulado The New New Product Development Game. Neste artigo, eles retratam a situação do mundo à época, em que a velocidade e flexibilidade necessários para se criar produtos competitivos forçava as empresas a mudarem suas estratégias, atuando mais como times esportivos do que como departamentos, inclusive fazendo uma analogia ao rugby que mais tarde seria continuada com o advento do Scrum (que é uma jogada do rugby).

A abordagem pregada por Takeuchi e Nonaka é baseada em seis características: instabilidade embutida (missão-controle ao invés de comando-controle), times de projeto auto-organizados (como uma startup), fases de desenvolvimento sobrepostas (sprints), multiaprendizado (fail fast e shared knowledge), controle sutil (checkpoints ao invés de microgerenciamento) e transferência organizacional do aprendizado (compartilhamento fora do time). Essas características juntas tornariam-se a base de uma mudança cultural no desenvolvimento de produtos uma vez que os métodos antigos não permitiam que as empresas se mantivessem competitivas ao longo que o mercado não pára de mudar.

Foi a primeira vez documentada que se desafiou o status quo de desenvolver projetos instaurado desde a década de 60, faseado e linear, onde o valor somente era gerado quando passasse pela última etapa ao final de todo o processo, como em uma corrida de bastão, onde vence quem chegar na reta final com o bastão na mão. Na nova abordagem, as fases se sobrepõem, com analogia de um time de rugby avançando com a bola, que é passada de mão em mão e o time avançando junto, o que mais tarde originaria as sprints do Scrum.

Processo com sobreposição
Processo com sobreposição

Estas conclusões foram tiradas a partir de projetos de produtos bem sucedidos em empresas americanas e japonesas daquela década, que mostraram que era possível tirar proveito do trabalho em equipe e de uma abordagem sobreposta para reduzir o go-to-market entre outros desperdícios. Essa busca incessante pela redução do desperdício nas fábricas americanas nos leva a ideias ainda mais antigas que Nonaka e Takeuchi beberam da fonte…

Sistema Toyota de Produção:1950

O Sistema Toyota de Produção foi desenvolvido pela Toyota Motor Corporation para fornecer a melhor qualidade, o menor custo e o lead time mais curto por meio da eliminação do desperdício. O TPS é formado sobre dois pilares, Just-in-Time e Jidoka, e é normalmente ilustrado pela “casa” mostrada a seguir. O TPS é mantido e melhorado por interações entre trabalho padronizado e kaizen, seguidos de PDCA.

Casa da Toyota
Casa da Toyota

O desenvolvimento do TPS é creditado a Taiichi Ohno, chefe de produção da Toyota no período posterior à Segunda Guerra Mundial. Começando nas operações de usinagem, Ohno liderou o desenvolvimento do TPS ao longo das décadas de 1950 e 1960, e sua disseminação à cadeia de fornecedores nas décadas de 1960 e 1970.

O seu trabalho depois foi levado ao ocidente por James Womack e Daniel Jones no livro Lean Thinking (Mentalidade Enxuta, 1996) criando a cultura Lean nos anos 2000 (Lean Development, Lean Startup, Lean Enterprise, etc), outra vertente muito forte que influenciou e foi influenciada pela cultura agile, sendo como já foi dito, focado na eliminação dos sete desperdícios da cadeia produtiva:

  1. Defeitos
  2. Superprodução
  3. Espera
  4. Transporte
  5. Movimentação
  6. Processamento errado
  7. Estoque

Uma vez que se trabalhe na eliminação destes desperdícios, chegaremos cada vez mais próximos de produtos Lean (enxutos): baixo custo, alta qualidade e tempo de entrega menor. Note que inclusive a superprodução é encarada como nociva, o que pode ser contraintuitivo para algumas pessoas mas que faz total sentido uma vez que o Princípio de Paretto se aplica a produtos em geral (80% das funcionalidades raramente são usadas).

O conceito de Kaizen também é muito forte aqui, garantindo a melhoria contínua dos processos em uma eterna busca pela perfeição, algo mais tarde levado pelos agilistas através de cerimônias como as retrospectivas.

E por fim, ferramentas de gestão à vista do chão de fábrica japonês, como o Kanban, mais tarde foram adaptadas para o mundo dos projetos, neste caso pelo americano David Anderson, criando outra legião de seguidores.

Agilidade para Todos

Note que os princípios da agilidade são universais e aplicáveis a qualquer grupo de pessoas que tenham de empreender projetos complexos e adaptativos. E se você leu o que escrevi acima sobre a origem da agilidade (e em consequência sua essência) deve ter entendido que um time ágil:

  • trabalha como um verdadeiro time, além de ser pequeno e auto-organizado, compartilhando a responsabilidade;
  • colabora e comunica-se clara e constantemente entre si, com clientes e com stakeholders, através de comunicação direta e gestão visual;
  • foca na entrega de valor contínua e incremental, aprendendo a cada entrega;
  • elimina desperdícios e ganha mais agilidade através de melhoria contínua;
  • compartilha seus aprendizados interna e externamente ao time;

Se você tem todas estas características no seu time, parabéns, você tem um time ágil!

Note que não estou menosprezando os frameworks populares, que aliás eu adoro e uso há anos. Note também que possuir todas estas características em um time não é uma tarefa fácil, exige pessoas maduras, organizadas, com desenvolvimento orientado a valor e foco no cliente e que sim, muito provavelmente usar um método vai lhe ajudar a criar a disciplina e musculatura para chegar em um time essencialmente ágil.

Então sim, usar Scrum e outros métodos pode ser um caminho para se chegar a times ágeis e de alta performance, mas note que esses métodos são um caminho, um meio, e não o fim. Ser ágil não é e nunca será executar uma receita, mas reagir às mudanças entregando valor de maneira contínua e incremental, em um ciclo perpétuo de melhoria contínua. Ponto.

Ninguém te disse que seria fácil, certo?

Gostou do assunto? Quer aprender mais sobre métodos ágeis? Conheça meu livro Scrum e Métodos Ágeis clicando no banner abaixo!

Agile Trends Florianópolis/SC

Ontem terminou o Agile Trends Florianópolis 2018, um evento sobre agilidade na capital catarinense, mais especificamente na praia dos Ingleses. Eu estive lá durante os dois dias de eventos e a ideia deste artigo é compartilhar um pouco do que vi por lá e a impressão que tive do evento, que acontece também em outras capitais do país como Brasília e São Paulo.

Agile Trends
Agile Trends

A organização

O que me chamou mais a atenção no evento foi o formato. Eram cinco trilhas simultâneas, sendo quatro teóricas e uma prática, composta de workshops, mas tudo isso aconteceu em um mesmo espaço aberto. Sim, era um único salão com cinco coisas acontecendo ao mesmo tempo!

Mas como isso era possível? Será que funciona?

Eu me assustei quando percebi este formato ao entrar no hotel Oceania em Ingleses. Me lembrei da Campus Party, que era uma bagunça neste sentido, um monte de palestra gritando no microfone, com palcos muito próximos um do outro e um monte de gente que tentava desesperadamente entender alguma coisa. Mas aqui a coisa foi diferente.

Cada participante ganhava emprestado um rádio com um fone de ouvido ao entrar no salão. O rádio tinha cinco canais, um pra cada trilha e os palestrantes falavam em um microfone, mas sem alto falantes (o que não atrapalhava as outras palestras), a voz era transmitida via rádio aos dispositivos que estavam com a gente, fazendo com que escutássemos perfeitamente cada palestrante, com o bônus de conseguir dar uma zapeada de vez em quando olhando para os lados e trocando os canais do rádio para ver se a outra palestra estava melhor, isso foi animal!

Já estive em muitos eventos com trilhas simultâneas como TDC e é um saco quando tu está em uma palestra meia-boca e não sabe se tem outra melhor acontecendo em outra sala. Esse talvez seja meu principal elogio ao evento, pois essa sacada foi genial. Tu não tinha de estar bem na frente do palestrante para ouvir e conseguia ir de uma trilha à outra muito facilmente.

As Trilhas

As trilhas eram cinco, como comentei antes. Na trilha de Workshops, tínhamos dinâmicas e muita mão na massa com pessoas de mercado bem experientes apresentando suas técnicas, como o Andy Barbosa do Agile Institute Brasil. Eu não cheguei a participar de nenhum workshop, me ative mais às palestras mesmo, mas pareciam bem interessantes.

A trilha #1 era de Agile Coaching, como um foco muito grande em pessoas e team building. Muito grande mesmo, eram quase filosóficas e assisti poucas palestras aqui. Sinceramente eu esperava mais cases de transformação ágil e resoluções de conflito em escala corporativa, que é o que mais me aflige hoje na minha função como Agile Coach no Agibank. Não desmerecendo o conteúdo da trilha, longe disso, mas não era o que eu estava procurando.

A trilha #2 era de Scrum e Lean/Kanban. Essa sim teve muitos cases, em especial de Kanban. Ficou muito claro que o mercado parece estar cada vez menos interessado em falar sobre Scrum e estão voltando suas atenções para Kanban e Lean. Não é algo anormal na minha opinião, uma vez que conforme a maturidade dos times e das empresas aumentam na adoção de métodos ágeis, faz-se menos necessária a utilização de frameworks, por menores que sejam como o Scrum.

A trilha #3 era de DevOps, a trilha mais técnica de todo o evento. Foi uma trilha interessante, com bastante ferramental e cases de adoção de DevOps. Acho que foi o primeiro evento que tive a oportunidade de ver palestras de DevOps, justamente por causa do formato de organização open-space, uma vez que nos eventos tradicionais eu acabo enfurnado em  salas de métodos ágeis com foco maior em dinâmicas e facilitação.

E por fim, a trilha #4 era de Gestão de Produtos. Note como cada trilha possuía um apelo para um papel ágil específico com #1 Agile Coach, #2 Scrum Master, #3 Dev Team e #4 Product Owner. Achei bem interessante isso. Nesta trilha tivemos alguns cases, muita técnica para cocriação, priorização, MVP e muito mais coisas que todo PO tem de ter no seu cinto de utilidades.

Agile Trends
Agile Trends

Os pontos altos

O evento começou muito bem com a keynote Mari Zaparolli do PagSeguro (também conhecida como Mari Canvas), contando o case de transformação ágil deles. Muito bacana mesmo como eles montaram um time de 15 Agile Coaches na Governança de TI da empresa para ajudar os 100 times de desenvolvimento a rodarem os projetos de maneira ágil.

Outra palestra muito boa foi da Dieine, Agile Coach da HostGator, contando toda a jornada deles para adoção de agile em todas áreas da empresa, não apenas na área de desenvolvimento.

Também teve um case bacana de transformação na divisão de produto Fluig da Totvs, onde existia um problema muito grande de qualidade e velocidade nas entregas, resolvidos com a adoção de métodos ágeis, principalmente Scrum e Kanban por lá.

Pra quem curte Kanban, tiveram muitas palestras sobre o assunto, abordando adoção, disfunções, métricas e por aí vai. Na minha opinião ficou até meio repetitivo.

Enfim, acho que isto é o que posso resumir do evento. Certamente valeu a pena a viagem até Santa Catarina e fiquei bem curioso com o anúncio da edição do ano que vem em SP, que ocorrerá durante 6 dias em abril e será o maior evento de agilidade do Brasil de todos os tempos.

Quem sabe não nos topamos por lá?

Gostou do assunto? Quer aprender mais sobre métodos ágeis? Conheça meu livro Scrum e Métodos Ágeis clicando no banner abaixo!

Backlog DEEP, Histórias INVEST e Tarefas SMART

Quem trabalha comigo há algum tempo sabe o quanto eu repito a frase “agile não é bagunça” e quando o assunto é o backlog do time, isso não pode ser menos verdade. Existe uma má interpretação do Manifesto Ágil e da própria cultura Lean-Agile em geral que entende que não se precisa ter documentação em projetos rodando sobre frameworks ágeis.

Pura mentira!

A grande mudança de mindset nos métodos ágeis é criar a documentação estritamente necessária e somente quando for necessária, ao invés de gastar meses escrevendo documentos de Visão do Produto, Especificações Funcionais e Não-Funcionais e por aí vai. Isso não quer dizer, no entanto, que jamais vamos ter este tipo de documentação ou algo próximo à elas, mas que vamos distribuir a sua produção ao longo de várias sprints conforme nosso entendimento for aumentando e a necessidade se torne emergente.

E por que eu falo que agile não é bagunça?

Porque justamente em um ambiente auto-gerenciável e sem metodologias prescritivas é que precisamos do mais alto grau de organização e isso começa com nosso requisitos ágeis. No artigo de hoje falarei sobre três acrônimos bem populares para ajudar na organização dos requisitos ágeis:

É importante ressaltar que estes acrônimos são norteadores para a criação e organização destes artefatos e de que não devem se tornar uma “religião” nem criar fanáticos que impeçam os projetos de prosseguirem apenas porque alguma demanda não atende 100% a todos requisitos do acrônimo. Use-os como guias e não como grilhões.

Vamos começar?

Backlog DEEP

DEEP é um acrônimo para Detalhado, Estimado, Emergente e Priorizado e são as características que o Product Owner deve buscar sempre em seu backlog.

Detalhado quer dizer que o backlog deve ter os detalhes suficientes para garantir clareza que propicie execução, mas não detalhado em demasia que gere desperdício. Entenda que a necessidade de profundidade no detalhamento é proporcional à emergência de uso do backlog, ou seja, os itens que vão entrar na próxima sprints (mais emergentes) devem estar melhor detalhados, enquanto que os itens que vão entrar daqui a várias sprints, podem estar bem menos detalhados.

Detalhamento de Backlog
Detalhamento de Backlog

Estimado quer dizer que todo item quando chega a um nível de detalhamento suficiente deve ter uma estimativa de esforço associada a ele, uma vez que o backlog não é apenas uma ferramenta de trabalho, mas e planejamento. Essa estimativa pode ser em horas, em pontos, em t-shirt size, em E/EE/EEE ou o que você possa imaginar e que faça sentido para seu time. Essa estimativa inclusive lhe auxilia a entender se o nível de detalhes está bom o suficiente, pois via de regra itens de backlog com uma estimativa muito alta deveriam ser quebrados em itens menores (a técnica de Planning Poker ou de Nivelamento de Features ajuda nisso).

 

T-Shirt Size
T-Shirt Size

Emergente quer dizer que o backlog evolui conforme o Product Owner vai aprendendo sobre o produto e o mercado vai lhe dando feedback sobre seus lançamentos (seu MVP, por exemplo), ele não é estático. O constante refinamento do backlog permite que o produto reaja bem a mudanças de estratégia e de escopo, ao invés de se apegar a um planejamento waterfall. O segredo aqui é rever todo o backlog a cada ciclo construir-medir-aprender do Lean Startup.

Ciclo do Lean Startup
Ciclo do Lean Startup

Priorizado quer dizer que a ordem em que os elementos estão dispostos no backlog importa. Os itens mais prioritários devem estar ao topo, enquanto que os menos prioritários devem estar mais embaixo. Os critérios e técnicas utilizados para priorização variam muito de Product Owner para Product Owner, de produto para produto e de mercado para mercado. Para o Scrum, não importa qual é a sua técnica, mas sim que o resultado deve gerar valor para os clientes e para a empresa.

WSJF - Técnica de Priorização do SAFe
WSJF – Técnica de Priorização do SAFe

Histórias INVEST

O acrônimo INVEST é um trocadilho para dizer que devemos “investir” tempo na escrita de boas histórias de usuário, tema de outro artigo aqui do blog. INVEST significa Independente, Negociável, Valiosa, Estimável, Small (Pequena) e Testável.

Independente significa que uma boa história de usuário não depende de outras e que outras não dependem dela. Que qualquer história deveria poder ser desenvolvida em qualquer ordem, conforme a prioridade que o Product Owner determinar. Sabemos que isso não é lá muito fácil de se alcançar, mas é sempre bom chegar o mais próximo possível disso.

Negociável significa que toda boa história é uma co-criação, uma negociação entre profissionais de negócio e profissionais técnicos. Uma história deve capturar a essência de um requisito, mas não os seus detalhes, que devem ser criados de forma colaborativa e emergente. Ao longo do tempo, mais detalhes serão adicionados a cada história conforme o produto evolui e os usuários demonstram novos comportamentos. Aqui entram os 3C’s necessários em todas histórias: Card, Conversation e Confirmation.

Valiosa quer dizer que toda história deve agregar valor ao produto e principalmente, ao usuário-chave da mesma. Uma historia jamais deveria agregar valor apenas ao desenvolvedor ou apenas ao negócio, e sim sempre centrada no cliente. O Product Owner sempre se deve perguntar se ele tornará melhor a vida do cliente ao colocar aquela historia em produção. A técnica de Nivelamento de Features pode ajudar a determinar o quão valiosa é cada história.

Estimável é semelhante ao que já falamos no DEEP sobre o backlog. Para entregar um backlog estimado que me permita planejar meu roadmap de produto, é necessário ter histórias estimadas primeiro. E para conseguir estimar as histórias elas precisam ser pequenas e claras, com detalhes suficientes e bom nível de entendimento entre negócio e técnicos. Esta estimativa não precisa ser precisa, mas deve dar noções de grandeza que ajudem na tomada de decisão, priorização, etc.

Small (Pequena) para que seja possível entregá-la em no máximo uma sprint, caso contrário ela será um épico. O grande desafio obviamente é o equilíbrio entre histórias pequenas o suficiente para que seja possível estimar, mas não tão pequenas que não entreguem valor algum para o cliente. Na verdade esse é o desafio de todo o INVEST, conciliar todas as características desejáveis em uma história. Via de regra, uma história não deveria levar mais do que alguns dias de um par de programadores trabalhando nela, se está levando mais de uma semana é uma dica de que deveríamos pensar em quebrá-la.

Testável indica que toda história deve poder ser coberta de testes para validar se seus requisitos funcionais e não-funcionais foram atendidos, geralmente abordados nos critérios de aceitação da história. Uma história que não podemos testar para garantir seu funcionamento não é uma boa história, pois ou não está Independente ou é pequena demais e não entrega valor algum.

Tarefas SMART

E para terminar, o acrônimo SMART é o mais famoso dentro e fora da computação uma vez que é usado para definir muito mais do que tarefas de qualidade, mas boas métricas, bons objetivos e por aí vai. Isso porque SMART é um acrônimo para Specific (Específica), Mensurável, Alcançável, Relevante e Temporal.

Specific (Específica) indica que toda tarefa deve ter uma responsabilidade única, ser coesa com seu objetivo e entregar apenas uma parte de uma história de usuário. Para quem é programador, é o mesmo que aplicar o princípio SRP (Single Responsibility Principle) do SOLID para tarefas. Ser específica ajuda a história ser Alcançável, Mensurável e Temporal, além de garantir o entendimento de todos no time.

Mensurável é uma característica desejável para apoiar o planejamento da sprint. Se eu não tenho como medir uma tarefa, como sei se entregaremos ela a tempo? Aqui não importa a unidade de medida, embora o ágil encoraje muito mais o uso de pontos do que de horas, desde que a unidade faça sentido para todos no time e gere informação valiosa para o time e para a empresa.

Alcançável é um requisito básico para toda tarefa. O time tem que ter as competências e recursos necessários para conseguir entregar a tarefa. Simplesmente não adianta definir como prioridade uma tarefa que ninguém sabe fazer ou que vai levar tanto tempo que ela por si só deveria ser uma história ou épico. Definir tarefas inalcançáveis para o time é o primeiro passo para perder o time, até mesmo por isso que geralmente a atividade de quebra de histórias em tarefas e feitas pelo Dev Team e não pelo PO.

Relevante tem a ver com o valor que esta tarefa agrega ao todo da história. Se a tarefa não agrega em nada, ou seja, é irrelevante para a história, ela não deveria ser feita. Tarefas são quebradas para ajudar os desenvolvedores a organizarem seu trabalho, mas cada uma deveria poder ser explicada em como contribui para a história principal.

Temporal quer dizer que toda tarefa tem um tempo para ser realizada, ela tem de estar delimitada a uma timebox específica, previamente combinada entre os membros do time e utilizada para ajudar na priorização e planejamento da sprint.

Claro, nenhum desses acrônimos é bala de prata e usar todos eles juntos, todos os dias, é um desafio imenso. Mas não desista, é justamente esta busca pela perfeição no trabalho com backlog, histórias e tarefas que cria maturidade em times ágeis.

E você, conhece algum outro acrônimo que eu não citei aqui? Deixe nos comentários!

Gostou do assunto? Quer aprender mais sobre métodos ágeis? Conheça meu livro Scrum e Métodos Ágeis clicando no banner abaixo!