Não se é "ágil" quando… Modelos híbridos

As conversas que tive com colegas, leitores do meu blog e um professor da Pennsylvania State University sobre esses obstáculos geraram discussões apaixonadas sobre o valor relativo e a utilidade dos modelos híbridos.

Cascata

Os métodos clássicos de desenvolvimento de software são como uma cascata, que começa com a definição de requisitos e termina com a implementação. O trabalho é realizado em etapas individuais ao longo dos degraus dessa cascata – semelhante ao trabalho em linha de montagem na produção automobilística. O produto só funciona quando sai da linha no final. Nesse modelo, determinados trabalhos são sempre realizados pelas mesmas pessoas especializadas. Henry Ford revolucionou o mercado automobilístico com esse método.

No entanto, esse tipo de desenvolvimento de software também pode promover todo tipo de comportamentos negativos. A razão para isso é geralmente a incompatibilidade entre trabalhos em linha de montagem (por exemplo, na produção) e trabalhos mais dinâmicos, que são mais orientados para pesquisa e desenvolvimento. Um exemplo de comportamento negativo é o uso inadequado dos chamados "Stage Gates" (marcos entre as etapas individuais). Muitas vezes, as equipes simplesmente continuam trabalhando, mesmo quando o método exigiria esperar por uma decisão de Stage Gate. O problema é que nunca terminariam a tempo se esperassem por uma decisão. Os gestores SEMPRE sabem o que está acontecendo, mas preferem não fazer perguntas. A razão para isso normalmente não é que alguém no processo trabalhe mal, mas sim que o próprio processo é ruim.

Agile é diferente

Agile interrompe essa cascata e divide o trabalho em partes menores. Essas partes menores são então projetadas, desenvolvidas, testadas e entregues com a ajuda de Sprints curtos para obter feedback direto. Com o "novo" processo, não há mais razão para ignorar os sinais de pare dos Stage Gates.

Os modelos híbridos devem aproveitar o melhor dos frameworks clássicos e ágeis e assim se adaptar de forma ideal à cultura e estrutura atual da organização. Querer adaptar métodos ágeis a uma organização que na verdade está configurada para métodos clássicos é o ponto onde os problemas frequentemente se infiltram. Os compromissos necessários muitas vezes contradizem as premissas dos valores e princípios ágeis.

Exemplos de tais premissas em Agile são equipes estáveis, responsabilidade própria e a entrega de software funcional no final de cada Sprint. É mais fácil se afastar desses valores e princípios do que mudar a cultura e estrutura da organização. Um dos compromissos mais comuns (e prejudiciais) pode ser observado em organizações que continuam trabalhando com equipes de composição dinâmica (frequentemente chamadas de organizações matriciais). Equipes estáveis frequentemente exigem a reformulação dos limites organizacionais e uma análise mais detalhada das competências.

Estes são os problemas típicos que – se não forem enfrentados – podem levar uma organização a usar formas mistas de métodos clássicos e ágeis:

Silos: Quando grupos individuais estão separados uns dos outros, é necessário mais planejamento e coordenação para garantir que as pessoas certas estejam disponíveis no momento certo – mesmo em caso de atrasos. Grandes organizações de desenvolvimento incorporaram o papel de um Scheduler (planejador de trabalho) ou de um Expediter (controlador de prazos) em seu organograma para lidar com esse tipo de problema.

Muito enxuto: Muitas organizações de desenvolvimento sofrem com anos de medidas de economia e têm muito menos pessoas disponíveis do que o necessário para concluir o trabalho com o qual se comprometeram. Os colaboradores trabalham ativamente em vários projetos diferentes para dar a impressão de progresso em toda uma série de iniciativas. Alternar entre diferentes tarefas é altamente ineficiente e diminui o valor entregue, o que frequentemente leva a uma pressão ainda maior para reduzir custos.

Falta de foco: Líderes em organizações de desenvolvimento frequentemente sentem a necessidade de aceitar e executar todos os projetos apresentados. Isso também é chamado de "síndrome do sim". Ocorre principalmente em organizações que não possuem uma gestão de portfólio forte. No final das contas, isso significa que equipes e colaboradores são forçados ao multitasking, o que por sua vez leva à ineficiência.

Pouca automação: Nunca conheci um método de desenvolvimento que não pudesse ser executado em pequena escala com caneta e papel. No entanto, uma escala maior é possibilitada pela automação. Imagine, por exemplo, que você tivesse que escrever alguns milhares de testes de regressão manualmente. Para executar os testes, você precisaria de muito tempo ou de muitas pessoas. Muitas pessoas normalmente significa também mais equipes, mais limites entre equipes, mais hierarquia e mais esforço – isso pode potencialmente levar a menos testes sendo realizados porque é preciso cumprir um prazo ou um determinado orçamento.

Os valores e princípios nos quais Agile se baseia são realmente importantes. Eles influenciam os comportamentos, de modo que você se concentra mais em entregar valor mais rapidamente. Os quatro valores do Manifesto Ágil são apresentados como pares. Por exemplo, o primeiro dos quatro valores diz: "Indivíduos e interações acima de processos e ferramentas". As coisas do lado esquerdo têm um valor maior do que as do lado direito (embora estas também tenham valor). Os modelos híbridos frequentemente criam compromissos que deslocam o foco dos pontos do lado esquerdo mais para o centro ou até de volta para os pontos do lado direito.

Modelos híbridos não são fundamentalmente maus ou ruins

No entanto, quando você se afasta dos valores e princípios ágeis fundamentais em vez de enfrentar questões difíceis na organização, isso geralmente é apenas uma manobra de evasão. Quer você concorde com tudo isso ou não, seus pensamentos sobre este tema são importantes e direcionam a conversa sobre o que é Agile e o que não é.

Este texto vem do Blog do SPaMCAST e foi traduzido por nós para o alemão.