No artigo Quem é o Time de Desenvolvimento do Scrum, escrevemos sobre as características deste importantíssimo papel. Neste artigo trataremos as disfunções mais comuns que ele pode enfrentar.
Ouça agora o conteúdo sobre disfunções no time de desenvolvimento!
Squad
Antes de entrarmos nesse assunto, deixo claro que não tenho nada contra o nome Squad. Quando a empresa está fazendo uma transformação organizacional, vão existir momentos em que queremos marcar um ponto de ruptura com o status quo. A troca de títulos pode ser uma boa forma de fazer essa marcação. O problema é como algumas empresas têm utilizado o título.
Trazendo um pouco de história. Em 2014, Henrik Kniberg apresentou a forma como alguns times de desenvolvimento trabalhavam no Spotify (serviço de streaming de música – veja os artigos originais aqui e aqui). Muitas empresas gostaram da ideia e começaram a implantar o “Modelo” Spotify. Coloco o termo entre aspas porque o próprio Henry, em 2015, já falou em outra ocasião, aparentemente menos famosa, que não há um Modelo Spotify (veja esse vídeo aqui, próximo ao minuto 45).
Nos artigos originais, ele conta a forma que eles trabalhavam e os anos de experimentos que eles passaram até chegar naquele estado.
Isso não impediu que várias empresas ignorassem os anos de experimentos, falhas e acertos e começassem a “instalar” o tal “modelo”. Do dia para a noite, os nomes dos times, unidades de negócio ou departamentos passaram a ser Squads. Como um passe de mágica, ao chamar um grupo de pessoas de Squad, todos os problemas se resolvem e passamos a ser ágeis.
Não funciona assim. Um grupo de pessoas incapazes de construir um produto de ponta a ponta permanece nessa situação, independente do nome. Para criarmos um time realmente multidisciplinar são necessários ações firmes, objetivos claros e muito trabalho.
João, o especialista imortal
Durante muitos anos nos acostumamos a ter pessoas ultra especialistas em um determinado assunto. Muitas das vezes, quando formamos um Time de Desenvolvimento, mantemos essa estrutura de alta especialização dentro do time.
Vou dar um exemplo e gostaria de chamar nosso especialista de João. Talvez você se identifique com ele ou conhece alguém parecido com o personagem desta história.
O time está na mão do João, o especialista. Se ele está lá as coisas andam, se não está, nada anda. Inicialmente João fica feliz, pois ele é o Herói do Time.
Só que nem tudo são maravilhas na vida do João. A caminho das tão sonhadas férias no Caribe, o telefone toca. É o time que depende do João e tem que tirar umas 2 horas de dúvida sobre um “probleminha”. João desembarca em Miami, conecta no wifi e recebe 265 mensagens que ele tem que responder porque o time depende dele. Enquanto aguarda conexão para as Bahamas, João responde todas as mensagens. Chegando em Bahamas, conecta no Wifi novamente para ver a direção do hotel e agora ele possui 367 novas mensagens porque ao tentar consertar o “probleminha” o time criou um problemão.
João tenta desesperadamente responder cada mensagem, mas recebe uma ligação do chefe: “João, você tá com seu notebook. Acessa aí a nossa rede para ver o relatório XYZ, o pessoal não sabe gerar”. Desesperado, João tenta achar o notebook no meio das malas e confusão de saída de aeroporto.
A esposa do João o vê abrindo o notebook e já dá aquela olhada fulminante para ele. O filho mais novo está vomitando no pé de uma senhora que está gritando palavras que nem João entende e a filha mais velha já está quase chegando ao portão de saída. João sabe que as férias acabaram (bem, nem começaram na verdade).
Pânico total, João grita com o chefe para sair da porta, fala Sorry, Sorry para a filha, entrega o relatório para a esposa e nem lembra que tem um filho. João tem um infarto e morre.
Só que a empresa não pode parar e João é fundamental. Agora há sessões mediúnicas todos os dias 11h para o time fazer perguntas para o João que não tem descanso nem depois de morto.
Brincadeiras à parte, a especialização excessiva das pessoas causa consequências graves para o Time de Desenvolvimento. O primeiro é a dependência do especialista, o segundo é a baixa eficiência do time, pois o ultra especialista fatalmente se tornará o gargalo do time.
A situação é pior se o time for muito segmentado em vários especialistas.Retornando ao texto acima. É como se tivéssemos o João, a Maria, a Ana, o José e cada um só faz uma coisa e ninguém sabe fazer o trabalho do outro.
Uma forma de reduzir essa dependência é começar a terminar com os silos de especialistas. Trabalho em par, Dojos, treinamento interno, workshops entre muitas outras formas de tornar profissionais tipo I (Especialista) em profissionais tipo T (Especialistas Generalistas).
Times de Especialistas
Ter um especialista no time é ruim, mas ter times inteiros compostos apenas por especialistas de uma determinada área do conhecimento é igualmente ruim. Exemplo: para uma entrega, o responsável é o Time A. Só que o Time A depende do Time B para tal. O que eles não sabem é que o Time B depende do Time C. Este depende do Time D e por aí vai.
Label: Dependência entre os times
Exemplos comuns no Desenvolvimento de Software: Time de UX, Time de Front-End, Time de Back-end, Time de Banco de Dados, Time de Produção, Time de Negócios…
Ninguém é responsável por entregar o produto, cada um é responsável por fazer uma parte mínima e “passar a bola” para o próximo da fila.
Figura: Time passando a “bola” para o outro.
Esse problema fica ainda maior caso existam dependências circulares.
Label: Exemplos de dependências circulares entre os times.
A solução para esse tipo de problema está na criação de times multidisciplinares. Quanto menor a quantidade de handoffs (passagem de bastão) mais eficiente será o time.
Já fiz a minha parte
Quando adotamos o Scrum há o papel do Dono do Produto (Product Owner). Todavia, também é necessário que o Time de Desenvolvimento tenha o senso de dono do produto. Tem uma diferença grande de quando você é dono de algo e quando você não é.
Imagine que apareceu uma infiltração no teto da sua cozinha. Provavelmente você não ficará olhando a infiltração piorar de braços cruzados. Como o apartamento é seu, imediatamente resolverá o problema.
Agora pense na situação em que você foi visitar um amigo e reparou que na casa dele tem uma infiltração no teto da cozinha. O que fazer? Alertá-lo do problema? Falar para ele que você conhece alguém que pode ajudar? Ficar calado porque você não quer se intrometer na vida dos outros?
Perceba que no primeiro caso, quando é na sua casa, você realiza alguma ação para resolver o problema: consertar a infiltração ou chamar alguém que saiba resolvê-lo. Agora, quando a casa não é sua, o máximo que você faz é falar sobre o problema, mas resolvê-lo é responsabilidade do outro.
A mesma coisa acontece quando estamos falando de produtos e serviços nas nossas empresas. Se temos o sentimento de dono do produto, temos carinho por ele e queremos que ele seja o melhor produto do mundo: útil, agradável, bonito, seguro, com qualidade, etc. Quando não temos esse sentimento de dono, cada um fará a sua parte e problemas serão sempre do “outro”.
Duas coisas são importantes para criar esse senso de dono. A primeira, mais uma vez, está relacionada à multidisciplinaridade do time.
A segunda está ligada à Programação Neurolinguística (PNL). Não reforce falas negativas sobre o produto. Exemplo:
- Esse produto vive dando defeitos.
- É mesmo, lembra daquele problema que tivemos com ele em 1998?
- Viramos a noite aqui, foi um inferno.
- É melhor jogar tudo fora e construir um novo.
Parece bobeira, mas isso atrapalha muito. Cria um ambiente negativo, cada membro do time reforça os aspectos negativos sobre o trabalho e ajudam a construir um estigma para o produto. Experimente trocar a reclamação por ações.
- Esse produto vive dando defeitos.
- O que aconteceu? Como podemos resolvê-lo? Posso te ajudar?
Tarefeiros
Há um abismo enorme tanto na eficácia quanto na eficiência quando comparamos times direcionados a entregar valor e times tarefeiros. Esse tema foi bem explorado pela Andressa Chiara no artigo O time tarefeiro e o time de produto. Então vou resumir aqui o que eles são.
Em métodos ágeis queremos entregar o produto de forma iterativa e incremental com o maior valor sendo disponibilizados nas primeiras iterações. Logo, os itens mais importantes estão no topo do meu backlog. Imagine que o time está trabalhando no item mais prioritário e acontece algo inesperado e o time fica impedido de dar continuidade àquele item. Qual a diferença no comportamento dos dois times?
Time direcionado a entrega de valor: Temos que remover o impedimento, pois este é o item mais importante que devemos entregar. Não tem nada no backlog que seja mais importante do que isso.
Time tarefeiro: Vamos pegar outro item, pois esse está impedido.
Infelizmente não haverá só um impedimento na vida de um time e o estoque de itens começados e não acabados pelo time tarefeiro será enorme.
O tarefeiro também pode ser sem impedimento. Por exemplo, se tenho um especialista no meu time e a participação dele no item de valor é curta, a tendência é que ele tente “adiantar” o trabalho. Ele estará trabalhando no item de backlog número 5.778 enquanto o resto do time estará no item 4. Esse adiantamento é ilusório e é muito provável que ele tenha que refazer os 5.774 itens. Ter muitos itens começados e não terminados significa que o seu “estoque” está muito alto e como qualquer estoque, ele irá perecer. Mudança de mercado, resultados anteriores, mudanças no perfil do cliente, etc.
Não temos tempo para…
“Aqui é trabalho, trabalho, trabalho. Não temos tempo para mais nada.”
(Ancelmo, 22 anos)
Normalmente é uma consequência do time tarefeiro. Não temos tempo para planejar, fazer melhorias, estudar novas tecnologias, pensar em soluções diferentes. Só trabalhar, trabalhar, trabalhar para entregar.
No início trabalhar excessivamente em um novo projeto, produto ou serviço parece uma boa ideia, mas com o passar do tempo se torna um fardo.
Figura: Tempo, tempo está acabando o tempo, tenho que trabalhar, trabalhar, trabalhar…
É necessário que sejam inseridas folgas no fluxo de valor para que o time possa aperfeiçoar sua forma de trabalho, inovar e aprender. Quer saber mais sobre esse assunto, veja o artigo Quer aumentar a produtividade da empresa? Dê folgas!
Conclusão
Disfunções são comuns em Times de Desenvolvimento, mas não devemos aceitá-las passivamente. É responsabilidade de todos, Time de Desenvolvimento, Scrum Master, Product Owner e gestores acabar com elas.
Espero que tenha gostado desse artigo. Em breve publicaremos As disfunções do Time de Desenvolvimento – Parte II.
Quer saber mais sobre os papéis do Scrum? Convido você a participar do nosso treinamento de Certified Scrum Master (CSM).
Veja outros artigos relacionados no Blog:
