Opinião: A metodologia Scrum na resolução de problemas
Por Tiago Sacchetti (*)
A metodologia Agile Scrum tem sido tradicionalmente utilizada no desenvolvimento de software. No entanto adequa-se de forma geral a projetos com requisitos voláteis ou não perfeitamente definidos. O scrum é uma forma ágil de gerir projetos originalmente desenhado para equipas de três a dez pessoas localizadas no mesmo espaço, que de uma forma autónoma, repartem o trabalho em pequenos períodos de tempo (sprints – usualmente de duas semanas). O scrum, como todos os métodos ágeis, prioriza a criação de valor para o cliente e assume que a quantidade de recursos e tempo disponíveis são limitados. Há que maximizar o resultado produzido mesmo que isso signifique não produzir todo o resultado desejado. Assumir este novo paradigma nem sempre é fácil para as organizações.
Será esta uma metodologia útil na resolução de problemas?
Para responder a esta questão há que relacionar o método de gestão de projectos Scrum com a resolução de problemas e demonstrar a sua eficácia. Podemos definir a resolução de um problema como um esforço temporário (limitado no tempo) para criar uma solução. Ora esta é também a definição de projeto. Assim sendo, não há dúvida que faz sentido utilizar métodos de gestão de projetos para gerir os processos de resolução de problemas.
Exemplificando, a resolução de problemas de qualidade na indústria automóvel é geralmente muito exigente do ponto de vista da rapidez na proteção da cadeia de valor a jusante do problema. As ações de contenção e as análises de risco e impacto são geralmente urgentes e os primeiros resultados das análises e verificações de causas raiz seguem-se num frenesim de pressão geralmente imposto vigorosamente pelo cliente ou pelo departamento de qualidade da própria organização.
Estas condições são justamente indicadas para a aplicação da metodologia Agile-scrum: resultado esperado não completamente definido, recursos e tempo limitados e necessidade de maximizar a criação de valor para o cliente. Não quero com isto dizer que as técnicas tradicionais de resolução de problemas devem ser preteridas, o que defendo sim é a utilização do Scrum para gerir o processo de resolução de problemas. Dependendo da complexidade do problema, métodos simples (Ishikawa, 5 porquês, 8D, etc) ou mais complexos (6Sigma, Shainin RedX)) devem ser utilizados na descoberta das causas-raiz. O papel do Scrum não é substituir esses métodos, mas sim gerir a equipa, as tarefas, as comunicações e os resultados.
Decide-se frequentemente atribuir a gestão do processo a um membro da equipa técnica de resolução do problema. Infelizmente esta decisão tem geralmente resultados pouco satisfatórios devido à falta de neutralidade que esse membro irá ter no seio da equipa. Para a dinâmica da equipa, é relevante e indesejável que esse elemento seja também um responsável operacional de uma área especifica (produção, logística, engenharia de produto, etc). Os potenciais conflitos de interesses que irão surgir, mesmo que infundados, irão com certeza minar a confiança da equipa e diminuir a sua performance. Por curiosidade, este conflito é também muito comum mesmo no desenvolvimento de software com Scrum: se um programador também acumula o papel de Scrum-Master, o valor do resultado gerado regra geral diminui.
Dado que os recursos são limitados especialmente numa organização otimizada para gerir as operações do dia-a-dia, e o número de problemas não se espera grande (devem ser a exceção e não a norma), faz sentido utilizar um Scrum-Master experiente possivelmente de um parceiro de negócios flexível que forneça esse tipo de serviços. O conteúdo técnico do problema deve continuar a ser desenvolvido pela equipa e pelos especialistas nas relações causa-efeito do produto e dos processos.
Por outro lado, há um benefício inequívoco em delegar as tarefas organizacionais: a comunicação com o patrocinador do problema (ou mesmo com o cliente); a organização e priorização do trabalho a realizar (backlog) incluindo preparar, moderar e documentar as reuniões da equipa de resolução de problemas e os resultados obtidos; a focalização da equipa e a proteção contra distrações externas ou opiniões não validadas nas reuniões de planeamento que poderiam dirigir os recursos de uma forma não coordenada; a promoção das dinâmicas de equipa de excelência (mediação de conflitos, promoção da velocidade na tomada de decisões e a focalização na entrega de valor – e.g “dias” FedEx). Estas são tarefas típicas do Scrum-Master.
Pelas razões acima descritas, recomendo vivamente a utilização do Scrum na gestão dos processos de resolução de problemas. As suas vantagens são especialmente notórias em cadeias de valor otimizadas e com políticas de qualidade de 0 defeitos. Usem a metodologia Scrum: mantenham um “backlog”, planeiem os sprints, monitorizem a velocidade com o gráfico “burn-down” e melhorem o vosso próprio processo de resolução de problemas nas reuniões de retrospetiva. Quem o fizer irá desenvolver a solução do problema de forma rápida e com menos custos para a imagem da organização e para a relação com o cliente. Consequentemente poderão desmobilizar mais cedo a equipa de resolução do problema (afinal é um projeto) e continuar com as tarefas do dia-a-dia e projetos especiais para atingirem os vossos objetivos estratégicos.
(*) Diretor da Bosch Industry Consulting em Portugal e Espanha