Modelos híbridos do Scrum

A “hibridação” do Scrum com outras metodologias de desenvolvimento de software é comum, pois o Scrum não cobre todo o ciclo de vida de desenvolvimento do produto; portanto, as organizações encontram a necessidade de adicionar processos adicionais para criar uma implementação mais abrangente. Por exemplo, no início do desenvolvimento do produto, as organizações geralmente adicionam orientações de processo no caso de negócios, coleta e priorização de requisitos, design inicial de alto nível e previsão de orçamento e cronograma.

Vários autores e comunidades de pessoas que usam o Scrum também sugeriram técnicas mais detalhadas de como aplicar ou adaptar o Scrum a problemas ou organizações específicos. Muitos se referem a essas técnicas metodológicas como ‘padrões’ – por analogia com os padrões de design em arquitetura e software.

Scrumban

O Scrumban é um modelo de produção de software baseado em Scrum e Kanban (Leia também: “Kanban“). O método é especialmente adequado para manutenção de produtos com itens de trabalho frequentes e inesperados, como defeitos de produção ou erros de programação. Nesses casos, as sprints por tempo limitado da estrutura do Scrum podem ser vistos como menos benéficos, embora os eventos diários do Scrum e outras práticas ainda possam ser aplicados, dependendo do time e da situação em questão.

A visualização das etapas e limitações do trabalho para defeitos e trabalhos inacabados simultâneos é familiar do modelo Kanban. Usando esses métodos, o fluxo de trabalho da equipe é direcionado de forma a permitir um tempo mínimo de conclusão para cada item de trabalho ou erro de programação e, por outro lado, garante que cada membro do time seja constantemente alocado.

Para ilustrar cada estágio do trabalho, os times que trabalham no mesmo espaço geralmente usam notas post-it ou um quadro branco grande. No caso de times descentralizados, pode ser usado software de ilustração de palco, como Assembla, JIRA ou Agilo.

As principais diferenças entre Scrum e Kanban são que, no Scrum, o trabalho é dividido em sprints que duram um período fixo de tempo, enquanto no Kanban o fluxo de trabalho é contínuo. Isso é visível nas tabelas de estágio de trabalho, que no Scrum são esvaziadas após cada sprint, enquanto no Kanban todas as tarefas são marcadas na mesma tabela. O Scrum se concentra em equipes com know-how multifacetado, enquanto o Kanban possibilita equipes especializadas e funcionais.

Scrum of Scrums

O Scrum of Scrums é uma técnica para operar o Scrum em escala, para várias equipes que trabalham no mesmo produto, permitindo que elas discutam o progresso de suas interdependências, concentrando-se em como coordenar a entrega de software, especialmente em áreas de sobreposição e integração.

Dependendo da cadência (tempo) do Scrum of Scrums, a Daily Scrum relevante para cada time de scrum termina designando um membro como embaixador para participar do Scrum of Scrums. Dependendo do contexto, os embaixadores podem ser colaboradores técnicos ou o Scrum Master de cada equipe.

Em vez de simplesmente uma atualização de progresso, o Scrum of Scrums deve se concentrar em como os times estão trabalhando coletivamente para resolver, mitigar ou aceitar quaisquer riscos, impedimentos, dependências e suposições (RIDAs) identificados.

O método rastreia esses RIDAs por meio de um backlog próprio, como uma placa de risco (às vezes conhecida como placa ROAM após as iniciais de resolvido, de propriedade, aceito e mitigado), o que normalmente leva a uma maior coordenação e colaboração entre times.

Isso deve ser semelhante a uma Daily Scrum, com cada embaixador respondendo às quatro perguntas a seguir:

• Quais riscos, impedimentos, dependências ou premissas sua equipe resolveu desde a última vez que nos encontramos?
• Quais riscos, impedimentos, dependências ou suposições sua equipe resolverá antes de nos encontrarmos novamente?
• Existem novos riscos, impedimentos, dependências ou premissas que tornam sua equipe mais lenta ou atrapalham?
• Você está prestes a introduzir um novo risco, impedimento, dependência ou suposição que atrapalhará o de outra equipe?

Como Jeff Sutherland disse:

Desde que eu defini originalmente o Scrum of Scrums (Ken Schwaber estava na IDX trabalhando comigo), posso dizer definitivamente que o Scrum of Scrums não é um ‘meta Scrum’. O Scrum of Scrums, como eu o usei, é responsável por entregar o software de trabalho de todas as equipes à Definição de Concluído no final do sprint ou por lançamentos durante o sprint. O Ancestry.com entrega a produção 220 vezes por Sprint de duas semanas. O Hubspot fornece software ao vivo 100-300 vezes por dia. O Scrum of Scrums Master é responsável por fazer esse trabalho. Portanto, o Scrum of Scrums é um mecanismo operacional de entrega.