Arquivo da categoria: Scrum

SWX Labs 08 – Equipes de Alto Desempenho

capa02

No SWX Labs 08 Mike e Vinicius  conversam com Alércio Bressano sobre Equipes de Alto Desempenho.

Alércio nos mostra o caminho das pedras para criar uma equipe de alto desempenho usando metodologias ágeis, notadamente o Scrum. Dos fracassos iniciais à construção de um time de alto desempenho, passando pela conquista da confiança de sua equipe Alércio mostra que inovar em metodologias de trabalho é um caminho possível e real.

Ouça o podcast clicando no play, se preferir faça o download

Assine o feed do nosso podcast e não perca nenhum episódio: http://feeds.feedburner.com/SWXLabs

Se preferir, também estamos no Itunes Store

Gostou? Não gostou? Erramos algo? Sua opinião é muito importante para nós, por isso deixe seu comentário ou envie email para mike@swx.com.br

Imagem: O termo Scrum se origina de uma jogada de Rugby, por isso homenageamos a competente e divertida seleção neozelandeza de rugby.

Rotação do papel do ScrumMaster: se puder, evite

Fonte: Rafael Buzon/InfoQ


Algumas equipes ágeis têm tido a iniciativa equivocada, segundo Mike Cohn, de rotacionar o papel do ScrumMaster entre os integrantes da equipe. Em post publicado recentemente em seu blog, Cohn argumenta que está sendo subestimado o papel do ScrumMaster quando se afirma que qualquer um pode exercê-lo e acrescenta:

Não defendo esta abordagem, pois não acho que demonstra o respeito apropriado aos desafios e ao significado do papel de ScrumMaster.

Cohn revela, entretanto, que há situações nas quais se deseja criar oportunidades de aprendizado, e que nesses casos rotacionar o ScrumMaster aumentaria o entendimento na equipe sobre como é estar neste papel.

Outra situação, para Cohn, que permitiria a rotação do ScrumMaster, surge quando se deseja evitar a imagem de um “gerente da equipe”. Com a rotação das responsabilidades, o “poder” fica mais balanceado e a equipe se torna mais autogerenciável.

Cohn não recomenda que o papel do ScrumMaster seja rotacionado sistematicamente, e aponta alguns problemas decorrentes de rotações frequentes:

  • Aqueles que assumiram o papel de ScrumMaster, devido a uma rotação, geralmente têm outras atribuições que terminam ganhando prioridade durante o sprint;
  • É difícil treinar pessoas em número suficiente para fazer bem o papel do ScrumMaster;
  • Algumas pessoas usarão seu tempo como ScrumMaster para forçar mudanças nos processos;
  • Designar alguém como ScrumMaster durante alguns sprints não garante que esta pessoa irá valorizar esse trabalho. Isso pode levar à impressão, da parte de ScrumMasters, de que o Scrum seria um erro.

Rotacionar o papel do ScrumMaster, portanto, não deve ser uma prática permanente. É aceita por Mike Cohn somente por tempo determinado e em situações específicas, que contribuam para o aprendizado da equipe e para a sua capacidade de autogerenciamento.

Quais são suas experiências em rotacionar o papel do ScrumMaster em sua organização?

7 opções para lidar com interrupções em Scrum e outras práticas ágeis

Fonte: Rafael Buzon/InfoQ

Mishkin Berteig, consultor e coach Agile, publicou recentemente no blog Agile Advice uma revisão de um antigo artigo de sua autoria, acrescentando sete opções para lidar com interrupções nas empresas que utilizam práticas ágeis. Aqui resumimos essas alternativas.

1. Seguir rigorosamente o Scrum

As regras do Scrum são claras, defende Berteig:

Se não faz parte do trabalho planejado para o sprint, então não deve ser feito. Do momento em que a equipe se compromete com o trabalho no início do sprint, na reunião de planejamento, até o final do sprint, na reunião de revisão, é necessário que a equipe seja protegida contra interrupções.

Berteig comenta que ao se rejeitar as interrupções, como resultado de seguir fielmente o Scrum, os obstáculos que impedem as equipes são evidenciados dentro da organização. Desse modo é possível identificar as causas-raiz dos problemas e tratá-las de forma apropriada.

2. Reservar um tempo para interrupções

De acordo com Berteig, em determinadas condições do ambiente de trabalho é possível estimar o tempo médio gasto com interrupções no passado e reservá-lo no sprint para tais ocorrências. A alocação deste tempo poderia acontecer de duas maneiras:

Na reserva de tempo para interrupções, diz Berteig, há duas possibilidades para alocação do tempo:

Todos na equipe dispõem de certa quantidade de tempo diária para lidar com interrupções, OU um ou dois membros da equipe ficam dedicados exclusivamente a lidar com as interrupções durante o sprint.

O autor lembra ainda que o tempo planejado para as interrupções nunca deve ser excedido, pois comprometerá as entregas do sprint. Ele recomenda que o tempo economizado seja sempre usado para analisar as causas-raiz dos problemas.

3. Negociar mudanças de forma visível

Outra abordagem é formalizar o processo de interrupções e mudanças, permitindo às partes interessadas (stakeholders) negociar e conhecer os impactos de suas solicitações imediatamente. Para isso, Berteig recomenda o uso de cartões coloridos para representar a solicitação de cada stakeholder, e que sejam diferentes dos cartões planejados para o sprint.

Após avaliação e estimativa da equipe, os envolvidos podem negociar prioridades e determinar qual trabalho poderia ser deixado de lado para a entrada da nova demanda.

Para que esta abordagem seja bem sucedida, Berteig defende que três condições devem ser verdadeiras:

  • Ter um quadro de tarefas visível de forma constante (e não através de ferramentas eletrônicas);
  • Ter uma equipe que seja boa em estimar rapidamente e com bom grau de acurácia;
  • Deixar muito claro, com todos os envolvidos, as mudanças realizadas e seus impactos na iteração atual.

4. Ter uma equipe separada, dedicada a interrupções

Outra abordagem apontada pelo artigo é dedicar uma equipe exclusiva para tratar as interrupções, liberando as demais equipes para a construção dos produtos.

Sobre o perfil desta equipe dedicada a interrupções, diz Berteig:

Quanto mais capacidade técnica tiver esta equipe, e autonomia para que possa realizar mudanças no código, banco de dados etc, mais efetiva será em proteger das interrupções as equipes de produto.

Esta abordagem pode ser especialmente interessante, por tornar mais visíveis os custos associados às interrupções. Funciona, assim, como um indicador da qualidade do código entregue pelas equipes.

Berteig recomenda, ainda dentro desta abordagem, que as equipes não tenham seus integrantes rotacionados, pois isso pode trazer problemas de sinergia entre eles.


5. Realizar iterações extremamente curtas

Realizar iterações extremamente curtas é outra abordagem apontada pelo artigo, que possibilita a realização das interrupções em um tempo médio aceitável, sem contudo comprometer a iteração já planejada e em andamento.

Para tanto, é necessário conhecer historicamente o prazo médio com que as interrupções (novas demandas) precisam ser entregues e realizar iterações menores que este prazo. Berteig cita um exemplo:

Uma equipe na qual trabalhei recebia interrupções que precisavam ser resolvidas dentro de até três dias (interrupções mais urgentes eram raras). Decidiram, então, realizar iterações de dois dias para que na média conseguissem terminar de lidar com uma interrupção em três dias.

A lógica é a seguinte, utilizando o exemplo dado por Berteig: usando iterações de 2 dias a interrupção geralmente ocorrerá entre os dias 1 e 2 da iteração. A equipe, então, ao invés de já iniciar os trabalhos da nova demanda gerada pela interrupção, apenas a prioriza para o próximo ciclo de 2 dias. Dessa forma, a interrupção não atrapalha o ciclo atual e é resolvida dentro de um prazo médio aceitável.


6. Manter o Status Quo

Berteig considera também que as empresas podem optar em manter o status quo e continuar lidando com as interrupções da forma como fazem atualmente. Destaca que em algumas indústrias, a forma atual pode ser estratégica e pode permanecer, mas faz uma ressalva:

Se você escolher manter o status quo é importante que o faça de forma transparente e deixe claro o que está sendo sacrificado. Diga a todos das equipes exatamente porque está optando por essas escolhas e quais os benefícios esperados de se fazer dessa maneira.

7. Estimar com a velocidade de comprometimento

A velocidade de comprometimento (commitment velocity), segundo o autor, é a menor quantidade de pontos entregues em um sprint, medida ao longo do projeto. Utiliza-se essa velocidade como sendo o limite possível para o planejamento dos próximos sprints, permitindo com isso que a equipe se comprometa tanto com as entregas do projeto como com as interrupções.

A equipe pode se sentir tentada a calcular a média das velocidades realizadas e utilizá-la como medida para o planejamento dos sprints, mas Berteig alerta que a média não representa a velocidade de comprometimento e acrescenta:

Com base na lei dos grandes números e no teorema do limite central, usando esta ferramenta da Velocidade de Comprometimento por muitos sprints, sua capacidade de manter compromissos, mesmo com interrupções, se aproximará cada vez mais de 100% de certeza.

Escolhendo a melhor abordagem

Para que a abordagem escolhida seja bem experimentada, Berteig recomenda que seja feita uma decisão consciente e que seja exercitada por tempo suficiente a fim de entender se funciona ou não para você. E acrescenta algumas considerações:

  • Se você está tentando realizar uma melhoria radical em sua organização, eu recomendaria escolher a opção 1 ( Seguir rigorosamente o Scrum) ou a opção ou 7 (Estimar com a velocidade de compromisso). Ambas as opções colocam pressão na equipe e na organização, em busca de melhoria;
  • Se você não tem um forte apoio executivo para o Agile, então as opções 2 (Reservar um tempo para interrupções), 4 (Ter uma equipe separada, dedicada para interrupções) e 5 (Realizar iterações extremamente curtas), serão as melhores;
  • Se você tem um forte apoio executivo, mas não está desesperado em melhorar sua organização, considere a opção 3 (Negociar mudanças de forma visível);
  • E claro, a opção 6 (Manter o Status Quo) é a mais fácil… Mas não recomendo! A agilidade requer mudanças sistemáticas para encorajar a melhoria contínua, e todas as demais opções ajudam nesse aspecto.