Acho que outras pessoas já deram boas respostas, mas adicionarei as minhas apenas porque acho que sua equipe acabou de fazer a transição para o Scrum e agora vocês estão em uma posição muito semelhante à que estávamos quando começamos.
Primeiro, nossa introdução ao Agile e, mais especificamente, ao Scrum não foi muito fácil. Basicamente, a gerência desceu e disse: a partir de hoje você fará o Scrum e este é um processo que todos seguirão. Tanta coisa para Pessoas acima do Processo .
O processo que seguimos originalmente (cegamente, devo acrescentar) acabou muito parecido com o que você descreveu. As pessoas recebem tarefas atribuídas, todos são contratados e todos voltamos para nossas mesas e nos desligamos. Então temos uma reunião de stand-up chata todos os dias.
A chave para perceber é que o Agile, e o Scrum incluído, são realmente pessoas. Quando a equipe entrar no planejamento da iteração, não deixe seu Scrum master (que provavelmente é seu gerente) atribuir horas, histórias e tarefas. É completamente ATÉ A EQUIPE. Eu acho que, para muitas pessoas, esse é um conceito muito difícil de superar, porque, anos antes, eles vinham trabalhar e tinham um chefe (gerente, líder técnico ...) que simplesmente designava trabalho. Eles mergulham no Scrum, mas todos (incluindo o próprio Scrum Master) continuam operando no mesmo modo.
Um dia, você ficará cansado disso, então começará a ler livros, blogs e continuará fazendo perguntas como essa na troca de pilhas. A percepção de que você obterá é que você, como desenvolvedor e seus colegas de equipe, deve ser a força motriz por trás do comprometimento com histórias e atribuição de tarefas. Se vocês sentirem que se beneficiarão da programação em pares, crie 2 tarefas para cada um dos engenheiros e atribua as duas horas. A única coisa que o scrum master deve fazer é medir a velocidade em relação às histórias concluídas que você entregou como equipe na iteração anterior.
Outra coisa que me incomoda é como as pessoas dizem que sua capacidade SEMPRE é de 75% do total de horas, então é com isso que elas se comprometem e, durante toda a duração da iteração, reclamam que a) elas não podem ajudá-lo ou b) eles não podem fazer a coisa certa porque receberam muitas horas. As pessoas não devem saber quantas horas cometer e certamente devem recuar se o scrum master estiver tentando puxar algo assim! Todos devem se comprometer exatamente com o que estão confortáveis. Por exemplo, eu sou líder de equipe e frequentemente acabava em uma discussão aleatória não planejada de design, ou ajudando alguém com código ou com a solução de problemas de coisas estranhas, para que minha capacidade nunca esteja acima de 50%.
Foram necessários quatro ciclos de lançamento para nossa equipe para aprender a não fazer as coisas que acabei de mencionar e mesmo que tenhamos melhorado definitivamente, se você perguntar aos especialistas, não somos nem meio ágeis. Ainda há muito a aprender a fazer.
Atualização 1: Resposta ao comentário de Cliff
Bem, você ofereceu seus ouvidos, então aqui está ...
Você está certo, a mudança cultural é fundamental, mas essa mudança não precisa acontecer no nível executivo. Seu próprio gerente de grupo pode mudar a cultura dentro de sua equipe e isolar vocês do BS corporativo com o qual ele tem que lidar. O que você está descrevendo foi EXATAMENTE de 2007 a 2010. Nossa equipe (e outras equipes também) fracassou de lançamento em lançamento. Em um dos lançamentos, usando o "processo de ser ágil" da gerência, conseguimos que nove pessoas produzissem o trabalho que normalmente seria feito por uma única pessoa e levamos o dobro do tempo. Eu tinha tanto tempo livre que até atualizei meu currículo.
Então, conversei com meu chefe e expliquei a ele todas essas coisas sobre a agilidade das pessoas e que, se você quiser que se preocupem com o produto, tomemos decisões que afetam a maneira como trabalhamos e entregamos o produto. Eu acho que ele decidiu fazer disso um experimento, ele fez todas as mudanças que nós ... bem, principalmente eu, mas converso muito com o restante da equipe, daí 50% da capacidade :) ... proposta. É possível que ele tenha pensado que, se fizer todas as mudanças que estamos pedindo e ainda falharmos, ele voltará com um vitorioso "Eu te disse".
Então, nos últimos 12 meses, eliminamos tantas "idiotas" que nem sequer é engraçado. Nossas reuniões de stand-up realmente fazem sentido agora, porque trabalhamos juntos, não isoladamente. Ainda temos a propriedade (pelo menos por enquanto) de partes específicas do produto, mas também cruzamos com muita frequência o código um do outro. Fazemos constantemente análises de código para que não apenas os membros da equipe aprendam outro código, mas também aprendam melhores técnicas de codificação e design. Dividimos uma equipe monolítica e gigante "ágil" em três equipes diferentes, de modo que o planejamento e outras reuniões são muito mais curtas e as pessoas realmente se preocupam com elas, porque não ficam sentadas e escutam coisas sobre as quais não se importam. EU' Vimos noites em que quatro de cada cinco membros (uma das equipes) ficavam on-line às 23h e ninguém nos disse que precisamos trabalhar duro ou nos pressionou a trabalhar por mais de 40 horas. Pessoas que não se importam menos de meio ano atrás, de repente, estão envolvidas e empolgadas com o trabalho que estão realizando. E tudo o que foi necessário para o nosso gerente fazer foi dizer: "vocês decidem o que é certo e fazem o que precisam fazer, e vou manter o BS corporativo fora da equipe o máximo que puder".
Tudo começou como um experimento (minha suspeita, ele nunca me disse isso), mas agora nosso grupo está chutando o traseiro em comparação com outros grupos de desenvolvimento do departamento e ainda temos outros desenvolvedores que agora estão tentando se juntar a nós.
O maior obstáculo para nós desde que essa mudança aconteceu (e ainda é um problema hoje) foi o fato de que os engenheiros no ambiente corporativo normal são como ratos experimentais em uma gaiola. Mesmo quando seu gerente decide ser verdadeiramente "ágil" e remove a gaiola, todos estão nessa gaiola há tanto tempo que nem percebem que são livres. Assim, mesmo com toda a liberdade, eles continuam agindo como se ainda estivessem constrangidos. Eu acho que o que ajudaria é ter pelo menos poucas pessoas na equipe (como você), que vão além dos limites do grupo e procuram maneiras melhores de fazer as coisas. Depois volte para o grupo e mexa um pouco.
No seu caso, talvez a programação emparelhada não seja uma solução se você estiver procurando outra força externa para entrar na equipe e dizer a eles como trabalhar. Em vez disso, jogue fora as regras, sente-se com elas, sem gerenciamento, e pergunte-lhes o que elas querem fazer? O que os fará felizes? Produtivo? Identifique os maiores problemas e pergunte à EQUIPE qual eles pensam que a solução deveria ser.