Café com o Scrum Master Escalando o Scrum com o Nexus Framework
Olá Pessoas,
Antes de mais nada eu gostaria de agradecer o wordpress, por ceder este espaço para que a gente possa, em alto nível, discutir a gestão de projetos no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)
Não há mais como conter o avanço do Scrum e das metodologias ágeis. Os mantras repetidos efusivamente de que o ágil é, digamos, a forma mais adequada de se produzir software funcionando, com qualidade, com time-to-market aceitável, que agregue valor para os clientes e tutti quanti… já estão démodé. (démodé é bem… deixa pra lá vai)
Modernamente, muitas empresas de TI já estão se adaptando a esta nova forma de pensar e rapidamente se movimentam no sentido de adotar, senão o todo, grande parte das técnicas e da cultura disseminadas pela filosofia ágil.
Ao passo, porém, que a adoção de tais métodos se acentua… novos desafios, com graus variados de complexidade, começam a emergir. Como por exemplo, o desafio que uma grande empresa – que decidiu adotar o Scrum em um dos seus projetos, e por questões N, precisará que, hipoteticamente, 40 desenvolvedores trabalhem de maneira sincronizada no desenvolvimento de um único produto – enfrentará para coordenar eficientemente todos os envolvidos, colaborando para que estes cumpram as metas de negócio definidas pela organização. Além de ser óbvio que esta não será uma tarefa fácil, o próprio Scrum desestimula a formação de times de desenvolvimento com mais de 9 membros.
Se concordamos que quando desenvolvemos software, estamos lidando com sistemas adaptativos complexos… imagine quão mais complexo fica, quando precisamos coordenar múltiplos times trabalhando na mesma base de código e integrando continuamente o seu trabalho sem que, por exemplo, a chamada dívida técnica cresça, tome forma, vire um bicho e nos engula.
Atividades precisarão ser sequenciadas e as dependências entre os times precisarão ser minimizadas e resolvidas… do contrário, teremos impactos indesejados na produtividade além de resultados desastrosos.
Façamos um breve exercício mental. Imagine 5 Times Scrum formados por 7 desenvolvedores e um Scrum Master (full time) para cada time. Todos numa sala – com um Product Owner e um Product Backlog contendo vários itens – planejando a Sprint #1. Eles desenvolverão um ERP completo. Nestas condições permita-me perguntar:
- Quem fará o que?
- Como integrar o que cada time desenvolverá em um único incremento?
- E se o que o time “A” precisar para desenvolver uma parte do incremento, depender de uma outra parte que está sob a responsabilidade do time “B”… como faremos para lidar com esta dependência?
Percebe o tamanho do desafio?
Para auxiliar as empresas a resolverem problemas desta natureza, a Scrum.org lançou, recentemente, o Nexus; um framework para escalar o Scrum… que trocando em miúdos, trata-se de um exoesqueleto que tem como proposta principal, auxiliar na coordenação de vários Times Scrum (3 à 9 idealmente) quando estes estão trabalhando no desenvolvimento de um único produto (Product Backlog).
#Pois é… enganam-se redondamente aqueles que ainda acreditam que o “Deus Mercado” não dará conta de atender às demandas que ele mesmo cria. 😉
O Framework Nexus
O Nexus consiste em regras, eventos, artefatos e papéis bem semelhantes aos previstos no framework Scrum. Como dito anteriormente, é uma estrutura criada para suportar de 3 à 9 times trabalhando num único produto. A diferença mais evidente é que mais atenção é dada às dependências e ao sincronismo dos Times Scrum envolvidos, para que estes formem uma única e consistente engrenagem, a fim de entregar, com êxito, um incremento pronto e integrado ao final de cada Sprint.
O Nexus recomenda a adoção de no mínimo 3 e no máximo 9 Times Scrum, e a formação de um Time de Integração Nexus.
Papéis do Nexus
Time de Integração Nexus
São os responsáveis por garantir que um incremento pronto e integrado seja entregue ao final de cada Sprint. São eles os responsáveis por resolver os problemas técnicos e não técnicos que impeça os Times Scrum de atingirem seus objetivos. O Time de Integração Nexus possui os seguintes papéis:
- O Product Owner
- Um Scrum Master
- Um ou mais Membros do Time de Integração Nexus
Eles podem fazer parte dos Times Scrum Individuais (exceto o PO), entretanto eles precisam priorizar as atividades inerentes ao Time de Integração Nexus.
Product Owner do Time de Integração Nexus
Como num Nexus só há um Product Backlog e no Scrum só há um Product Owner (via de regra) para cada Product Backlog. As responsabilidades do Product Owner continuam sendo basicamente as mesmas:
- Maximizar o valor do produto desenvolvido de forma integrada;
- Priorizar e refinar constantemente o Product Backlog.
Scrum Master do Time de Integração Nexus
É o responsável por assegurar que o Nexus é entendido e suas regras são cumpridas. Ele pode fazer parte de um ou mais Times Scrum Individuais dentro de um Nexus.
Membros do Time de Integração Nexus
Os Membros do Time de Integração Nexus são os responsáveis por treinar e orientar os Times Scrum, que formam um Nexus, a implementarem e aprenderem sobre práticas e ferramentas de integração contínua, testes automatizados e etc. Além disso, eles treinam os Times Scrum sobre os padrões de desenvolvimento exigidos para que se obtenha um incremento integrado, com a qualidade esperada, ao final de cada Sprint. Assim como o Scrum Master, se suas obrigações estiverem sido satisfeitas eles podem integrar um dos Times Scrum Individuais.
Eventos do Nexus
Os eventos do Nexus são os mesmos previstos no Scrum. Inclusive os time-boxes permanecem proporcionalmente os mesmos. Portanto, teremos sempre a cada Sprint – além dos eventos previstos pelo Scrum para cada Time Scrum Individual (exceto Sprint Review Individual) – um Nexus Sprint Planning, um Nexus Sprint Review, um Nexus Sprint Retrospective e um Nexus Daily Scrum.
A novidade é que – muito embora o Schwaber tem recomendado que se invista cerca de 10% da Sprint com Refinamento e no Scrum Guide há apenas algumas alusões sobre o tema no tópico Product Backlog – consta no Nexus Guide, um tópico específico para o refinamento prevendo vários níveis dentro de uma sprint.
A ideia passada pelo Nexus é que quanto mais aumentamos a frequência, a duração e a eficácia do refinamento… menor será a complexidade do desenvolvimento e as dependências entre os Times Scrum Individuais.
O Nexus prescreve ainda que os eventos sejam divididos em duas ou três partes. Geralmente a primeira parte de um evento, tem como finalidade, permitir que o Time de Integração Nexus levante questões relacionadas a integração, gerando assim importantes entradas para a realização dos eventos individuais de cada Time Scrum. A segunda parte serve para que os Times Scrum alcancem, individualmente, os objetivos propostos pelo evento em questão e a terceira parte, se houver necessidade de acontecer – como no caso do Nexus Sprint Retrospective – será para consolidar o que foi planejado e/ou discutido nas duas primeiras partes.
Por outro lado, o Nexus Sprint Review é o único que substitui um Sprint Review Individual, pois a ideia de um Nexus é sempre a obtenção de feedbacks do incremento integrado.
Artefatos do Nexus
Praticamente foram mantidos os mesmos artefatos previstos no framework Scrum. Product Backlog, Nexus Sprint Backlog e Incremento Integrado.
A diferença é que o Nexus Sprint Backlog foi criado com o objetivo de compor todos os Sprint Backlogs dos Times Scrum Individuais. Além disso, ele se propõe a evidenciar as dependências e acompanhar o fluxo de trabalho durante as Sprints. Ele é atualizado diariamente no Nexus Daily Scrum.
Um Nexus Goal (meta) deve ser definido a cada sprint. Esta meta é única, e deve ser perseguida e atingida conjuntamente por todos os Times Scrum Individuais.
Para concluir, a Definição de Pronto é de responsabilidade do Time de Integração Nexus, pois é ele quem deve garantir um Incremento do Produto Integrado ao final de cada Sprint. Os Times Scrum Individuais devem aderir a esta definição, mas podem ter definições de pronto individuais mais rigorosas.
Enfim… se você, assim como eu, acredita que – daqui para um horizonte de no máximo 10 anos – o Scrum (ou algo parecido com ele) será uma realidade presente na maioria das empresas de TI; saber como escalá-lo deverá ser uma de nossas habilidades.
Creio que este resumo (em formato de post) seja um início. Para mais detalhes consulte o Nexus Guide.
Momento cabotino: Como fui um dos primeiros brasileiros a conquistar a certificação Scaled Professional Scrum (SPS) emitida pela Scrum.org farei, em breve, um post abordando este assunto. 
Saudações. Ψ
Café com o Scrum Master 
Parabéns pelo excelente artigo Pedro.
Direto e objetivo.
CurtirCurtido por 1 pessoa
Senhor Pedro, o senhor ARRASA!
CurtirCurtir
Lais Altube… quanta honra a minha receber sua visita no blog! Você é nota mil! Tamo junto, sempre!
CurtirCurtir