Cada vez mais em times Agile (principalmente Scrum), tem se seguido a pratica de um ou mais times que tem como foco trabalho “front end” serem alocados no que vem sendo chamado de “um sprint a frente” (“one sprint ahead”). A principal argumentação é manter uma integridade maior da experiencia de usuário que ó pode ser alcançada dando-se aos designers tempo de antever o que esta no backlog e tomar decisões a respeito, preparando o campo para quem for desenvolver as features em questao.

Exemplos fortes desta opinião podem ser observados em vários dos casos apontados no artigo Agile Usability: Best Practices for User Experience on Agile Development Projects da Nielsen Norman Group.

Particularmente considero a principal argumentação desta pratica uma falacia, claramente vinculável com o pensamento tipico dos times waterfall. A justificativa é exatamente a mesma, uma determinada função responsável por parte do trabalho criativo considera que para manter um conceito único e apropriado de seu trabalho, é necessário que se pense (pouco ou muito) antes de executar. A pratica vem sendo engolida justamente porque como é “apenas” um sprint, o impacto parece minimizado, mas na verdade o impacto é absolutamente o mesmo: um time começa a determinar como as coisas serão, com base em teorias soltas que refletem muito pouco das capacidades da empresa em responder ao que se espera, alem disso, esta pratica vai em detrimento da propriedade geral sobre o projeto, inibindo os membros dos demais times a fazer qualquer critica que pode ser pertinente, pois a pratica dá ao primeiro time uma propriedade maior sobre as escolhas.

Esta pratica acaba por coibir a melhor participação dos demais membros do time e é evidente que certas decisões tomadas pelo time de designers tendem a fugir da realidade e da capacidade dos desenvolvedores.

Dudu Pontes (que é Product Owner na Globo.com), aponta ainda a possibilidade sempre presente do projeto ser congelado ou concluído, ou mesmo ocorrer uma mudança drástica nas prioridades e conseqüentemente no backlog, o que invalidaria ou inutilizaria o trabalho previamente realizado pelos membros do time de UX.

Um time agile precisa estar preparado para responder a mudanças no ambiente… Concorrentes lançam produtos novos, o interesse do cliente diminui ou os objetivos dos Stakeholders precisam ser alterados. Qualquer mudança deste tipo tende a alterar os rumos seguidos pelo time e um time agile abraça este tipo de mudança. No caso de times onde praticas de trabalho de “planejamento” acontecendo em paralelo ao trabalho de desenvolvimento, o trabalho feito “a frente” é perdido em qualquer mudança de rumos.

A argumentação de que um time precisa de trabalho de planejamento de UX de antemão ao trabalho de desenvolvimento é uma prova forte da má compreensão da proposta agile e dos valores a serem considerados. Empresas que consideram esta pratica normal, provavelmente não acreditam realmente na premissa de que é mais importante software rodando e interações entre indivíduos sobre qualquer processo.

Desenvolvedores que defendem waterfall alegam exatamente a mesma coisa, que precisam de planejamento “up front” para manter uma arquitetura apropriada. Este tipo de argumento é uma falacia, nada garante que o tempo gasto vá gerar uma arquitetura mais solida e a experiencia tem mostrado que é exatamente o oposto, o que é gerado é um sistema com varias features inúteis e que não responde a expectativa do publico/cliente. O fato de que o trabalho em questão esta “apenas” um sprint a frente é apenas um detalhe, poderíamos dizer que neste caso não é bem um waterfaal e talvez seja um mini-waterfall (com quase nenhuma vantagem que o watterfall poderia trazer e com vários problemas novos).

Times comprometidos em entender os problemas do cliente e a realidade do mercado, se envolvem com o processo e ajudam a construir uma visão clara do projeto. Para facilitar este tipo de situação, alguns times abraçam praticas como Metáforas da XP, de forma a ter alguma abstração que permita verificar desvios no projeto geral, mas mesmo sem este tipo de pratica, a maioria consegue obter bons resultados dependendo exclusivamente do que se pretende e da transparência e sinceridade dos envolvidos. Em um time ágil que esta realmente comprometido, as demandas de UX são incorporadas como praticas do dia a dia e critérios de aceitação, manter o nível esperado para a UX torna-se parte da avaliação de qualidade do time.

Qualquer esforço de deslocar membros dos times para trabalhos paralelos é altamente nocivo. Pouco interessa se os envolvidos são desenvolvedores, designers, gerentes ou o que for, todos precisam estar envolvidos diretamente com o que se pretende entregar. As decisões, sejam elas de origem gerencial ou criativa, devem ser tomadas junto com os envolvidos de forma que todos possam entender os efeitos e intervir com observações que possam ser pertinentes. Qualquer coisa diferente disso ainda é o mesmo que sempre tivemos, projetos sendo administrados por profissionais que acham que tem a capacidade de prever o futuro, que supõe que seu trabalho é mais importante que o dos demais e que normalmente conhecem muito pouco do dia a dia da criação e desenvolvimento agindo sempre por traz de praticas e processos que lhes defendem da responsabilidade que lhes deveria ser legada.