Retrospectivas ágeis sem frescuras

Avaliar se projetos e times estão indo bem é uma ideia já antiga, popularizada em corpos de conhecimento como o PMBOK (Project Review) ou RUP (Iteration Review). E com o crescimento dos métodos ágeis e do SCRUM, o termo retrospectiva ganhou muito popularidade nesse século (Sprint Review).

No Brasil vemos muitos times praticar retrospectivas. Ao mesmo tempo, vemos que muitas dessas reuniões estão focadas puramente em avaliar aspectos motivacionais das pessoas e capturar sentimentos de ansiedade, irritação, desespero ou melancolia.

O foco está primeiro nas pessoas e depois no trabalho. E essa abordagem é perigosa por vários motivos. Enumero alguns motivos aqui:

  1. Se você enquanto Agile Coach não tem formação em psicologia, você pode fazer mais estragos do que melhorias ao tentar promover mudanças comportamentais baseadas em percepções de problemas do campo do subjetivo.
  2. Tentar “melhorar” aquele garoto enxaqueca do seu time não é algo que possui receita, resultado garantido e muito menos tempo definido. O contrário é verdade. Converse com qualquer psicologo sobre o assunto e se surpreenda com o tempo necessário para trabalhar frustrações do campo do subjetivo. Definitivamente, não é algo que você possa colocar em um cartão e executar em uma sprint.
  3.  A sua reunião pode virar uma sala de lamentação, onde desenvolvedores passivo-agressivos vão ficar expondo lamúrias e riscando post-is sem parar para lidar com a agressividade reprimida.
  4. O papel conceitual de uma retrospectiva é o melhorar o seu sistema de trabalho. Se a reunião não cumpre esse objetivo, ela não é um ciclo de feedback de verdade para o sistema adaptativo complexo de trabalho.

Veja. Não estou dizendo que pessoas não são importantes. O contrário é verdade. E é justamente por isso que precisamos respeitar os adultos que estão ali convidados por você e honrá-los com uma reunião que funcione.

Retrospectiva Sem Frescura

Para isso vamos apresentar a Retrospectiva Sem Frescura, centrada no trabalho e respeitando as pessoas ali presentes.

Você deve conduzir uma retrospectiva olhando para o seu quadro Kanban de histórias. Observe a coluna de trabalho realizado. Para cada história ali depositada, pergunte:

  1. Os nossos clientes ficaram satisfeitos com essa história?
  2. Esse história atendeu aos parâmetros de qualidade, custo, e demais critérios de aptidão dos clientes internos e diretoria.
  3. Essa história fluiu bem ao longo do nosso quadro Kanban? O tempo de entrega dessa história foi boa? Ou tivemos impedimentos, bloqueios ou esperas em filas?

Observe também que essas perguntas vão trazer as insatisfações pessoais, com certeza. Por exemplo, se um desenvolvedor precisou esperar 3 dias para ter uma permissão em um banco de dados específico, a insatisfação concreta irá emergir e poderemos ter atos de liderança para endereçar essa situação específica. Mas a agenda é motivada pelo trabalho e para o trabalho, respeitando as pessoas e buscando soluções objetivas para melhorar aquele trabalho.

E se você nem consegue responder ao item 1 do roteiro acima, o seu trabalho está com problemas graves. Você está conduzindo uma retrospectiva onde não houve entrega de valor para os seus clientes. É um sintoma de empresas que focam mais em iniciar coisas do que terminar. Ao invés, pare de começar e comece a terminar.

O passo a passo – Retrospectiva Sem Frescuras

  1. A revisão é feito em frente ao quadro Kanban. Ela foca nos itens completados.
  2. Ela coleta observações, ocorrências, falhas, ideias a serem exploradas e políticas atuais.
  3. Ela categoriza o feedback coletado e define ações de melhoria no sistema de trabalho.

Gerencie o trabalho e não as pessoas

Corpos de conhecimento com o método Kanban e o Management 3.0 nos ensinam que a gestão deve ocorrer sobre o trabalho e não sobre as pessoas.

Ao focar no trabalho, você cria pragmatismo e honestidade com a sua empresa. Você cria foco também para lidar com os problemas e frustrações. E você respeita também o direito das pessoas estarem irritadas e ainda assim entregar um trabalho honesto e apto para o propósito da sua organização e seus clientes.

 

Um panorama de métodos para aumentar a agilidade de negócios

A agilidade de negócios se tornou um imperativo para muitas organizações. Inovar, criar produtos melhores, engajar mais clientes, encurtar o tempo de ciclo e reduzir desperdícios são alguns dos desafios que atormentam muitos gerentes nas empresas do Brasil e do mundo.

Os métodos ágeis tem sido usados, nos últimos 20 anos, para buscar entregar agilidade de negócios e apoiar gestores e times em linhas gerais. Mas se em 2001 podíamos enumerar os tipos de métodos ágeis em uma única mão, hoje o ecossistema ficou muito mais complexo. Os métodos, frameworks e práticas se multiplicaram e a simples escolha de qual método usar para apoiar as iniciativas de agilidade de negócio se tornou um desafio.

Nesse contexto, trago aqui uma compilação de 11 métodos ligados à agilidade de negócios e que tem obtido alguma visibilidade nos últimos anos.

Método Kanban

O método Kanban é uma abordagem de gerenciamento e melhoria de sistemas de fluxo e que busca criar um modelo evolucionário de aumento de maturidade nas organizações. Ele é uma alternativa a abordagens pesadas que introduzem mudanças radicais, reestruturações organizacionais e modelos prescritivos desconectados da realidade objetiva de cada organização.

O método Kanban foi criado por David Anderson a partir das suas experiências na Microsoft no começo do século e hoje é um dos métodos mais promissores na comunidade ágil.

Ele é mantido pela Kanban.University, que fornece uma trilha de cursos de formação e uma coleção de práticas provadas em centenas de organizações nos últimos 15 anos.

O método Kanban é acelerado por duas ferramentas conceituais poderosas:

  1. STATIK, que é uma abordagem sistêmica para introduzir sistemas Kanban em organizações. Um excelente artigo sobre ele pode ser encontrado aqui no LinkedIn do David Anderson.
  2. KMM, que é um modelo de maturidade organizacional baseado em sistemas Kanban.

Livro chave:

Management 3.0

O Management 3.0 é uma coleção de jogos, ferramentas e práticas em constante mudança para ajudar qualquer trabalhador do conhecimento a gerenciar o seu trabalho em organizações. Ele é uma maneira de ver os sistemas de trabalho em contextos complexos e melhorar esse sistemas.

O Management 3.0 é centrado em seis pilares.

  1. Energizar Pessoas: As pessoas são as partes mais importantes de uma organização e os gerentes devem fazer de tudo para manter as pessoas ativas, criativas e motivadas.
  2. Empoderar Equipes: As equipes podem se auto-organizar, e isso requer empoderamento, consentimento e confiança da gestão.
  3. Alinhar Restrições: A auto-organização pode levar a qualquer coisa e, portanto, é necessário proteger as pessoas, compartilhar recursos, dar às pessoas um propósito claro e metas definidas.
  4. Desenvolver Competências:  As equipes não podem alcançar seus objetivos se os membros da equipe não forem suficientemente capazes, e os gerentes devem, portanto, contribuir com o desenvolvimento de competências.
  5. Crescer a Estrutura: Muitas equipes operam em um contexto de uma organização complexa. E assim é importante considerar estruturas que favoreçam a comunicação.
  6. Melhorar Tudo: Pessoas, equipes e organizações precisam melhorar continuamente.

Publicado oficialmente em 2010 em Jurgen Appelo, o M3.0 teve grande receptividade no Brasil e hoje conta com uma forte comunidade de facilitadores e praticantes.  O portal Management 3.0 contém informações oficiais sobre esse método.

Livro Chave:

DevOps

O DevOps é um movimento cultural habilitado por práticas, técnicas e ferramentas e que tem por objetivo reduzir tempos de ciclo na entrega de produtos de TI, reduzir retrabalhos e habilitar a inovação organizacional.

O DevOps é baseado nos princípios do acrônico CALMS.

  • Cultura
  • Automação
  • Lean
  • Medições
  • Sharing (Compartilhamento de informações)

Na perspectiva mais pragmática, o DevOps é conhecido pelas seguintes práticas técnicas:

  • Automação de Testes
  • Integração Contínua
  • Entrega Contínua
  • Infraestrutura como código
  • DevSecOps
  • Engenharia do Caos

O portal IT Revolution, mantido por Gene Kim, um dos líderes desse movimento, possui uma coleção rica de informações e livros para você se aprofundar nessas práticas.

Mantenho também no meu blog diversos artigos sobre DevOps acessíveis a partir desse link: https://marco-mendes.com/devops/

Livro chave:

OKR – Objetivos e Resultados Chave

Esse é um método para lidar com o problema de definição e execução de metas. A definição de metas tradicional em exercícios de planejamentos estratégicos anuais, geralmente envolve declarações de objetivos criados em torres de marfim desconectadas da realidade operacional, mal comunicadas e cascateados de cima para baixo. Como consequência, a taxa de fracasso é alta.

O OKR, ao invés, é uma estrutura leve para definir e rastrear objetivos e seus resultados baseada em ciclos curtos (até 3 meses), envolvimento de todos na definição de metas e uma abordagem colaborativa para resolver e integrar dependências e conflitos.

O OKR traz como benefícios:

•Foco e disciplina: Poucos objetivos, gerando foco na organização;
•Alinhamento entre equipes: Interdependências funcionais entre os times integradas e resolvidas pelo método;
•Transparência: Todos os OKRs são públicos e possibilitam um alinhamento entre os objetivos e a visão da empresa;
•Gestão e Performance : Os OKRs são acompanhados em base periódica pelos próprios times que definiram as metas;
•Accountability: Todos passam a ser responsáveis por seus objetivos, com critérios claros de sucesso, conhecidos por toda a empresa;
• Centrado em dados: Os resultados chave são quantitativos e centrados em métricas acionáveis (ao invés de métricas de vaidade).
O portal What Matters traz uma rica coleção de recursos sobre OKR. No Brasil, recomendo também o portal do Felipe Castro, pioneiro de OKR no Brasil.

Livro Chave:

Modelo de Fluência Ágil

O modelo de Fluência Ágil ajuda os times a entender onde eles estão em termos de seus próprios objetivos, e entender o que é relevante para o seu contexto e necessidades específicas.
Esse modelo é resumido no seguinte esquema e define um conjunto de práticas e ferramentas que podem tornar uma organização fluente em um dos  possíveis níveis do modelo (nível 1 a 4).
O modelo de fluência ágil não é um modelo de maturidade, mas um mecanismo que permite que empresas possam escolher uma jornada de agilidade apta aos seus propósitos. Esse modelo usa outros métodos como Kanban, Scrum, XP ou DevOps dentro das suas jornadas específicas.
Um excelente artigo sobre o modelo é descrito aqui e foi escrito pelos seus criadores, James Shore and Diana Larsen. E você encontra muito material legal aqui no portal do Agile Fluency também.

Agile BOSSA Nova

O BOSSA é uma abordagem para agilidade organizacional, combinando as seguintes práticas de agilidade de negócio.

  • BB – Beyond Budgeting (orçamentos adaptáveis e flexíveis). Esse é um método de orçamentação moderno que habilita a tomada rápida de decisões em contextos complexos. Recomendo esse portal aqui com mais informações sobre o BB.
  • Open Space (abordagem para habilitar o poder da inovação de todos os funcionários),
  • Sociocracia 3.0 (estrutura organizacional flexível que permite a tomada de decisão descentralizada). Mais informações podem ser encontradas aqui no portal oficial.
  • Agilidade (aprendizado contínuo por meio de experimentos e feedback).
O portal Agile Bossa Nova traz uma rica coleção de recursos para quem quiser conhecer essa abordagem em mais detalhes.
Livro Chave:

Estruturas Libertadoras (LISA ou Liberating Structures)

As estruturas libertadoras são micro-estruturas narrativas que aprimoram a coordenação e a confiança entre as pessoas de uma empresa. Eles rapidamente estimulam a participação ativa de grupos de qualquer tamanho, tornando possível incluir e liberar o potencial de todos os participantes. Estruturas libertadoras são uma alternativas a abordagens de reuniões mais controladoras ou restritivas.
Em termos objetivos, elas são práticas para você conduzir encontros de trabalho no seu dia a dia. São técnicas de facilitação poderosas para apoiar grupos de trabalho a alcançar objetivos específicos em períodos curtos de tempo.
Um resumo dessas estruturas é mostrada na figura abaixo.
O portal do LISA contém uma explicação detalhada dessas estruturas. Existe também um APP móvel que considero muito útil e que disponível aqui na loja da Google Play.
Livro Chave:

Cynefin (leia Kinevin)

Esse modelo foi desenvolvido ainda em 1999 por Dave Snowden para ajudar líderes a compreender melhor o ambiente organizacional onde estão inseridos, e com base nisso, tomar decisões mais apropriadas.
Em termos práticos, o Cynefin é uma ferramenta de análise situacional e que permite qual o tipo de domínio onde as narrativas da sua empresa ocorrem. Os domínios possíveis estão listados abaixo (simples, complicado, complexo ou caótico). Dentro de cada domínio, o Cynefin sugere ferramentas apropriadas para aquele contexto.
O portal Cognitive Edge, mantido pelo Dave Swoden e associados, possui uma rica coleção de recursos e ferramentas ligadas ao ecossistema do Cynefin.

Modern Agile

O Modern Agile é uma comunidade para pessoas interessadas em descobrir melhores maneiras de obter resultados melhores para potencializar a agilidade de negócio. Ele aproveita a sabedoria de muitas indústrias, é orientado por princípios e não possui uma estrutura prescritiva.
Os princípios fundamentais dessa abordagem são resumidos na figura abaixo.
O site oficial do Modern Agile apresenta também as práticas emergentes dessa abordagem.

Heart of Agile

O Heart of Agile é um movimento liderado por Allistair Cockburn e que compila a experiência duas décadas de práticas ágeis dentro do modelo minimalista abaixo.
Esse movimento é um retorno à essência do manifesto ágil e pode ajudar você a descobrir a essência do Scrum, sem cair nas complicações e regras excessivas que foram adotadas pelos guias Scrum nos últimos anos.
O portal Heart of Agile conta também com uma coleção rica de recursos sobre esse movimento e apresentações do Cockburn.

Shiftup

O movimento Shiftup é uma nova marca de workshops, criada por Jurgen Appelo, que abraça a inovação contínua e a agilidade dos negócios como ponto de partida para a mudança organizacional.

O Shiftup é um programa para inovação contínua. Ele oferece um conjunto dinâmico de regras e modelos simples para as organizações se transformarem continuamente. Duas de suas regras fundamentais são colocadas abaixo.

  1. Cada idéia inovadora que evolui para um negócio de sucesso (seja um fluxo de valor individual ou um modelo de negócios inteiro) segue uma progressão natural dos estágios do ciclo de vida ou dos níveis de maturidade.

2.  A abordagem iterativa e incremental da inovação contínua (promovida pelos métodos Agile, Lean, Design Thinking e Lean Startup) se aplica a todos os fluxos de valor e modelos de negócios em todos os estágios do ciclo de vida.

O modelo conceitual é apresentado no esquema abaixo e esse e outros recursos de apoio se encontram no portal Shiftup.Work

Livro chave:

Lean Inception

O Lean Inception é um workshop colaborativo para alinhar um grupo de pessoas sobre o produto mínimo viável a ser construído. Ele é inspirado nos seguintes conceitos, modelos e processos:

  • Lean Startup e MVP
  • Iniciação do Processo Unificado da Rational
  • Design Thinking
  • User Centric Design

Similar à ideia do Design Sprint popularizada pela Google, o Lean Inception obteve uma boa tração no Brasil e tem sido usado por muitas empresas para realizar iniciações ágeis mais efetivas.

O portal do Paulo Caroli, pai do Lean Inception, contém muito mais informações ricas sobre esse workshop.

Livro Chave:


Vejo essa diversidade com bons olhos pois nenhum método é completo e perfeito.

“Não desenvolva apego a nenhum arma ou escola de combate”,
Samurai Miyamoto Musashi, Século 17

Eles são abstrações apenas e uma combinação efetiva deles pode ser interessante dentro da sua realidade. Espero que alguns desses modelos lhe possam ser úteis.

Existem muitos mais modelos de agilidade de negócio e ficaria feliz com feedbacks de outros modelos que não foram contemplados aqui.

Um feliz 2020 repleto de agilidade de negócio para você e até a próxima.
😀

Como matar uma iniciativa DevOps em sete passos.

A TI é afeita a termos e letrinhas que surgem de tempo em tempo. No momento atual, os termos “transformação digital”, “microsserviços” e “DevOps” são tão modinhas quanto as músicas de qualidade ruim da Anitta.

E o problema das modinhas é que que todos querem dizer que estão fazendo, mesmo que tenham uma ideia distorcida do que estão realmente fazendo. A este respeito, tenho observado excelentes oportunidades DevOps sendo jogadas nos lixo por implementações equivocadas em pequenas e grandes empresas.

E se é para nos equivocarmos, gostaria de ajudar também. Vamos direto ao ponto e criar um guia rápida de como fracassar com DevOps.

É fácil. Siga os sete passos abaixo e falhe na sua implementação DevOps. É fracasso garantido ou o seu dinheiro de volta.

  1. Contrate um “Analista DevOps”

Existem sim líderes técnicos, desenvolvedores, testadores e profissionais de qualidade, entre outros, que praticam DevOps. Ao mesmo tempo devemos nos lembrar, desde o início, que o DevOps é uma cultura. Ou seja, não existem *Analistas DevOps*.

Acreditar que você vai encontrar um “Analista DevOps” já é ruim. E para piorar alguns gestores acreditam que contratar um “Analista DevOps” é o suficiente para ter a sua implementação DevOps realizada.

2. Crie uma área especialista para fazer DevOps

Erro clássico, embora muito comum. Criar mais um silo em um departamento de TI que já tem áreas de gestores, analistas, desenvolvedores, testadores, homologação e produção trabalhando em locais diferentes definitivamente não irá ajudar.

O DevOps prega a quebra das paredes (físicas e invisíveis). E não adicionar mais uma área funcional dentro da sua TI.

3. Estabeleça um pipeline DevOps dentro da área de qualidade ou governança

Qualquer iniciativa de centralizar uma esteira DevOps vai intensificar o oposto do que a cultura DevOps promove. O DevOps é uma cultura que promove comunicação ampla e a quebra de silos.

Que fique claro: o DevOps ocorre NOS PROJETOS e não em uma torre de marfim de qualidade.

4. Mantenha testadores e desenvolvedores trabalhando em áreas diferentes

Apartar (no espaço e no tempo) testadores e desenvolvedores é um dos piores erros que gestores podem cometer. Isso gera adiamento na resolução dos defeitos, desalinhamento e dedos apontados sobre as culpas no final do projeto. E isso também mantem a nefasta cutural funcional e os malefícios que os processos cascata nos impuseram ao longo dos últimos 40 anos.

5. Não envolva o time de infraestrutura. Ou não envolva o time de desenvolvimento

DevOps sem Ops soa estranho, certo? Assim como uma iniciativa DevOps sem Dev. E mesmo assim estamos vendo muitas implementações DevOps que ocorrem apenas dentro da área de desenvolvimento ou da área de operações.

6. Implante as ferramentas DevOps em primeiro lugar

Muitos gestores acreditam que ferramentas como VSTS, Chef, Puppet, GitLab, Docker ou Ansible já trazem o DevOps dentro dela. É como se você comprasse uma panela de cerâmica laranja e esperasse que o seu jantar vá ter qualidade de restaurante três estrelas Michelin.

Embora estas e outras ferramentas sejam excelentes devemos nos lembrar que no mundo DevOps devemos:

  • primeiro trabalhar as pessoas e a cultura,
  • depois as práticas;
  • e finalmente as ferramentas.

7. Venda o DevOps como a bala de prata que irá matar os lobisomens da sua organização

Não, o DevOps não é uma bala de prata. Ele não irá revolucionar a sua TI, não irá zerar o backlog e os defeitos, não irá garantir todas as entregas dentro dos prazos e também não irá fazer que pessoas deem as mãos em harmonia.

Apesar disso,  o DevOps pode lhe ajudar sim no contínuo caminho da melhoria contínua que buscamos nos ensinamentos do sistema Toyota de Produção e nas práticas Lean.

Algo está errado se os trabalhadores não olham ao seu redor cada dia e não encontram coisas tediosas ou aborrecidas para depois reescreverem eles mesmos os procedimentos. Mesmo o manual do mês passado deveria estar desatualizado hoje, Taiichi Ohno

Para combater essa e outras mazelas, recomendo o livro abaixo. Já um clássico dentro da recente e empolgante literatura DevOps.

A fábula dos porcos assados (e os sistemas de informação)

Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir dai, toda vez que queriam comer porco assado, incendiavam um bosque.  O tempo passou, e o sistema de assar porcos continuou basicamente o mesmo.

Mas as coisas nem sempre funcionavam bem: às vezes os animais ficavam queimados demais ou parcialmente crus. As causas do fracasso do sistema, segundo os especialistas, a dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou, ainda, às árvores, excessivamente verdes, ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.

As causas eram, como se vê, difíceis de determinar – na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: havia maquinário diversificado, indivíduos dedicados a acender o fogo e especialistas em ventos – os anemotécnicos. Havia um diretor-geral de Assamento e Alimentação Assada, um diretor de Técnicas Ígneas, um administrador-geral de Reflorestamento, uma Comissão de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias e o Bureau Orientador de Reforma Igneooperativas.

Eram milhares de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.

Um dia, um incendiador chamado João Bom-Senso resolveu dizer que o problema era fácil de ser resolvido – bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então sobre uma armação metálica sobre brasas, até que o efeito do calor – e não as chamas – assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor-geral de Assamento mandou chamá-lo ao seu gabinete e disse-lhe: “Tudo o que o senhor propõe está correto, mas não funciona. Isso pode funcionar na teoria, mas na prática não faz sentido. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? E com os acendedores de diversas especialidades? E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadoras de ar? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Hein?.”

“Não sei”, disse João, encabulado.

“O senhor percebe agora que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que, se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo?.”

“O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas? O que o senhor espera que eu faça com os quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? E o que fazer com nossos engenheiros em porcopirotecnia? Vamos, diga-me!”.

“Não sei, senhor.”

“Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia – isso poderia trazer problemas para o senhor no seu cargo.”

João Bom-Senso, coitado, não falou mais um “a”. Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.”

Desconheço o autor desta fábula, mas ainda vejo florestas sendo queimadas com muito mais frequência do que imaginaria na área de Tecnologia de Informação.

Ouvi um relato de um projeto que foi fragmentado para quatro empresas fornecedoras operando remotamente, cada um com a sua especialidade tecnológica (Mobilidade, barramento, back-end e Web). Uma desculpa para este arranjo foi que cada empresa fornecedora era “dona” de uma tecnologia e os acordos contratuais exigiam esta distribuição. Dois anos depois e com com milhões de reais gastos nenhum produto foi entregue. O diretor de assamento então resolveu assar no espeto os gerentes e algumas fábricas que participaram deste processo.

Também tive a oportunidade de ver um time de produto que herdou uma arquitetura Web absurdamente complexa de um  “arquiteto super inteligente” de uma fábrica de software. O efeito desta arquitetura é o que time demora 3 semanas para implementar um cadastro de complexidade média.

Estas histórias reais me lembram do conceito de complexidade acidental e complexidade essencial, popularizado na TI por Neal Ford.

A complexidade essencial representa a dificuldade inerente a qualquer problema. Na nossa fábula acima, acender fogo era necessário para assar os porcos.  A complexidade decorrente dos compromissos que assumimos que incorrem em dívidas técnicas é diferente. Consiste em todas as formas imposta externamente de que o software se torne complexo e não deve existir em um mundo perfeito. A isso chamamos de complexidade acidental. Tecnologias como o Java EJB, Microsoft BizTalk e ERPs cujos nomes não podem ser pronunciados são exemplos de complexidade acidental na TI.

Tomo a liberdade aqui de expandir a definição original do autor, pensada para arquiteturas de software, para arranjos essenciais e arranjos acidentais.

Por exemplo, a existência de analistas desenvolvedores, analistas de testes e líderes de projetos são arranjos essenciais para entregar software de qualidade. Já times de testes e times de desenvolvedores que trabalham em salas separadas e com processos cascatas são exemplos de arranjos acidentais. E os  “gerentes de projetos” que ficam atrás das suas mesas 8 horas por dia atualizando cronogramas Gantt de 1000 linhas e perguntando aos seus coordenados “Eh aí, tá pronto?” são exemplos também ruins de arranjos acidentais.

Se você está cansado de queimar florestas inteiras para assar porcos, recomendo a aplicação de práticas do Lean Software Development, um corpo de práticas muito legais para você descomplicar a sua TI e a forma como entrega e mantém software.

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
Edsger W. Dijkstra