Scrum OUTside Software

Com os recente depoimentos de altos executivos brasileiros sabemos que a verdade é sobre “Doing Business in Brazil”, sabemos que as empresas brasileiras precisam começar a crescer através da agilidade. Dê uma olhada neste artigo para ver como aplicar metodologias ágeis, não apenas na área de tecnologia da informação, mas em toda a empresa.

Scrum não é apenas para Software, Robbie Mac Iver

Os métodos de gerenciamento de projetos tradicionais geralmente abordam todos os projetos no mesmo modus operandi, independentemente do nível de incerteza e mudanças representadas pelo projeto. Como consequência, os projetos não cumprem seus objetivos de negócios e toda confiança na capacidade da equipe de entregar os resultados é perdida. Os métodos ágeis estão se tornando referência para resolver essas questões nos esforços de desenvolvimento de software, porém a agilidade não é aplicável somente a softwares. Segundo a definição de agilidade de Jim Highsmith:

Agilidade é a habilidade de criar e responder a mudanças para lucrar em um ambiente de negócios turbulento.                 

– Jim Highsmith, Gerenciamento de Projeto Ágil

Essa definição não fala somente de desenvolvimento de software, mas sim de enfrentar mudanças (e incertezas) para trazer benefícios de negócios apesar de o ambiente corporativo estar sempre mudando. Os métodos ágeis, como o Scrum, podem ser aplicados a qualquer projeto para entregar melhores resultados em ambientes de negócio em constante evolução, fazendo-o de maneira que demonstra visibilidade e previsibilidade alinhadas às mais importantes prioridades de negócio.

Scrum Overview

Embora mais frequentemente associado com desenvolvimento de software, Scrum é um framework de gerenciamento de projetos que se adequa a projetos com alto nível de incerteza. Um projeto Scrum inicia como qualquer outro projeto; com um Termo de Abertura que justifica o business case e o macro escopo projeto. Em Scrum isso é chamado de Backlog do Produto. Ao contrário de métodos tradicionais, em Scrum o Backlog do Produto não é visto como o escopo final. Espera-se que o escopo evolua à medida que o projeto segue e mais é aprendido sobre os problemas de negócios abordados e a solução necessária.

As Sessões de Planejamento de Sprints são realizadas para selecionar trabalho de um Backlog de Produto para ser completado no próximo Sprint, formando um Backlog de Sprint. O time então executa o Sprint, que tem a duração média de 2 a 4 semanas, produzindo um “Potencial Incremento Lançável de Produto”. No desenvolvimento de software isso é um recurso em que o feedback do Dono do Produto e de outros stakeholders é necessário. As reuniões diárias de Scrum, também conhecidas como Stand-Ups diários, são realizadas durante todo o Sprint para coordenar o trabalho e manter a equipe focada nos objetivos do Sprint. A revisão do Sprint é realizada no final do Sprint para avaliar as entregas durante o Sprint e mostrar o trabalho final. Finalmente, a Retrospectiva do Sprint é realizada para rever o que ocorreu de positivo e de negativo, assim os ajustes apropriados podem ser feitos no planejamento do próximo Sprint.

Para ver como o Scrum pode ser usado em diferentes situações, além do desenvolvimento de software, vamos considerar um business case que é baseado na experiência recente de um cliente meu. A PoochPals é uma empresa nacional que provê suprimentos, alimento, brinquedos, remédios e uma variedade de outros produtos para os animais de estimação mais mimados do país (pelos seus donos obviamente). A companhia não fabrica nada. Ela compra esses produtos de um grande número de fornecedores de todo o país e depois distribui para pet-shops. Fornecedores transportam produtos de várias fábricas e distribuidores para um armazém da PoochPals. Os produtos são, assim, entregues (baseados na demanda) de um armazém da PoochPals para os clientes.

Para se ter uma ideia da complexidade envolvida, multiplique isso por 500 ou mais fornecedores e você poderá ver que a otimização da cadeia de suprimentos é um grande negócio para empresas como a PoochPals. A medida que sua linha de produtos expande, sua base de clientes cresce ou sua demanda de produtos muda de uma área geográfica para outra, a PoochPals otimiza sua cadeia de suprimento de várias formas. Uma das mais utilizadas é a abertura de um armazém adicional para servir mercados geográficos particulares. Embora adicionar um novo armazém é um imenso esforço sob vários pontos de vista, o que nós queremos considerar é o esforço que determina quais fornecedores, produtos e clientes serão servidos pelo novo armazém. Isso não é um esforço trivial quando pode envolver centenas de fornecedores e milhares de produtos. O processo fim-a-fim leva aproximadamente 6 meses por fornecedor e requer uma equipe de mais de 50 pessoas de múltiplas áreas de negócio.

O macro processo é assim:

•     Selecionar fornecedores e produtos
•     Recolher e validar informações específicas de produtos
•     Projetar a cadeia de suprimento para cada fornecedor
•     Negociar contratos de fornecedor
•     Construir o inventário inicial de produtos no novo armazém

A Abordagem Tradicional

A abordagem tradicional reúne um plano de projeto muito detalhado que define todas as tarefas em cada uma das áreas do processo acima. Isso equivaleria a várias centenas de tarefas que precisam ser realizadas para cada fornecedor. Imagine criar esse plano detalhado e ao mesmo tempo gerenciar independentemente mais de 200 fornecedores. Ao invés disso, nós podemos criar grupos de 10 a 15 fornecedores para serem gerenciados juntos. Finalmente nós definimos uma agenda baseada no objetivo da administração de estocar o inventário inicial no ritmo que o armazém pode aceitar. A partir daí os processos de reposição assumem o controle para manter os níveis do inventário necessários baseados na demanda de clientes. Esses processos de reposição não estão considerados no escopo dessa discussão.

De acordo com o plano detalhado do projeto, as práticas tradicionais de gerenciamento de projetos empurram o grupo de fornecedores em direção a vários marcos definidos no plano. A premissa aqui é que o esforço para cada fornecedor seja o mesmo; ou que as diferenças entre cada fornecedor em um grupo particular seriam equilibradas. Isso é a premissa ideal, e todos nós sabemos como isso geralmente funciona.

Na realidade o esforço de cada fornecedor poderia ser muito diferente um do outro.

•     Primeiramente, a capacidade ou disposição de cada fornecedor para cooperar é diferente em alguns aspectos, o fornecedor tem maior controle sobre nossa programação que o plano poderia indicar;
•     Segundo, o trabalho requerido para um fornecedor do qual eu compro um produto de um determinado local é muito diferente do que para um fornecedor do qual eu compro 500 produtos de 15 locais diferentes;
•     Terceiro, alguns fornecedores não passarão pelo processo; ou talvez passarão com uma seleção reduzida de produtos. Nenhuma dessas diferenças talvez sejam conhecidas quando os grupos de vendedores arbitrários são formados.

Os marcos do projeto logo perdem o sentido e a equipe estará em queda-livre.

Inevitavelmente, quando uma data de um marco do planejamento é atingida para o grupo de fornecedores, algumas atividades não foram finalizadas por um ou mais vendedores do grupo. Assim, começa um enorme esforço de gestão de mudança para mover os fornecedores para outro grupo ou “espremendo” a data do marco acreditando que a equipe pode alcançar os fornecedores atrasados.

O resultado final é que o progresso em direção ao objetivo de construir o inventário inicial do armazém se torna lento, mas não de uma maneira visível. Possivelmente você também notou que o objetivo final em si não é muito visível (na verdade nós não mencionamos isso ainda), e a equipe não está, certamente, focada nisso. Eles estão focados em completar algum conjunto de tarefas para uma data pré-definida, e as decisões que eles fazem são destinadas ao cumprimento das datas.

Como o Scrum pode ajudar?

O framework Scrum oferece a melhor maneira de abordar esse processo e gerenciar as mudanças e incertezas inerentes desse tipo de esforço. Sem realmente mudar as tarefas do dia-a-dia que a equipe precisa realizar, o Scrum nos permite mudar como o trabalho é organizado e mensurado para:

•     O foco da equipe no real valor do negócio;
•     Esclarecer os fluxos de trabalho e o alinhamento da equipe;
•     Reforçando no que “feito” significa;
•     Tornar o progresso e os problemas visíveis (algumas vezes de forma “dolorosa”).

Qual é o Valor Real do Negócio?

Primeiro de tudo, temos de reconhecer o que é importante e focar a equipe nisso. Executar um determinado conjunto de tarefas guiado uma data prescrita é realmente importante? Isso é realmente o meio, não o fim. O objetivo final é aumentar o volume do produto movendo-se através do novo armazém para o nível desejado até a data desejada. Este é um direcionador primário no business case para abrir o armazém; mas não é o que a equipe está focada. Então vamos concentrar a equipe nisso. Para o nosso exemplo, digamos que o objetivo é ter 52 milhões de unidades de produtos passando pelo armazém anualmente e alcançar essa taxa dentro de 6 meses após a abertura da nova instalação. Agora a equipe tem um objetivo no qual pode avaliar o progresso que faz.

Validar fluxos de trabalho

A seguir, queremos trabalhar em “linha de tempo” de sprints para que possamos avaliar o nosso progresso e se beneficiar do feedback frequente para ajustar nosso planejamento e processos. Então, vamos supor que nossos sprints são duram duas semanas. É óbvio que todo o trabalho de um único fornecedor não pode ser concluído em um único sprint de duas semanas, por isso, dividiremos o trabalho em fluxos de trabalho finitos para que cada um deles possa ser concluído em um sprint de duas semanas, ou pelo menos para a maioria dos fornecedores.

Em nosso caso, os fluxos de trabalho podem ser:

•     Validação do Produto – determina os produtos do fornecedor; coleta e valida informações específicas do produto
•     Cadeia de Suprimentos – analisa e define a rede ótima de cadeia de suprimentos para o fornecedor
•     Contrato – negocia um contrato com o fornecedor
•     Distribuição – acumula o inventário inicial do produto no armazém e permite os processos de reabastecimento padrão

Definir metas de sprint

Em seguida, os membros da equipe estão alinhados aos vários fluxos de trabalho de acordo com a área de especialização de cada pessoa e as necessidades de cada fluxo[3]. Cada uma dessas equipes pode ser considerada uma equipe Scrum e, como tal, cada equipe é responsável em cumprir sua meta de sprint a cada duas semanas. Supondo sprints de duas semanas, teremos 13 sprints (6 meses = 26 semanas / 2 semanas de Sprint = 13 sprints). O objetivo do sprint para a equipe de Distribuição é fixado em 4 milhões de unidades por sprint (meta de 52 milhões de unidades / 13 sprints). Isso significa que a cada duas semanas se espera da equipe de Distribuição aumentar o volume do produto movendo-se através do armazém por 4 milhões de unidades anualizadas. Finalmente, como há um histórico de fornecedores sendo eliminados do programa em vários pontos do processo, os objetivos de sprint para cada equipe anterior são aumentados conforme mostrado no desenho acima. Isso explica o atrito esperado do fornecedor e garante que o objetivo final de 52 milhões de unidades seja atingido.

O que significa “Concluído”?

As equipes Scrum também precisam concordar sobre o que “concluído” realmente significa. Novamente, em um esforço de desenvolvimento de um software, esperamos que a equipe produza um “potencial incremento lançável de produto” no final de cada sprint. Em nosso caso, cada equipe define um checklist que detalhe as tarefas de trabalho que devem ser concluídas antes que a equipe em sequência possa iniciar seu trabalho para o fornecedor. A equipe de validação do produto, por exemplo, define o checklist de trabalho que deve ser concluído antes que a equipe da cadeia de suprimentos possa começar a trabalhar no mesmo fornecedor. Isso também significa que a equipe da Cadeia de Suprimentos define seus pré-requisitos como parte do checklist da Equipe de Validação de Produto.

“Concluído” é então definido como concluir o trabalho na checklist para um fornecedor selecionado. Se tudo estiver completo no final do sprint, o volume do produto para esse fornecedor conta para a meta de sprint. Se o trabalho não estiver completo, nenhum volume do produto para o fornecedor é contado para a meta de sprint. É como se fosse preto no branco; uma avaliação de tudo ou nada que indique claramente o progresso em direção ao objetivo de sprint de cada equipe e pela transferência do progresso geral da equipe para o objetivo final de 52 milhões de unidades. As equipes do Scrum trabalham com o backlog do produto. Em um backlog de esforço de desenvolvimento de software, essa é a lista de recursos de software ou históricos de usuário mantidas pelo proprietário do produto. Em nosso caso, o backlog do produto é a lista de fornecedores que estão prontos para entrar no fluxo de trabalho da equipe. O backlog também registraria qualquer informação pertinente que a equipe quisesse saber sobre o fornecedor, como o volume do caso antecipado ou o número de produtos.

Uma Simulação de Sprints

Então vamos ver como isso funciona.

Sprint 1:

•     Somente a equipe de Validação de Produto pode trabalhar neste sprint[4].
•     Na reunião de Planejamento de Sprint, a equipe seleciona fornecedores de seu Backlog para atender a sua meta de volume de casos (4 milhões de unidades, por exemplo).
•     Scrums diários mantêm o foco da equipe na meta durante o sprint.
•     Durante a Avaliação do Sprint, a equipe avalia quais fornecedores estão concluídos e registra o número de unidades concluídas em direção à sua meta.
•     Os fornecedores concluídos são colocados no Backlog da Cadeia de Suprimentos
•     Finalmente, a Retrospectiva do sprint olha para o sprint concluído para avaliar como a equipe pode melhorar no próximo sprint.

Lembre-se que o desafio para a equipe não é mais “tomar este grupo de fornecedores e realizar essas tarefas por essas datas”. O desafio é “nas próximas duas semanas completar o trabalho da sua checklist para os fornecedores totalizando X milhões de unidades de produto; trabalhando com os fornecedores de sempre que você acha que podem apoiar o cumprimento deste objetivo”.

Sprint 2:

•     A equipe de Cadeia de Suprimentos pode agora começar a trabalhar.
•     Em suas reuniões de Planejamento de Sprint, cada equipe seleciona fornecedores de seu Backlog para atender às suas respectivas metas de sprint.
•     Scrums diários mantêm o foco da equipe na meta durante o sprint.
•     Durante a Avaliação do Sprint, a equipe avalia quais fornecedores estão concluídos e registra o número de casos concluídos em direção à sua meta.
•     Os fornecedores concluídos são colocados no Backlog da equipe em sequência.
•     Finalmente, a Restrospectiva do Sprint olha para o sprint concluído para avaliar como cada equipe pode melhorar no próximo sprint.

As equipes de Contrato e Distribuição começam a trabalhar nos Sprints 3 e 4 respectivamente e seguem o mesmo processo de planejamento, execução e revisão do sprint. Todas as equipes continuam trabalhando em sprints até atingirem a meta de negócios (52 milhões de unidades). O progresso real feito por cada equipe determinará quantos sprints são realmente necessários.

Medições

Ferramentas simples como uma planilha de Excel podem ser usadas para registrar o objetivo de sprint de cada equipe, bem como o progresso real em direção a esse objetivo. Equipes ágeis muitas vezes usam gráficos simples como os mostrados aqui para tornar o progresso para o objetivo de sprint mais visível. Muitas vezes chamado de radiadores de informação, estes gráficos são frequentemente publicados em áreas públicas ou disponibilizados em um site da equipe para que todos possam ver. Nada está escondido ou mascarado sobre o progresso real da equipe. Na Figura 4, a linha azul representa o alvo que conduz aos 52 milhões de unidades na meta de seis meses. Uma vez que as equipes não tiveram qualquer contribuição para estabelecer esse objetivo, cada equipe foi solicitada a definir seu próprio número de plano no início de cada sprint. Isso proporcionou uma meta para a qual a equipe se sentiu responsável e é mostrado em rosa. A linha amarela mostra o volume real de unidades concluídas. Em um relance você pode ver que a equipe da Validação do Produto está ajustando objetivos próximos ao alvo e após o primeiro sprint estão alcançando sua meta. Em contraste (Figura 5.), a equipe do Contrato está tendo séria dificuldade. Apenas olhando para este gráfico, sabemos que a equipe precisa de ajuda[5]. Pode ser que a equipe só precise de ajuda para descobrir como fazer seu trabalho. Ou talvez falte para a equipe um conjunto de habilidades chaves e a constituição da equipe precisa ser alterada. Isso também pode significar que a equipe está trabalhando bem, porém o objetivo do sprint não é razoável. Nesse caso, talvez precisemos de duas equipes de Contrato para alcançar esse objetivo, e não uma. Seja como for, como gestores de projeto podemos facilmente determinar onde o nosso foco é necessário para garantir que o projeto avance de forma que atinja o objetivo geral de negócios.

Como podemos avaliar a “velocidade” da equipe no final de cada sprint de duas semanas, podemos razoavelmente projetar o cronograma geral. Se, por exemplo, a equipe de Distribuição só consegue atingir 3 milhões de unidades por sprint ao invés de 4 milhões, então podemos projetar que são necessários 17 ou 18 sprints, e não 13 (52 milhões de casos divididos por 3 milhões). Se a velocidade da equipe for de 5 milhões de unidades por sprint, então sabemos que precisamos apenas de 10 ou 11 sprints. Não só esta projeção baseia-se na realidade do desempenho real da equipe, ela pode ser avaliada de forma confiável após os primeiros sprints e monitorada a partir daí. Não mais se espera 4 ou 5 meses em um projeto de 6 meses para reconhecer que não será possível atingir a data. Você pode avaliar que esta equipe está indo bem mesmo se você não tem ideia de qual trabalho a equipe está realmente fazendo.

Lembre-se de que não fizemos alterações no trabalho que a equipe precisava fazer ou como fazê-lo. O que mudou foi como o trabalho foi organizado e medido, o que fez com que as equipes responsáveis atingissem uma meta de negócios, e não apenas cumprissem uma data.

Antes

•       Fornecedores foram arbitrariamente empurrados através do processo.
•       O fornecedor é “movido” através do processo para cumprir o plano.
•       Todo o planejamento era feito de forma antecipada.
•       A equipe era responsável por “cumprir a data”.
•       A forma de alcançar o objetivo de negócios era obscura
•       Impacto das decisões sobre a meta de negócios não era clara

Depois

Os fornecedores são selecionados pela equipe e puxados através do processo.

O fornecedor “move-se” através do processo em seu próprio espaço

O planejamento é feito continuamente nos limites do sprint.

 A equipe é responsável pelo cumprimento da meta de negócios (x casos a cada duas semanas).

Alcance da meta visível

Impacto das decisões sobre os objetivos de negócios é imediatamente visível.

Conclusão

Na experiência do meu cliente, a equipe esforçou-se para cumprir a meta geral de volume de produto para os primeiros sprints. Mas quatro coisas, que antes não eram, se tornaram verdadeiras:

•     Eles imediatamente sabiam que não estavam cumprindo a meta.
•     Eles sabiam exatamente o quão longe estavam de alcançar seu objetivo.
•     Ao ver quais equipes não estavam realizando o seu objetivo, elas sabiam porque não estavam cumprindo a meta.
•     As equipes assumiram mais responsabilidade pela meta e adaptaram seus processos de fluxo de trabalho para melhorarem sua capacidade de cumprirem a meta.

Eventualmente, a equipe satisfez a meta de negócios da gerência executiva para a nova instalação. Também atingimos um objetivo para o Escritório de Gerenciamento de Projetos de reduzir o número de gerentes de projeto que supervisionam o processo de seis para dois. Ao reconhecermos que nossos projetos possuem um alto grau de incerteza e mudança, não devemos evitar olhar além dos processos tradicionais de gerenciamento de projetos para abraçar e gerenciar essa mudança. Métodos ágeis, como Scrum, podem oferecer soluções inventivas que podem trazer ordem e razão para ambientes caóticos. Concentre a equipe na verdadeira meta de negócios, posicione-a para organizar seu trabalho de forma que o significado de “concluído” seja claramente entendido, avalie o progresso da equipe em termos de alcançar alguma parte da meta de negócios, e liberte-a para buscar e reagir ao feedback que irá ajudar a melhorar continuamente o seu desempenho e seus processos, a fim de atender o verdadeiro objetivo de negócios.