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.

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 com Presidência, Assessoria; Diretoria de Operações, Departamento de Novos Negócios, Departamento de Produção, Departamento de Segurança; Diretoria de Marketing, , Departamento de Marketing Digital; , Departamento de Propaganda; Departamento de Planejamento; Diretoria de Logística, , Departamento de Transporte Aéreo, Departamento de Transporte Rodoviário, , Departamento de Grandes operações; Diretoria de Informática, Departamento de Desenvolvimento de Software, Departamento de Infraestrutura, , Departamento de Banco de Dados, , Departamento de Suporte

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 o time 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.

Exemplo de um Quadro de tarefas. Ele está dividido em 11 colunas. Backlog, Priorização limitada a 4 itens e com 4 itens nela. Experiência do cliente (externa ao time), sem limitação com 5 itens e um ponto de interrogação. Design de interface limitada a 2 itens com os 2 itens nela. Construção limitada a 3 itens com 3 itens nela. Testes (externa ao time) não limitada e com muitos itens e um ponto de interrogação. Preparar aprovação limitada a 3 itens e com 3 itens nela. Aprovação do Gestor (etapa externa) sem limitação e com muitos itens e um ponto de interrogação. Preparar para entrega limitada a 4 itens com 2 itens nela. Entrega (etapa externa) sem limite e sem nenhum item. Concluído com apenas um item. Importante ressaltar que no quadro como temos muitos handoffs externos, estamos entregando pouco. Muitos itens parados em times externos. Além disso na imagem temos a indicação do Customer Lead Time que começa na coluna priorizado e termina na coluna Concluída da entrega. Também temos o Local Lead Time para cada etapa.

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!

O personagem Malone, interpretado pelo Sean Connery no filme Os intocáveis de 1987, aparece com uma escopeta cano duplo serrado apontando para um inimigo (que não aparece na imagem) armado apenas com uma faca. Na imagem estão as palavras: Não leve uma faca para um tiroteio!

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 segui-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. 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) (Mais um artigo que temos que escrever 😊). 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.

Quadro de delegação onde as colunas são os níveis de delegação que vão de 1 até 7. As linhas são exemplos de processos que queremos avaliar o nível de delegação: Contratação, Demissão, Promoção, Escolha de Ferramentas e Treinamentos. Nas células temos post-its colados pelo time dizendo em que níveis estamos. Contratação - nível 3; Demissão - nível 1; Escolha de Ferramentas - Nível 5; Treinamentos - Nível 2. Também temos o desejo do time de sair do nível 1 de contratação para o nível 4.

Delegation Poker e Delegation Board do Management 3.0.

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.

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.

Adesivo da K21 com o Ciclo de Construção, Medição e Aprendizagem.

Ciclo de Experimentação. Serve para construção do produto e para melhoria do time.

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.

Fórmula da Lei de Brooks

Lei de Brooks onde I é a quantidade de conexões, e, no caso do Scrum, n é a quantidade de pessoas no Time Scrum e demais stakeholders.

4 pessoas =6 conexões; 5 pessoas = 10 conexões; 7 pessoas = 21 conexões.

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. 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?

Curva S em o eixo Y é aprendizagem e o Eixo X é a experiência (conhecimento).

Curva de aprendizagem (Learning). Para que um novo componente chegue ao nível mais básico do Time de Desenvolvimento. Levará tempo e experiência (Experience).

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.

Adesivo da K21 - Menos Recursos Mais Humanos. Um Smile cobrindo uma roldana. Temos que deixar de pensar em pessoas como recursos e começar a pensar em pessoas como pessoas.

Gostou desse artigo? Confira outros relacionados ao tema:

Participe dos nossos treinamentos de