O Scrum foi criado por Jeff Sutherland, Ken Schwaber e Mike Beedle (SCHWABER, 2004), tendo como foco o gerenciamento de projetos de desenvolvimento de software. A ideia central é que o desenvolvimento de sistemas envolve múltiplas variáveis ambientais e técnicas que podem ser alteradas durante o processo (ABRAHAMSSON et al., 2002). A Figura 6 traz uma referência para a aplicação desse método.
Figura 6: Modelo de referência para gerenciamento com SCRUM.
Ele se baseia no uso de iterações para realizar o projeto. Uma iteração é um período de tempo com duração fixa no qual um conjunto de atividades são realizadas (DRURY; CONBOY; POWER, 2012). O Scrum opera da seguinte forma: ao início da iteração a equipe revisa o que deve fazer e seleciona as atividades priorizadas que acredita ser possível realizar durante a iteração, se comprometendo a entrega-las ao final desse período, tendo a liberdade para trabalhar nesse tempo e apresentando, ao final, um incremento de funcionalidades e valor aos stakeholders, que as inspecionam e podem sugerir melhorias e adaptações (SCHWABER; SUTHERLAND, 2011).
Logo, o Scrum não trabalha com uma fase de desenvolvimento em um determinado tempo, mas sim, com uma entrega em um determinado tempo, devendo ao final da sprint ter incorporado algum incremento de valor ao produto/ serviço (RUBIN, 2012).
Por meio desta abordagem, o Scrum adota a estratégia de deixar as opções “em
aberto”, procurando atrasar o comprometimento com uma solução que seja irreversível até o último momento possível (RUBIN, 2012). Com isso, além de evitar custos de retrabalho, também procura estimular a exploração de soluções possíveis, incentivando a inovação.
Quando o Scrum é usado, o trabalho é organizado para rapidamente criar uma solução validada, por meio da confirmação ou refutação de uma suposição realizada (RUBIN, 2012). Esse autor também argumenta que o trabalho tem como princípio a validação rápida de suposições, alavancagem de múltiplos loops de aprendizados concorrentes e organização do fluxo de trabalho para rápido feedback e avaliação.
Os principais elementos do Scrum, segundo Schwaber (2004), são: o product backlog, a sprint planning meeting, o sprint backlog, a sprint, a daily scrum e a sprint review meeting, retrospective meeting. Todos eles devem estar presentes no decorrer de uma iteração. O product owner tem uma visão do que se pretende criar, contudo, como a mesma geralmente é grande e complexa, ela é desmembrada através do gromming em partes menores que são colocadas em uma lista priorizada denominada product backlog (RUBIN, 2012). Esse backlog define os requisitos funcionais e não funcionais que devem existir para que a visão seja entregue (SCHWABER, 2004). Sendo assim, o grooming é composto pelas seguintes atividades: a criação e refinamento dos itens do product backlog, sua estimação e priorização.
O product backlog é um conjunto de requisitos definidos com investidores, parceiros e outras pessoas envolvidas no projeto, e formam uma lista de atividades a serem desenvolvidas durante o empreendimento. Um subconjunto do backlog, denominado Sprint
backlog, é então selecionado e ordenado em uma lista de atividades a serem desenvolvidas durante a iteração (SCHWABER, 2004), descrevendo, através de tarefas detalhadas, como a equipe planeja projetar, construir, integrar, testar e selecionar este subconjunto de atividades selecionadas para a sprint (RUBIN, 2012).
A construção do sprint backlog é feita durante uma reunião denominada Sprint planning, na qual são definidos o número e as atividades a serem realizadas na iteração. Esta reunião possui duas partes: na primeira o Product Owner apresenta os itens do backlog de maior prioridade para a equipe que o questiona sobre o conteúdo, propósito, significado e intenções. Na segunda, a equipe seleciona as atividades que acredita ser possível de realização durante a iteração e a planeja, sendo responsável por gerenciar o seu trabalho (SCHWABER, 2004).
Durante a sprint a equipe executa as atividades planejadas. Diariamente acontece uma reunião rápida denominada daily scrum, na qual se define as tarefas a serem realizadas no dia e discutidos os resultados do dia anterior (SCHWABER, 2004).
Por fim, a equipe completa a sprint por meio de duas atividades de inspeção e adaptação: a sprint review e a sprint retrospective. A primeira tem como objetivo inspecionar e adaptar o produto que está sendo construído, sendo crítica a reunião que acontece entre os participantes (equipe, stakeholders, patrocinadores, clientes e scrum master). A interação entre eles deve ser focada na revisão das atividades recém-finalizadas, no contexto do esforço de desenvolvimento, podendo resultar em adaptações e correções a serem incorporadas no product backlog (RUBIN, 2012).
Já a sprint retrospective é uma oportunidade de se inspecionar e adaptar o processo. Durante essa retrospectiva a equipe, o scrum master e o product owner se reúnem para discutir o processo Scrum, focando em sua melhoria contínua (RUBIN, 2012). Segundo esse autor, ao final da reunião a equipe deve ter identificado e se comprometido com algumas ações de melhoria a serem realizadas na próxima sprint.
Por fim, com relação aos papéis no Scrum, esses também possuem algumas diferenças com relação ao GP tradicional, sendo apenas três: Product Owner (PO), a equipe de projetos e o Scrum Master (SM) (SCHWABER, 2004).
O Product Owner é responsável por representar os interesses dos stakeholders/ clientes, dar suporte no projeto, ajudar na confecção do Product Backlog, além de priorizar e validar as atividades realizadas durante a Sprint (SCHWABER, 2004).
A Equipe de Projetos é responsável por desenvolver as funcionalidades, tendo como características serem autogeridas, auto-organizadas e multifuncionais assumindo, desse modo, uma responsabilidade coletiva pelo sucesso do projeto.
Já o SM é responsável pelo sucesso do método, ensinando suas práticas e rituais para todos os envolvidos no projeto, também devendo conciliar a cultura da empresa e o método, de modo a entregar os resultados esperados, assegurando que todos sigam as regras e práticas do Scrum (SCHWABER, 2004).
Com relação à documentação, o Scrum define quatro relatórios a serem criados pelo PO e pelo SM. O primeiro é a lista do product backlog no início da sprint previamente executada. O segundo é uma lista para a próxima sprint. Também são elaborados o relatório de mudanças, que detalha todas as diferenças entre as duas listas anteriores, além de sumarizar o que aconteceu durante a sprint e as adaptações feitas no projeto após a sprint review, e o quarto é o relatório burndown do product backlog (SCHWABER, 2004).
Observando a estrutura do método e seus papéis, percebe-se que a criação de conhecimento acontece durante todo o processo de desenvolvimento, por meio da solução dos problemas que aparecem. Também ocorre nas interações com o PO, tanto na formulação do backlog e priorizações, quanto na validação.
Como pontos fortes, têm-se as reuniões de Sprint planning, review e retrospective, que são momentos propícios para reflexão, aprendizado e melhoria contínua. Sendo assim, a equipe a cada iteração, reflete sobre o produto e sobre ela mesma, melhorando suas estimativas e o aprendizado de forma geral.
Uma dificuldade no uso do Scrum, e dos projetos de forma geral, é a realização de grandes empreendimentos, com vários colaboradores e interdependências. O Scrum prega, nesses casos, a formação de várias equipes trabalhando em conjunto, como forma de ganhar escala. Como é de se esperar, esses projetos apresentam desafios na coordenação, integração e também na gestão do conhecimento.
Uma prática comum para coordenar o trabalho entre equipes de projetos é a realização do Scrum of Scrums (SoS), que é especialmente adequada para pequenos esforços de desenvolvimento, com apenas algumas equipes ou com poucas dependências que requeiram solução (RUBIN, 2012; SCHWABER, 2004). Ela consiste em uma reunião diária com a participação de um membro de cada equipe em um projeto com múltiplas equipes (SCHWABER, 2004).
Essa prática permite a coordenação do trabalho entre equipes, acontecendo da
previamente por elas – se reúnem na SoS para discutir sobre os projetos, em especial, os assuntos relacionados as dependências interprojetos (RUBIN, 2012). A Figura 7 ilustra a composição do SoS.
Figura 7: Scrum of Scrums (SoS).
Fonte: Adaptado de Rubin (2012)
Outra abordagem, geralmente utilizada em projetos maiores, é o release train para alinhar a visão, o planejamento e as interdependências de várias equipes por meio da sua sincronização baseada em uma cadência comum, com foco em um fluxo rápido e flexível (RUBIN, 2012).
Segundo esse autor a metáfora do trem é usada implicitamente. Existe um
cronograma de quando uma ferramenta ou funcionalidade vai “deixar a estação”. Todas essas
equipes participantes do desenvolvimento do produto precisam colocar sua “carga” no trem no horário determinado.
Para serem utilizadas, as durações dos sprints de todas as equipes participantes são identificadas e alinhadas para que os seus resultados comecem e terminem nas mesmas datas, sincronizando não apenas determinadas entregas, mas todas as equipes trabalhando em determinado produto (RUBIN, 2012).
Ela se inicia com uma reunião de release planning com tempo pré- determinado, na qual é estabelecido o contexto organizacional, alinhadas as equipes atuantes no projeto tendo como norte os objetivos para o release. Outras entradas são a visão atual, um conjunto de objetivos desejáveis e um conjunto de funcionalidades desejáveis para o próximo release. Os resultados dessa reunião são utilizados para atualizar o roadmap do projeto, que mostra como a empresa espera realizar entregas de valor com o passar do tempo
(LEFFINGWELL, 2011). Segundo Leffingwell (2011), esse roadmap consiste em uma série de datas de grandes entregas (releases), cada qual com um tema, um conjunto de objetivos e um conjunto de funcionalidades priorizadas.
Quando as sprints do release train estão completas, chega-se a fase da entrega de valor, ou seja, a chegada do trem, também com as atividades de inspeção e adaptação. A primeira delas é a revisão na qual um conjunto completo de “cargas” colocadas no trem são apresentadas e validadas. A segunda é a retrospectiva em nível de “release train” focada em como fazer as futuras entregas mais eficientes (RUBIN, 2012). Esses “releases train” possuem uma cadência padrão, além de datas e qualidade fixadas, mas com escopo variável, sendo que as grandes entregas permitem que se tomem ações corretivas para aumentar a velocidade, confiabilidade e qualidade para as futuras (LEFFINGWELL, 2011).
Analisando mais profundamente os problemas de escala em projetos ágeis, assim como a gestão do conhecimento em grandes organizações, verifica-se que, da mesma forma que nos projetos tradicionais, raramente os canais de comunicação estão completamente conectados entre todas as equipes (RUBIN, 2012), conforme ilustrado na Figura 8.
Figura 8: Diversas equipes de projetos com os canais de comunicação totalmente conectados.
Na maioria dos casos, as equipes se aglomeram em clusters de áreas comuns ou equivalências de produtos, nos quais os canais de comunicação diretos, pessoais, são utilizados de forma mais intensa, sendo que esses clusters também podem se comunicar entre si, facilitando a sua coordenação (RUBIN, 2012) e troca de conhecimentos, conforme ilustrado pela Figura 9.
Contudo, a presença de muitos clusters diferentes, mesmo com a coordenação realizada por meio do SoS pode apresentar dificuldades (RUBIN, 2012). Esse mesmo autor propõe que, nesses casos, a coordenação entre clusters seja realizada por um gerente de projetos. Esse modelo pode funcionar para coordenação de projetos de desenvolvimento, contudo, apresenta limitações para outros usos como, por exemplo, na gestão do conhecimento, uma vez que essa centralização de informações em uma única pessoa parece contraproducente, pois limitaria sua realização devido à sobrecarga e apresentaria grande risco de perda de conhecimentos para organização caso esse colaborador fosse transferido ou desligado por qualquer motivo.
Figura 9: Clusters de colaboração entre equipes.
Fonte: Rubin (2012)
Na seção 6.6 essa discussão é retomada e proposta a substituição da figura do gerente de projetos por uma estrutura de Apoio a GC do projeto, que dentre outras funções,
seria responsável pela coordenação entre os clusters de projetos e por armazenar e processar os conhecimentos gerados em diversos projetos, de forma a permitir sua transferência para diferentes equipes, contribuindo para o aprendizado organizacional.
.