Não se é ágil… com uma cascata ágil

Muitas organizações se descrevem como ágeis. Quem não gostaria de ser ágil? Se você não é ágil, não seria por definição pesado, lento e letárgico?

Poucas organizações se descreveriam assim; no entanto, Agile no mundo do desenvolvimento, melhoria e manutenção de software significa mais do que apenas ser capaz de agir com rapidez e leveza. Agile significa que uma equipe ou organização adota certos princípios que moldam comportamentos e levam à internalização de determinados métodos.

Quando as ações não correspondem ao que é afirmado, frequentemente a gestão se coloca no caminho dos princípios e os praticantes no caminho dos métodos. Os métodos nas organizações costumam estar muito enraizados e exigem um esforço significativo de mudança. Algumas organizações afirmam usar uma abordagem mista, fazendo a transição de uma abordagem mais clássica para uma combinação de Scrum, Kanban e Extreme Programming. Isso é visto como uma abordagem mais segura e conservadora que permite que uma organização mude organicamente. O problema, no entanto, é que essa tática raramente funciona e as organizações rapidamente ficam travadas. Se você não investe tempo e esforço suficientes na gestão de mudanças, isso rapidamente leva a frameworks híbridos que não são nem uma coisa nem outra – e estes raramente são verdadeiramente ágeis.

Características de organizações estagnadas (ou potencialmente estagnadas)

A cascata iterativa:

A cascata iterativa clássica tem suas raízes no modelo espiral de Barry W. Boehm. Nesta pseudoversão do desenvolvimento iterativo, iterações curtas e limitadas no tempo são usadas para cada uma das fases clássicas da cascata. Um sprint de requisitos é seguido por um sprint de design, depois um sprint de desenvolvimento, e assim por diante. Tanto o modelo espiral clássico quanto a pseudoversão do Agile são consideravelmente melhores que o modelo cascata clássico para gerar feedback e entregar valor mais rapidamente; no entanto, as organizações param de evoluir em direção ao Agile e, portanto, colhem apenas uma parte dos benefícios.

Definir requisitos antecipadamente:

Nesta abordagem híbrida do Agile, equipes ou organizações coletam todos os requisitos (às vezes chamados de features) no início do projeto e os definem antes que o trabalho real comece. O Agile é baseado em certas suposições sobre requisitos. Duas das principais suposições são que requisitos surgem continuamente e que – uma vez conhecidos – desaparecem com o tempo. Definir Product Backlogs antecipadamente contradiz ambas as suposições. Além disso, isso leva equipes e organizações de volta a uma época em que soluções eram desenvolvidas que, no final, não atendiam às necessidades de negócio atuais. Esta abordagem geralmente existe quando a introdução do Agile é feita de forma escalonada, começando pelos desenvolvedores e depois incluindo os Business Analysts etc. Entre os grupos que internalizaram o Agile e aqueles que não o fizeram, frequentemente surge atrito adicional, que muitas vezes é atribuído aos métodos ágeis, dificultando assim mudanças posteriores.

Testar depois que o desenvolvimento está "done":

Uma das formas híbridas mais perigosas do Agile é testar após o desenvolvimento concluído. Já conheci essa forma híbrida pelo nome de "Desenvolvimento + 1 Sprint". Neste cenário, uma equipe desenvolve uma solução (código funcional no caso de um problema de software), demonstra aos clientes, afirma que está "done" e ENTÃO passa para os testadores. Testadores SEMPRE encontram algo. Por isso, o software é devolvido para ser trabalhado diretamente (o que interrompe o sprint atual) ou para ser movido para o backlog para ser tratado mais tarde. Os princípios ágeis apoiam a conclusão de software entregável (ou pelo menos potencialmente entregável) ao final de cada sprint. Entregável significa TESTADO. Duas variantes menos dramáticas deste problema são o uso de Hardening Sprints e testar apenas no final de um projeto. Pelo menos nesses casos não se afirma ser ágil.

Conclusão sobre agile e cascata

A forma como as pessoas trabalham é o único indicador seguro de se uma organização é ágil ou não. Às vezes, a forma de trabalhar dessas pessoas reflete uma mudança para o Agile – no entanto, presumo que logo ficarão estagnadas se essa mudança não for realizada com grande empenho. Quando uma equipe ou organização quer adotar o Agile, escolhe-se um projeto e faz-se com que todos os envolvidos nesse projeto trabalhem com Agile simultaneamente e durante todo o fluxo de trabalho. Se isso significa que é preciso fazer coaching de um projeto inteiro ou de uma equipe inteira, então é assim que deve ser. Esta abordagem pode ser bem comparada a uma cebola que se corta em fatias, alcançando cada camada individual da cebola a cada corte, em vez de descascar camada por camada.

Uma última observação: Mesmo que se chegue aos limites com essas abordagens híbridas em algum momento, elas provavelmente ainda são melhores que o(s) método(s) usado(s) anteriormente. Isto não pretende ser uma acusação às pessoas que têm dificuldades em mudar para o Agile. É antes um incentivo para que continuem em frente.

Este texto é do blog SPamCAST e foi traduzido por nós para o alemão.