Tarefas não paralelas para scrum e enxame

Meu atual scrum master é um verdadeiro crente que não está disposto a mudar as formas oficiais de scrum. Não quero que isso pareça certo, estou realmente perguntando sobre a solução ortodoxa para esse problema, porque tive êxito em resolver problemas com ele no passado, reformulando as coisas em termos oficiais.

O exemplo atual de uma questão recorrente que temos é que existem algumas dependências de pedidos entre algumas de nossas histórias. (Em particular, parte do desenvolvimento usa um programa de terceiros para o qual temos apenas uma licença de assento.) Existem algumas tarefas de configuração necessárias associadas a isso que foram reunidas em uma "História da instalação" e, em seguida, temos 6 tarefas que podem ser seguidas em qualquer ordem.

A questão é que, para o sprint atual, inserimos a história da instalação e uma das histórias seguintes, quando eu disse que não podemos ter mais histórias nesse grupo, mesmo que o sprint esteja menos da metade. Há histórias não relacionadas no backlog que foram priorizadas abaixo desse grupo que eu sugiro que possamos trazer para o sprint. No entanto, todos foram priorizados abaixo das histórias deste grupo. Nesse ponto, o scrum master afirmou que deveríamos enxamear a "Tarefa de Configuração" e concluí-la mais rapidamente, esse é um conflito que já tivemos antes e ele se adiantou.

Portanto, na primeira metade deste sprint, dois desenvolvedores e um recurso de teste estão me observando trabalhar no site de configuração do fornecedor externo, fazendo o download de recursos e embaralhando certificados. Todo o tempo eu sei que temos um lançamento em três sprints e poderíamos obter quase todo o backlog que o OP gostaria, mas não o faremos porque nenhum trabalho está sendo feito nessas tarefas enquanto todo mundo fica assistindo (er, enxames) a tarefa de configuração da história de maior prioridade.

Meu mestre de scrum diz que nossa única preocupação é completar as histórias que aceitamos para o sprint. O que eu entendo, mas sinto que estamos falhando com a organização maior por não comunicar a "embalagem ruim" que a priorização que recebemos do proprietário do produto está causando.

Então, como oficialmente as questões de dependências entre histórias e histórias em série são tratadas pela metodologia?

Então, como oficialmente as questões de dependências entre histórias e histórias em série são tratadas pela metodologia?

Como com qualquer outra coisa no Agile: Individuals and interactions over processes and tools

Se o seu processo não estiver atendendo você, você o transformará em algo útil. Para isso, selecionaria histórias de menor prioridade (ou alguma dívida técnica / crescimento pessoal que talvez não seja visível no backlog) até que o pré-requisito seja limpo. Supondo, é claro, que você tenha feito sua devida diligência e esse seja realmente um pré-requisito difícil e rápido. Para muitas coisas, interfaces e zombarias podem desbloquear o trabalho até que a coisa real esteja pronta.

Uma das características do kanban, que eu acredito que transborda, é que o processo como um todo otimiza para a equipe , não para o indivíduo. Em outras palavras, não é pecado se alguém da equipe estiver ocioso por parte do sprint.

Se a equipe como um todo escolhe X pontos da história, realmente não importa (para as partes interessadas) se uma pessoa fez todo o trabalho ou se o trabalho foi dividido igualmente. Portanto, se o proprietário do produto estiver satisfeito com o número de pontos trazidos para um sprint (e essa é a chamada do proprietário do produto, não do scrum master!), Isso é tudo o que importa.

Obviamente, dito isso, se alguns membros da equipe não estiverem diretamente envolvidos na primeira história, eles poderão estar ocupados escrevendo testes ou fazendo o que puderem nas outras histórias.

Como nota final, o scrum master tem pouco negócio "cavando nos calcanhares". O scrum master deve estar trabalhando para você remover barreiras à produtividade, não configurar barreiras. Se a equipe como um todo sente que pode recorrer a outra história de menor prioridade, essa é uma decisão da equipe; o scrum master não tem uma palavra final sobre o assunto.

Uma exceção pode ser feita se a equipe for jovem e ainda aprender scrum, mas se a equipe for madura, todo o objetivo do scrum é capacitar a equipe e não os gerentes.

Na minha opinião, você tem dois problemas diferentes:

1. Como otimizar a produtividade da sua equipe.
2. Como solicitar o backlog do produto e do sprint com base nas dependências.

Pela produtividade de sua equipe , posso simpatizar com seu Scrum Master: Descobri, devido à natureza humana, que a maioria das pessoas deseja manter todos ocupados, em vez de otimizar toda a equipe. Estar ocupado não é igual a produtividade. A ociosidade pode ser a melhor coisa para um membro da equipe em um determinado momento.

Sobre o assunto específico da tarefa de instalação: isso parece algo que deve ser automatizado. Dada a sua descrição, se eu estivesse trabalhando com sua equipe, gostaria de dedicar algum tempo a descobrir o que está acontecendo com esse processo de configuração que consome tempo e bloqueia, pois parece ser o principal candidato para melhorar a eficácia da equipe.

Eu também espero, no mínimo, que você não seja a única pessoa na equipe que possa fazer isso. Se você tiver um dia de folga, espero que a equipe tenha outras pessoas que possam lidar com esse processo de gargalo. O enxame pode ser uma chance de garantir que várias pessoas aprendam como fazer isso.

Supondo que você tenha uma dependência inevitável entre PBI (Product Backlog Items), eu consideraria todos os PBIs dependentes bloqueados até que a dependência de bloqueio seja resolvida. Em geral, isso significa deixar os PBIs bloqueados fora de um Sprint. Como você tem controle sobre a dependência de bloqueio, posso ver trazendo os PBIs dependentes para o sprint, mas isso parece uma jogada arriscada. No Sprint Planning, eu geralmente esperaria considerar PBIs que não estão bloqueados.

O ponto principal, porém, é encontrar o que funciona melhor para fornecer software valioso, testado e funcional da maneira mais eficaz possível.

A regra número 1 para criar seu backlog do sprint (adicionando itens de backlog do seu produto ou PBIs) deve seguir o princípio básico do INVEST:

1. Independente: O PBI deve ser independente, de maneira que não exista dependência inerente a outro PBI.
2. Negociável: os PBIs, até fazer parte de uma iteração, sempre podem ser alterados e reescritos.
3. Valioso: Um PBI deve agregar valor às partes interessadas.
4. Estimativa: você sempre deve poder estimar o tamanho de um PBI.
5. Pequeno: os PBIs não devem ser tão grandes que se tornem impossíveis de planejar / tarefa / priorizar com um certo nível de certeza.
6. Testável: O PBI ou sua descrição relacionada deve fornecer as informações necessárias para possibilitar o desenvolvimento do teste

Parece que seu Scrum Master está forçando a equipe a violar a primeira regra, todas as histórias em um sprint devem ser independentes - o que você faz se estiver bloqueado nessa história que precisa concluir para fechar outras histórias? Você provavelmente falhará no sprint neste caso.

Concordo que a programação de pares / enxames é uma boa maneira de colaborar e compartilhar conhecimento na equipe - mas se não houver necessidade de enxame em algo assim, então eu me atento às suas armas e cito INVEST :)

Copiado da Wikipedia: https://en.wikipedia.org/wiki/INVEST_(mnemonic)