O scrum master pode alocar tarefas?

Estamos seguindo o scrum em nosso projeto. Vejo na maioria das vezes o scrum master aloca as tarefas para nós. No entanto, li em muitos livros de scrum que o scrum funciona de maneira inversa (a abordagem 'pull') e os membros da equipe pegam tarefas ou recursos. O scrum master atribui tarefas à abordagem correta ou vai contra a ideologia ágil?

De acordo com o artigo da Wikipedia sobre Scrum , as tarefas do Sprint não são atribuídas pelo ScrumMaster:

As tarefas no backlog do sprint nunca são atribuídas; em vez disso, as tarefas são registradas pelos membros da equipe, conforme necessário, de acordo com a prioridade definida e as habilidades dos membros da equipe. Isso promove a auto-organização da equipe e a adesão do desenvolvedor.

Além disso, a definição de ScrumMaster é que ele é a pessoa responsável por garantir que as pessoas sigam as regras do processo Scrum.

ScrumMaster A pessoa responsável pelo processo Scrum, garantindo que ele seja usado corretamente e maximizando seus benefícios.

O ScrumMaster não atribui tarefas, simples e simples. A equipe é auto-organizada e decide quem trabalha no que é decidido pela equipe.

Isso é verdade Scrum. Muitas organizações, é claro, podem usar variações disso, no entanto.

É assim que deve funcionar, mas como em todas as coisas que funcionam muito bem na teoria ... nem sempre funciona.

Existem dependências, desejos dos clientes e drivers de fora. Algumas coisas precisam ser feitas antes que você possa trabalhar nesse widget sofisticado em que todos desejam trabalhar.

Há habilidades básicas de desenvolvedor dirigindo por dentro. Algumas coisas são difíceis e outras são melhores. Claro, ao trabalhar dentro de uma linha do tempo infinita, posso apenas deixar você descobrir; mas quando algo precisa ser feito, atribuir à pessoa mais bem posicionada para fazê-lo o mais rápido e melhor é aquele que está conseguindo o emprego.

E também há questões de personalidade, como o controle excessivo do Scrum Master e / ou desenvolvedores que não podem amarrar seus próprios sapatos sem receber instruções. Minha equipe, por exemplo, tem os dois. Simplesmente funciona melhor para todos ignorarem esse pequeno fato sobre o Scrum nesses casos.

Em outras palavras, não faça isso apenas porque o processo exige. Faça o que funciona. Dane-se o resto.

Claro, também há outro fato básico da existência humana ... talvez você nem saiba quem é realmente o Scrum Master. Talvez não seja a pessoa com esse título. Talvez você nem tenha um.

Nunca.

Scrum é totalmente claro sobre isso. A Equipe de Desenvolvimento, como um grupo, é responsável por concluir os itens no backlog da Sprint. Eles também estão completamente no controle de como eles realizam o desenvolvimento e ninguém pode dizer a eles como fazê-lo.

Como treinador, o Scrum Master tem um papel importante em apontá-lo quando vê que a equipe corre o risco de perder os objetivos da Sprint por qualquer motivo. Mas, então, ele precisa pedir que eles descubram como eles vão lidar com isso e depois saiam do caminho.

Outra abordagem poderia ser deixar a equipe concluir o Sprint, responsabilizá-lo pela falta de resultados e depois discuti-lo na Retrospectiva do Sprint.

Como qualquer ideologia, há momentos em que o livro de regras precisa ser jogado fora ou cuidadosamente ignorado.

Use um julgamento sobre o que parece apropriado. Apenas tome cuidado para alguém se tornar um gerente de projeto de fato - ou pior, intimidar as pessoas para que façam certas coisas.

Há uma grande diferença entre a alocação de tarefas por ordem (você DEVERÁ fazer X) e a alocação por discussão e acordo. Às vezes, o acordo pode ser morno.

Por outro lado, talvez a equipe precise dirigir ... é difícil saber.

No entanto, eu ficaria preocupado com qualquer processo que insista em que você deve seguir o processo à risca, sem espaço para mexer ou julgar. Tal processo é um substituto para o pensamento.

Na minha opinião, o scummaster não deveria fazer isso, os membros da equipe deveriam pegar tarefas. Se o scrummaster está apenas fazendo a administração, como é o caso em nossa equipe, não há problema. Nosso scrum master garante que a placa scrum de papel permaneça sincronizada com o arquivo do excel. O papel do scrum master deve ser um facilitador, pois ele garante que você possa realizar seu trabalho sem impedimentos. É assim que trabalhamos. Você sabe por que seu scrummaster faz isso? Ele é gerente de projetos com medo de se tornar obsoleto? Ele tem medo de que a equipe não realize tarefas sozinha? Pode ser uma boa ideia discutir isso durante uma retrospectiva.

Eu tenho sido um mestre de scrum nos dois tipos de ambientes (onde eu empurrei tarefas para indivíduos e onde indivíduos puxa tarefas).

Na equipe Push, os recursos de desenvolvimento não eram intercambiáveis. O trabalho do Windows Client teve que ir para o desenvolvedor do Windows e o trabalho da Web para o desenvolvedor da Web. Por isso, fui capaz de enviar tarefas aos recursos durante as sessões de planejamento. Também pude fazer um planejamento de capacidade individual para saber quando parar de pressionar.

O método pull funcionou bem em uma equipe onde qualquer tarefa poderia ser escolhida por qualquer recurso. Porém, não pude fazer o planejamento da capacidade individual durante a sessão de planejamento; ao invés disso, tive que depender da velocidade média para saber quando bastava. (Foram necessários ~ 3-4 sprints antes de termos uma boa idéia da velocidade).

Me deparei com um artigo interessante que descreve os prós / contras de Push vs. Pull.