O Scrum define que há três papéis dentro do Time Scrum: Product Owner, Scrum Master e Time de Desenvolvimento. Há muita bibliografia explicando os dois primeiros, porém quase não ouvimos sobre o último.
Experimente ouvir o artigo sobre Time de Desenvolvimento do Scrum!
O que é o Time de Desenvolvimento?
De acordo com o Guia do Scrum, são todas as pessoas necessárias para fazer com que um item do backlog do produto se transforme em um incremento do produto potencialmente entregável. De forma bem assertiva, são elas que fazem a coisa acontecer. Se não tivermos um bom Time de Desenvolvimento que construa o produto, pouco importa se temos os melhores Product Owners e Scrum Masters.
As características do Time de Desenvolvimento
Ele deve ser:
- multidisciplinar;
- auto-organizado;
- autogerido;
- autônomo;
- comprometido;
- focado;
- incansável na busca de melhorar a sua forma de trabalho e seus resultados.
São características fáceis de falar, difíceis de fazer. Vamos olhar cada uma delas.
Multidisciplinar
O Time de Desenvolvimento possui todas as habilidades necessárias para executar o fluxo de trabalho de ponta a ponta. Desde a formulação das hipóteses de solução de um problema de negócio até a entrega ao consumidor final e coleta de resultados.
Se você trabalha em uma pequena ou média empresa, criar um time multidisciplinar é relativamente mais fácil. Já se você está em uma grande empresa, provavelmente está em um cenário em que já se formaram com grandes verticais de especialização.
Exemplo de Hierarquia de especialistas em grandes empresas.
Com a especialização vem a gerência dos especialistas, o forte controle do custo de operação e a coordenação dos “recursos” (Veja o texto do Rodrigo de Toledo sobre Humanos sim, Recursos não!). Isso dificulta bastante ter um time realmente multidisciplinar, pois agora é necessário fazer política.
Quando a equipe não é multidisciplinar começa a ter handoffs (passagens de bastão) para pessoas externas. Isso diminui a eficiência e cria o espírito de nós vs. eles: “já passei a bola, agora é contigo”.
Gosto de trazer transparência sobre as perdas que temos com os handoffs externos. Primeiro ponto é deixar claro no Quadro de Tarefas quando eles acontecem.
Além disso, o uso de métricas é fundamental para aumentar a transparência. A mais interessante é o Customer Lead Time que é o tempo decorrido desde que o Time de Desenvolvimento se compromete com um item do backlog até sua entrega para o consumidor final. E também o Local Lead Time (Cycle Time) que é o tempo entre quaisquer etapas dentro do fluxo.
Com isso, o time terá o tempo que o item de valor fica na responsabilidade dele e quanto tempo o item fica com os times externos. Conheça mais sobre métricas no treinamento Métricas Ágeis.
Quadro de tarefas do time. As colunas em vermelho são os handoffs externos. Difíceis de controlar, praticamente impossível prever quanto tempo as coisas durarão ali.
Outra métrica importante que não costuma aparecer quando falamos de Agilidade é o custo do time. É importante sabermos esse número para justificar a vinda de uma pessoa ou o investimento que teremos que fazer para que algum membro adquira a capacidade que ainda não está contida no time.
Essas foram três métricas de eficiência. É fundamental ter a eficácia do time, caso contrário ele será visto apenas como custo e empresas adoram cortar custos. A próxima pergunta é quanto esse time vale? Quanto a empresa ganha com as entregas que ele faz? Existem diversas métricas de eficácia que podem ser usadas aqui: faturamento, churn, satisfação do cliente, retenção, aquisição de clientes, Retorno sobre o Investimento, etc. (Veja o artigo Métricas – Como medir a agilidade do seu time).
Uma que eu recomendo e ainda quero explicar neste blog é o Custo do Retardo (Cost of Delay). #FicaDica para pesquisar na internet. Fazendo uma explicação bem sucinta: é quanto dinheiro eu deixo de ganhar por retardar a entrega de um produto ou incremento de produto. Essa métrica considera possíveis concorrentes entrando no mercado e eventos sazonais.
Munido dessas informações, o time pode buscar mais investimentos. Não vá discutir com gestores e diretores sem dados e fatos!
Imagem do filme Os Intocáveis (1987) em que o personagem Malone (Sean Connery) fala com um matador: Isn’t that just like a (pejorative slur)? Brings a knife to a gun fight.
Auto-organizado
No Guia do Scrum está escrito que NINGUÉM fora do Time de Desenvolvimento deve dizer a ele como realizar o desenvolvimento. Nem Scrum Master, nem gerentes. O Product Owner diz o que será feito. O como depende do Time de Desenvolvimento.
Todavia é comum vermos times que perguntam para pessoas em posição de liderança como eles farão o desenvolvimento, quais tarefas devem ser executadas ou quais pessoas devem fazê-las.
A origem desse problema pode estar no modelo de ensino que perdura até hoje. Desde criança, temos a figura de uma pessoa que determina o rumo das pessoas. A relação professor-aluno que vem do modo fordista (Veja o vídeo de Sugata Mitra sobre o assunto). Daí em diante, aprendemos que há um ser superior que é o “mais inteligente da sala” (professores, pais, gestores e líderes) e que devemos seguí-los.
A auto-organização quebra esse paradigma. A partir de agora, o Time é a pessoa mais inteligente da sala. Essa quebra depende muito da maturidade tanto dos líderes quanto dos liderados.
Se você for um líder, toda vez que for acionado para tomar uma decisão ou responder uma pergunta que o time tem capacidade para resolver, uma sirene tem que tocar na sua cabeça. Antes de realizar alguma ação, a primeira pergunta que você deveria fazer é: “O que estou fazendo de errado que o time ainda precisa de mim para tomar essa decisão?” Em seguida, as perguntas que geram ação: “Como eu faço para que o meu time não dependa de mim para isso?”, “Como eu faço para não ser copiado em todos os e-mails (insegurança)?”, “Como eu faço para não participar de reuniões que não dependem de mim?”
Se você for do Time de Desenvolvimento, as perguntas inversas podem ser feitas: “Precisamos que as pessoas mais caras da empresa ($$$) estejam presentes para tomar essa decisão ou responder esse questionamento?”, “Vale a pena entupir a caixa de e-mail do líder com qualquer coisa?”
Infelizmente, há gestores que ainda acreditam no modelo retrógrado de gestão e acham que se não falarem exatamente como as coisas devem ser feitas, elas perderão o “controle”. Se você está nessa situação, sinto dizer, mas quando falamos de trabalhadores do conhecimento, trabalho criativo e sistemas complexos (papo longo, talvez em outro artigo), o “controle” já está perdido. Gosto muito da frase que Peter Senge escreveu no livro A Quinta Disciplina (1985): “Você contrata as pessoas pelo que elas têm do pescoço para cima e não do pescoço para baixo”.
Autogerenciamento
Há times que pedem licença antes de fazer algo ou benção após fazer alguma coisa para pessoas em posição de liderança. Em um Time de Desenvolvimento maduro, espera-se que eles não só saibam se organizar como também saibam se gerenciar. O Time de Desenvolvimento deve ser capaz de decidir quem deve ser contratado ou demitido, quais treinamentos os membros farão, se o trabalho é remoto ou colocado, horário das reuniões, participação de eventos, entre outras atribuições gerenciais.
Essa é uma característica particularmente difícil para algumas empresas, pois há leis e processos que muitas vezes bloqueiam a autogestão. Nesses casos, é importante descobrir até que ponto o Time pode ir. Por exemplo: eles podem decidir os horários das cerimônias do Scrum, mas demissão e contratação dependem da unidade de RH (confira artigos sobre RH Ágil e conheça o treinamento!). Qual o nível de autonomia?
Autonomia
O Time de Desenvolvimento deve ter autonomia para tomar as decisões necessárias para executar o trabalho. Quais ferramentas eles vão utilizar, autorizações, atividades administrativas, quais os conhecimentos necessários, etc.
Uma ferramenta que é muito interessante para determinar o nível de autonomia do time e dar transparência é o Quadro de Delegação (Delegation Board). Resumindo, é um quadro em que o Time Scrum e gestores podem definir qual o nível de autonomia para cada tipo de decisão. Os níveis vão de 1 (o gestor decide) até 7 (Delegação total). Na versão mais recente, de 1 até 5.
Comprometido
Compromisso com o incremento do produto, comprometido em resolver o problema do cliente, comprometido com os resultados do negócio e principalmente comprometido com o Time Scrum. Se não há comprometimento com essas coisas, não temos um time, apenas um grupo de pessoas que por sorte podem entregar alguma coisa.
Além disso, não há sub times dentro de um Time de Desenvolvimento. Não podemos cair na discussão do tipo: “eu já fiz a minha parte”. O sucesso depende do trabalho de todos. Já o fracasso é compartilhado por todos.
Focado
Foco na entrega. Se o Time é comprometido, deve estar muito claro o objetivo que ele quer alcançar. Para quais métricas de eficácia ele vai utilizar para saber se está no rumo certo.
Atenção com a transparência. Não podemos ter trabalho invisível sendo executado durante o desenvolvimento. Se alguns membros do time estão fazendo outras atividades que não estão relacionadas à construção e entrega do produto, temos que dar visibilidade a esse trabalho. Pode ser no Quadro de trabalho ou um quadro a parte. Meça o impacto causado por esse tipo de trabalho antes de tentar matá-lo (lembre-se da dica do Malone lá em cima).
Quadro do Time de Desenvolvimento de Software (SEDSIS) do Tribunal Regional Eleitoral do Rio de Janeiro. O quadro principal (realçado em verde) é o fluxo de trabalho de desenvolvimento do produto. O quadro ao menor ao lado (realçado em vermelho) dá visibilidade ao trabalho não relacionado à entrega de produtos.
Melhoria Contínua
Parar de melhorar é parar de evoluir. O Time de Desenvolvimento deve ser incansável para aperfeiçoar o seu trabalho. Melhoria em todas as direções: fluxo de trabalho, processos, ferramentas, formas de colaboração, procedimentos administrativos, etc. No Scrum temos um evento específico para isso, a retrospectiva. Importante ressaltar que qualquer momento é um momento de melhoria. Não precisa esperar a retrospectiva acontecer.
É fundamental que tenhamos uma cultura de experimentação. Não tente acertar tudo na primeira tentativa. Prever todas as possíveis consequências de um experimento leva ao trágico BDUF.
Tamanho do Time
O Time de Desenvolvimento deve ter um tamanho mínimo de três pessoas para que ele seja minimamente multidisciplinar e não tenhamos dependências externas que nos impossibilite de entregar o incremento do produto. Também não deve ser superior a nove pessoas, pois o custo de coordenar times grandes é muito alto. A Lei de Brooks sobre interconexões de canais de comunicação explica o porquê disso.
A Lei de Brooks em imagem. O número de nós representa a quantidade de pessoas do time e as arestas a quantidade de conexões (canais de comunicação).
Se você tem 11 pessoas (9 no Time de Desenvolvimento + Product Owner + Scrum Master), você tem no mínimo 55 canais de comunicação. Mais do que isso o custo de coordenação e o tempo para tomada de decisões fica muito alto.
São pessoas
Outra infelicidade foi que o mundo da gestão e gestão de projetos se acostumou a chamar as pessoas de recurso e recurso nos dá a impressão de objetos (Assista ao vídeo sobre Humanos Sim, Recursos Não!). Se quebrar, jogue fora e compre um novo. Se você está em um Time agora, olhe para ele. O que você faria se os seus melhores técnicos saíssem da empresa hoje. Treinar alguém novo?
Cadeiras, mesas, papel, lápis, telefones, computadores são recursos. Eles não precisam aprender e não evoluem com o tempo. Caso queira melhorá-los terá que comprar um novo. Pessoas são diferentes. Elas se aperfeiçoam com o tempo. Trabalhar em um ritmo sustentável, proporcionar um ambiente seguro, respeitar a diversidade transformará o seu time em um Time de Alta Performance.
Gostou desse artigo? Confira outros relacionados ao tema:
- Espiral positiva de times de alta performance
- Características de times de alta performance: Práticas
- Características de times de alta performance: Estruturas
- Características de times de alta performance: Valores
- A batalha das 5 disfunções de um time
- As disfunções do Time de Desenvolvimento – Parte 1
