Eu não tenho dúvidas que um dos maiores desafios ao se tentar implantar métodos ágeis em um projeto de software é o de criar o denominado “self-managed team”, ou time auto-gerenciado. Essa abordagem de gerenciamento pressupõe que o próprio time de projeto assuma a responsabilidade de auto-organização, auto-melhoramento e observância voraz no cumprimento das metas. Organizar a equipe, distribuir as tarefas, melhorar o processo de trabalho não é mais papel do Gerente de Projeto, é responsabilidade da própria equipe. Isso dá uma guinada de 180º naquilo que todos nós estamos acostumados desde que conseguimos nosso primeiro emprego há muitos anos atrás. Alguém sempre nos disse o quê fazer! E agora?
O melhor texto que eu encontrei sobre esse assunto foi no livro do casal Mary/Tom Poppendieck – Implementing Lean Software Development From Concept to Cash (2006). O texto deles entra diretamente no cerne da questão, estabelecendo inclusive uma ótima metáfora que ajuda a entender como deve ser a dinâmica de trabalho em um projeto de software. Segundo os autores, a dinâmica em um projeto de software é bem semelhante àquela demonstrada em um barco a remo (desses de competição). Todos têm que estar sintonizados, com um olho no seu remo e o outro no ritmo do time. Um remador desconectado de seu time pode colocar tudo a perder (a metáfora também explora muito bem as questões e o papel da liderança nesse contexto. Se você tiver o livro, dê uma olhada que vale a pena. Isso está no Cap. 6 – People).
Mas... como o próprio livro sugere, isso não é fácil. Estamos falando de mudança cultural e esse tipo de mudança é invariavelmente traumática. Veja um cenário muito comum (não me espantaria se fosse a minha ou a sua realidade nua e crua):
“I tried the team approach, but I can't get the team to take the iteration goals seriously. They punch the clock and go home at the end of the day. At the end of an iteration, the work the team supposedly committed to is not done, and no one really cares.”
O fato é que identificar se você participa apenas de um grupo de desenvolvedores ou de um verdadeiro time de produto é o início da descoberta do que ainda falta percorrer nessa questão para melhorar seu projeto. Abaixo eu elenquei uma lista de comportamentos que, a meu ver, definem claramente que aspectos levam uma equipe para um lado ou para o outro. Quanto mais do lado direito você se enquadrar, maior será a capacidade de self-management da sua equipe.
| Aspecto | Grupo de Devs | Time de Produto |
| Cumprimento das Metas | > Metas individuais são perseguidas. A meta coletiva é secundária. > O interesse sobre a evolução da equipe em direção à meta só aparece no stand-up. > O não cumprimento da meta da equipe não leva a nenhuma frustração, especialmente se as tarefas individuais forem feitas no prazo. A iteração se arrasta por mais um ou dois dias, ou, o que não foi feito é jogado para a próxima iteração. > Nenhum esforço adicional é feito no sentido de se aproximar mais da meta. Equipe apática e fisiológica. | > A meta do time é perseguida. Metas individuais são secundárias quando a meta da equipe está em jogo. > Há interesse constante sobre o andamento do trabalho da equipe.
> Há um grande sentimento de frustração quando a meta não é alcançada e de grande empolgação quando é. > Se há risco de não cumprimento da meta da equipe, a própria equipe se organiza e conduz um esforço extra. Equipe motivada e energizada. |
| Atribuição de Tarefas | Um gerente atribui tarefas à equipe | Os próprios membros da equipe se organizam para resolver as tarefas de forma a se chegar mais rápido à meta da iteração. |
| Resultado | Features – muitas vezes desconexas umas das outras - são entregues | Uma solução coerente com a necessidade do cliente é entregue |
| Compromisso e Participação | > A participação de cada membro da equipe está vinculada unicamente ao cumprimento das tarefas que lhe foram alocadas > Não há participação de todos no fechamento e entrega do produto. Normalmente, o último que ficou com alguma pendência assume o ônus da entrega. | > A participação de cada membro da equipe está associada ao atingimento da meta independendo da finalização das tarefas que ele está executando. Se o membro da equipe termina o que está fazendo, imediatamente procura uma maneira de ajudar o time a alcançar a meta. > A equipe começa a trabalhar junta e termina de trabalhar junta no mesmo produto. |
| Review | Features são revisadas pelo Gerente | Features são revisadas por outros membros da equipe |
| Conhecimento | Cada um conhece muito aquilo que fez e pouco (ou nada) daquilo que os outros fizeram. | Todos conhecem um pouco de tudo. |
| Comunicação | O desenvolvedor avisa ao gerente que acabou uma tarefa. O desenvolvedor não relata a ninguém que vai começar uma nova tarefa. | O desenvolvedor comunica à equipe que concluiu uma tarefa. O desenvolvedor deixa claro para a equipe que está iniciando uma nova tarefa, mas antes disso, verifica se não pode ajudar alguém que está tendo dificuldade em finalizar a sua. |
| Delivery | Alguém apresenta as features desenvolvidas (normalmente um líder técnico ou gerente) para o cliente. | A equipe toda apresenta a solução desenvolvida para o cliente. |
| Auto-Improvement | Um líder técnico ou gerente define e cria melhoria contínua no processo. | O próprio time define o melhor processo para executar o seu trabalho. |