O tão falado e polêmico SCRUM!

*Artigo de opinião

Conheça a metodologia SCRUM e saiba quais são suas principais características e aplicabilidade na Gestão Pública

SCRUM é um framework, um “jeito” de gerenciar projetos, cujo nome faz analogia a uma jogada de RUGBY, esporte que demonstra a força e união de uma equipe organizada para atingir um objetivo conhecido. O SCRUM surgiu em 1995 e foi criado por Ken Schwaber e Jeff Sutherland.

Aqui vou me ater ao contexto do serviço público e comentar sobre a agilidade e como o SCRUM pode ser utilizado na Gestão Pública. Sugiro que, caso você não tenha tido contato com o framework, acesse as referências mencionadas ao final deste artigo, para entender melhor os detalhes dele.

Como comentei no artigo anterior (Agilidade na gestão pública: funciona mesmo?), é muito importante entender como esse framework pode ser utilizado na Gestão Pública. Entendo que para utilizar qualquer metodologia, framework ou prática deve-se entender como ela funciona e qual valor agregado se espera com sua aplicação, bem como verificar possíveis adaptações necessárias.

Há 8 características importantes a se observar no SCRUM: entregas cadenciadas (sprints), times auto-organizáveis e multidisciplinares, documentação enxuta, reuniões diárias, revisões de entrega, retrospectivas, papéis e responsabilidades bem definidos e backlog conhecido. Confira-as a seguir:

1. Entregas cadenciadas (sprints): o SCRUM preconiza que as entregas ocorram em espaços de tempo acordados e conhecidos, as sprints, que levam de 2 a 4 semanas. Isso gera previsibilidade (eu sei o que foi acordado para a entrega e qual a previsão desta entrega) e cadência (o time trabalha com um tempo de entrega conhecido). Por mais que se tenha um projeto de médio a longo prazo, controlar as entregas por sprint faz com que todos vejam a evolução dele e as mudanças possam ser realizadas.

2. Times auto-organizáveis e multidisciplinares: nem sempre é possível contar com essa máxima, pois seguimos contratos firmados junto ao cliente, e esses contratos possuem funções específicas que precisam ser exercidas. Porém, no dia a dia, pode-se promover essa cultura de que todos os membros do time podem apoiar-se mutuamente, com autonomia e comprometimento de cada um.

3. Documentação enxuta: utilizam-se as user stories ou histórias de usuário, que em um português simples, pode-se explicar o que se deseja para um produto ou sistema. Isso tudo é muito prático e eficiente, mas muitas vezes nos vemos diante de contratos em que a documentação exigida é com casos de uso, que tendem a ser mais extensos por conterem muitos detalhes. Neste cenário, o que pode ser feito é redigir os casos de uso de maneira mais objetiva, verificar se eles precisam mesmo ser redigidos (não criar documentações extensas e que não fazem sentido para o contexto) e criar as histórias de usuário para o que for facilitar o trabalho do time de desenvolvimento (histórias que respondam às três perguntas: que / o que / para que). Também devem ser considerados documentos complementares às histórias, tais como regulamentos, decretos etc. 

4. Reuniões diárias: por mais que conversemos e vejamos as pessoas do time o tempo todo, a reunião diária traz muitos ganhos, visto que é focada e responde a questões fundamentais para saber o andamento do desenvolvimento de produto: O que eu fiz ontem? O que farei hoje? Estou dentro do objetivo da sprint (ou do planejado?).

5. Revisões da entrega: são reuniões realizadas para refletir sobre a entrega realizada e o que pode melhorar. Esse evento traz ganhos pois permite que todos do time tragam suas percepções e atuem com o ciclo de inspeção (como está tudo?) e adaptação (o que preciso mudar?).

6. Retrospectiva: oportunidade de todos do time refletirem sobre sua atuação, seu comprometimento nas entregas. É um evento extremamente benéfico pois dá voz aos membros, provoca empatia no time e foca no objetivo de que todos contribuam para a entrega e melhoria contínua.

7. Papéis e responsabilidades bem definidos: 

• Scrum Master é o guardião do SCRUM. É a pessoa com mais experiência em agilidade e quem implementa o framework, ou seja, um líder servidor. Num ambiente hierarquizado, este papel normalmente é exercido pelo líder técnico. 
• Product backlog: é a pessoa que mais entende do produto, o representante do usuário final, sendo a ponte entre o Scrum Master e os demais stakeholders. É ele quem traz esclarecimentos e prioriza as funcionalidades. Nem sempre na Gestão Pública o cliente pode assumir essa função. Então o Product Owner (PO) passa a ser um grande articulador entre as áreas e stakeholders.
• Time de desenvolvimento: são os designers, analista de requisitos, desenvolvedores e todos os envolvidos na confecção do produto. Todos trabalham juntos e podem exercer várias funções (ou não), de acordo com sua multidisciplinaridade (desde que não fira as cláusulas contratuais junto ao cliente). 

8. Backlog do produto conhecido: é a listagem de funcionalidades que precisam ser desenvolvidas para entregar o produto efetivamente. É de extrema importância que o time conheça o conteúdo do backlog para saber o que precisa ser feito, as prioridades e as complexidades de cada entrega. É uma prática que traz clareza para o time como um todo e que permite ao cliente visualizar as  entregas ao longo do tempo. Isso faz com que todos, independente de atuar com agilidade ou não, tenham entendimento do que precisa ser feito.

Diante do exposto, pode-se constatar que com um pouco de flexibilidade é possível usar o SCRUM no contexto público, fazendo algumas adaptações e tendo uma preocupação maior com a mudança de mindset que se faz necessária: entregar maior valor agregado ao cliente através uma nova forma de trabalho: mais colaborativa, mais focada nas necessidades do cliente e de pronta resposta às mudanças.

Referências bibliográficas:

Manifesto para desenvolvimento ágil de software

Surgimento do Scrum

The Scrum Guide

Scrum - A arte de fazer o dobro do trabalho na metade do tempo

*Os artigos aqui divulgados são enviados pelos redatores voluntários da plataforma. Assim, o Radar IBEGESP não se responsabiliza por nenhuma opinião pessoal aqui emitida, sendo o conteúdo de inteira responsabilidade dos autores da publicação.