Profissionais TI - Pra quem respira informação

Olá, amigos!

Neste artigo quero compartilhar um pouco mais sobre a certificação Scaled Professional Scrum (SPS) da Scrum.Org. Trata-se de uma certificação baseada no framework Nexus, criado por Ken Schwaber com apoio de outros membros do mundo ágil. Obtive esta certificação recentemente e gostaria de compartilhar algumas dicas com os amigos.

O framework Nexus

O propósito do framework Nexus é auxiliar na coordenação da entrega de produtos que necessitem entre 3 a 9 equipes Scrum para seu desenvolvimento. 

O framework utiliza a estrutura básica do Scrum com:

• Um único Product Owner para todo o produto
• Um único Product Backlog
• Sprint Backlog
• Scrum Master
• 3 a 9 Equipes de Desenvolvimento
• Sprints
• Sprint Planning
• Daily Meeting
• Sprint Review
• Sprint Retrospective
• Potencial Incremento do Produto

O que temos de diferente?

• Nexus Sprint Planning – Dividida em 2 partes, onde na primeira parte representantes adequados de cada equipe entendem com o Product Owner qual a meta geral da Sprint a ser atingida (Nexus Goal) e na segunda parte as Equipes Scrum realizam suas Sprint Plannings individuais, definindo suas metas individuais (Sprint Goals) necessárias para atingir a meta geral e criando seus Sprint Backlogs que serão consolidados no Nexus Sprint Backlog.

• Nexus Integration Team – Equipe responsável por garantir que os trabalhos das Equipes estejam integrados e possíveis problemas de dependências entre as equipes sejam resolvidos. Esta equipe é composta pelo Product Owner, por um Scrum Master que garanta o andamento do Nexus (pode ser um Scrum Master de uma das Equipes Scrum ou não) e por membros técnicos que possuam conhecimento em técnicas de integração (que podem ser das Equipes de Desenvolvimento das Equipes Scrum ou não).

• Nexus Daily Scrum – Reunião diária realizada com representantes adequados de cada Equipe Scrum com o intuito de se discutir dependências e gerar insumos para as reuniões Daily Scrum das Equipes Scrum individuais.

• Refinement – O Product Backlog Refinement ou Grooming, considerado uma boa prática em Equipes Scrum individuais, torna-se uma reunião obrigatória no Nexus, cujo intuito é identificar dependências, que as Equipes Scrum selecionem os Product Backlog Items (PBIs) que pretendem trabalhar e façam a decomposição, revejam priorização e estimativas dos PBIs.

• Nexus Sprint Review – Elimina a necessidade da Sprint Review individual de cada Equipe Scrum, pois a entrega final da Sprint deve ser um potencial incremento de produto integrado com os trabalhos de todas das Equipes Scrum.

• Nexus Sprint Retrospective – Dividida em 3 partes, onde na primeira parte representantes apropriados das Equipes Scrum compartilham seus desafios sobre os itens referentes à integração dos trabalhos. Na segunda parte, as Equipes Scrum realizam suas retrospectivas individuais levando em consideração os insumos gerados pela primeira parte da reunião. Na terceira e última parte, os representantes apropriados das Equipes Scrum voltam a se reunir para criarem o plano de ação de melhorias para todo o Nexus.

A certificação Scaled Professional Scrum

Sobre o exame da certificação você irá encarar:

• Total de questões: 40
• % de acerto: 85% (34 acertos)
• Tempo: 60 minutos
• Idioma: Inglês
• Valor: 250 USD

Para se inscrever você deve acessar o site https://www.scrum.org/professional-scrum-certifications/scaled-professional-scrum-assessment, clicar em Buy Assessment para realizar o pagamento e obter o voucher para a realização do exame.

O exame é realizado de forma on-line e sem monitoramento via WebCam.

As dicas que eu posso te dar para seu estudo são as seguintes:

• Ler e reler diversas vezes o Nexus Guide, de preferência em Inglês que é o idioma do exame
• Ter alguma experiência prática com modelos escalados ajuda bastante, pois caem diversas questões situacionais no exame.
• Resolver os simulados da Scrum.Org repetidamente até manter uma média de 100% de aproveitamento.
• O curso preparatório não é obrigatório mas no meu caso ajudou a incorporar novos pontos de vista sobre modelos em escala que ajudaram, principalmente, nas questões situacionais.
• Resolver os simulados do ótimo blog do Simon Kneafsey repetidamente até manter uma média de 100% de aproveitamento.
• Resolver os simulados do blog do Mikhail Lapshin repetidamente até manter uma média de 100% de aproveitamento.
• Fazer o exame com o Nexus Guide do seu lado e sempre consulta-lo se você tiver a mínima dúvida.

Sobre as questões do exame, algumas outras dicas:

• Caem algumas questões de teoria do framework, então ter o Nexus Guide “devorado”, e ao seu lado no momento do exame, será de extrema valia.
• Nas reuniões Nexus, a participação de todos os membros de todas as Equipes Scrum não é obrigatória. Somente a participação dos representantes apropriados.
• Mesmo com várias Equipes Scrum temos um único Product Owner e um único Product Backlog.
• “Mas Vitor, como um Product Owner vai dar conta de 9 equipes?”. O Product Owner pode delegar trabalhos de decomposição e refinamento de requisitos para membros apropriados das Equipes Scrum, mas ele sempre será responsável (accountable) pelo produto.
• Aliás, tome cuidado na diferença entre os termos responsible (aquele que deve realizar a atividade) e accountable (aquele que deve garantir e presta contas pela atividade, mas não necessariamente a realiza).
• O Nexus Integration Team é responsável (accountable) por garantir que a integração entre as Equipes Scrum seja realizada e possíveis problemas de dependência entre Equipes sejam mapeados e identificados.
• As Equipes Scum são responsáveis (responsible) por realizarem todas as atividades necessárias para integrarem seus trabalhos e garantirem o potencial incremento de produto.
• Técnicas de integração contínua são necessárias para auxiliar na integração automática dos trabalhos. Integrações manuais podem gerar esforço extra e possíveis problemas. 
• Tente ao máximo não escalar o modelo. Tente resolver os problemas com a equipe atual refinando o Product Backlog, refinando a arquitetura e, principalmente, resolvendo suas disfunções e débitos técnicos. Uma frase marcante do curso que fiz, e bem apropriada para tempos onde está surgindo uma “síndrome de Homem-Aranha” e todo mundo resolveu “escalar o ágil” em um “passe de mágica” sem resolver seus problemas básicos de legado e processos: “Escalar Scrum em um ambiente cheio de disfunções só servirá para escalar estas disfunções”.
• Preocupação extrema com a tríade: Dependências x Débito Técnico e Arquitetura
• O foco do Nexus é controlar e buscar minimizar ao máximo as dependências entre as Equipes. Para isso pode ser necessário revisar o Product Backlog, a arquitetura ou até mesmo composição das Equipes Scrum.
• Tenha em mente que aumentar a quantidade de Equipes não significa que a produtividade irá aumentar na mesma proporção, uma vez que existe uma curva de aprendizado e maior complexidade na gestão das dependências. Aliás, qualquer mudança na estrutura de uma Equipe Scrum pode provocar alterações na produtividade.

Outros modelos de escala

Quem conhece e acompanha meu trabalho sabe que procuro não me apegar a ferramenta e sim ao resultado. O foco deste artigo foi falar exclusivamente sobre o  Nexus, mas existem outros frameworks que podem ser mais aderentes ao problema que você precisa resolver, ou mesmo complementar o Nexus. São eles:

• SAFe
• LeSS
• DaD
• Scrum At Scale

E na prática? Funciona?

Compartilho um exemplo de roadmap integrado em um projeto acadêmico realizado por uma das maiores instituições privadas de ensino do Brasil.

Então posso dizer que funciona, mas traz uma série de desafios e preocupações. E a grande dica: primeiro garanta que seu Scrum “arroz-com-feijão” funciona para depois escalar o modelo. Escalar o caos só trará mais caos. Mas esta é uma discussão para outro artigo! 😉