Jornada nas Estrelas foi uma série fora do seu tempo. Lançada no meio dos anos 60, essa série discutia guerra e paz, lealdade, autoritarismo, imperialismo, economia, racismo, existencialismo, metafísica, religião, direitos humanos, sexismo, feminismo e o papel da tecnologia. E tudo isso contado de forma leve e épica dentro do propósito da frota estelar de “audaciosamente ir onde nenhum homem jamais esteve”.
Esse série apresentava dois icônicos personagens, o capitão da nave James Tiberius Kirk e seu oficial Spock (o segundo em comando).
Kirk é passional, emotivo, intuitivo e com uma incrível facilidade para improvisar. Já Spock, filho de mãe terráquea e pai Vulcano, é racional, analítico, dedutivo e busca sempre ponderar e analisar todas as possibilidades antes de tomar as suas decisões.
Na série, eles tem diálogos que mostram suas naturezas distintas tais como:
– “Algumas coisas são impossíveis até o momento onde elas não são mais”, James. T. Kirk
– “Isso é altamente ilógico”, Spock
Para alguns fãs de ficção científica, Star Trek foi maior e mais importante que Star Wars. Mas não vamos iniciar uma guerra interplanetária aqui.
O Cérebro Humano – Spock e Kirk Juntos
Durante séculos, filósofos, psicólogos e cientistas distinguiram entre raciocínio intuitivo e o consciente. Platão, por exemplo, já falava em seu livro Psyche entre o nosso cérebro consciente (Logos), do nosso cérebro emocional – aquele dos desejos e apetite (Eros) e do afeto (Thymos).
Mais recentemente, Daniel Kahneman criou os termos sistema 1 e sistema 2 em livro “Rápido e Devagar”, que popularizou a distinção entre processos de pensamento automáticos e deliberados. O modelo de Kahneman divide os processos da mente em dois sistemas distintos:
O sistema 1 “é a abordagem rápida, automática e intuitiva do cérebro”, que apelido aqui de modo Capitão Kirk. A atividade do sistema 1 inclui as atividades mentais inatas com as quais nascemos, como uma preparação para perceber o mundo ao nosso redor, reconhecer objetos, orientar a atenção, evitar perdas. Outras atividades mentais tornam-se rápidas e automáticas através da prática prolongada.
O sistema 2 é “o modo analítico mais lento da mente, onde a razão domina”, que chamo aqui de modo Spock. Geralmente, a atividade do sistema 2 é ativada quando fazemos algo que não ocorre naturalmente e requer algum tipo de esforço mental consciente.
Daniel Kahneman fornece um exemplo comum usado para demonstrar os dois sistemas. Um taco e uma bola juntos custam US$ 1,10. O taco custa US $ 1 a mais que a bola. Quanto custa a bola? Diante desse quebra-cabeça, a maioria das pessoas adivinha instantaneamente 10 centavos. A resposta correta, no entanto, é de 5 centavos – o que, novamente, a maioria das pessoas pode resolver depois de passar mais tempo pensando sobre a questão.
Minimizando a resistência a mudanças
Quando buscamos implantar métodos ágeis, temos que ter atenção extrema às respostas dos outros. Peter Senge, exímio pensador sistêmico, já falava:
“As pessoas não resistem às mudanças. As pessoas resistem a serem mudadas”.
Ao reconhecer uma mudança, as pessoas podem trazer objeções no modo Kirk (Sistema Tipo 1 em ação) ou no modo Spock (Sistema Tipo 2 em ação).
O primeiro modo são receios emocionais tais como:
Dignidade
Respeito
Status
Identidade
Desejos
Confiança
Orgulho
O segundo modo está ligado a receios de natureza intelectual e aspectos que desafiam o seu modo de pensar. Busque reconhecer as objeções as mudanças quando você se depara como uma resistência.
David Anderson, líder da comunidade Kanban, nos apresenta as duas regras de ouro para lidar com objeções.
Nunca combata uma objeção racional com um argumento emocional.
Nunca combata uma objeção emocional com um argumento racional.
Trabalhar a primeira regra é menos complexo. Se você enfrenta objeções racionais, você pode desenvolver argumentos, trazer fatos e dados para criar um debate. O Spock que habita o cérebro racional da pessoa eventualmente fará as conexões.
A notícia ruim é que na grande maioria das vezes as objeções são emocionais. E enfrentar o capitão James T. Kirk não é tarefa simples. Se você enfrenta uma objeção emocional, você precisa trazer uma emoção ainda mais forte para lidar com a resistência. Emoções mais fortes podem ser aquelas que irão gerar neurotransmissores positivos como dopamina, oxitocina, serotonina e endorfinas ou mecanismos de urgência gerados por descargas de adrenalina e cortisol.
Cito aqui um caso extremo onde pude observar que um gerente de projeto que não aceitou uma mudança de papel para um novo papel de Scrum Master. Se uma mudança de papel afeta a dignidade ou identidade de um funcionário e ele resiste, uma ação que gera uma emoção mais forte (embora negativa) seria uma ameaça de demissão. E foi isso que o diretor fez. Ele ameaçou o gerente de projeto e disse que a mudança era mandatória. O medo de não ter comida ou casa é mais forte (gera adrenalina e cortisol) e sobrepuja o receio da sua mudança de identidade.
Não queremos, óbvio, fazer a mudança pelo medo. Até porque agile coaches não são, normalmente, ou donos das organizações. E mudanças baseadas em medos podem gerar efeitos colaterais muito ruins. Encontrar uma emoção mais forte pode ser difícil e demorado nesses casos, mas é o caminho para combater objeções emocionais. O método Kanban, por exemplo, não busca trabalhar reorganizações ou mudanças de papel na sua introdução pois esses tipos de mudanças estão mais suscetíveis a mudanças que ativem caminhos límbicos de pavor, medo ou perda da identidade.
Um exemplo positivo que pude observar em um time estava ligado a troca do trabalho empurrado para trabalho puxado em um time ágil. Havia uma cultura Scrum de assumir um lote de funcionalidades de uma única vez em uma reunião longa e demorada de Planejamento de Sprint. No final da reunião as funcionalidades já eram atribuídas aos desenvolvedores dessa organização. A gerente percebeu que esse modelo levava a falhas contínuas de entrega. As promessas eram continuamente quebradas. E isso minava a confiança dos diretores e clientes nesse time. Inicialmente a gerente tentou introduzir a mudança para um sistema puxado onde as demandas seriam trazidas uma por vez apenas quando houve capacidade disponível do time. Ao tentar propor a mudança, o time resistiu. Havia uma identidade muito forte ligada a papéis e práticas do Scrum.
Ela então buscou uma abordagem alternativa baseada em princípios Kanban. Primeiro, ela não atacou a identidade do time. Ela teve paciência. Durante algumas semanas ela melhorou a gestão à vista mostrando o trabalho em andamento, impedimentos e bloqueios. Ela também construiu métricas de fluxo como histogramas de tempo de ciclo e fluxos cumulativos de valor. Isso permitiu que as retrospectivas mudassem de momentos de pura lamentação para conversas mais ricas. A gerente também teve cuidado de apontar os problemas sobre o trabalho e não sobre os trabalhadores. A partir de conversas mais ricas e um ambiente seguro para falhar, o time desenvolveu uma base emocional mais sólida para lidar com os problemas de previsibilidade. Depois de poucos meses o time estava emocionalmente preparado para fazer a mudança de um trabalho empurrado para um trabalho puxado. E com o suporte de histogramas de tempo de ciclo o time agora era capaz de trabalhar previsibilidade sobre demandas novas para o seu sistema de trabalho.
Definitivamente, um caminho longo e duro. Mas é necessário quando um agente de mudança enfrenta objeções emocionais no seu caminho e queira criar mudanças consistentes e perenes.
A mensagem aqui é que criar uma cultura de agilidade de negócio é complexo. Não existem receitas de bolo. Ao mesmo tempo, existe hoje uma ampla base sociológica e de práticas de gestão para orientar agentes de mudanças ou agile coaches.
Dando sequência ao tema de disfunções ágeis, relato aqui mais disfunções ágeis que podem drenar todo o dinheiro da sua iniciativa ágil como um chupa-cabra de métodos ágeis. Mais à frente, apresentamos antídotos para esses problemas.
Mais 5 disfunções ágeis
Critério de preparado (Ready) ausente ou mal especificado
Um problema comum em vários times que operam Scrum é não estabelecer um acordo claro para aceitar um requisito e iniciar a sua construção. Isso se manifesta com reuniões de planejamento longas e cansativas e, pior, problemas de entendimento que acompanham a sprint e um número excessivo de defeitos de negócio em ambientes de produção.
2. Critério de aceite (Acceptance) ausente ou mal especificado
É também comum quando POs novatos ou que estendem a confiança ingenuamente não definem os critérios de aceite funcionais e não-funcionais externos, como por exemplo a usabilidade, performance ou segurança.
“O óbvio é individual”, já disse um sábio certa feita. Assumir que o time de engenharia de produtos irá incorporar aspectos de qualidade porque aquilo é óbvio é uma decisão ingênua.
3. Critérios internos de qualidade ausentes
Quando desenvolvedores e QAs olham apenas para os requisitos funcionais, uma dívida técnica será naturalmente introduzida dentro do sistema. A razão é a entropia crescente nesses sistemas complexos. Exemplos incluem:
Ausência de automação de testes
Códigos-fonte sujos (mal-cheiros)
Arquiteturas de software erodidas
SQLs ineficientes
Problemas de segurança
Se um time não age proativamente e introduz políticas para pagamento permanente da dívida técnica, os sistemas irão apenas degradar ao longo do tempo e eventualmente gerarem problemas gravíssimos para suas áreas de negócio.
4. Ausência de folgas (Slack) e previsibilidade inconsistente
Tom de Marco escreveu um livro muito instigante em 2001 (Slack) mostrando a estupidez da hiper-otimização dos trabalhadores do conhecimento e os seus efeitos ruins para as pessoas e também para a própria organização em médio e longo prazo.
Nicholas Taleb também nos adverte, de forma ainda mais contundente no seu livro Antifragilidade – Coisas que se beneficiam do caos, da fragilidade inerente de organismos hiper-otimizados. A natureza e os sistemas complexos amam redundâncias.
Donald Reinertsen, outro grande pensador, nos mostra também que sistemas de trabalho ocupados afetam brutalmente e negativamente a previsibilidade de entrega de novas funcionalidades.
Assumir que alguém trabalha exatamente 7 ou 8 horas por dia e tentar alocar o esforço de pessoas como se fossem máquinas é ruim economicamente para a organização, psicologicamente para as pessoas e também para a previsibilidade de entregas.
Em linguagem simples, você observa essa disfunção através de sprints “que falham”, i.e, não entregaram todo o “escopo” porque as pessoas não “trabalharam” de forma eficiente. Ou titica de galinha sobre esterco de vaca.
5 – Heroísmo. Ou síndrome de Tanus.
Outra disfunção comum é esperar que pessoas e times ágeis irão ter comportamentos heróicos e irão fazer o que for necessário para bater as “metas” definidas pela gerência.
O heroísmo na construção de produtos digitais é um fenômeno estudado há décadas. E a “má notícia” é que não existem heróis. Você não está em um filme de espionagem onde hackers com “intelecto avançado” teclam um monte de comandos mágicos e o sistema começa a operar. E até nos filmes mais recentes, basta alguém estalar os dedos e metade dos heróis vai embora.
Modelos de maturidade mais modernos, como por exemplo o excelente Kanban Maturity Model, mostram que o heroísmo é um sintoma de serviços de baixa maturidade (ML1). Não é algo sustentável em médio e longo prazo e impede a criação de serviços previsíveis e aptos para o propósito de negócio.
Mais Antídotos
1. Gestão do Upstream (para o critério de Preparado mal especificado)
A gestão de upstream é uma técnica descrita no KMM (Kanban Maturity Model) e assunto central do livro Essential Upstream Kanban.
Entre o Upstream (território do PO) e o Downstream (território da engenharia e Scrum Masters) existe o ponto de compromisso que precisa ser bem estabelecido através de políticas explícitas, prática geral de todo sistema Kanban maduro.
2. Compromisso em duas fases (Two Phase Commit)
Sistemas de trabalho bem estruturados devem ter não apenas o ponto de compromisso bem estabelecido para iniciar o trabalho. Devem ter também o ponto de compromisso onde o trabalho seja aceito. E para isso precisamos ter políticas explícitas indicam como o trabalho deve ser entregue para ser considerado como finalizado.
Se você quer que o seu copo de água seja servido em copo de vidro, com duas pedrinhas de gelo e uma rodela de limão siciliano, explicite isso no começo do jogo. O combinado não é caro.
O Two Phase Commit é uma técnica Kanban que reduz, semana após semana, a ambiguidade para iniciar e fechar um trabalho do conhecimento. Ela permite que você crie critérios de preparado e de aceite incrementais e que funcionem na sua realidade objetiva.
3. Critérios internos de qualidade
Ninguém em sã consciência pede para um cozinheiro não lavar as verduras para apressar o preparo dos pratos. E provavelmente cozinheiros profissionais não aceitariam essa proposta estranha. Lavar as verduras é dever ético e de higiene em uma cozinha profissional.
Da mesma forma, nenhum desenvolvedor deveria negociar aspectos básicos da higiene do seu código no dia a dia. Refatorar e fazer testes de unidade devem ser parte integrante e diária do trabalho. Como tomar banho e escovar os dentes. E não um trabalho adicional que deveria ter permissão gerencial.
Lógico. Falar isso é fácil. E reconheço que isso é ainda muito difícil em ambientes abusivos onde metas de prazo são impostas de cima para baixo e não descobertas pela vazão do time.
Mas é dever ético de qualidade de um time expor e brigar por seus critérios internos de qualidade. Git Pull Requests, Pair Programming, Mob Programming, Testes de Unidade, Refatoração, entre outras práticas, são exemplos nesse sentido.
E se você quiser se armar com argumentos sólidos para conversar com a sua chefia, recomendo dois clássicos a respeito do sempre incansável Uncle Bob, um dos signatários do Manifesto Ágil de 2001.
4. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de previsibilidade)
Times sem políticas de limitação do trabalho e outras políticas explícitas são facilmente abusados no seu dia a dia. Um dos papéis de um sistema de trabalho é conhecer e estabelecer a capacidade de trabalho apropriada para um time em um contexto real de forma a:
Reduzir os prazos de entrega
Reduzir a variabilidade.
Fato curioso é que o tempo médio de entrega é inversamente proporcional ao volume de trabalho em progresso, como já nos mostrou John Little ainda nos anos 60 na sua Lei de Little.
Quando você introduz sistemas Kanban sobre times que estão operando o framework Scrum, você ganha consciência da utilização de trabalho mais apropriada para aquele time e evita problemas de sobrecarga que se manifestam como engarrafamentos (muita coisa para fazer, muito estresse, pouca vazão e resultados pífios).
5. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de heroísmo)
O heroísmo é sintoma de um sistema de trabalho frágil, i.e., onde as metas são impostas de cima para baixo sem conhecer a vazão possível e ideal dos times. É um sintoma de um sistema desequilibrado, onde medições não são realizadas consistentemente, onde políticas corretas estão ausentes e sistemas de feedback não estão instalados.
Novamente, o mesmo antídoto aplicado no item 4 pode ser usado para identificar as causas raízes que levam aos atos de heroísmo, introduzir hipóteses de melhoria e com base no pensamento científico testar e manter as hipóteses que melhorem o sistema de trabalho. Através de um processo contínuo de melhorias através da abordagem de mudanças evolucionárias, criamos um sistema robusto de trabalho em médio e longo prazo.
A mensagem desse post é simples. Faça uso do sistema de gestão de mudanças Kanban para melhorar o seu trabalho como Scrum Master.
Se você é um gestor ou líder de time e tem mais de 30 anos, provavelmente você foi educado em métodos de gerenciamento modernos. Esses métodos são baseados em conceitos chave como progresso, eficiência e modernização.
Algumas consequências desses pressupostos mentais podem ser sintetizadas nas dimensões abaixo:
Visão de sistemas: Os fenômenos são complicados, i.e., possuem muitas partes interconectados mas a relação entre elas é conhecida e pode ser descrita a priori.
Planejamento: O planejamento é possível e pode ser realizado por ferramentas como cronogramas e redes que avaliam interdependências.
As relações possuem causa e efeito óbvias e instrumentos clássicos de gestão de risco são de grande auxílio para prever e evitar riscos.
Os prazos podem ser determinados por estimativas.
As pessoas precisam ser monitoradas para que a sua eficiência possa aumentar. A ociosidade no trabalho é danosa e buscamos portanto eficiência de recursos.
Relações de trabalho: São estáveis e baseadas na CLT.
Os processos são prescritivos, i.e, temos receitas claras do que fazer em termos de atividades, passos, etapas e papéis envolvidos.
O avanço ocorre fundamentalmente através das melhores práticas da indústria.
As mudanças são tipicamente revolucionárias, i.e., conduzidas através de iniciativas de grande porte conhecidas como projetos.
Empresas são organizadas em equipes com especialistas funcionais.
Os sistemas de informação de TI são monolíticos e feitos para durar, resultados de grandes projetos.
Aquisição de informações: Entrevistas um-para-um e documentação abrangente.
Profissões de gestão: Gerentes de projetos, gerente de qualidade, superintendentes.
Pare por um momento. Lembre como corpos de conhecimento como ISO, COSO, COBIT, CMMI, RUP, ITIL, PMBOK são organizados. A própria profissão e identidade do gerentes de projetos foi moldada por esses mecanismos.
De repente, 2020
O espírito do nosso tempo, aquela palavra legal do alemão chamada zeitgeist, não é mais do progresso, eficiência e modernização absolutos. Avançamos do moderno para o pós-moderno e do pós-moderno para o pós-normal.
Se o progresso, eficiência e modernização eram os lemas do mundo moderno, no mundo pós-moderno temos a relativização, pluralidade de conceitos e a individualidade com conceitos dominantes. E no mundo pós-normal temos a complexidade, caos e contradição como conceitos dominantes.
Complexidade
Sistemas complexos tem incertezas substanciais que não podem ser gerenciadas como ‘riscos’. Eeles tem uma multiplicidade de perspectivas legítimas.
Um sistema complexo em rede está cheio de incertezas, múltiplas perspectivas e propenso a comportamentos turbulentos que às vezes podem resultar em caos.
O clima, epidemias como o COVID-19, organismos biológicos, ecossistemas, organizações sociais, culturas humanas, a linguagem, o cérebro, serviços de saúde e até mesmos sistemas de informação de TI são exemplos de sistemas complexos.
Caos
O caos não significa aleatoriedade. O caos é o resultado de muitas variáveis independentes interagindo de várias maneiras diferentes em um sistema complexo em rede. Pequenas perturbações no sistema podem levar a consequências imprevisíveis e que somente podem ser estuados a posteriori.
Por exemplo, alguém pode comer um morcego em uma cidade na China e o seu emprego é ameaçado porque você e sua empresa estão em distanciamento social forçado. Isso é o chamado “Efeito Borboleta”.
Contradição
Um sistema complexo tem muitas posições que são logicamente inconsistentes. Sistemas complexos à beira do caos ainda mais. As contradições não podem ser resolvidas. Elas só podem ser integradas e transcendidas. Em outras palavras, as contradições precisam ser sintetizadas e requerem a formulação de uma nova posição que incorpore a maioria das várias posições diferentes.
A contradição geralmente fornece os primeiros sinais de que um sistema está se movendo em direção à complexidade, caos e, eventualmente, para a pós-normalidade.
A gestão no tempo pós-normal
Em áreas onde o trabalho do conhecimento é dominante, não vemos mais ofertas abundantes de vagas para “Gerente de Projeto” ou “Gerentes de Qualidade”. Observo várias pessoas da minha rede, especialmente acima de 40 anos, perplexas e indignadas com esse movimento.
E, pior, aqueles que são demitidos de suas empresas simplesmente não conseguem se reposicionar. Ou precisam se reposicionar vários meses depois por salários menores do que tinham anos atrás. Algo mudou nas profissões do trabalhador do conhecimento.
As coisas nos tempos pós-normal não podem ser “gerenciadas” no sentido clássico da palavra. Elas precisam ser, ao invés, navegadas.
Para entender isso, vamos observar as consequências dos pressupostos da pós-normalidade podem ser sintetizados nas dimensões abaixo:
Visão de sistemas: Os fenômenos são complexos, i.e., possuem muitas partes interconectados e a relação entre elas não é conhecida a priori. Ela somente pode ser descrita em retrospectiva.
Planejamento: O planejamento não é possível e agora precisa ser acomodado por instrumentos dinâmicos que absorvem fluxos variáveis e contínuos como por exemplo um Sistema Kanban.
As relaçõesnão possuemcausa e efeitoóbvias. O uso de narrativas é fundamental para entender como atuar em cenários de imprevisibilidade
Os prazos não são determinados por estimativas. #NoEstimates é o novo pós-normal. Ao invés, trabalhamos com previsibilidade (Forecasting).
As pessoas não devem ser gerenciadas. Ao invés, devemos gerenciar o sistema de trabalho e permitir que as pessoas se auto-organizem. Ao invés de eficiência de recursos humanos, buscamos eficiência de fluxo.
Os processos não são prescritivos, eles são descritivos. O contexto é chave para saber o que fazer.
O avanço ocorre fundamentalmente através de práticas contextuais e de aprendizados por retrospecto através de narrativas.
As mudanças são evolucionárias, i.e., devem reduzir a resistência a mudança e incorporar visões contraditórias para permitir a criação de antifragilidade. A noção de grandes transformações e projetos está morrendo.
Empresas são organizadas em equipes com generalistas especialistas. Os papéis são fluidos e não mais fixos.
Os sistemas de informação de TI são baseados em serviços ou microsserviços, resultados de entregas de fluxo contínuo. Eles são desenhados para mudar.
Aquisição de Informações: Oficinas, Open Spaces, Aprendizado 3.0, Design Thinking e espaços que permitam que a contradição surja e possa ser integrada.
Relações de Trabalho: Dinâmicas, baseadas em empreendimentos, contratos e resultados ganha ganha.
Profissões de gestão: Empreendedores, Líderes, Mentores, Agentes de mudança e Agile Masters. As profissões clássicas da gestão estão morrendo e as pessoas que se agarrarem a elas podem talvez sejam varridas do mercado de trabalho.
Corpos de conhecimento como o Management 3.0, desenhado para gestão em ambientes complexos, e o Método Kanban, desenhado para gestão de mudanças evolucionárias, estão mais bem preparados para lidar com os tempos pós-normais.
Para o trabalhador do conhecimento e da inovação, é o momento de reflexão e questionar os seus pressupostos. O caminho que nos trouxe até aqui pode ser não ser o caminho que nos levará para o futuro.
Como já dizia Alvin Toffler ainda no século passado.
Os analfabetos do próximo século não são aqueles que não sabem ler ou escrever; mas aqueles que se recusam a aprender, esquecer, reaprender e voltar a aprender.
Muitas organizações estão tentando implementar métodos ágeis e buscado aplicar práticas Scrum, Kanban, Squads e Lean no seu dia a dia de projetos e operações de TI. Entretanto, várias organizações tem falhado semana após semana nessas tentativas. Apesar das reuniões diárias, papéis estruturados como o PO e SM, pessoas trabalhando em contato físico permanente e ambientes modernos para atender as insatisfações das gerações Y e Z, vários gestores não tem observador melhoria efetiva nos resultados de negócio.
Se você está vivendo essa realidade, você pode estar contaminado por um terrível vírus que transformou o seu processo em uma coisa chamada Agile Zombie.
Agile Zombie
São sintomas comuns do Agile Zombie:
Não existe coração pulsante
Times Agile Zombie repetem ritos, mas não existe entrega frequente de software em produção. Em equipes ágeis saudáveis, entendemos que ter um fluxo contínuo de software entregue não é apenas uma boa ideia, mas um objetivo fundamental do método. O Agile Zombie aborda isso de forma diferente. Para eles, é sempre muito complicado fazer entregas intermediárias e sempre existem respostas prontas para dizer porque isso não é possível.
2. Sem resposta emocional a fracassos e sucessos
Como um corpo sem vida, as equipes do Agile Zombie não mostram resposta a um Sprint fracassado ou bem-sucedido. Onde outras equipes amaldiçoam ou se alegram, elas simplesmente mantêm seu olhar vazio. O moral da equipe é muito baixo. Itens do Sprint Backlog são transferidos para o próximo Sprint sem questionamentos. Porque não? Há sempre um próximo Sprint e as iterações são artificiais de qualquer maneira.
3. Sem força de vontade para melhorar
No Agile Zombie não há alegria e certamente não há necessidade de melhorias. E ninguém parece se importar. O Product Owner não está normalmente presente durante a Revisão da Sprint ou o Planejamento da Sprint. As equipes são altamente instáveis, pois os membros são continuamente emprestados a outras equipes que precisam de suas habilidades (especializadas). Os desenvolvedores possuem desculpas prontas sobre o porque eles não tem tempo para fazer testes de unidade e os testadores também tem desculpas prontas sobre porque eles insistem em usar documentos Word para organizar casos de testes. Alguns dos gargalos podem ser reais, enquanto outros podem ser imaginados. E isso facilmente se traduz em retrospectivas chatas com muitas reclamações. E certamente nenhum desejo de melhorar. Os sentimentos de sarcasmo, cinismo e desânimo são muito comuns.
Afinal, de quem é a culpa? Preciso trocar o meu time ou aquele mala que trabalha comigo?
Times ágeis são estruturas complexas, i.e., o seu poder vem das interações entre as pessoas que as formam e das interações entre essas pessoas com o ambiente, estruturas e crenças culturais. E isso implica que usemos instrumentos apropriados para compreender como eles realmente funcionam. O pensamento sistêmico nos ensina que na vasta maioria dos casos o problema não está nas pessoas, mas em elementos mais profundos e normalmente não óbvios.
E se você vive o Agile Zombie na sua organização, vamos conhecer um poderoso antivírus para esse sintoma, que é uma ferramenta do pensamento sistêmico chamado de Modelo Iceberg.
Modelo Iceberg
Eventos
Um software com incidentes críticos em produção ou uma pessoa que reclama muito são exemplo de eventos dentro do modelo Iceberg
Acima da linha de água estão os eventos. Os eventos são marcadores no tempo em que várias variáveis são observadas. Elas são o “o que aconteceu” ou “o que vimos”. Ao aplicarmos o Modelo Iceberg às questões globais, poderíamos dizer que na ponta, acima da água, há eventos ou coisas que vemos ou ouvimos acontecendo no mundo todos os dias. Os eventos que ouvimos dos nossos clientes, gerentes e colegas representam a ponta do iceberg. A maior parte dos gerentes gasta seu tempo no nível do eventos, tentando resolver problemas não triviais como produtividade e motivação de times. E isso quase nunca funciona.
Padrões de comportamento
Padrões são as mudanças nas variáveis que ocorrem ao longo do tempo. São as tendências que percebemos ao longo do tempo. Por exemplo, podemos observar um fluxo cumulativo de valor ao longo de três meses e perceber que a taxa de entrega está reduzindo. Os padrões são importantes para identificar porque indicam que um evento não é um incidente isolado. Os padrões respondem às seguintes perguntas O que está acontecendo e o que está mudando?
Quando fazemos uma declaração como “parece que estamos reduzindo o tempo gasto para implantar software em produção”, esses são padrões que estamos observando, uma série de relações entre eventos observados na linha do tempo. Quando chegamos ao nível do padrão, podemos antecipar, planejar e prever. Ele nos permite adaptar aos problemas para que possamos reagir de forma mais eficaz a eles.
Estrutura do sistema
A estrutura suporta, cria e influencia os padrões que vemos nos eventos. Estruturas podem ser entendidas como as “regras do jogo”. Elas podem ser escritas ou não escritas; eles podem ser físicas e visíveis ou invisíveis. São regras, normas, políticas, diretrizes, estruturas de poder, distribuição de recursos ou formas informais de trabalho institucionalizadas tacitamente ou explicitamente. Eles respondem a pergunta: o que pode explicar esses padrões?
Pode não ser fácil ver a estrutura, mas os padrões que podemos ver nos dizem que a estrutura deve estar lá. Estruturas são compostas de relações de causa e efeito. Estas são conexões entre padrões. Por exemplo, um desenvolvedor pode dizer: “Se eu aumentar o número de testes de unidade automatizados, terei menos problemas em produção”. Ela está dizendo que há uma conexão entre um número crescente de casos de testes – um padrão – e uma quantidade decrescente de defeitos – outro padrão.
Se você observar a causa raiz de alguns padrões, poderá começar a entender e abordar soluções sustentáveis de longo prazo, como por exemplo políticas robustas de testes de regressão ou mecanismos que apoiem que pessoas se motivem.
Modelos mentais
O modelo mental usado para perceber o mundo e é o que gera as estruturas, padrões e eventos
Abaixo das estruturas estão os modelos mentais. Estes definem o pensamento que cria as estruturas que então se manifestam nos padrões dos eventos. Os modelos mentais são suposições e crenças profundamente arraigadas que, em última análise, impulsionam o comportamento de todo o time. E não existem apenas um padrão, estrutura ou modelo mental em jogo; podem haver muitos.
Os modelos mentais são as atitudes, crenças, moralidades, expectativas, valores ou cultura que permitem que as estruturas continuem funcionando como estão. Essas são as crenças que muitas vezes aprendemos subconscientemente em nossa sociedade ou família e também nas empresas e times de desenvolvimento e sustentação de software. Os modelos mentais são, em última análise, o que mantém a estrutura fazendo o que faz. São os pensamentos e processos de raciocínio que precisam existir para fazer com que a estrutura seja como é. Essas ideias existem nas mentes das partes interessadas da estrutura, das pessoas que montam a estrutura ou daquelas que desempenham um papel na maneira como ela opera. Modelos mentais são tipicamente difíceis de identificar, pois geram muitas suposições que nunca são explicitadas.
Ao mesmo tempo, se você trabalhar e for bem sucedido em trabalhar os modelos mentais dos gerentes e dirigentes de uma organização, você irá permitir que todo um novo conjunto de estruturas, padrões e eventos possam ocorrer.
Exemplos de Uso do Modelo Iceberg
Cliente “Mal Educado”
Ao invés de reclamar que o seu cliente é mal educado, pare e pense por um momento no sistema onde ele trabalha e na pressão que ele recebe em base diária dos chefes e clientes deles. Observe também os sistemas pessoas dessa pessoa, como condições de vida, família e outros fatores.Ao fazer isso você poderá ter uma compreensão mais profunda sobre os comportamentos observados, que são apenas os efeitos (e não as causas).
Aquele seu colega lambão que entrega muito defeito
Ao invés de reclamar que o seu colega entrega muitos defeitos, busque compreender o sistema de incentivos onde ele trabalha. Por exemplo, se ele é incentivado para entregar no prazo para receber bonificações financeiras, é perfeitamente esperados que ele entregue código com muita rapidez .. e com defeitos de brinde. Ou você pode se questionar se ele foi treinado em práticas de código limpo ou até mesmo se ele aprendeu na prática como fazer código limpo com um mentor em algum projeto.
Um Caso Real
Vamos omitir o nome da empresa, para sermos educados. E nessa empresa existe uma tribo com várias Squads que estão lutando com todas as suas forças para implementar práticas de Squads e acelerar a implantação do Scrum e Kanban.
E, apesar das tentativas repetidas de uma pessoa bastante competente, os resultados são ruins. A taxa de defeitos é muito alta e o moral do time é muito baixo.
Conduzi nessa organização uma análise com o modelo Iceberg e chegamos a alguns resultados interessantes, resumidos abaixo.
Eventos
Pessoas reclamam e demonstram atitudes cínicas.
Sprints falham.
Produtos lançados em produção tem um índice alto de defeitos.
Clientes reclamam e alguns deles o fazem com muita agressividade.
O gerente interrompe os analistas que ousam gerar reclamações, no meio de suas falas.
A gerência discute com o time de arquitetura como o produto deve ser desenhado e implementado.
Padrões
O moral do time está reduzido, devido a contaminação do ambiente pelas críticas ao longo do tempo.
O produto está atrasado e a taxa de chegada de novos requisitos é maior que a taxa de saída.
Estruturas
As áreas de negócio não se envolvem e não tem “tempo” para interagir com os times
A gerência sênior delega todo o problema para o gerente de projeto, que atua colocando ainda mais pressão no time.
A gerência sênior bonifica o time pelo cumprimento de datas, a qualquer custo.
A gerência apartou o time de testes do time de desenvolvimento. Eles se comunicam primordialmente com emails e documentos Word.
Modelos Mentais
A gerência acredita no micro-gerenciamento, especificando o que fazer e impedindo que os times introduzam práticas técnicas “estranhas” ao conhecimento dele.
A gerência acredita em hierarquias rígidas e no modelo do Management 1.0
A área usuária acredita que projetos devem atender simultaneamente o custo, escopo e o prazo, ainda que esse compromisso tenha sido feito com informações precárias em um documento de 1 página.
Vários desenvolvedores e testadores acreditam que eles devem receber comandos claros e o que trabalho deles termina no comit do código (time de desenvolvedores) e na geração de defeitos (time de testes)
Ao analisar esse caso, vemos que o modelo de incentivo da diretoria induz comportamentos de micro-controles em alguns gerentes médios, que por sua vez propagam e criam força a uma cultura comando e controle aumenta o nível de passividade de várias técnicos do time.
Aplicando Mudanças com o Modelo Iceberg
O modelo Iceberg não apenas ilustra as diferentes dimensões de um problema, mas também oferece uma visão sobre como implementar mudanças de maneira mais eficaz dentro do sistema, através dos chamados pontos de alavancagem.
“Dê-me uma alavanca e um ponto de apoio e eu moverei o mundo”, Arquimedes.
Um ponto de alavancagem é um lugar dentro de um sistema – uma organização, uma economia, um corpo vivo, uma cidade, um time -, onde uma pequena mudança em uma coisa pode produzir grandes mudanças em tudo. Quanto mais baixo nós vamos no iceberg, mais alavancagem teremos para transformar o sistema. Mudar estruturas e influenciar modelos mentais tem um efeito mais amplo e mais abrangente do que reagir no momento e eventos discretos de combate a incêndios.
Mudança no nível dos Eventos – Efeito: Reação
Se apenas olharmos para os eventos, o melhor que podemos fazer é reagir. Algo acontece e nós consertamos. Essa é tipicamente nossa resposta na primeira vez que um evento ocorre. Nós não mudamos nosso pensamento de forma alguma; Nós apenas agimos rapidamente para corrigir o problema imediato usando soluções pré-existentes que funcionaram no passado. Para alguns eventos superficiais, esta abordagem pode funcionar bem, mas falhará claramente se uma questão é mais sistêmica, pois estamos apenas lidando com os sintomas do problema, não com as causas subjacentes.
A metáfora do iceberg ajuda a ilustrar que, se de alguma forma alteramos o evento no topo sem encontrar uma solução para a causa, a flutuabilidade do gelo por baixo simplesmente empurra para recriar a ponta novamente. Como tal, apenas os problemas mais superficiais podem ser resolvidos neste nível.
Mudança no nível de Padrões de Comportamento – Efeito: Antecipação
Quando começamos a notar um padrão em uma série de eventos, temos mais opções. Podemos antecipar o que vai acontecer e podemos planejar isso. Quando começamos a perceber padrões, podemos começar a considerar o que está fazendo com que os mesmos eventos aconteçam repetidamente.
Por exemplo, você observar que liberações sem testes de regressão irão trazer um alto volume de incidentes no mês seguinte. E isso lhe permite estabelecer no futuro estratégias de testes e práticas de qualidade contínua para se antecipar a esses problemas.
Mudanças no nível da Estrutura – Efeito: Redesenho
Quando começamos a prestar atenção às estruturas subjacentes, começamos a ver onde podemos mudar o que está acontecendo. Nós não estamos mais à mercê do sistema. Podemos começar a identificar o pensamento e os modelos mentais que estão causando essas estruturas a serem do jeito que são.
Por exemplo, podemos ter uma estrutura de desenvolvimento onde os usuários chave estão em contato diário com o time de desenvolvimento e possuem tempo semanal dedicado para gerar feedback dos produtos. E isso permite que novos padrões de construção floresçam, que irão reduzir muito retrabalho de requisitos e reduzir defeitos.
Mudanças no Nível dos Modelos Mentais – Efeito: Transformar
Mudar o modelo que uma organização usa é o ponto de alavancagem mais alto, pode levar a uma transformação real, com a possibilidade de reestruturar totalmente o sistema e superar até mesmo desafios complexos.
Por exemplo, quando você tem um time cujo gerente “comando e controle” foi removido e agora você tem um líder que promova discussões aberta e transparência radical para tratar e resolver problemas, você consegue criar um ambiente de aprendizado verdadeiro e mais resiliente para lidar com as pressões.
Em resumo, o pensamento sistêmico nos convida a parar de reclamar das pessoas pelo ato de reclamare estudar os motivadores diretos e indiretos que levam as pessoas a fazer o que elas fazem. Os atos que você observa são apenas eventos. Julgar os eventos sem entender os padrões, estruturas e modelos mentais é raso e normalmente não vai resolver nada que seja realmente complexo.
Efeitos da Aplicação do Modelo Iceberg
As regras do jogo mudam quando você começa a jogar
Quando você incorpora o espírito de times ágeis, você compreende que o seu trabalho é não linear, i.e., que regras que anteriormente valiam podem ser invalidadas no meio do jogo. Por exemplo, você pode perder aquele excelente desenvolvedor de backend que foi trabalhar em uma outra empresa. Ou você pode ter parte do seu escopo invalidado por uma regulamentação que acabou de chegar do governo. Aceitar a imprevisibilidade e desenvolver mecanismos de adaptação a mudança são fundamentais para fazer com que as Squads prosperem.
Você pode estar errado
Outra regra importante do pensamento sistêmico diz que mesmo que você seja muito experiente, você pode fracassar. Você pode ter executado uma prática com sucesso em vários locais, mas pode falhar miseravelmente na próxima iniciativa. Ou seja, ter a mente aberta para tratar seus movimentos ágeis como hipóteses e buscar validar essas hipóteses o mais rapidamente possível é crítico para prosperar.
Você pode ter efeitos colaterais
Quando você está experimentado com uma Squad, você deve ter ciência que seus movimentos podem gerar efeitos colaterais, também chamados de consequências não-intencionais. Esteja aberto para avaliar os efeitos de segunda e terceira ordem das suas mudanças e crie um ambiente de banda larga
Você deve envolver muitas pessoas, continuamente.
Não é fácil mudar o modelo mental e estruturas e você deve envolver muitas pessoas para discutir as mudanças e debater o que deve ser realizado. Crie instrumentos de meritocracia para avaliar quais são as pessoas que estão realmente aptas para contribuir com mudanças e lhe ajudar a estabelecer pontos de alavancagem firmes.
Dicas para Operar Mudança no Nível dos Modelos Mentais
Descubra o que é REALMENTE importante para as pessoas, ignorando o que dizem que é importante.
Incentive as pessoas nas dimensões que são valiosas para elas, mas quem podem ser facilmente proporcionadas por você.
Preste atenção à maneira como reagem. Se você ficar frustrado ou surpreso com suas reações, trate de aprender com elas e experimentar algo diferente
Crie incentivos que mudem as estruturas de antagônica para cooperativa.
Nunca acredite que as pessoas farão algo simplesmente porque é a coisa certa.
Saiba que certas pessoas farão tudo que estiver ao seu alcance para manipular o sistema, encontrando maneiras de vencer que você jamais havia imaginado. Esteja preparado para isso e se adapte.
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.
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.
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
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?
“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
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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:
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.
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.
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.
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.
Marco Mendes 