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.
Qual você acha que seria a melhor abordagem em sua organização para evitar interrupções? Você utiliza alguma prática diferente destas?