Scrum para compras – Um caso de agilidade num ambiente preditivo - Projetos e TI
Home Agile Scrum para compras – Um caso de agilidade num ambiente preditivo
Já faz algum tempo que um cliente me perguntou se eu conseguiria utilizar Scrum para compras.
Neste caso era necessário uma análise de um produto que ele não tinha certeza de como fazer e o que seu setor comprava por vezes deixava de ser utilizado por não ter as funcionalidades necessárias.
Como consultor, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar.
Vou relatar aqui alguns pontos do que fizemos neste caso, além de mais alguns itens sobre agilidade e procurement (compras) mas em alguns casos não poderei revelar os nomes de algumas das empresas.
Caso tenha necessidade de uma conversa com maiores detalhes, me convide para um café, posso ajudá-lo transformar sua empresa também.
Neste caso ele me pediu para ajudá-los a adquirir e implementar um produto comercial pronto para uso2 – mas eu tive que usar o Scrum para fazê-lo.
Dito isto, quando cheguei lá, recebi uma RFP de 326 páginas de um Benchmarking que uma organização semelhante havia feito para o mesmo tipo de aquisição.
Isso era exatamente o contrário de agilidade, MEU DEUS! Era muita informação técnica, neste caso fizemos uma experimentação logo depois do meu desabafo:
Eu não vou fazer uma RFP destas! Bora tentar agilizar isso?
Então, como fizemos isso? Aqui estão os três passos:
Scrum para compras – Passo-a-passo
1 – Descobrir por que a empresa precisava de um produto comercial pronto para uso
O primeiro passo era descobrir por que os negócios precisavam do produto de prateleira. Para fazer isso, fiz um Mapeamento de resultados (que é uma variante do Mapeamento de Benefícios) para ajudá-los a articular mais claramente por que eles precisavam fazer o projeto de uma perspectiva de negócios e não de uma perspectiva tecnológica.
O documento de RFP de 326 páginas que recebi foi focado principalmente em tecnologia, e foi por isso que senti que precisávamos evitar uma armadilha dessas.
Assim que tivemos o primeiro rascunho do mapa de resultados criado, imprimimos em uma folha A1 e colocamos na parede em nossa sala de guerra para o projeto (sim realizar compras também é um projeto, o problema nesse caso é que encontramos um programa).
Ter um mapa visível do "porquê" permitiu que as equipes de negócios e de TI adicionassem detalhes ou fizessem perguntas usando post-its sempre que olhassem para o mapa.
Em seguida, ficávamos todos os dias revendo o mapa como uma equipe e revisamos o conteúdo dos últimos lembretes para descobrir onde precisávamos atualizar nosso mapa com nossa compreensão, agora emergente, do problema comercial que estávamos resolvendo.
Uma vez que concordamos sobre o que precisava ser mudado, nós atualizávamos o mapa, o reimprimiríamos e colocaríamos o mapa recém-revisado de volta na parede.
Isso criou uma oportunidade de novas descobertas para o negócio e para a TI, pois eles andavam e estudavam o mapa.
Enquanto eles olhavam para o mapa, frequentemente outros acabavam por parar e analisar também, o que, é claro, levou-os a falar sobre o mapa juntos. Essas conversas ad-hoc levaram a algumas das mais perspicazes adições ao mapa.
As identificações referentes ao mapa
Durante o período de aproximadamente 8 semanas, o grande mapa visível do motivo do projeto levou à identificação de:
Quatro grandes áreas de processos de negócios deveriam ser projetadas, desenvolvidas e implementadas, já que a empresa não tinha pensado anteriormente por somente trabalhar com os requisitos técnicos enviados.
Pronto acabamos de começar a usar a agilidade num projeto e caímos num programa!
O fato de que o produto de prateleira que pretendiam comprar era apenas uma das cinco ferramentas diferentes que eram realmente necessárias e era apenas uma das duas na área de processo de negócios em que ele seria usado.
O que me remete aos 45% das funcionalidades de um produto que não são usados após a entrega, por este motivo o Scrum foi adaptado para as compras e nos artigos posteriores vou mostrar com maiores detalhes.
À medida que você cria um mapa de resultados, existem estruturas naturais que o ajudam a categorizar diferentes partes do mapa.
À medida que esse quadro toma forma, ele também ajuda a identificar o que você precisa fazer (projetos / iniciativas) para satisfazer o motivo pelo qual você está fazendo (os resultados).
2 – Descobrir o que o produto a ser adquirido precisava fazer
É fato que como Triber, Gerente de projetos ou Agile Coach nem sempre somos contratados sabendo exatamente do que se trata um projeto, em projetos preditivos usamos o planejamento em ondas sucessivas, no Scrum fazemos isso de forma incremental trazendo valor com Sprints.
Eu facilitei os grupos da área de negócios na identificação dos requisitos de negócios necessários que o produto precisava cumprir, juntamente com as declarações de requisitos em cada área em relação ao que eles precisavam que o produto fizesse.
Isso permitiu que eles classificassem cada declaração de capacidade de acordo com uma escala de importância comercial (Muito Alta, Alta, Média, Baixa, Muito Baixa).
Isso levou cerca de 8 semanas ou neste caso 4 Sprints. As regras de negócio foram as responsáveis por essas priorizações.
Criamos um Business Service Canvas para essa etapa, adaptando o scrum para compras, que era um derivativo do Business Model Canvas.
Como no mapa de resultados, imprimimos a tela em uma folha de A1 e a colocamos na parede para que a equipe usasse post-its para capturar suas adições ou perguntas.
Os Serviços na tela começaram com o grupo de P&D (o grupo de negócios) que já tinha fornecido informações para o restante da organização.
Em seguida, lideramos a equipe de negócios por meio de uma série de comparações em pares de "comprar um recurso" para cada uma das instruções em cada nível de prioridade dentro de cada área de recursos, da seguinte maneira:
Digamos que a área de capacidade 1 tenha 4 declarações de capacidade classificadas em Muito alto. Queríamos que eles comparassem os dois primeiros perguntando o seguinte: "Você só tem condições de comprar 1 deles, qual você seleciona como prioritário?
Se eles escolhessem um sobre o outro, a declaração "perdedora" seria alterada para Alta ao invés de Muito Alta. Se eles não pudessem escolher um sobre o outro, ambos ficariam em Muito Alto.
Fizemos isso para todas as prioridades e para todas as áreas envolvidas.
Uma vez que todas as declarações das áreas foram re-priorizadas, pedimos que elas considerassem as de Baixa e Muito Baixa e se queriam incluí-las na RFP, já que elas já haviam dito que não eram tão importantes com base em seu nível atribuído.
Scrum para compras – Decisões in/out
Depois de alguma discussão, a empresa decidiu retirá-los da RFP.
Isso nos permitiu confeccionar um documento de RFP de 7 páginas ampliado por planilhas pré-preenchidas com as declarações de requisitos organizadas por área de capacidade dentro do negócio.
Fornecemos espaço nas planilhas para os fornecedores preencherem suas respostas reais, que tinham que se referir à documentação de seu próprio produto que suportava suas declarações de adequação do produto.
Os fornecedores não puderam enviar respostas vinculadas ou impressas à RFP.
Dica: O uso do Business Service Canvas também ajudou a empresa a identificar a necessidade de reavaliações de função com base em lacunas de habilidades recém-realizadas, bem como funções ausentes em sua organização.
Esta etapa levou cerca de 4 Sprints para ser concluída.
3 – Mãos na massa, fazendo compras – Colocando o Scrum para compras para funcionar!
Agora que sabíamos por que estávamos fazendo o projeto e tínhamos uma sólida compreensão do que o produto de prateleira precisava, estávamos prontos para executar a compra em si, o que significava:
Emitir a RFP
Avaliar as respostas dos fornecedores
Realizar uma demonstração do produto em algumas reuniões para que os fornecedores mostrasem como o produto atenderá aos recursos necessários para os negócios
Selecionando um vencedor
As respostas dos fornecedores à RFP foram recebidas depois de estarem em cotação por 4 semanas.
As avaliações de respostas completas levaram menos de uma semana, incluindo as demonstrações em salas de reuniões dos três principais fornecedores.
Os demonstrativos nas sala de reuniões também levaram a uma troca dos primeiros fornecedores classificados em 1° e 2° lugares, eles geralmente ganhavam as cotações da empresa e eram melhor rankeados.
Entretanto muito do que era apresentado gerava desperdício, trazer transparência na contratação e uma RFP melhor desenhada fez com que eles estivessem fora desta vez, o que raramente acontece em aquisições tradicionais.
A implementação do produto levou ao todo três meses.
Nota: Enquanto alguns atrasos internos estenderam o cronograma geral de entrega para 12 meses, ele estava dentro do tempo esperado original, que também foi de 12 meses. Sem esses atrasos, teríamos terminado cerca de 4 meses antes
O gasto real com o software adquirido foi apenas cerca de 25% da expectativa original de despesas, pois apenas avaliamos as coisas que o cliente realmente precisava.
O negócio gastou apenas R$ 25.000,00 dos R$ 100.000,00 originalmente alocados originalmente para o produto.
O processo de seleção de fornecedores também considerou a capacidade do fornecedor de ajudar com uma implantação incremental e usar práticas ágeis para desenvolver a integração necessária com outros sistemas corporativos dentro do escopo de negócio.
Usar práticas ágeis de aquisição significa estar disposto a repensar o próprio processo de aquisição, bem como a capacidade do fornecedor escolhido de oferecer suporte a práticas ágeis em suas implementações de produto.
Scrum para compras, mapeamento de resultados e o Business Services Canvas, bem como outras práticas que introduzimos nos permitiram:
Perceber que o "projeto" era na verdade um programa e não um único projeto como se pensava inicialmente. Ao todo, foram seis iniciativas em quatro áreas principais de negócios
Orientar a equipe de negócios na definição de seus recursos de produto minimamente viáveis ​​para o produto de prateleira, que economizou 75% do orçamento original de R$ 100.000,000
Identificar e definir os novos serviços que eles precisavam para se destacar na área de P&D para satisfazer as quatro áreas de negócios.
Identificar, projetar e desenvolver todos os Processos de Negócios Minimamente Viáveis ​​necessários.
Fazer análise para identificação das novas funções podem alterar as funções existentes que seriam necessárias para dar suporte aos serviços novos e existentes com base nos novos processos das áreas de recursos
A aquisição em si levou menos tempo, custou consideravelmente menos que o planejado (apenas 25% do orçamento de R$ 100 mil).
Utilizou-se um processo de aquisição muito menos complexo e alcançou os resultados certos para o negócio.
O projeto foi concluído dentro do custo orçado global original, dentro do mesmo prazo esperado de 12 meses, afinal houveram atrasos internos, mas entregou processos de negócios, serviços e ferramentas adicionais recém-identificadas (com o dinheiro economizado na aquisição), nenhuma das quais foram identificados na definição e do escopo do projeto original e que deveriam ser entregues.
Vou dar maiores detalhes em novos artigos ainda nas próximas semanas, você já pensou em usar Scrum fora da TI? Comente!
Produto comercial pronto pra uso ou COTS é o mesmo que um programa pronto de prateleira assim como o Microsoft Office por exemplo