O Papel dos Referências, no Scrum Escalável

Um dos principais desafios do Scrum Escalável, é criar um fluxo de comunicação, que garanta uma visão compartilhada - e única - entre todos os times. Principalmente, entre aqueles que compartilham o mesmo Product Backlog.

E, quando dizemos compartilhar a mesma visão, significa que todos os times entendem o produto da mesma forma: em termos de negócio, arquitetura, padrão de desenvolvimento, testes e etc.

Esta é uma missão que pode parecer simples, quando temos poucos times - cerca de 5 ou 6 times -,mas imagine o quão difícil é realizar essa tarefa, quando falamos em uma composição de 10, 20, ou 30 times - imagine com 50!

Para se ter uma ideia, a regra para se saber quantos caminhos de comunicação existem, entre os diferentes times, existe a seguinte equação: Qtde Times * (Qtde Times - 1) / 2. Exemplo: Se temos 5 times, então temos: 5 * (5 - 1) / 2 = 10. Com 10 times, temos: 10 * (10 - 1) / 2 = 45. E com 20 times, temos: 20 * (20 - 1) / 2 = 190. 

Se manter a mesma comunicação, entre 10 canais é difícil, imagina com 190! Como se pode ver, o crescimento dos canais de comunicação, deixa a tarefa de compartilhar a mesma visão, extremamente complicada.

Para resolver este problema, criou-se a função de Referências. Mas, para entender seu papel, vamos voltar um pouco e entender a divisão entre capítulos.

Apesar de o Scrum Guide dizer que o Scrum Team, deveria ser multidisciplinar, é muito comum vermos times, onde cada integrante é especialista em alguma tecnologia. Ex: em um time, temos especialistas em desenvolvimento Backend, Frontend iOS, Frontend Android, Tester, e assim por diante. Assim, os integrantes dos times, com as mesmas áreas de atuação, forma Capítulos (Chapters).

Já os times com missões semelhantes, forma Tribos (Tribes). Essa semelhança pode ser em relação à entrega dos times - ex: times que desenvolvem o mesmo App; ou responsáveis pela área de Clientes, ou Fraudes; etc.

E ainda temos a Agremiação (Guild), que é composto pelos integrantes do mesmo Capítulos, mas de diferentes Tribos.

Então, o papel do Referência, no Scrum Escalável, é aquele que tem a responsabilidade de criar um fluxo de comunicação, dentro de seu Capítulo e, da mesma maneira, nas Associações. Assim, todos os colaboradores, com a mesma área de atuação, terão uma visão única, em relação ao negócio, tecnologia, arquitetura e etc.

Pode parecer pouco mas, manter uma visão única entre todos os times, traz inúmeros benefícios como:

• Facilitar a rotação de profissionais entre times;
• Agilidade na manutenção do produto;
• Padronização de cultura de desenvolvimento;
• Possibilidade de criação de um Backlog único do produto, a ser compartilhado pelos times.

Mas os Referências de Capítulo, não devem ser vistos como gerentes funcionais, ou hierarquicamente acima dos colaboradores. Seu papel fundamental, é o de facilitador.

Scrum: Afinal o que significa ser empírico, iterativo e incremental?

De acordo com o Guia Scrum, o framework Scrum é fundamentado no empiricismo e emprega uma estratégia iterativa (e não interativa) e incremental. Mas a final o que significa cada uma dessas palavras?

Independente de seus significados no dicionário, para o Scrum, seus significados são:

* Empiricismo: o conhecimento provém de experiências e toda decisão é embasada no que se conhece e que se tem como verdade, até o momento de sua tomada. 

Na prática, isso significa evitar adotar premissas como verdades, sem sua efetiva comprovação. Adotar premissas é uma técnica muito comum, em projetos waterfall. No começo do projeto, quando estamos na fase de levantamento de requisitos, não temos maneiras eficientes de garantir aquilo que definimos. Então, criamos premissas que, caso não se comprovem, serão tratadas como mudanças de requisito (change request). 

O problema em se trabalhar assim é que, o momento de se testar a premissa é, geralmente, tardio; na fase de testes - após um longo período de design e desenvolvimento. Caso algo tenha que ser alterado, seu custo será alto, tanto em prazo, quanto financeiro. Ex: imagina que existe um projeto de um site e assumimos a premissa de que todos nossos clientes utilizam o navegador Internet Explorer 9.0. 

Então, todo desenvolvimento e testes são feitos, com base nesta premissa. Porém, no momento dos testes finais, nas máquinas dos clientes, identificamos que 40% utilizam o navegador Chrome. Imaginem o custo, de termos que alterar TODAS as funções desenvolvidas e que funcionam apenas no Internet Explorer.

Para evitar tal situação, o Scrum adota a prática de só decidir - e assim trabalhar - com fatos concretos. Caso não se tenha experiência anterior, ou fatos que embases uma premissa, o time trabalha para "comprar" o conhecimento. POC (provas de conteito), são uma técnica comum, para se adquirir um conhecimento importante e que ainda não temos. 

No exemplo acima, em vez de assumir uma verdade, o time faria um trabalho de campo, para verificar, exatamente, quais navegadores são utilizados pelos clientes. Isso evitará a necessidade de alteração futura, com menos custo e maior assertividade.

* Iterativo: iteração significa repetição. Assim, o conceito de iterativo, segundo o Scrum, significa realizar ciclos constantes (Sprints) repetidas vezes. Ciclos constantes - em duração, rotina de eventos, pessoas envolvidas (time) e ferramentas (tecnologia, linguagem de desenvolvimento, etc.) - elevam o conhecimento, velocidade de entrega e qualidade.

Independente do contexto (pessoal, profissional, entretenimento, etc.), toda vez que refazemos algo, o fazemos melhor. É aquele ditado: "a prática leva a perfeição". Logo, quanto mais praticamos, melhor nos tornamos no que fazemos.

Este conceito parece óbvio e simplório de mais. Mas, se olharmos sob outra ótica, veremos um risco que precisa ser gerenciado. Se toda vez que fazemos algo, o fazemos melhor; então aquilo que fizemos ano passado, certamente poderia ser melhorado - afinal, desde o ano passado, praticamos mais e, certamente, hoje fazemos melhor!

Sob esta perspectiva - e com foco no âmbito profissional -, a cada vez que desenvolvemos um entregável - seja uma funcionalidade de sistema, uma planilha Excel, um relatório, ou qualquer outro tipo de entregável - deixamos ali um débito técnico. Este débito é inevitável, uma vez que com o passar do tempo, a forma como fizemos o entregável fica desatualizada. 

Desta maneira precisamos, de tempos em tempos, revisitar aquilo que fizemos no passado - desde que ainda utilizado, lógico - para verificar se não poderíamos aprimorar algum ponto importante. Caso não revisitemos nossas entregas, corremos o risco de ficarmos tão desatualizados, que qualquer nova melhoria se torne complexa de mais, a ponto de não ser implementada - ou ter um custo mais caro, de implementação.

* Incremental: Este é o ponto mais difundido, para àqueles que já ouviram falar de Scrum. Incremental significa entregar partes de um todo, a cada final de ciclo (Sprint).

O benefício de se utilizar esta técnica, é que o cliente não precisa esperar todo desenvolvimento, para usufruir de benefícios do produto / entrega. 

Ao mesmo tempo, ao ter acesso constantemente às entregas (final de cada Sprint) - e mesmo que parciais - o cliente pode nortear o time de desenvolvimento, através de feedbacks contantes, sobre o que gostou ou não, do produto entregue.

Outro benefício, é que o cliente pode decidir mudar os rumos do produto - ou até parar seu desenvolvimento - no momento que entender ser necessário. Isso reduz riscos e prejuízos, aumenta a confiança, entre negócios e time de desenvolvimento, e produz um produto mais próximo às necessidades reais do cliente final.

Enfim, para se ter um melhor resultado, na utilização do Scrum, é importante analisar o guia com um olhar mais profundo sobre seus pilares, valores e técnicas. Buscar entender cada uma das iniciativas ali apresentadas. 

Afinal, como Mike Cohn diz no prefácio do livro Scrum Essencial (Kennet S. Rubin, 2012), existem milhões de maneiras de se fazer um hambúrguer, assim como existem bilhões de maneiras de se implementar o Scrum. Enquanto não existe certo ou errado, existe uma maneira melhor e pior de se fazer um hambúrguer, ou implementar o Scrum.

Product Backlog e Scrum Master. Uma ligação mais próxima do que se pensa

De acordo com o framework Scrum, o Product Owner (P.O.) é o responsável pela criação, priorização e gestão, do Product Backlog (P.B.). Este é um fator importante, para uma boa gestão do produto. Entretanto, o mesmo framework diz que o Scrum Master "serve" o P.O. na busca por técnicas, que resultem numa gestão eficaz do Product Backlog e garantir que o P.O. entenda como maximizar seu valor. Mas o que este "servir" significa, então?!

Primeiro, não significa que o Scrum Master atuará na escrita dos Product Backlog Items (P.B.I.) - ou histórias -, na priorização de itens ou intercederá, nas conversas entre o P.O. e seus Stakeholders. Isto deve ser responsabilidade do P.O. 

Além disso, devemos lembrar que o time de desenvolvimento é responsivo ao P.O. Isto é, ele deve esperar que o P.O crie e priorize os itens, em que o time trabalhará - salvo exceções. E é neste ponto, que o Scrum Master torna-se importante, no processo.

O Scrum Master deve certificar-se, que o P.O. possui um backlog preparado e priorizado. Parece trivial, que isso ocorra; mas é impressionante o número de times que trabalham sem um backlog mínimo. Uma boa prática, é ter um backlog com itens para 2 Sprints. Assim, o time poderá antecipar dependências e bloqueios e, caso o projeto / produto tome uma nova direção, não haverá muito trabalho perdido. Vale lembrar que, ter um bom backlog significa que todos seus itens possuem o nível de informações necessárias, para que o time entenda o que deve ser feito - o que varia entre times e itens do backlog.

Porém, apenas ter um backlog não garante que este esteja apto à ser desenvolvido. Para tal, é importante que o time o conheça bem, assim como que estime o esforço necessário, para sua entrega. O framework Scrum sugere um evento chamado de Refinamento, como forma de preparar o backlog, para seu desenvolvimento. 

Refinamento, é um evento que deve ocorrer durante toda Sprint, com tempo máximo de 10% de todo seu tempo útil. Assim, se uma Sprint tem prazo de 2 semanas, o Refinamento deverá tomar, no máximo, 8 horas (10% de 80 horas). Nele, o P.O. apresenta o backlog para o time, para que este possa tirar dúvidas, validar que possui toda habilidade necessária, para entrega, e estimar seu esforço.

Portanto, novamente o Scrum Master deve garantir que os eventos de refinamento ocorram, durante a Sprint. Quanto mais cedo na Sprint este evento iniciar, mais rico será seu resultado; pois o time poderá ter mais tempo para entender os itens, do backlog, e estudá-los, antes da reunião de planejamento - ou Planning.

Há, ainda, outros pontos onde o Scrum Master apoia, ou "serve" o P.O, em relação ao Product Backlog. Através do acompanhamento da velocidade do time - ou capacidade de entregas, por Sprint - o P.O. pode avaliar o prazo necessário, para finalização de uma funcionalidade, MVP ou release.

Enfim, o Scrum Master não é o guardião do Product Backlog, tão pouco seu representante. Mas é certo que suas relações são bem próximas.