Os três princípios fundamentais dos métodos ágeis e do DevOps

Muitos times já aprenderam que fazer Scrum não é (apenas) colocar um conjunto de pessoas em uma sala e executar ritos como um planejamento de sprint ou uma retrospectiva. Se observamos por exemplo que o gerente determina as tarefas do time e interrompe as falas de um colaborador que traz uma sugestão, sabemos que não estamos vivendo um ambiente ágil.  É como se estivéssemos observado um animal que possui penas e bota ovos, mas você percebe que não se trata de um pássaro verdadeiro ao olhar a boca dele.

feathered-dinosaur-beipiaosaurus-exhibition-museum-natural-history-vienna-foto-taken-february-th-39609374
Archaeopteryx lithographica

Acompanhei um caso em uma empresa em 2016 onde um determinado analista, muito bem intencionado, me disse que eles possuíam o DevOps muito bem implementado. E então ele me mostrou todo um conjunto de pipelines de gestão de builds e releases implementados no Visual Studio Team System. Ele também me mostrou painéis técnicos dos vários projetos no Sonar Source e muitas estatísticas geradas.

E então eu perguntei como os times estavam usando isso para melhorar suas práticas. E a resposta foi que ele não tinha autorização do seu gerente para buscar intervenções de melhoria nos times. (!?) E mais um bicho estranho me veio à cabeça – um animal com bico de pato, que bota ovos, nada muito bem, mas que não é um pássaro.

1024px-Ornithorhynchus
Ornitorrinco – Platypus Ornithorhynchus anatinus

 

Um dos maiores riscos à adoção do ágil e do DevOps é que as pessoas não compreendam os princípios que levaram à criação dessas práticas. Isso porque os times e os resultados não irão melhorar realmente sem que os princípios fundamentais da agilidade sejam internalizados. E então podemos ter conclusões precipitadas na esfera gerencial que podem levar ao descrédito nos métodos e o retorno ao modo anterior de trabalho.

A Origem dos Princípios Ágeis e DevOps – Sistemas de Produção Lean

Um dos conceitos fundamentais no Lean é o fluxo de valor (Value Streams). Vamos defini-lo primeiro no contexto da manufatura e depois extrapolar como ele se aplica ao DevOps e ao fluxo de valor de TI. Podemos definir o fluxo de valor como “a sequência de atividades que uma organização empreende para atender a uma solicitação do cliente” ou “a sequência de atividades necessárias para projetar, produzir e entregar um bem ou serviço a um cliente, incluindo os fluxos de informação e material.

Nas operações de manufatura, o fluxo de valor é geralmente fácil de ver e observar. Ele começa quando um pedido do cliente é recebido e as matérias-primas são liberadas no chão-de-fábrica. Para permitir tempos de execução rápidos e previsíveis em qualquer fluxo de valor, normalmente há um foco implacável na criação de um fluxo leve e uniforme de trabalho, usando técnicas como pequenos tamanhos de lote e redução do trabalho em progresso (WIP). Buscamos também evitar o retrabalho para garantir que não transmitamos defeitos para as próximas etapas do processo. Finalmente, buscamos otimizar continuamente nosso sistema em direção aos nossos objetivos globais.

Os mesmos princípios e padrões que permitem o fluxo rápido de trabalho em processos físicos são igualmente aplicáveis ​​ao trabalho de tecnologia de informação ou qualquer outro trabalho de natureza de conhecimento. No mundo Agile e DevOps, normalmente definimos nosso fluxo de valor de tecnologia como o processo necessário para converter uma hipótese de negócios em um serviço habilitado por tecnologia que agregue valor ao cliente.

A entrada para o nosso processo é a formulação de um objetivo de negócio, conceito, ideia ou hipótese. El começa quando aceitamos o trabalho em Desenvolvimento, adicionando-o ao nosso backlogde trabalho. A partir daí as equipes de desenvolvimento que seguem um processo ágil ou iterativo típico provavelmente transformarão essa ideia em histórias de usuários e em algum tipo de especificação de recurso, que é implementada em código no aplicativo ou serviço que está sendo construído. O código é então guardado no repositório de controle de versão, onde cada alteração é integrada e testada com o restante do sistema de software.

Como o valor é criado somente quando nossos serviços estão sendo executados na produção, devemos garantir que não apenas fornecemos fluxo rápido, mas que nossas implantações também podem ser realizadas sem causar caos e interrupções, como interrupções de serviço ou deficiências de atendimento a requisitos de performance, segurança e usabilidade, entre outros.

O Foco Implacável no Tempo de Entrega

usain-bolt-atleta-0816-1400x800-3

Em implantações Ágeis DevOps, nossa atenção deve estar no tempo total de entrega dos itens do backlog a até a produção (Lead Time). Esse fluxo de valor começa quando qualquer analista em nosso fluxo de valor verifica uma alteração no controle de versão e termina quando essa alteração é executada com êxito na produção, fornecendo valor ao cliente e gerando feedback útil e telemetria.

Em empresas tradicionais muitas vezes nos encontramos em situações em que os prazos de implantação exigem meses. Isso é especialmente comum em organizações grandes e complexas que trabalham com aplicativos monolíticos muito acoplados, geralmente com ambientes de teste de integração escassos, longos períodos de teste nos departamentos de qualidade, alta dependência de testes manuais e muitos processos manuais de aprovação.

Quando temos longos tempos de implantação, precisamos de super-heróis em quase todos os estágios do fluxo de valor. Podemos descobrir que nada funciona no final do projeto quando integramos todas as alterações da equipe de desenvolvimento, resultando em códigos que não são mais compilados corretamente ou que não passam em nossos testes. A correção de cada problema requer dias ou semanas de investigação para determinar quem quebrou o código e como ele pode ser corrigido e ainda resulta em resultados insatisfatórios para os clientes.

Ao falar de ágil e DevOps, os desenvolvedores recebem feedback rápido e constante sobre seu trabalho, o que permite que implementem, integrem e validem seu código de maneira rápida e independente e com isso implantem o código no ambiente de produção sem efeitos colaterais.

Conseguimos isso verificando continuamente pequenas alterações de código em nosso repositório de controle de versão, realizando testes automatizados e exploratórios e implementando-o na produção. Isso nos permite ter um alto grau de confiança de que nossas alterações funcionarão conforme projetado na produção e que quaisquer problemas podem ser rapidamente detectados e corrigidos. Isso é mais facilmente alcançado quando temos uma arquitetura modular, bem encapsulada e fracamente acoplada, para que as pequenas equipes possam trabalhar com alto grau de autonomia, com falhas pequenas e contidas, sem causar interrupções globais.

De fato, times DevOps desenvolvem um sistema de trabalho que os permitem entregar software em produção em base diária. Exemplos de empresas que publicados relatos impressionantes dessa agilidade de negócio incluem a Amazon, Netflix, WalMart, Target, Nordstorm, Facebook, Adobe e Sony, entre outras.

Mas, afinal, que princípios são esses que permeiam o ágil e o DevOps e o que eles dizem de tão importante?

Yoda_7
“Os três princípios deve você usar para habilitar a força dos métodos ágeis e DevOps”

Princípio #1 – Fluxo Contínuo

No fluxo de valor de TI, o trabalho normalmente flui de Desenvolvimento para Operações. O primeiro princípio demanda o fluxo rápido e suave do trabalho desde o Desenvolvimento até as Operações para entregar valor aos clientes rapidamente. Nós otimizamos esse objetivo global mais que metas locais, como taxas de conclusão de tarefas de desenvolvimento, taxa de correção de testes ou medidas de disponibilidade de operações.

Aumentamos o fluxo tornando o trabalho visível, reduzindo o tamanho dos lotes e os intervalos de trabalho e criando qualidade, evitando que os defeitos sejam transmitidos aos estágios anteriores de trabalho. Ao acelerar o fluxo através do fluxo de valor da tecnologia, reduzimos o tempo de espera necessário para atender às solicitações dos clientes internos e externos, aumentando ainda mais a qualidade do nosso trabalho, tornando-nos mais ágeis e capazes de superar a concorrência.

Nosso objetivo aqui é diminuir o tempo necessário para que as mudanças sejam implantadas na produção e aumentar a confiabilidade e a qualidade desses serviços. Dicas sobre como fazemos isso no fluxo de valor da tecnologia podem ser obtidas a partir de como os princípios do Lean foram aplicados ao fluxo de valor na indústria e incluem:

  • Tornar o trabalho visível;
  • Limitar o trabalho em progresso;
  • Reduzir o trabalho em lotes;
  • Reduzir os repasses;
  • Identificar e limpar impedimentos e
  • Reduzir a dificuldade do trabalho diário.

Princípio #2 – Feedbacks Frequentes

O segundo princípio descreve os mecanismos que permitem feedbacks rápidos da direita para a esquerda em todos os estágios do fluxo de valor. Como exemplo, feedback dos times de operações para implantadores e feedbacks dos analisas de testes para implementadores. O nosso objetivo é criar um sistema de trabalho cada vez mais seguro e resiliente.

Na TI, o trabalho acontece quase inteiramente dentro de sistemas complexos com risco alto de defeitos e paradas em produção. Como na manufatura, geralmente descobrimos problemas apenas quando ocorrem grandes falhas, como uma interrupção de produção em massa ou uma violação de segurança que resulta no roubo de dados do cliente.

Iremos tornar o nosso sistema de trabalho mais seguro através da criação de fluxo de informações rápido, frequente e de alta qualidade em todo o fluxo de valor e em nossa organização, o que inclui feedback frequente entre toas as pessoas e funções. Isso permite detectar e corrigir problemas enquanto eles são menores, mais baratos e mais fáceis de consertar; evitar problemas antes que causem catástrofe; e criar aprendizado organizacional que integramos no trabalho futuro. Quando fracassos e acidentes ocorrem, devemos trata-los como oportunidades de aprendizado, em oposição a uma causa de punição e culpa.

Uma das características que define um sistema complexo é que ele desafia a capacidade de qualquer pessoa de ver o sistema como um todo e entender como todas as partes se encaixam. Os sistemas complexos normalmente possuem um alto grau de interconectividade de componentes fortemente acoplados, e o comportamento no nível do sistema não pode ser explicado meramente em termos do comportamento de cada componente individual do sistema.

Falhas são inerentes e inevitáveis em sistemas complexos. E então devemos projetar um sistema de trabalho seguro onde possamos executar o trabalho sem medo, confiantes de que quaisquer erros serão detectados rapidamente, muito antes de causarem resultados catastróficos como danos aos trabalhadores, defeitos no produto ou impacto negativo no cliente.

Projetar sistemas perfeitamente seguros está além da capacidade de qualquer time, mas podemos tornar mais seguro trabalhar em sistemas complexos quando as quatro condições a seguir são atendidas:

  • O trabalho complexo é gerenciado para que os problemas no design e nas operações sejam revelados;
  • Os problemas são tratados coletivamente e resolvidos, resultando na rápida construção de novos conhecimentos;
  • Novo conhecimento local é explorado globalmente em toda a organização;
  • Os líderes criam outros líderes que continuamente aumentam as capacidades da organização.

Em um sistema de trabalho seguro, devemos testar constantemente nossas premissas de projeto e operação. Nosso objetivo é aumentar o fluxo de informações em nosso sistema de tantas áreas quanto possível, mais cedo, mais rápido, mais barato e com tanta clareza entre causa e efeito quanto possível. Quanto mais suposições possamos invalidar, mais rápido podemos encontrar e corrigir problemas, aumentando nossa resiliência, agilidade e capacidade de aprender e inovar.

No fluxo de valor de TI, muitas vezes obtemos resultados ruins devido à ausência de feedback rápido. Por exemplo, em um projeto de software em cascata, podemos desenvolver código por semanas ou meses e não obter feedback algum sobre qualidade até começarmos a fase de testes – ou, pior ainda, quando lançamos nosso software para os clientes. Quando o feedback é atrasado e pouco frequente, é pouco eficaz para permitir evitar resultados indesejáveis.

No mundo DevOps, o nosso objetivo é criar feedback rápido em todos os estágios do fluxo de valor de tecnologia, abrangendo Gerenciamento, Desenvolvimento, Controle de Qualidade, Segurança da Informação e Operações do Produto. Isso inclui a criação de processos automatizados de criação, integração e teste, para que possamos detectar imediatamente quando uma alteração foi introduzida que nos tire de um estado de funcionamento e implementação corretos.

Também criamos telemetria abrangente para que possamos ver como todos os nossos componentes de sistema estão operando no ambiente de produção, para que possamos detectar rapidamente quando eles não estão operando conforme o esperado. A telemetria também nos permite medir se estamos atingindo nossas metas pretendidas e, idealmente, é irradiada para todo o fluxo de valor, para que possamos ver como nossas ações afetam outras partes do sistema como um todo.

Os loops de feedback não apenas permitem a rápida detecção e recuperação de problemas, mas também nos informam sobre como evitar que esses problemas ocorram novamente no futuro. Isso aumenta a qualidade e a segurança de nosso sistema de trabalho e cria aprendizado organizacional.

O Terceiro Princípio – Aprendizado Organizacional

Enquanto o Primeiro Caminho aborda o fluxo de trabalho da esquerda para a direita e o Segundo Caminho aborda o feedback rápido e constante recíproco da direita para a esquerda, o Terceiro Caminho foca na criação de uma cultura de aprendizagem e experimentação contínua. Esses são os princípios que permitem a criação constante de conhecimento individual, que é então transformado em conhecimento de equipe e organizacional.

Diversas empresas tem aprendido que a formação de times de alta performance depende da promoção da segurança psicológica e do estabelecimento de clareza de propósitos. A segurança psicológica é a crença compartilhada pelos membros de uma equipe que a equipe é segura para assumir riscos interpessoais. Em outras palavras, é uma crença que as pessoas não serão repreendidas ou humilhadas por trazer ideias, questões, preocupações e por simplesmente errarem. Afinal, errare humanum est! 

Pesquisadores de eficiência organizacional na Google descobriram que indivíduos em equipes com maior segurança psicológica são menos propensos a sair do Google, são mais propensos a aproveitar o poder de ideias diversas de seus companheiros de equipe, trazem mais receita e são classificados como duas vezes mais eficazes por seus líderes.

Empresas de TI de alto desempenho exigem e promovem ativamente o aprendizado. Em vez de o trabalho ser rigidamente definido, o sistema de trabalho é dinâmico, com os times realizando experimentos em seu trabalho diário para gerar novas melhorias, possibilitadas pela rigorosa padronização dos procedimentos de trabalho e documentação dos resultados.

No fluxo de valor de TI, nosso objetivo é criar uma cultura de alta confiança, reforçando que somos todos aprendizes ao longo da vida que devem assumir riscos em nosso trabalho diário. Ao aplicar uma abordagem científica para a melhoria de processos e o desenvolvimento de produtos, aprendemos com nossos sucessos e fracassos, identificando quais ideias não funcionam e reforçando aquelas que funcionam. Além disso, qualquer aprendizado local é rapidamente transformado em melhorias globais, de modo que novas técnicas e práticas possam ser usadas por toda a organização.

Reservamos tempo para a melhoria do trabalho diário e para acelerar ainda mais e garantir a aprendizagem. Nós constantemente introduzimos estresse em nossos sistemas para forçar a melhoria contínua. Podemos até simularmos e injetamos falhas em nossos serviços de produção sob condições controladas para aumentar nossa resiliência. E ao criar esse sistema contínuo e dinâmico de aprendizado, possibilitamos que as equipes se adaptem rápida e automaticamente a um ambiente em constante mudança, o que, em última análise, nos ajuda a vencer no mercado.

Quando trabalhamos dentro de um sistema complexo, por definição, é impossível prevermos perfeitamente todos os resultados de qualquer ação que tomemos. É isso que contribui para resultados e acidentes inesperados, ou mesmo catastróficos, em nosso trabalho diário, mesmo quando tomamos precauções e trabalhamos com cuidado.

Quando esses acidentes afetam nossos clientes, procuramos entender por que isso aconteceu. A causa raiz é muitas vezes considerada como erro humano, e a resposta gerencial muito comum é “nomear, culpar e envergonhar” a pessoa que causou o problema. E, de forma sutil ou explícita, a gerência sugere que a pessoa culpada cometer o erro será punido. Em seguida, eles criam mais processos e aprovações para evitar que o erro ocorra novamente. No fluxo de valor da TI, estabelecemos as bases de uma cultura generativa, esforçando-nos para criar um sistema de trabalho seguro.

Quando acidentes e falhas ocorrem, em vez de procurar por erro humano, procuramos como podemos redesenhar o sistema para evitar que o acidente aconteça novamente.

Por exemplo, podemos realizar uma análise post-mortem após cada incidente para obter o melhor entendimento de como ocorreu o acidente e definir quais são as melhores contramedidas para melhorar o sistema, evitando de maneira ideal que o problema volte a ocorrer e permitindo uma detecção e recuperação mais rápidas.

O resultado de eliminar a culpa e colocar o aprendizado organizacional em seu lugar é que as organizações se tornam cada vez mais autodiagnosticas e auto aperfeiçoadas, hábeis em detectar problemas e resolvê-las”.

Muitos desses atributos também foram descritos pelo autor Peter Senge como atributos das organizações que promovem aprendizado continuado. No excelente livro chamado A Quinta Disciplina, ele escreveu que essas características ajudam os clientes, garantem a qualidade, criam vantagem competitiva e uma força de trabalho comprometida e motivada.

Resumo dos Três Princípios

Os métodos ágeis e o DevOps não são processos fechados ou um conjunto de ferramentas. Ao invés, eles são uma cultura baseada nos sistemas Lean e que busca reduzir o tempo da entrega de valor em produção, aumentar o feedback entre o time e fornecer um ambiente seguro para experimentações e inovações de negócio.

Ao realizar o seu próximo planejamento de sprint, ao pensar em automações de testes, ao criar pipelines DevOps ou contêineres Docker, pare e pense:

  • Como estou ajudando o meu time a entregar software mais rapidamente em ambiente de produção?
  • Como estou melhorando os feedbacks entre os membros do time e também o time e os nossos clientes?
  • Como o nosso ambiente está ficando mais seguro para habilitar que as pessoas aprendam e melhorem continuamente?

Se você identificou as relações, muito bom! Ajude o seu time a internalizar os princípios ágeis e DevOps e prospere continuamente no aumento da maturidade do Scrum, XP, Kanban e DevOps na sua empresa.

“Are you too busy for improvement? Frequently, I am rebuffed by people who say they are too busy and have no time for such activities. I make it a point to respond by telling people, look, you’ll stop being busy either when you die or when the company goes bankrupt.”
— Shigeo Shingo, Pai do Sistema Toyota de Produção

 

 

Desenvolvedores que sabem dizer NÃO. Você é um deles?

Qualquer semelhança com o mundo real.. Não é mera concidência.

Marco (o gerente ansioso, na segunda-feira) – Eu preciso desta funcionalidade entregue até Sexta-Feira. É ordem do cliente!

Bernardo (o desenvolvedor) – Hmm. Marco, sei não. Esta funcionalidade lida com três itens regulatórios, uma nova aba com 30 campos e um relatório complexo. E eu ainda preciso testar tudo isso e cuidar da implantação no nosso ambiente de nuvem.

Marco (o gerente mais ansioso ainda) – Olha. Eu REALMENTE preciso desta funcionalidade realmente para Sexta-Feira. O prazo já está dado. Faça o que for necessário e não me venha com esta bobagem de precisar fazer testes e código limpo.

Bernardo (o desenvolvedor passivo, resmungando..) – Ok, chefe. Eu vou tentar!

Marco (aliviado) – Ótimo, então. Estou já no aguardo. 

….

Na sexta-feira…

Marco  – Bernardo, o código já está pronto? Cliente me ligou aqui já.

Bernardo – Ainda não, chefe. Mal consegui terminar o cadastro. E tenho apenas o protótipo do relatório. E o Cauã ainda está testando o cadastro.

Marco – P#@*$ Bernardo. Você não consegue cumprir prazos. Que m*#&$! O que vou dizer para o cliente?

Bernardo – Olha. Eu disse apenas que ia tentar. E não meu culpe por isso porque o requisito veio incompleto, o analista financeiro do cliente não tinha disponibilidade para tirar minhas dúvidas. Não é minha culpa!!!

E mais uma pequena tragédia da vida real da TI ocorre.

O que aconteceu aqui?

  • Se você é um desenvolvedor, você vai pensar que a culpa é do chefe malvado e opressor. E isso não é um problema do pobre desenvolvedor, que fez o seu melhor.
  • Se você é um gerente, você vai pensar que o problema é do desenvolvedor desmazelado e sem compromisso.

Mas vamos sair para a TI por um momento.

Você entra em um Uber e precisa cruzar o centro da sua cidade. Você precisa estar no seu compromisso em 10 minutos. Mas o motorista sabe que isso não é possível, pois isso leva 30 minutos no horário da tarde. E você como cliente pode protestar e dar um soco no capô do carro e dizer. P*##&#…. eu preciso estar lá em 10 minutos. E ainda assim qualquer motorista responsável irá dizer que isso não é aceitável. E tentar ir mais rápido não irá mudar a situação.


Do; or Do Not. There is no Try!

Diga Sim ou… Diga Não.

O que o desenvolvedor deveria ter feito?

  • Dizer sim, se ele possui uma experiência com este tipo de demanda e se sente bastante confortável com os prazos.
  • Ou dizer que ele não consegue entregar este escopo no prazo estabelecidor.

“Mas isso não é meu problema” …. pode pensar um desenvolvedor. “A culpa é do meu chefe”.

Sinto informar, mas é você que está sendo demandado. E então é sua obrigação ética dizer se a tarefa é viável ou não.

Se fazer de vítima (passivo) e depois ficar putinho na Sexta-feira (agressivo) é atitude imatura do esterótipo profissional passivo-agressivo. Isso demonstra, no mínimo, um quociente emocional ainda que precisa ser desenvolvido. Para não dizer um quarto palavrão no meu texto, que seria muito deselegante.

Entendi…  Então preciso apenas dizer Não!?

A resposta é… Não.

É fácil dizer Não e não fornecer opções. Qualquer criança de 6 anos faz isso. Mas enquanto profissional pleno você deve apresentar opções. E isso envolve negociações e encarar sem medo o conflito momentâneo com o seu chefe.

Bernardo (desenvolvedor responsável): Olha, Marco. Sexta-Feira não é aceitável. Eu preciso fazer a modelagem de dados, o protótipo de telas, a implementação do código. Preciso limpar dúvidas de regras de negócio com o cliente e isso vai demandar 4 horas apenas de reuniões. E preciso fazer os testes de unidade, refatorar o código, preparar a implantação na EC2 e coordenar os testes com o Cauã (Analista de testes) e com o time da infraestrutura.

Marco (gerente ansioso): Testes de unidade. Refatoração. Isso é frescura de desenvolvedor Nutella! ha ha…  E ..hmmm… podemos envolver o Cauã apenas na Sexta-Feira e pular pode parte dos testes do relatório, não? E você pode fazer horas extras novamente! Tenho certeza que sua esposa irá entender a gravidade da situação

Bernardo (o desenvolvedor responsável):  Não fazer testes é gerar débito técnico. Você sabe, Marco, pela experiência do ano passado o que acontece quando envolvemos o time de testes apenas no final da demanda. E não criar a automação de testes de unidade vai gerar efeito muito ruim em médio prazo. E tudo isso vai afetar a imagem do produto e da nossa empresa.

Bernardo (o desenvolvedor responsável): E veja. Insistir em fazer horas extras em base continuada não irá melhorar a sirtuação. Você e eu sabemos que pessoas cansadas inserem mais defeitos no código. Já estou com 15 horas no banco de horas neste mês e não posso comprometer mais o tempo com meus filho e minha esposa.

Bernardo (o desenvolvedor responsável): Ao mesmo tempo … podemos buscar negociar com o cliente o escopo. Também fiz uma estimativa detalhada aqui com o João e a Marina e vi que podemos trabalhar primeiro na parte regulatória e negociar a nova aba com os dados adicionais que ele está pedindo. E podemos fazer uma consulta momentânea para exibir os dados centrais do relatório que ele está pedindo. E com isso podemos buscar negociar a outra aba do cadastro e o relatório para a próxima semana.

Marco (o gerente ainda ansioso): E então você me entrega isso na Sexta-Feira!

Bernardo: Sem problemas, chefe! 

O que aconteceu aqui?

O nosso desenvolvedor trouxe a realidade para a sala. Ele não removeu da sua lista as atividades essenciais, como testes de unidade ou refatoração. Ele sabe que isso seria irresponsável pois somente traria passivo técnico para ele e para o time. Ele fez um trabalho de estimativas com o time. E ele negociou o escopo e apresentou alternativas para a sua chefia.

Mas… eu tenho medinho de contestar com o meu chefe!!

Sim. Quanto tinha seis anos, eu também tinha medo de contestar meu pai. Mas quando você é adulto, você precisa ser responsável pelos seus atos.

E se você é um desenvolvedor responsável você precisa sim negociar e tomar atitudade responsáveis na hora de fornecer compromissos. Por experiência ao longo dos meus últimos 25 anos em TI, observo que a solução simples “Dizer sim” pode gerar um conforto momentâneo, mas o problema irá voltar. Muito pior e ainda sim teremos uma situação muito desagradável.

Negociar pode também ser desagradável. Você pode ter medo de ser repreendido. Você pode ter medo de ser despedido. Você pode ter medo do seu chefe ficar com raiva de você. Mas por experiência vejo que bons gerentes não despendem profissionais que contestem seus pedidos. Eles despedem profissionais que falham continuamente na entrega dos seus acordos.

E conheço vários bons gerentes que conheço esperam que os desenvolvedores saibam contestar. Eles passam a respeitar aqueles profissionais, muito mais que os passivos-agressivos que somente sabem resmungar e criticar o chefe na hora do almoço com seus coleguinhas de 6 anos de idade.

E saber contestar envolve:

  • Estudar com o profundidade o problema sendo dado;
  • Realizar diagnósticos precisos;
  • Apresentar alternativas;
  • Buscar soluções ganha ganha.

Mas… você não conhece o meu chefe! E aqui na minha empresa é diferente…

Talvez sim. E apesar disso você não irá cruzar o centro da capital do seu estado em 10 minutos no horário de rush. Não de carro. E dizer sim de forma ingênua não irá resolver o seu problema.

Ser transparente, que por acaso é um dos pilares dos métodos ágeis, é o caminho a ser seguido.

E onde aprendo a negociar com o meu gerente? No SEBRAE?

Para fazer negociações de desenvolvimento de software, não, infelizmente.

Recomendo duas leituras obrigatórias para o desenvolvimento emocional de todo bom desenvolvedor. O primeiro discute como a importância da atitude ética, técnicas de negóciação e como lidar com a natural pressão gerencial em toda empresa.

Já o livro abaixo é um dos cinco melhores que já tive a oportunidade de ler em minha vida e teve profunda influência no meu modo de pensar em TI. Ele irá lhe trazer uma visão sóciotécnica muita rica sobre o que é trabalhar em TI e 50 ferramentas para você usar no seu dia a dia de trabalho para bater as pressões de tempo que a realidade corporativa nos traz.

Quando a circunstância é boa, devemos desfrutá-la; quando não é favorável devemos transformá-la e quando não pode ser transformada, devemos transformar a nós mesmos, Victor Frankl

 

Maturidade 5 em Métodos Ágeis – Em busca da Anti-Fragilidade

Neste último artigo sobre um modelo de maturidade em métodos ágeis, iremos descrever como reduzir a fragilidade organizacional.

A figura abaixo mostra um esquema com níveis de maturidade organizacional em métodos ágeis, ao longo das perspectivas de times, ritos, entregas e qualidade. O nível 1 mostra uma organização mais frágil. Os níveis intermediários e avançados mostram organizações que não são mais frágeis.

 

ModeloMaturidadeMetodosAgeisv2
Melhoria contínua em métodos ágeis [Imagem maior]

A fragilidade organizacional é aqui definida aqui como aquele tipo de organização onde os eventos negativos provocam efeitos devastadores.

Um exemplo – A Anti-Fragilidade para Times

Um exemplo de fragilidade é uma organização que tenha um time baseado no modelo comando e controle. Neste modelo, existe a figura de um gerente forte e subordinados que cumprem comandos, com baixa interação entre si. Este modelo é frágil, pois pode ser abalado por várias questões tais como:

  • Uma provável baixa capacidade do gerente de lidar com todos os problemas do dia a dia;
  • Uma baixa capacidade de aprendizado dos comandados devido a sua baixa comunicação (não é tão comum encontrar pessoas que aprendam sozinhas);
  • Uma baixíssima resiliência a qualquer evento que afete o gerente (ausências no dia a dia ou faltas ao trabalho);
  • Um provável colapso do time quando esse gerente deixa a organização.

Ao reconhecer a fragilidade em um time, uma organização pode introduzir mecanismos de resiliência. Ao fazer isso, por exemplo, com mais autonomia para as pessoas, delegação administrativa  e maior comunicação interna, estaremos avançado para um time robusto.

Definimos robustez organizacional aqui como a capacidade de resistir a eventos negativos, que ocorrem em todas organização. No exemplo acima teríamos então a figura forte de um gerente, ao mesmo tempo com mais autonomia e comunicação entre os liderados. Nesse modelo robusto, o time consegue trabalhar sem o gerente e até suportar a sua perda, pois possuem autonomia e se comunicam com frequência.

A robustez parece o objetivo desejável, mas ela não é o contrário da fragilidade. Se a fragilidade fosse um número negativo, a robustez seria o número zero. Isto é, na robustez apenas lidamos com os eventos negativos, mas não geramos oportunidades de ganhos positivos nas incertezas. Times robustos, ao invés, apenas restauram o estado inicial após um incidente negativo.

E aqui entra o conceito da anti-fragilidade. Quando uma organização avança além da robustez, ela se torna anti-frágil. A anti-fragilidade é definida aqui como a resiliência para lidar com eventos negativos e ao mesmo tempo explorar oportunisticamente os eventos negativos e positivos. A anti-fragilidade é o contrário da fragilidade, i.e., é o tipo de organismo que se torna mais forte após as adversidades.

No exemplo de times, definimos então um time anti-frágil como um time auto-organizado.

  • Em times auto-organizados, não existem “gerentes” no sentido clássico. Existem líderes facilitadores que preparam o terreno para o time atuar e fazer o seu melhor coletivamente.
  • Aqui eles organizam as suas tarefas, resolvem os seus conflitos e periodicamente discutem o que funcionou e o que precisa ser aperfeiçoado. Aquilo que não funcionou irá gerar uma agenda de melhoria, que irá fortalecer esse time.
  • Em times auto-organizados, análises de causa raiz são realizadas para lidar com a fonte dos problemas, evitando erros similares futuros e portanto os tornando mais anti-frágeis.
  • Times auto-organizados são generalistas-especialistas e portanto redundantes a absenteísmos e rotatitivades (até um certo ponto). A redundância é uma das propridades desejadas em sistemas anti-frágeis.
  • Finalmente, time auto-organizados promovem e resolvem conflitos através de uma cultura permanente de feedbacks estruturados. Isso limpa arestas, problemas de relacionamento e cria extrema confiança entre os participantes.

Frameworks gerencias modernos como o Management 3.0  ou a Holocracia tem promovido a formação de times auto-organizados (e mais anti-frágeis que os tradicionais times de mercado). O  caso Zappos, que citamos em um post anterior dessa série, é um exemplo emblemático do uso da holocracia em uma empresa que fatura mais de 1 bilhão de dólares por ano.

Um outro exemplo – A Anti-Fragilidade para a Qualidade de Produtos

Um exemplo de qualidade frágil é um time de desenvolvimento de software que entrega produtos em produção com muitos defeitos e por isso tem boa parte da sua agenda ocupada com incidentes críticos no ambiente de produção.

Ao mesmo tempo, se esse time reconhecer a fragilidade, criar uma consciência de testes e começar a trabalhar em pequenos instrumentos como refatoração, testes de unidade e TDD, essa mesma organização pode avançar do mundo da fragilidade para a robustez.

Uma organização robusta para testes e qualidade parece apropriada, mas ela simplesmente tolera até certo nível os riscos negativos que ocorrem no desenvolvimento e manutenção dos seus produtos. No exemplo de qualidade acima, ela é aquela que escreve testes e os automatiza para lidar com a imprevisibilidade ambiental, que sempre irá acontecer. (exemplo: hardwares ou banco de dados sempre falharão em algum momento). Ao mesmo tempo, a robustez não cria inovação e não usa as oportunidades positivas que também se apresentam (assim como as negativas).

Nesse mesmo exemplo de qualidade, um time pode perceber que as práticas de testes podem ser tão poderosas que podem ser usadas para:

  • provocar falhas rapidamente no ambiente com automação de testes (CI/CD) – gerar erros pequenos no começo do produto é benigno e anti-frágil;
  • trabalhar a especificação de requisitos em uma abordagem BDD (Behavior Driven Development). Com o BDD, analistas exploram narrativas de negócio na forma de teste desde o começo do desenvolvimento do produto, reduzindo assim o custo total do desenvolvimento de software e ao mesmo capturando problemas que somente seriam descobertos mais tarde no projeto;
  • realizar testes de situações anômalas, como provocar deliberamente a falha de componentes e observar o comportamento do sistema (um exemplo ótimo nesse sentido é o aplicativo CodeMonkey do NetFlix, que derruba aleatoriamente servidores em produção para descobrir e antecipar problemas. Sim, ambiente de produção!);
  • introduzir tolerância a falhas e elasticidade computacional nos seus ambientes de produção, para aproveitar as oportunidades de picos de usuários em eventos futuros incertos.

 

Da fragilidade para a robustez. E da robustez para a anti-fragilidade

A melhoria contínua é o processo contínuo que levou organizações sem maturidade a estágios mais avançados. Mesmo nas organizações mais avançadas quanto ao uso de métodos ágeis, a melhoria contínua é o instrumento que as levam a manter as suas conquistas e buscar ainda mais aprimoramentos.

A melhoria contínua é a mola mestra para sair da fragilidade e avançar para a robustez e anti-fragilidade. Ela envolve sistematizar:

  • a observação ambientel dos eventos (positivos e negativos);
  • o debate regular sobre os acontecimentos positivos e como eles podem ser mantidos no sistema;
  • o debate regular sobre os acontecimentos negativos e como eles podem ser eliminados ou mitigados através de ações de melhoria no sistema.

Se um time realiza este “ritual” periodicamente, ele avança de forma contínua e em breve começa a eliminar as suas fragilidades, uma a uma.

Se pudesse recomendar uma prática inicial para qualquer time que queira se tornar ágil, esta prática seria a retrospectiva Scrum ou o ritual Kaizen em métodos Lean.

A Toyota é um excelente exemplo de como a aplicação sistemática de pequenas melhorias, de forma contínua, pode trazer grandes resultados em longo prazo. De forma geral, a Toyota é reconhecida por produzir carros com maior qualidade, menos defeitos embutidos,  menos horas de pessoas, estoques e plantas menores no processo produtivo do que os seus concorrentes. O livro Toyota Way mostra como essa cultura gerencial fantástica foi trabalhada passo a passo.

Sobre Anti-Fragilidade

É um conceito cunhado por Nicholas Taleb e inicialmente sistematizado na história humana na filosofia estóica (Sêneca, Marcus Aurelius e Epícuro). Um artigo introdutório e interessante sobre o tema pode ser encontrado no artigo Beyond Sissy Resilience: On Becoming Antifragile, que apresenta uma bela figura metafórica sobre o conceito.

antifragile-3

 

Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better ― Nassim Nicholas TalebAntifragile: Things That Gain from Disorder

Maturidade 4 em Métodos Ágeis – Agilidade em Escala Organizacional

Em continuidade ao nosso modelo de maturidade em métodos ágeis, iremos falar da escalabilidade das práticas ágeis em organizações. Vimos que no nível 3 de maturidade as práticas ágeis se tornam consistentes dentro de um projeto. O caminho natural  é o espalhamento dessas práticas por diversos projetos, áreas ou até mesmo toda uma organização.

Desde a nascimento dos métodos ágeis há 20 anos atrás, diversos praticantes enfretaram o problema da escalabilidade de métodos ágeis. Os resultados foram diversos e levaram a um conjunto robusto de frameworks de processo. Compilamos alguns abaixo.

LESS (Large Scale SCRUM)

Large Scale Scrum

Origem: O LESS foi compilado a partir das  experiências  de Craig Larman e Bas Voodle em consultoria e desenvolvimento de produtos em larga escala, com centenas de analistas trabalhando simultaneamente com um objetivo unificado.

Bases conceituais: O LESS tem como pilares o SCRUM, o pensamento Lean e Teoria de Sistemas. O SCRUM fornece ao LESS a estrutura, papéis, ritos e produtos de trabalho. O pensamento Lean fornece a esse framework a sólida base de conhecimento do Sistema Toyota de Produção, incorporado com robustez nesse trabalho. A Teoria de Sistemas traz os elementos poderosos de pensamento tais como efeitos defasados no tempo, ciclos de reforço positivos e negativos, análise de causas raízes e arquétipos organizacionais. O sítio mantido pelos autores é uma rica fonte de informações, congregando ao mesmo tempo conceitos sofisticados e práticas aplicáveis em virtualmente qualquer tipo de projeto.

Livro essencial:  Scaling Agile and Lean Development: Thinking and Organizational Tools for Large-Scale Scrum, Craig Larman e Bas Voodle.

Certificação de entrada: Certified LESS Practicioner


 

SAFe (Scaled Agile Framework)

SAFE 4.0
SAFE 4.0

Origem: O SAFE, que teve a versão 4.0 lançada em Janeiro de 2016, é fruto do trabalho de Dean Leffingwell, direcionado para operar uma área de Tecnologia de Informação em alinhamento ao portifólio organizacional, com o uso de princípios e práticas ágeis e lean.

Bases Conceituais: O SAFE também é fortemente baseado no SCRUM e no pensamento Lean. Entretanto, observamos nesse método também conceitos gerenciais clássicos como o uso de cadeias de valor, portifólio e programas de projetos. O SAFE é um método com uma estrutura mais rígida que outros métodos ágeis, o que traz críticas de agilistas mais extremos e elogios de gerentes que estão acostumados com escolas gerenciais mais tradicionais.

Livro Essencial: Scaling Software Agility: Best Practices for Large Enterprises (Agile Software Development Series)

Certificação de Entrada: SAFe Agilist


NEXUS

Nexos Framework
Nexus Framework

 

Origem: O Nexus teve origem a partir da experiência de Ken Schwabber, um dos pais do SCRUM, no desenvolvimento de produtos com vários times Scrum operando em paralelo. O Nexus é mantido pela comunidade Scrum.Org.

Bases Conceituais: O framework Nexus é a sistematização da técnica de escala o Scrum chamada Scrum of Scrums, para projetos que demandem entre 3 e 9 times operando em paralelo. Ele introduz novos papéis e um time especial (Time de Integração) e tem como foco central a integração e coordenação dos esforços de cada time na construção dos incrementos de produtos.

Livro Essencial: Guia do Nexus, já traduzido para o português.

Certificação de Entrada: Scaled Professional Scrum (SPS)


 

Holocracia (Holacracy)

Holocracia
Holocracia

Origem: A Holocracia é um sistema descentralizado de tomada de decisões para que empresas possam criar mecanismos de auto-organização para operar em ambientes dinâmicos e complexos.  

Base Conceitual: A Holocracia tem em seus pilares conceitos sociológicos de organizações de centro vazio, conceitos de auto-organização, teoria da complexidade e teoria da emergência (emergence). A Holocracia não é um framework de TI e tampouco centrada em projetos apenas. Ele lida com o problema de criar organizações anti-frágeis (como definido por Nassib Taleb no seu potente livro Anti-Fragilidade: coisas que se beneficiam da desordem). A Zappos, bilionária empresa americana recentemente comprada pela Amazon, implementa a holocracia como o seu sistema gerencial descentralizado. O portal Holacracy.org é uma vasta fonte de recursos para interessados e praticantes.

Livro Essencial: Holacracy: The New Management System for a Rapidly Changing World 

Certificação de Entrada: Holocracy Practicioner


 

Cada uma desses frameworks possui dezenas de casos documentados e milhares de empresas em todo o mundo que os usam para seu benefício econômico e social. E de volta ao nosso modelo de maturidade, definimos o uso de métodos ágeis em escala organizacional com esses ou outros frameworks similares como sendo o nível 4 de maturidade.

Organizações que atingem esse nível transcedem os projetos de desenvolvimento de software ou infraestrutura. Essas organizações mudam a sua estrutura interna de funcionamento e transcendem as mazelas gerenciais e ineficiências tão fortemente instaladas em muitas organizações ainda presas ao modelo da administração do século XX.

Se você já opera algum método ágil (SCRUM, OpenUP, XP, Entrega Ágil Disciplinada) de forma consistente em seu projeto há mais de 6 meses, talvez exista espaço para você avançar para o nível 4 de maturidade. Algumas dicas rápidas a respeito incluem:

  • estudar o pensamento e práticas lean;
  • estudar práticas de agilidade organizacional citadas nesses frameworks;
  • avaliar os casos de sucesso citados nesses frameworks e se informar como se deu a implementação;
  • promover debates entre times na sua organização que já praticam o SCRUM;
  • começar a incorporar o pensamento lean dentro das suas práticas ágeis;
  • começar a incorporar práticas lean dentro das suas práticas ágeis. Em particular, percebo da minha experiência que práticas lean ligadas à redução de desperdício tem apelo imediato nos gerentes e possuem baixa resistência para adoção.
  • escolher um framework em escala organizacional e começar a incorporar algumas de suas práticas em uma área ou produto de larga escala;
  • buscar apoio de pessoas que já possuam conhecimento mais sólido nesses frameworks.

Os resultados podem ser muito interessantes.

No próximo post, o último dessa série, iremos descrever como organizações podem atingir a excelência através desses métodos através da  mola mestra da melhoria contínua (Maturidade 5).

Pensamento do dia: “If everyone has to think outside the box, maybe it is the box that needs fixing.”, Malcolm Gladwell

Maturidade 1 em Métodos Ágeis – Reconhecimento

Muitos times e organizações desconhecem que eles não desempenham bem. Isso é muito natural e faz parte da limitação humana em compreender o efeito das suas ações no desempenho dos sistemas onde estão inseridos.

Mas o que é um sistema? Convido você a investir alguns minutos do seu tempo para assistir o vídeo abaixo, que apresenta o conceito de forma brilhante: Em Um Mundo de Sistemas (YouTube).

O desenvolvimento de software é também um sistema. E um sistema complexo, infelizmente. Os efeitos das ações tomadas nem sempre geram os efeitos desejados.

Algumas ações comuns na indústria parecem muito naturais e eficazes, tais como:

. especificar todos os requisitos antes que a primeira linha de código seja construída;

. especializar funções e otimizar a comunicação através de emails e documentos;

. testar apenas quando o código estiver pronto;

. reduzir o custo do desenvolvimento de produtos através da contratação de pessoas mais baratas;

. comandar e controlar o trabalho das pessoas;

. adicionar pessoas a um projeto atrasado para colocá-lo no trilho novamente.

Curiosamente, todas estas ações acima geram efeitos contra-intuitivos, i.e, eles tendem a gerar efeitos destrutivos no sistema. Um exemplo (levemente mais elaborado que o vídeo anterior) é mostrado por Craig Larman no diagrama abaixo.

xsystemsp20thinking-15-pagespeed-ic-wns033qpdz

Fonte: Craig Larman – Pensamento Sistêmico

Embora o desenho pareça complicado, ele mostra que existe um efeito defasado no tempo e no espaço na qualidade de um produto a partir da contratação de desenvolvedores baratos, que por sua vez gera um efeito negativo na produtividade do produto. É um exemplo de uma dinâmica negativa, tomada por uma ação que parece correta (contratar mais pessoas, mais baratas, para aumentar a produtividade do produto).

Reconhecer, pois, as armadilhas dos métodos tradicionais é o primeiro ponto para aumentar a maturidade do seu trabalho e do seu time em direção à melhoria de produtividade trazida pelos métodos ágeis. Trabalhar este reconhecimento requer que você comece a desenvolver uma habilidade de “atenção correta”, i.e., perceber conscientemente o que acontece ao seu redor.

Uma dica simples para começar a ter ciência do seu ambiente é o uso de reuniões de lições aprendidas, que deve ser executada em base semanal ou base quinzenal. Nesta reunião você convida todo o seu time e executa a seguinte dinâmica:

  1. Primeiro, o time avalia o que funcionou. Os fatos positivos devem ser capturados e escritos em um quadro branco ou cartolina. Enquanto facilitador, você deve incentivar o seu time a relatar tudo o que foi bom durante o período da avaliação.
  2.  Depois, você avalia o que não foi tão bom. Os fatos negativos também devem ser capturados, mas sem julgamentos ou acusações. Assim como os fatos positivos, os fatos negativos também devem ser escritos em um quadro branco.
  3. Finalmente, cada ação marcada na lista dos fatos negativos deve gerar uma ou mais ações de melhoria. Esta lista é fundamental e será perseguida pelo time no próximo ciclo de trabalho.

Métodos ágeis são desenhados a partir das premissas que o sistema onde um software é desenvolvido não é linear, i.e, a sua dinâmica complexa emerge a partir das interações entre seus atores. Para lidar com este tipo de ambiente, métodos ágeis estão baseados em um processo contínuo de experimentação e adaptação. Instrumentos como as reuniões diárias, reuniões periódicas de demonstraçao (revisão) e a coleta de lições aprendidas (retrospectiva) são exemplos neste sentido.

Iremos abordar os  princípios e práticas fundamentais dos métodos ágeis no nosso próximo post, onde discutiremos o segundo nível de maturidade de métodos ágeis dentro de uma escala de maturidade de adoção de métodos ágeis.

 

 

 

 

 

Aumento de Maturidade em Métodos Ágeis

Muitos times no Brasil tem experimentado o uso de princípios e práticas ágeis no seu trabalho de desenvolvimento de projetos e operação continuada. Entretanto, nem sempre os efeitos originalmente buscados em termos de eficiência de tempo e qualidade são alcançados. Para os mais céticos, isso cria uma “prova” que não funcionam na realidade única e particular de suas empresas. Se o ceticismo alcança a camada gerencial, isso pode significar a morte de iniciativas ágeis, que se tornam para sempre amaldiçoadas como apenas mais um modismo de consultores.

Pessoas que se debruçaram seriamente sobre a dinâmicas de times e projetos em empresas já perceberam que a dinâmica tradicional baseada em hierarquias rígidas, comando e controle, comunicação através de papel e aceitação de defeitos e desperdícios é ineficiente. Taiichi Ohno foi uma dessas pessoas e o resultado do seu sistema alternativo de pensamento pode ser observado no desempenho superior da Toyota através do sua filosofia Toyota Way, conhecido no ocidente como pensamento Lean há quase 50 anos. Kent Beck, Jeff Sutherland, Allistair Cockburn, Craig Larman, Mary Poppendick, entre outros, tem evidenciado há mais de 20 anos que métodos ágeis funcionam em organizações dos mais diversos tamanhos, setores e propósitos.

Para evitar que a desilução se instale e acabe com os movimentos ágeis nascentes na sua organização, é fundamental reconhecer que adotar métodos ágeis não é apenas tomar uma decisão ou comprar um livro. Adotar métodos ágeis é um processo, que demanda tempo e disciplina. Ao mesmo tempo, podemos observar a nossa maturidade ao longo do caminho, comparar com um modelo de referência, reconhecer as fragilidades e então decidir como avançar.

Modelo de Maturidade para Implantações Ágeis

Boa parte da comunidade ágil não usa modelos de maturidade, que tendem a ser prescritivos e ordernar artificialmente as ações futuras de uma TI. O CMMI é um exemplo deste tipo de modelo prescritivo. Ao mesmo tempo, nem todo modelo de maturidade precisa ser prescritivo. Ele pode ser um modelo de reconhecimento crescente da dinâmica da sua organização e uma capacidade crescente de sentir e responder aos fenômenos e incidentes que lá acontecem.

Neste contexto, apresentamos aqui um modelo de maturidade para aumentar a agilidade no seu trabalho, do seu time e até mesmo da sua empresa. O modelo apresenta os seguintes níveis.

0. Desconhecimento (Ignorância)
1. Reconhecimento da Realidade (Princípios)
2. Práticas Ágeis Nascentes em Indivíduos e Projetos
3. Práticas Ágeis Consistentes em Projetos
4. Agilidade em Escala Organizacional
5. Melhoria Contínua em Escala Organizacional

O nível 0 (Desconhecimento) é ainda dominante na maior parte das empresas. Muitas pessoas trabalham mal, geram resultados ruins, não reconhecem o seu desempenho ruim e reclamam que o problema está sempre lá fora. Frases comuns incluem:

  •  “A realidade aqui na minha empresa é diferente. Esta teoria não irá funcionar aqui.”
  •  “Eu trabalho com isso há quase 30 anos. Eu já sei muito bem o que preciso fazer”.
  •  ” Se você conhecesse o meu chefe, saberia que não posso fazer nada.”
  • ”O nosso contrato com o fornecedor nos impede de fazer isso.”
  • ”Eu já sou muito eficiente.”
  • ”O meu time somente funciona na base da pressão.”

O nível 1 (Reconhecimento) acontece quando pessoas começam a reconhecer que existe algo errado. É como alguém com sobrepeso extremo começar a ter ciência que o seu estilo de vida irá matá-lo em poucos anos. Em métodos ágeis, o reconhecimento se dá através da descontrução das crenças limitantes e percepção que:

  • pessoas e interações entre pessoas é o fator crítico de sucesso em projetos;
  • responder a mudanças é vital para lidar com o ambiente dinâmico de projetos e organizações;
  • buscar colaboração com os clientes e resultados ganha-ganha é mais eficiente que regulações e contratos rígidos;
  • entregar produtos em funcionamento em ciclos curtos é um aspecto vital no estabelecimento de confiança com seus clientes internos e externos;

O nível 2 (Práticas Nascentes) acontece quando alguém começa a realizar um experiento em base pessoal ou no seu time. Por exemplo, um desenvolvedor de software começa a fazer “Código Limpo”, que é uma abordagem estruturada para codificar com manutenibilidade, estensibilidade, segurança e reduzidos defeitos. Um outro exemplo é um arquiteto que implanta a prática de “Arquiteturas Evolutivas” no seu trabalho de infraestrutura. Um terceiro exemplo são times que introduzem o conceito de sprints, que são intervalos de tempo fixos usados para construir e demonstrar incrementos de produtos para os seus clientes internos e donos de produto. No nosso exemplo da pessoa com sobrepeso extremo, ela começa a agir e deixa de comer o seu terceiro ou quarto pedaço de pizza antes de dormir. Para avançar para o nível 2, é importante investir em leituras contínuas e um processo enxuto de experimentação (hipótese plausível, experimento curto, análise de resultados e relato das lições aprendidas).

Quando uma organização avança para o nível 3 (Práticas Consistentes), a cultura instalada na organização já reconheceu e aceitou que as novas práticas são melhores e que devem ser mantidas em novos projetos. É como um indivíduo que fumou durante 30 anos, reaprendeu a viver sem nicotina no seu organismo e que agora consegue subir 3 lances de escada sem ficar ofegante. Ele não aceita retornar para o nível de mediocridade que vivia e almeja agora subir 4 ou 5 lances de escada para alcançar o seu escritório e tornar irrelevante o elevador. Em organizações, observamos que este fenômenos em times com alta produtividade, que estabeleceram o seu conjunto de práticas vencedoras e são muito mais produtivos que times similares na mesma organização.

O nível 4 (Agilidade em Escala Organizacional) acontece quando a alta direção incorpora os modelos ágeis como cultura dominante na organização. Este novo organimo agora opera de forma com modelos gerenciais descentralizados com o uso de práticas como por exemplo a Holocracia. A Zappos, que faturou 2 bilhões de dólares em 2014, é um exemplo deste tipo de organização e foi citada em um Revista Forbes – Caso Zappos de 2015 pela revista Forbes. Frederic Laloux, no seu livro – Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness – descreve este tipo de maturidade organizacional como Green Companies, em oposição a empresas Red Companies, que representam o clássico modelo “Comando e Controle”.

O nível 5 (Melhoria Contínua) acontece quando uma organização opera em melhoria contínua, com uma cultura contínua de aprendizado. A prática de cada trabalhador se torna o lema Kaizen do Toyota Way“O meu trabalho é fazer o meu trabalho e melhorar continuamente o meu trabalho”. Aqui as pessoas operam com excelência, que foi trazida por anos da prática da observação, orientação, decisão e análises consistentes.

Observe que este modelo de maturidade não diz quais são as práticas que devem ser adotadas, nem a sua ordem implantação. Mas ele indica que o nível de consciência organizacional e o grau de espalhamento das práticas é que determina maturidade. Iremos abordar estes níveis em detalhes nos próximos artigos e lhe explicar como iniciar essa jornada em nível pessoal e promover esta melhoria para o seu trabalho, os seus times e a sua empresa.

Nível 1 – Reconhecimento (publicado em 08/12/15).

Nível 2 – Práticas Nascentes (publicado em 18/12/15).

Nível 3 – Práticas Consistentes (publicado em 04/01/16).

Nível 4 – Agilidade em Escala Organizacional. (publicado em 14/01/16)

Nível 5 – Em busca da Anti-Fragilidade (publicado em 07/03/16)

Além do SCRUM – Kit Ágil para Agilistas

O Scrum, método ainda pensando em 1986 no seminal artigo The New New Product Development Game, ganhou muito popularidade no Brasil nos últimos anos e disseminou alguns valores e princípios ágeis entre times de projetos em tecnologia da informação. O universo de métodos ágeis, entretanto, é muito mais vasto que as práticas apresentadas pelo Scrum. Compilo neste artigo algumas referências importantes para agilistas que queiram avançar nas práticas e valores de métodos ágeis.

  1. Livro Peopleware, de Tom de Marco. Um clássico escrito nos anos 70 e reeditado em 2013 que apresenta princípios e práticas da liderança efetiva de pessoas em TI e organização de times.
  2. O blog de Allistair Cockburn, que nos apresenta um grande número de informações de primeira linha sobre métodos ágeis e a sua excelente (mas pouco conhecida) metodologia Crystal. Recomendo, sobre este método, o excelente livro Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams.
  3. A página do método Entrega Ágil Disciplinada, do famoso agilista Scott Ambler, que apresenta um conjunto de práticas que estendem o Scrum para situações complexas de projetos de TI e realidades culturais diversas.
  4. Manufatura enxuta para desenvolvimento de software, que fornece poderosos princípios para redução do tempo de ciclo na entrega de software e redução de desperdícios. Um artigo introdutório ao tema é apresentado aqui e alguns excelentes livros sobre o tema foram escritos pelo casal Poppendick – Agile Toolkit,  Implementing the Lean Software Development e Leading Lean Software Development.
  5. Os artigos do Uncle Bob (Robert Martin), muito sensatos, e os seus clássicos livros Clean Code e Clean Coder.
  6. O trabalho de extensão de métodos ágeis para o nível organizacional descrito no excelente trabalho do método ágil corporativo Scale Agile Framework.