Os entraves à implantação do modelo Agile

Muitas empresas, com o intuito de se tornarem mais adaptativas, apressaram-se a implementar o desenvolvimento de software Agile, porém grande parte delas acabou perdendo agilidade devido à forma de condução desse processo. O ganho de agilidade ocorreu apenas em teoria, já que, em muitos casos, o procedimento adotado afeta a motivação e a produtividade da engenharia de software.

Desenvolvimento de software Agile

Os frameworks de desenvolvimento de software adaptativo, tais como o modelo Agile, já existem há muito tempo em várias implementações. No entanto, a maioria deles gira em torno de dois conceitos centrais: a elaboração de hipóteses (p. ex., o propósito de determinada funcionalidade), e o trabalho colaborativo de todas as áreas de especialização na realização de práticas, sempre com o intuito de proporcionar o aprendizado sem trilhar caminhos que acabam por mostrar-se equivocados.

Quando surgiu o modelo Agile, em 2001, estruturaram-se quatro princípios básicos destinados a potencializar o desenvolvimento de software e aumentar a motivação dos gestores de desenvolvimento e produção:

Pessoas e interações acima de processos e ferramentas
A funcionalidade do software acima da amplitude da documentação
A colaboração com o cliente acima das negociações do contrato
A resposta às mudanças acima da observância do planejamento

Durante nossa pesquisa sobre motivação, nos últimos três anos, analisamos as atividades de desenvolvedores de mais de 500 empresas por meio de uma combinação de abordagens baseadas tanto em levantamentos quanto em experimentos. Constatamos uma enorme discrepância entre a prática e os princípios mencionados.

Por exemplo, no dia a dia, o trabalho está voltado a processos e ferramentas, em vez de pessoas e interações. Em uma grande empresa da lista Fortune 100, o chefe de produtos digitais revelou: “não temos permissão de questionar o processo Agile”. Já em outra, que figura na Fortune 500, os gerentes e técnicos de produtos só se comunicam por meio de ferramentas, utilizadas sobretudo para a transmissão de ordens de supervisores a subordinados.

Da mesma forma, costuma-se privilegiar a documentação em vez da funcionalidade do software. Em uma grande empresa de tecnologia, a equipe de produtos destinava muito tempo, logo de antemão, para escrever pequenos requisitos (denominados “relatos do usuário”), que eram ordenados em uma sequência de tarefas para o próximo desenvolvedor disponível. Os entraves à continuidade do trabalho atingiram tal proporção que o processo acabou por tornar-se mais uma das pequenas etapas de um “modelo em cascata”, no qual as tarefas passam do departamento de produtos para os designers e, por fim, para o desenvolvimento. A finalidade do Agile era justamente a eliminação de tal modelo. Assim sendo, não causou surpresa a afirmação do diretor técnico da própria empresa de que “meus desenvolvedores se sentem como cozinheiros de lanchonete”.

Já a prioridade da “resposta às mudanças em relação à observância do planejamento” é, com frequência, um conceito entendido com uma recomendação de simplesmente “não seguir uma programação prévia”. Por exemplo, em uma empresa de tecnologia em rápida ascensão, as equipes envolvidas com o modelo Agile não buscaram compreender a estratégia mais ampla da companhia, de forma que as iterações acabaram focadas em funcionalidades de baixo valor agregado ou sem importância. Sem um plano, não será possível nem priorizar as tarefas, nem nelas investir de maneira responsável. Com base no princípio em questão, os desenvolvedores chegaram até mesmo a pensar que não deve haver timeboxes e objetivos específicos a alcançar.

Se o emprego incorreto dos princípios acima discriminados acabasse gerando uma melhora da motivação e desempenho, seria até justificável. Entretanto, na prática, verificamos que ocorre o contrário. O modelo Agile, se aplicado conforme se descreveu, diminui o empenho em geral dos desenvolvedores, que, sem poderem experimentar, gerenciar o próprio trabalho e se conectar com o cliente, perdem grande parte da percepção do aspecto lúdico e do propósito de sua atividade, bem como do potencial. Pelo contrário, sentem a pressão emocional ou econômica pelo sucesso, ou uma inércia, por conseguinte, deixam de adaptar-se, de aprender, e de dar o melhor de si ao trabalho.

Por exemplo, um de nossos parceiros investidores falou-nos de uma empresa de desenvolvimento de jogos eletrônicos que, contra a opinião de todos os seus desenvolvedores de que determinado produto não gerava interesse, deu continuidade ao projeto por um ano, só então dando conta de que havia desperdiçado tempo e dinheiro.

Os processos Agile perdem a eficácia sempre que as empresas, ao almejar um alto rendimento, tornam-se ou táticas demais (com muita preocupação com processos e microgerenciamento) ou adaptativas em excesso (sem foco em metas de longo prazo, cronogramas ou colaboração multifuncional).

A solução é o equilíbrio entre o desempenho tático e o adaptativo. Tanto para desenvolvedores quanto para gerentes de produtos, seguem algumas sugestões de mudanças com vista a atingir esse objetivo, melhorar a motivação e o desempenho da equipe de desenvolvimento (ou de qualquer outra área).

O desenvolvimento de software deve ser um processo colaborativo, nunca baseado na simples transferência de tarefas.

Em vez de uma sequência de etapas estanques, em que alguém estabelece um requisito (ainda que de pequena importância) para outro executá-lo, sem um norteamento estratégico básico, a equipe realmente empenhada na busca da agilidade deve adotar um processo em que não haja meras “passagens de bastão” (os chamados handoffs), ou seja, em que os dois profissionais acima mencionados não atuem de maneira isolada. Assim sendo, o gerente de produtos e os desenvolvedores (bem como quaisquer outros envolvidos) são parceiros colaborativos, do início ao fim, no projeto de determinada funcionalidade.

Em primeiro lugar, a equipe, inclusive os gestores, delineiam os “desafios” estratégicos, na forma de perguntas, sempre visando à geração de melhores resultados para o cliente. Pode-se dizer que se trata de uma descrição pormenorizada da missão da equipe, na forma interrogativa, visando a desencadear uma reflexão mais ampla. Os desafios são desenvolvidos e reanalisados pela equipe em conjunto, que inclui clientes e investidores, sendo que qualquer membro dela (bem como de outra) poderá dar ideias com relação a cada um dos pontos definidos, sempre que quiser.

Por exemplo, em um banco, um dos desafios era: “como podemos ajudar o cliente a prepara-se para eventuais choques financeiros?”. Outro era: “como tornar mais agradável e menos entediante para o cliente a manutenção de hábitos financeiros prudentes?”. A partir daí, surgiram dezenas de ideias vindas oferecidas por muitas pessoas com perfis bem distintos.

Com isso, em vez de alguém elaborar os requisitos a serem cumpridos por outro, a equipe desenvolve e amadurece uma ideia de forma colaborativa, do esboço à formulação de conclusões sólidas.

A equipe deve ter, como parâmetro de resultados, a prática baseada em critérios mínimos de viabilidade

Para muitas equipes, perde-se tempo com o excesso de adequações. Para que isso não aconteça, devem-se não só formular as ideias para determinado desafio estratégico, mas também testá-las na prática, por meio de breves experimentos, com o único propósito de descobrir o que produz bons resultados para o cliente. Ou seja, deve-se otimizar a buscar “saber a verdade” o mais rápido possível.

Para evitar o trabalho perdido e ampliar o direito decisório da equipe, esses testes deverão ser de curta duração, sem exceder uma semana, se possível.

Ocasionalmente, esse prazo exige que se reduza determinada funcionalidade ao mínimo necessário para pôr à prova sua premissa menos sólida. Outras vezes, nem se chega à codificação, mas realiza-se um experimento “offline” por meio de pesquisas.

A abordagem da equipe deve ser voltada ao cliente.

O desenvolvimento de software (mesmo para uso interno) deve, sem a menor sombra de dúvida, centrar-se no cliente.

Nesse sentido, os princípios básicos são:

Os “desafios” sempre se definem em termos de impacto para o cliente.
As reuniões para resolução de problemas sempre começam com últimas informações a respeito do cliente, e, em muitos casos, os representantes da linha de frente participam dessas tais discussões.
Todo experimento gira em torno de uma hipótese relacionada ao cliente. Assim, a equipe tem condições de assumir a responsabilidade quanto ao resultado esperado.

Entretanto, é mais importante ainda que os desenvolvedores observem com os próprios olhos como o cliente utiliza o produto, o que exige que a linha de frente trabalhe diretamente com esses profissionais, para garantir que o produto esteja gerando impacto para o usuário.

Devem-se utilizar timeboxes para direcionar a experimentação e evitar desperdícios.

Curiosamente, o desenvolvimento de software adaptativo propicia a utilização das timebox com vista a garantir o investimento adequado a cada experimento e indicar o nível aceitável de qualidade das funcionalidades. Por outro lado, a maioria dos profissionais do modelo Agile evita cronogramas e prazos, que podem dar ensejo a pressões emocionais. Para os desenvolvedores, uma das piores sensações é a de ter-se dedicado por meses a algo que veio a ser inútil, resultando nesse sentimento (“Decepcionei todo o mundo”), além de uma impressão de inércia (“Estou fazendo isso para quê?”).

É por isso que é fundamental deixar claro até que ponto o desenvolvedor deve seguir em frente sem a certeza de estar na direção certa. Quanto mais dúvidas a respeito da hipótese da equipe e maior o risco, menor o espaço de exploração de possibilidades. Nesse sentido, as timeboxes não representam prazos, mas limites destinados a orientar o nível de profundidade e a qualidade do experimento antes de um teste efetivo, servindo como meio de estimular a motivação em geral.

A organização da equipe deve propiciar a colaboração

Para garantir que o processo não tenha handoff e estimular a colaboração, todas as partes interessadas deverão agir como uma única equipe multifuncional, também conhecida como pod, ou célula, cada uma das quais deve contar com a participação de todos os especialistas necessários para desenvolver um produto de grande qualidade, inclusive diretores executivos. Por exemplo, pode haver um gerente de projetos, um desenvolvedor do lado do cliente (front-end), um do lado do servidor (back-end), um designer, um engenheiro de qualidade, representantes do atendimento ao cliente e um diretor.

Em muitas empresas, há claros sinais da existência de “pseudocélulas” — equipes que se autodenominam células mas na verdade não trabalham como deveriam, entre os quais:

Os especialistas estão alocados em equipes diferentes, mas “alinhadas”, por exemplo, uma equipe de produtos tem desenvolvedores dedicados exclusivamente aos “ciclos sprint”. Isso não é uma célula.
Utilizam-se recursos que impedem a colaboração efetiva. Por exemplo, questionada por que havia escolhido as ferramentas de software Agile em questão, uma equipe de desenvolvimento respondeu: “com elas os executivos não poderão envolver-se com trabalho.” Isso só perpetua um ciclo de desconfiança.
As metas das funções desenvolvimento e de produto não são as mesmas que as dos níveis hierárquicos mais elevados. Os executivos dessas áreas utilizam-se do poder do cargo para que os subordinados priorizem os objetivos da função, em detrimento de todos os outros, inclusive os da própria célula. Esses conflitos acarretam desavenças entre as equipes de trabalho, o que impede cooperação legítima.
A gestão de talentos baseada em processos com forte ênfase na hierarquia, tais como avaliações de desempenho, títulos de cargo, pressão por promoções, e sistemas “ou sobe ou cai fora” (up-or-out) impede a cooperação essencial para o bom funcionamento das células. Com isso, os membros da equipe ou se comprometem mais com o chefe do que com o próprio cliente, ou se tornam concorrentes. Qualquer que seja o caso, não funcionam como um time.

Posto de outra forma, quanto mais a empresa operar com base em “cercados” isolados uns dos outros, mais pessoas cuidarão das necessidades de seu próprio canto, em vez de atender às da equipe, dificulta muito a colaboração e o consenso sem apelos constantes aos níveis hierárquicos mais altos.

A equipe deve questionar o processo de trabalho de maneira contínua.

Uma das grandes máximas da área de engineering design é conhecida como Lei de Conway, segundo a qual “a estrutura do projeto de qualquer sistema é inevitavelmente uma cópia da estrutura de comunicação da empresa que o realizou”. Em outras palavras, se a companhia é monolítica, assim será o projeto. Se estiver organizada por segmentos de usuários, seu produto será otimizado dessa forma.

Para desmentir a Lei de Conway, a melhor estratégia é a busca constante de uma adequação, ao problema do momento, tanto da estrutura quanto dos processos para se adequar ao problema em questão, que deverão, portanto, ser simples e enxutos, para que as equipes possam sempre questioná-los e aprimorá-los.

Assim sendo, em contraponto ao conceito de “Agile” como uma religião inquestionável, as equipes técnicas devem estar habituadas ao diagnóstico e à iteração contínua do próprio modelo operacional. Conforme observamos todo mês melhores exemplos, após esses procedimentos, decide-se se há necessidade de alterações para alcançar um produto melhor.

Na área de produtos digitais, a capacidade de atrair, inspirar e reter talentos vem-se tornando um fator crítico para as empresas. A maior parte delas foi vítima de uma mensagem simplista: a implantação do modelo Agile como uma série de cerimônias e melhoras em todos os sentidos. Infelizmente, isso não costuma ocorrer quando se desconsidera o fator humano. Com o retorno aos princípios básicos da motivação e do desempenho adaptativo, é possível criar uma empresa verdadeiramente ágil.

Por Lindsay McGregor e Neel Doshi