Especificidades do trabalho de uma equipe Agile em SAFe em relação ao Scrum na prática

Após a publicação entre amigos do primeiro artigo sobre Burn Down Chart, nos comentários a primeira pergunta feita foi: "Seria interessante saber mais sobre a sua experiência com SAFe". Por isso, neste artigo tentarei revelar as especificidades do trabalho em SAFe em relação ao Scrum na nossa prática. Não pretendo de forma alguma ser a verdade absoluta e ficarei feliz com quaisquer correções e esclarecimentos por parte dos colegas.

Primeiro, listarei em tópicos o mais essencial que diferencia o trabalho em SAFe do SCRUM, na minha opinião.

• Increment no Scrum e Program Increment no SAFe
• ART - Agile Release Train
• Quantidade de equipes que interagem
• PIPE
• SOS
• PO - não é dono do negócio
• RTE
• Quinto sprint para aprendizado
• System Demo

Increment no Scrum e Program Increment no SAFe. Na verdade são termos diferentes, mas é fácil se confundir porque ninguém usa entre nós o termo Program Increment, todos dizem apenas Increment - e esse já é outro termo, que é usado no SCRUM. Mas, em geral, eles são bastante semelhantes do ponto de vista de sentido, na minha opinião. Increment no SCRUM - é, em essência, o produto atual + as histórias planejadas para o sprint em estado concluído (que passaram pelo DOD da equipe). Program Increment - é o intervalo de tempo durante o qual o trem (Agile Release Train) entrega valor incremental em produção. Em duração, no nosso caso, são 4 sprints de 2 semanas para desenvolvimento e um sprint para aprendizado.

Agile Release Train - é uma equipe de equipes trabalhando em um único fluxo de criação de valor. Nós chamamos isso simplesmente de trem, mas pelo framework o correto é chamar de "Solution". No nosso caso, essa regra não é totalmente seguida e as equipes frequentemente trabalham em produtos diferentes do ponto de vista técnico, pois a maioria das funcionalidades de negócio é implementada de forma complexa e envolve vários produtos. Isso do ponto de vista técnico. Mas, tenho certeza de que alguém considera todos os sistemas de TI como um único produto da empresa e, talvez, isso seja até mais correto.

Quantidade de equipes que interagem no nosso SAFe é substancialmente maior, no total recomenda-se até 125 pessoas em um trem. Temos 3 trens e não em todos essa regra é seguida, há trens com mais de 125 pessoas. O SCRUM não descreve como interagir com outras equipes, pelo que sei, diferentemente do SAFe, onde há recomendações muito claras sobre isso. O artefato mais marcante, na minha opinião, para isso é o Program Board.

Nele são exibidas as inter-relações entre as equipes do trem e, discutindo-o, acontecem os eventos semanais Scrum Of Scrums (SOS) no nosso caso.

Aproximadamente a cada 2,5 meses (a cada 5 sprints) ocorre o evento PIPE - Programm Increment Planning Event. É quando todas as equipes distribuídas se reúnem em um único salão por 2 dias e planejam seus trabalhos para os próximos 2,5 meses. No processo desse evento surgem artefatos como o Program board, por exemplo, no qual são exibidas todas as dependências das equipes entre si para cada um dos trens, acima já mostrei como ele se parece. A tarefa do Scrum Master de cada equipe nesse evento é facilitar a identificação do máximo de dependências, depois, se possível, sua remoção (por meio da transferência de competências verbalmente, por exemplo, de uma equipe para outra ou por meio da transferência de uma dependência de uma equipe para outra, para que a equipe possa implementar de forma autônoma sua funcionalidade sem depender de ninguém). Na prática, é assim que acontece conosco. Primeiro as funcionalidades são decompostas em User Story, as User Story são distribuídas pelos 4 sprints. As funcionalidades são colocadas no Program Board e são estabelecidas as dependências de outras equipes que existem. Durante o evento isso é discutido e ajustado.

SOS - Scrum Of Scrum. Esse evento acontece uma vez por semana para cada trem separadamente. Os Scrum Masters de todas as equipes do trem se reúnem online, o Program Board do trem é transmitido e são discutidos os status de todas as dependências e funcionalidades das equipes do trem específico. Em essência, esse evento é necessário para a sincronização centralizada das equipes dentro do trem. Algo como um standup, mas uma vez por semana e não para a equipe, mas para os Scrum Masters.

PO (Product Owner) - não é dono do negócio. Há o Product Manager - ele trabalha com os Business Owners das respectivas áreas de negócio e, em essência, distribui as funcionalidades para os Product Owners. O Product Owner trabalha já diretamente na equipe - divide as funcionalidades em User Stories (no nosso caso, junto com a equipe) e nem sempre divide, mas estamos constantemente progredindo nessa direção.

RTE (Release Train Engineer - maquinista do trem. Scrum Master de Scrum Masters. Realiza os eventos SOS do seu trem. Interage com o Product Manager no nível de features. Facilita o PIPE.

Quinto sprint para aprendizado - sim, diferentemente do Scrum, aqui é destinado à equipe um sprint inteiro no final do incremento para aprendizado. Na prática, costumamos usá-lo em primeiro lugar para participar de treinamentos internos, inclusive sobre SAFe, mas não só. Cursos particulares e meetups procuramos agendar para esse período quando possível. Também temos desenvolvedores que ampliam seu stack durante o 5º sprint, para que haja possibilidade de cobrir a competência de alguém na equipe (dar suporte quando necessário).

System Demo. Como resultado do PIPE, cada equipe tem uma lista de metas para o incremento e cada uma dessas metas é avaliada pelo Business Owner do trem numa escala de 10 pontos. Isso se chama Business Value. Essas metas se dividem em principais e estendidas. As metas principais são aquelas em que a equipe não vê nenhum risco em alcançar. As estendidas são metas com riscos de alcance. Todas as metas são obrigatórias e o volume de trabalho é planejado para todas as metas. Na System Demo o Business Owner aceita os resultados do trabalho do incremento. Suponhamos que a equipe tinha 3 metas principais com avaliações 10, 6, 8 e 2 estendidas com avaliações 10, 3. Imaginemos que o Business Owner atribuiu respectivamente as seguintes notas: 8, 6, 4, 2, 0. Agora é possível calcular o percentual de alcance das metas: como 100% toma-se a soma inicial de pontos das metas principais, no nosso caso 10+6+8=24. Os pontos alcançados são contados considerando as metas estendidas (ou seja, 20 de 24 a equipe alcançou), portanto, como resultado, o percentual de alcance das metas da equipe será (20*100)/24 = 83,3%. Um resultado normal é considerado o alcance de 80% a 100%.

Em todo o resto trabalhamos conforme o SCRUM. Bem, ou quase em tudo :) Quanto à nossa experiência: posso dizer que, do meu ponto de vista, a evolução é evidente. Em um ano de trabalho as equipes cresceram muito, tornaram-se auto-organizadas, algumas equipes, é verdade, se desfizeram, mas mesmo nisso se percebe uma certa evolução. Ainda há espaço para crescer.

Comentários de colegas do facebook

«Zhenya, olá! Legal que você escreva, muito bem! Vou corrigir um pouco sobre os trens - eles se formam não em torno do produto, mas em torno do fluxo de criação de valor. E no varejo, do ponto de vista do SAFe, não temos um trem, mas um Solution. Apenas por conveniência de comunicação e simplificação do entendimento, continuamos a chamar isso de trem)»

– Konstantin Voronin (representante do escritório de projetos da Ingosstrakh)

«Bem, e talvez alguém note que, do ponto de vista do SAFe, a avaliação das metas ocorre no I&A; (onde o SD entra como parte, mas não está diretamente ligado à avaliação) e os próprios SD devem ocorrer a cada sprint (após a demo das equipes). Mas ainda estamos longe disso, por isso conscientemente chamamos tudo como está escrito no seu artigo)»

– Konstantin Voronin (representante do escritório de projetos da Ingosstrakh)

«Zhenya, continue, por favor, é muito útil!»

– Alexey Ionov (Treinador Certificado em SAFe)