SAFe e os Desafios do Ágil em Escala: Mantendo a Simplicidade em Estruturas Complexas
Um dos grandes paradigmas da metodologia ágil é a simplicidade, porém como manter essa simplicidade com uma estrutura complexa e de maneira escalada? Grandes frameworks nos ajudam a organizar as ideias, um deles e talvez o mais famoso é o SAFe (Scaled Agile Framework). Nele são previstas diversas cerimônias e estruturas para que seja possível escalar o SCRUM ou outra metodologia que esteja utilizando. No artigo de hoje falaremos principalmente do SCRUM.
Quando a metodologia ágil começou a tomar forma, se pensava que era uma abordagem mais voltada a projetos simples, coisa de Startup. Mesmo os dias atuais ainda pode ser difícil de convencer os mais tradicionais de que uma metodologia ágil pode entregar muito mais rápido que um método tradicional. Afinal de contas, SCRUM é sobre aceleração!
Primeiro de tudo, qualquer metodologia ou framework, ágil ou não, irá definir uma série de regras e padrões. Por mais enxunto que a metodologia ágil possa ser, ela define sim alguns padrões. No SCRUM temos o o SCRUM Guide que nada mais é que basicamente um livro de regras, mas calma! Apesar de existirem algumas regras, elas não são a verdade absoluta. Primeiro de tudo é saber usar cada uma delas a seu favor ou então estará fadado ao fracasso.
SCRUM Escalado
Tenha em mente que para ententer o SCRUM escalado e seus desafios, você deve entender primeiro como ele funciona em um escopo menor, mais restrito, ou seja, como UM único time SCRUM funciona. Sem isso, não é possível escalar. Se você tiver um ambiente caótico só irá espalhar o caos, tenha isso em mente.
O início da escala seria o conhecido como “SCRUM of SCRUMS”, onde os times se reúnem para alinhar e ajustar suas dependências entre sí.
Basicamente é o modo em que vários times SCRUM conseguem trabalhar em conjunto, alinhados a um mesmo objetivo.
Entendendo o SAFe
O Scaled Agile Framework (SAFe) é um dos frameworks mais populares globalmente, oferecendo uma visão abrangente e diversas cerimônias adaptáveis.
Este está entre os 3 mais famosos no mundo. E não é por acaso, pois nele temos uma ampla visão do projeto e uma vasta opção de cerimônias que podem ser adaptadas nos mais diferentes tipos de projetos.
O principal, na minha opinião, é a parte de planejamento de PI (Planning Interval). O nome não é tão importante, mas pense que, você gerencia um backlog de um conjunto Sprints. Chame como quiser, Quarter, Trimestre, Bimestre, etc. O importante é, Reduza seu escopo em um espaço de tempo menor que o ano inteiro! Basicamente isso. Quebre suas atividades e inicie seu período com as atividades já estimadas e refinadas, em READY! Neste ponto você terá 3 ou 4 Sprints já estimadas, alocadas de acordo com a previa de capacidade de cada time. Neste momento é muito importante mapear principalmente dependências e riscos que já são visíveis no início do período. Obviamente, ao início de cada Sprint você começa com a planning e faz aquele ajuste no que for preciso, revisa cada tarefa e estima ou refina novamente, caso necessário.
Não entraremos muito no detalhe do time, o ponto aqui é como o SCRUM escalado funciona, então entenda que dentro de cada time você segue rodando o SCRUM, normalmente.
Um pouco do Framework
Semanalmente, é previsto que você tenha uma reunião entre as demais lideranças dos projetos SCRUM, os Product Owners, Scrum Masters e Project Managers. Não necessariamente na mesma reunião, mas é mandatório que haja um alinhamento do andamento de cada um dos times, para eliminar possíveis bloqueios entre times.
Neste momento você irá revisar o andamento das Features e Epicos do seu projeto, lembre-se, ao final do seu PI deve haver alguma entrega consistente, entrega de valor ao seu cliente.
No SAFe, cada conjunto de SCRUM Teams é chamado de Agile Release Train ou ART e cada um dos ARTs é coordenado por um Release Train Engineer ou RTE, que simplificando faz um papel parecido com o do Scrum Master, mas ele gerencia e lidera os times dentro de um ART, provendo ensinamentos e liberando dependências que possam existir.
Desafios e obstáculos
Talvez o maior desafio, de qualquer time, seja a comunicação e a resistência à mudança.
Então, se sua empresa está precisando de uma solução escalada de SCRUM é porque sua estrutura não deve ser trivial. Existem particularidades que serão difíceis de simplesmente encaixar em um modelo, por mais complexo e versátil que ele possa ser. Sempre vai existir alguma situação específica em que o framework não atende você, nesse caso você adapta. Todavia, provavelmente você precisará mudar seu processo, o que pode ser doloroso, pois adaptar o modo de executar o framework, pode ser traiçoeiro e muita gente começa por aqui.
Avalie bem a abordagem que irá seguir. Tome como base a ideia de que se você está buscando melhorar a sua maneira de trabalho, melhorando os resultados. Parece óbvio, mas você não conseguirá resultados melhores fazendo as coisas da mesma maneira. Então, o conselho é… mude primeiro, avalie o resultado e adapte o que for preciso.
Um dos grandes desafios em estruturas escaladas será em grande parte a comunicação e alinhamento entre os times. Entendendo que o SCRUM já esteja dominado por parte das equipes, foque em difundir a comunicação. Aderir a uma única ferramenta de controle do processo e das atividades irá ajudar. Evite diferentes planilhas e meios de controle, pois sua informação será dividida e eventualmente irá se perder. Procure saber qual será a ferramenta adotada pela sua empresa e foque nela, realize o máximo das atividades nessa ferramenta, mantenha ela sempre atualizada. Evite ter informações fora dela, pois isso irá minimizar sua margem de erro e qualquer pessoa com acesso aos dados poderá saber o andamento do projeto sem a necessidade de uma exaustiva reunião.
Escopo e backlog
Reduza o escopo do seu backlog ao mínimo! Se um item está muito velho, descarte. Lembre-se de não se apegar a User Stories ou Features. Se algo for realmente importante, irá voltar.
Este pensamento pode parecer radical de começo, mas quem já teve aquele item de backlog aberto há mais de 2 anos e que ninguem sabe se foi ou não resolvido? Provavelmente foi e, se não foi, ou não faz mais sentido ou então não era tão importante assim, caso contrário já haveria sido tratado de alguma forma.
Defina um limite para os seus itens de backlog, baseado no tempo de entrega dos itens dos seus times, provavelmente algo maior que 2 ou 3 anos já não faz mais tanto sentido ou não tem tanto valor para sua área de negócio. Logo são candidatos há, pelo menos, uma quarentena e futuramente serem fechados ou até mesmo excluídos. Há uma forte discussão sobre excluir itens de trabalho, mas essa é uma discussão para o futuro.
Agora que seu time está com o caminho livre, backlog ajustado, basta rodar! Certo? Basicamente sim, mas não!
Considere agora que você passou uma semana planejando o próximo PI e, ao iniciar a Sprint 1, alguém mudou seu plano e incluiu itens não planejados na sua Sprint, logo de cara. O que fazer?
Apesar da sensação de que um vendaval soprou no seu castelo de cartas, nem tudo está perdido. Reavalie a capacidade da sua sprint, converse com o PO e reveja a prioridade do que sobrou. Como funciona na sprint, o planejamento do PI também irá se alterar no decorrer do tempo, então mantenha-o sempre atualizado de acordo com o andamento e levante as alterações durante as reuniões de alinhamento que forem ocorrendo.
Algumas considerações
O grande ponto é sobre manter o backlog atualizado, organizado. Inicialmente mantenha este o seu foco, tente seguir seu planejamento, force um pouco se precisar. Literalmente faça acontecer, como planejado.
Claro que existirão momentos em que o plano vai precisar ser ajustado, principalmente quando estamos falando de meses de trabalho, porém considere que o plano foi feito por algum motivo. Então, a cada mudança de contexto que possa existir, questione se o objetivo final ainda segue o mesmo.
Caso o objetivo mude, talvez seja a hora de revisitar todo o planejamento.
E ai? Essa postagem ajudou você de alguma forma? Já utiliza ou conhece o SAFe? Quais seus desafios utilizando ele?
Deixe um comentário