O membro "Do Not Disturb"

Postado por Vikas Hazrati , traduzido por Pedro Mariano em 10 Mar 2010

Seções

Processos e Práticas

Tópicos

Agile ,

Técnicas Ágeis

Tags

Produtividade

Diversos desenvolvedores gostam de trabalhar isoladamente, por algum tempo, senão sempre. O XP recomenda uma organização da área de trabalho chamada "Caves and Commons" (cavernas e comuns). Áreas comuns servem para maximizar a comunicação. Cavernas servem para facilitar o isolamento para determinadas atividades como verificar email pessoal, chamada de telefones ou um rápido estudo. Contudo, podem existir situações onde vários membros do time ou um em particular deseja se isolar de uma forma exagerada.

Jacob mencionou uma situação no Grupo de Desenvolvimento Scrum onde, durante as retrospectivas, um membro do time quis  que houvesse um tempo de isolamento, no estilo "Do not Disturb" (não perturbe), durante o sprint. De acordo com o desenvolvedor, ele estava sendo interrompido tantas vezes que sua produtividade não estava boa. Ele sugeriu que houvesse um período de 2 horas por dia de isolamento. Durante esse tempo ele não falaria com o time. De acordo com Jacob, o time achou isso um ato anti-agile e um detrimento a comunicação. Esse membro do time é um engenheiro sênior e Scrum Master sem contar que ele é um dos sócios da empresa.

Alan Dayley sugere que interrupções são dependentes do tipo. De acordo com Alan,

Se a interrupção estiver totalmente relacionada com o que ele está atualmente fazendo? Bem, então esse tipo de interrupção será bem vinda! E se duas ou mais pessoas, senão o time inteiro estiver trabalhando na mesma coisa? Então essas interrupções não serão bem interrupções, elas serão o trabalho em si, o que deveria ser feito!

Kurt Hausler apoia o desenvolvedor quando ele diz que alguns desenvolvedores precisam de um ambiente isolado e pode não ter nada de errado nisso. Ele menciona que podem existir outras razões do que o óbvio para isso, ele diz:

Se ele está sendo interrompido a cada 15 minutos, mesmo quando o resto do time sabe que isso dificulta o seu trabalho, isso pode ser um indício que as pessoas que estão fazendo o trabalho não são as mesmas pessoas que possuem a informação para realizar o trabalho.

Kurt também mencionou que olhando pelo lado positivo, é muito legal ver a postura do time dado que uma coisa dessas começou a ser discutida na retrospectiva.

Da mesma forma, Elisabeth Shendrickson diz que um cenário desses pode ser um belo treinamento. Elisabeth sugere que podem haver várias causas para isso e a manifestação pode ser apenas um sintoma de uma Sindrome do Herói ou falta de aplicação das Práticas Agile ou visibilidade insuficiente ou colaboração ou mesmo falta de pensar em equipe , falta de incentivos organizacionais, etc. É necessário se aprofundar mais na causa e analisar a mesma.

Roy Morien também comentou que, mais do que apenas "Do Not Disturb" isso parece um problema de multiplos papéis que o desenvolvedor está exercendo.

Johanna Rothman, tem a opinião de que esse desenvolvedor não deve estar no time. De acordo com Johanna,

Tire essa pessoa do time. Ele não está no time de qualquer forma. Deixe ele fazer o que ele deseja em seu canto, não nesse projeto. A velocidade do time condiz ao *time* e não a velocidade pessoal. Se o resto das pessoas precisam discutir, ele precisa discutir com os outros e não trabalhar sozinho. Eu não consigo entender como uma pessoa pode ser, ao mesmo tempo, um bom engenheiro sênior, scrum master e o sócio da empresa. Ele está fazendo escolhas por si mesmo.

Adram Sroka também possui uma visão similar, ele menciona que,

Alguém que não gosta de ser interrompido não deveria ser ScrumMaster. O título de ScrumMaster serve para servir o time. Ele deve estar disponível para o time durante o dia inteiro. Esse é o trabalho dele. Se algo é mais importante então ele não é um ScrumMaster de fato. Sendo assim, deixe ele ser um sênior que ele quer e encontre alguém que poderia servir o time, e ai sim, intitular este como ScrumMaster.

Siddharta Govindaraj, faz uma interessante observação ao sugerir que algumas situações são maduras nas organizações quando você está movendo da visão tradicional para a visão Agil de trabalhar. Ele diz,

*Idealmente*, você queria que o time colaborasse o tempo todo. Mas as vezes você precisa balancear as coisas para que o seu ambiente suporte a transição. A coisa engraçada sobre o cone do silêncio é que ele vai contra vários príncipios agéis. Mas ele pode ser útil em um contexto particular.

Siddharta diz que em seu projeto, ele usa o cone do silêncio uma vez por semana. Esse dia todo mundo trabalho sozinho enquanto os outros 4 dias são colaborativos. Eventualmente com o tempo e a maturidade do time eles perderão a necessidade de utilizar o cone do silêncio.

Deste modo muitos membros da lista ficaram estusiasmados com o conceito de "Do Not Disturb". Entretanto, existem integrantes que acreditam que deve haver um ótimo balancemento entre colaboração e isolamento. O que funciona para os seus times e o que você faria em uma situação como essa?

1. Voltar ao topo

   O membro "Do Not Disturb"

   por Fernando Cézar

   Eu acho que o Scrum Master está na equipe para ser interrompido, seja pela equipe, ou seja pelo PO, ou qualquer outro fator externo. Se tem alguém que pode ser interrompido, é o SM, a equipe tem que ter paz para trabalhar e tocar o projeto.
   Se o SM está reclamando de ser interrompido pela própria equipe, ele não está fazendo o seu papel corretamente e não foi bem claro nos objetivos do sprint.
   Considero o SM o elo de ligação entre a equipe e o "mundo lá fora".
   Esse SM em questão, está acumulando muitas funções e não está conseguindo lidar com isso.
   Eu reavaliaria a posição dele na equipe.

   Responder

• Mais antigos >