Time disfuncional

O Scrum e qualquer outro método/framework agile é feito para que a equipe consiga se organizar e ter autonomia para tomar todas as decisões importantes, definindo como irão agir para entregar suas tarefas e conseguir completar os objetivos do projeto. Um dos pontos chave para isso tudo dar certo é a comunicação entre os integrantes do time.

_Pense no seu trabalho. Quanto tempo é desperdiçado enquanto você espera alguém concluir uma tarefa, ou receber alguma informação, ou porque está tentando fazer um monte de coisas ao mesmo tempo? Talvez você prefira trabalhar o dia todo - quanto a mim, eu prefiro surfar. _ Jeff Sutherland, Scrum: A Arte de fazer o dobro do trabalho na metade do tempo.

Um time Agile, geralmente, deve ser multifuncional, possuindo todas as habilidades necessárias para entregar o produto, dependendo o mínimo de terceiros. Não dá para ter meio time multifuncional. Ou ele tem todo o poder, ou não tem. Ou ele tem todas as especialidades trabalhando em conjunto, ou não tem. Eu fazia parte de um time onde o UX trabalhava todos os dias focado no nosso projeto. Para as pessoas de fora, ele era o responsável pelo UX daquele produto. Mas para o time (desenvolvedores, coordenador, P.O.) ele era alguém de passagem, que estava ali para executar um trabalho temporário. Ele também se sentia assim, tanto que nem sentava com o time do produto. Ali não era a sua tribo e ele considerava que o silo de UX era o verdadeiro time dele.

Se ele fazia parte de um silo, você já deve imaginar, que esse não era um problema do time que eu trabalhava, mas de todos os que precisavam de um UX. Se existe um silo, seja ele de Front-end

• design, QA, Operações etc etc etc, é muito difícil que um integrante desse silo se sinta parte do projeto. É muito difícil que ele compartilhe os objetivos que o time tem com o produto. O ciclo se quebra. A comunicação não acontece. Isso nunca será um time multifuncional.

Por causa desse formato disfuncional, vários problemas aconteciam. Por exemplo: uma parte do trabalho de UX é criar especificações para que o usuário use bem o produto. Os desenvolvedores só entravam em contato com essas especificações de UX no momento da implementação. Nem preciso dizer que isso era um desastre. Muitas vezes a especificação não poderia ser executada por causa de limitações técnicas, outras vezes a especificação era modificada durante a Sprint e o time herdava os imprevistos, atrasando as entregas, refazendo muito código, perdendo muito tempo. Esse é um problema gigante de comunicação, que não aconteceria se o time fosse multifuncional de verdade, trabalhando juntos num mesmo objetivo.

Se você gera retrabalho e não acerta o alvo nas primeiras vezes, você investe esforço sem obter qualquer resultado positivo. Se o UX, por exemplo, não está em contato constante com o time de desenvolvimento, validando seu protótipo, suas ideias, fluxo e interações, a equipe fica mais lerda. Não há a saturação boa de informação fluindo por todo o time.

Quanto maior a saturação de comunicação - quanto mais todos sabem de tudo -, mais rápida é a equipe. - Jeff Sutherland

Sim, o UX, QA, Ops

• front-end ou qualquer outro integrante de silo pode até participar das dailies e de outras cerimonias como Retrospectivas, Sprint Reviews e etc com o intuito de diminuir o bloqueio e melhorar a transparência do trabalho… Mas se eles não trabalharem de verdade com e para o produto, juntamente com o resto do time, a comunicação não vai fluir e o time não vai se sentir um time de verdade. Sempre vai parecer que algo está faltando e aquele sentimento de equipe nunca vai existir. Se existir, com certeza o integrante do silo não vai fazer parte dessa equipe.

Eu não vejo solução para este problema a não ser transformar o time em um time realmente multifuncional. Trazendo TODAS as especialidades para dentro do time, para que esse seja totalmente comprometido com o objetivo e a missão do time. Isso um trabalho árduo, sem graça, necessário e recompensador.