Revisão sistemática de literatura sobre gestão de projetos Lean-Ágeis

Tânia Raquel Caridade Sousa Revisão Sistemática de Literatura sobre Gestão de Projetos Lean/Ágeis Dissertação de Mestrado Mestrado em Engenharia Industrial Trabalho efetuado sob a orientação do Professor Rui M. Lima Dezembro de 2019 ii DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ iii AGRADECIMENTOS Em primeiro lugar um agradecimento aos meus pais e à minha irmã, pelo apoio que me deram em todas as fases da minha vida, que se revelou crucial para a elaboração desta dissertação. Agradeço-lhes a compreensão total que tiveram e a habitual motivação com que pude contar ao longo deste trabalho. Ao meu orientador, Prof. Doutor Rui M. Lima, por todo o apoio e paciência que teve comigo. Agradeçolhe pela sua boa disposição, compreensão, conselhos e total disponibilidade que revelou em todas as fases do trabalho. E por fim quero agradecer aos meus amigos, pela força, motivação e confiança que sempre me transmitiram para elaborar esta dissertação. iv DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. v RESUMO Os projetos são essenciais para o crescimento das empresas, porque são indispensáveis no desenvolvimento de novos produtos e na exploração de novas oportunidades ou na resolução de problemas existentes. E por isso, a gestão de projetos tem contribuído para a criação, gestão e distribuição de valor às empresas, através de métodos e princípios de gestão. Nas últimas décadas surgiram duas abordagens de gestão de projetos, denominadas de Lean e ágil. A gestão de projetos ágeis baseia-se em métodos de desenvolvimento adaptáveis e flexíveis. Sendo que, estes foram projetados para usarem a mínima documentação possível, de forma a facilitar a flexibilidade e a capacidade de resposta face às alterações do ambiente onde estão inseridos. Por sua vez, a gestão de projetos lean caracteriza-se por sistemas estruturados projetados para entregar o produto enquanto agregam valor e minimizam o desperdício. Estas duas abordagens têm vindo a propor caminhos para lidar com a gestão de projetos. Porém, ao que tudo indica, estas duas abordagens gestão de projetos Lean e gestão de projetos ágil, seguem caminhos semelhantes. Assim, o objetivo desta dissertação prende-se em identificar as principais características, semelhanças e diferenças, entre estas duas abordagens de gestão de projetos. Para alcançar este objetivo o método utilizado para a realização desta dissertação foi através de uma revisão sistemática de literatura. Este método é um meio de identificar, avaliar e interpretar estudos disponíveis e relevantes, por isso este método foi o escolhido, proporcionando uma visão geral sobre os trabalhos já executados. Assim, de acordo com este método e a pesquisa efetuada foram obtidos 35 artigos para analisar. Desta forma, através dos dados retirados foi efetuada uma análise bibliográfica, e rapidamente se chegou à conclusão que este é um tema em crescimento e que tem suscitado interesse. Isto é visível através do gráfico que apresenta uma relação entre o ano e o número de citações, onde se observam que estão registadas 196 citações em 2016, 285 em 2017 e por fim 388 citações em 2018. Foram efetuadas duas análises qualitativas, em que uma das análises consiste em classificar os artigos em dois tipos, se são Lean ou Ágil, e concluiu-se que 9 artigos são do tipo Lean, 25 artigos são do tipo ágil, e 1 artigo enquadra-se nas duas classificações. Contudo, a segunda análise efetuada refere-se a categorias e ferramentas de aplicação nos artigos. Assim, é possível observar que as áreas de construção e produção, têm 5 e 6 artigos respetivamente, e que todos pertencem ao tipo Lean. A área educação contem 3 artigos do tipo ágil, e a área software conta com 8 artigos dos dois tipos. Quanto às ferramentas, case study tem 29 artigos e framework tem 20 artigos distribuídos pelos dois tipos de classificação Lean e Ágil. Palavras-Chave Gestão de Projetos Ágil, Gestão de Projetos Lean, Kanban, Revisão Sistemática de Literatura, Scrum vii ABSTRACT Projects are essential for business growth because they are indispensable for developing new products and exploring new opportunities or solving existing problems. That is why project management has contributed to the creation, management and distribution of value to companies through management methods and principles. In recent decades, two project management approaches have emerged, called Lean and Agile. Agile project management is based on adaptable and flexible development methods. These are designed to use as little documentation as possible to facilitate flexibility and responsiveness to changes in the environment in which they operate. In turn, lean project management is characterized by structured systems designed to deliver the product while adding value and minimizing waste. These two approaches have been proposing ways to deal with project management. Thus, the objective of this dissertation is to identify the main characteristics, similarities and differences between these two project management approaches. To achieve this goal, the method used for this dissertation was through a systematic literature review. This method is a means of identifying, evaluating and interpreting available and relevant studies, so this method was chosen, providing an overview of the work already performed. Thus, according to this method and the research carried out 35 articles were obtained to analyze. Thus, through the data obtained was made a bibliographical analysis, and quickly came to the conclusion that this is a growing theme and that has aroused interest. This is visible through the graph showing a relationship between the year and the number of citations, which shows that 196 citations are recorded in 2016, 285 in 2017 and finally 388 citations in 2018. Two qualitative analyzes were performed, in which one of the analyzes consists in classifying the articles in two types, whether they are Lean or Agile, and it was concluded that 9 articles are Lean type, 25 articles are Agile type, and 1 article falls into both ratings. However, the second analysis carried out refers to categories and application tools in the articles. Thus, it can be observed that the areas of construction and production have 5 and 6 articles respectively, and all belong to the Lean type. The education area contains 3 agile type articles, and the software area has 8 articles of both types. As for tools, case study has 29 articles and framework has 20 articles distributed by both Lean and Agile classification types. Keywords Agile Project Management, Lean Project Management, Kanban, Systematic Literature Review, Scrum ix Índice Agradecimentos .................................................................................................................................. iii Resumo............................................................................................................................................... v Abstract............................................................................................................................................. vii Índice de Figuras ................................................................................................................................ xi Índice de Tabelas ............................................................................................................................. xiii Introdução .......................................................................................................................................... 1 1.1 Objetivo .............................................................................................................................. 1 1.2 Estrutura da dissertação ...................................................................................................... 2 2. Enquadramento Teórico .............................................................................................................. 3 2.1 Gestão de projetos .............................................................................................................. 3 2.2 Abordagens ágeis ................................................................................................................ 3 2.2.1 Conceitos gerais .......................................................................................................... 4 2.2.2 Scrum ......................................................................................................................... 6 2.3 Abordagens lean ................................................................................................................. 8 2.3.1 Lean Production .......................................................................................................... 8 2.3.2 Desperdícios .............................................................................................................. 10 2.3.3 Gestão de Projetos Lean ............................................................................................ 11 2.4 Revisão Sistemática de Literatura ...................................................................................... 11 3. Metodologia .............................................................................................................................. 14 3.1 Problemática de Investigação ............................................................................................ 14 3.2 Método de Revisão Sistemática de Literatura ..................................................................... 14 3.3 Critérios de Revisão ........................................................................................................... 20 3.3.1 Lean .......................................................................................................................... 20 3.3.2 Ágil ............................................................................................................................ 20 3.4 Análise Qualitativa ............................................................................................................. 21 4. Resultados ................................................................................................................................ 27 4.1 Análise Bibliográfica .......................................................................................................... 27 4.1.1 Informação Geral ....................................................................................................... 27 4.1.2 Análise de revistas ..................................................................................................... 29 4.1.3 Análise de autores ..................................................................................................... 30 3 2. ENQUADRAMENTO TEÓRICO De forma a compreender-se melhor o tema abordado desta dissertação, encontra-se a seguir descrito o enquadramento teórico de tópicos relevantes para o assunto. Este capítulo está dividido em quatro secções: gestão de projetos, abordagens ágeis, abordagens Lean e por fim revisão sistemática da literatura. 2.1 Gestão de projetos A gestão de projetos tem contribuído para a criação, gestão e distribuição de valor às organizações através de métodos e princípios de gestão, que articulam as equipas de forma a apoiar o seu trabalho, superar obstáculos, e incertezas inerentes na implementação de ações para o sucesso dos projetos. De acordo com Project Management Institute (2013), um projeto é um esforço temporário, com um início e fim definidos, sob recursos restritos com o objetivo de alcançar um resultado, produto ou serviço. O tradicional modelo em cascata caracterizado pela formalização de documentos e fases fixas, influenciou o método de gestão de projetos. Ao longo das últimas décadas, pelo menos duas abordagens de gestão de projetos propuseram diferentes caminhos para lidar com a gestão de projetos, gestão de projetos Lean e gestão de projetos ágil. Ao longo dos anos a experiência mostrou que a estrutura tradicional não consegue responder rapidamente a um ambiente em mudança. Logo, num ambiente em constante mudança deve existir gestão de projetos ou outras estruturas de gestão temporárias que sejam altamente orgânicas e que possam responder rapidamente à medida que as situações se desenvolvem dentro e fora da empresa (Kerzner, 2009). Gestão de projetos é a aplicação, nas atividades do projeto, do conhecimento, ferramentas e técnicas de modo a responder às exigências do mesmo. A aplicação de gestão de projetos envolve cinco grupos de processos que segundo o guia PMBOK (Project Management Body of Knowledge) , (PMI, 2013) são: iniciação, planeamento, execução, monitorização e controlo e encerramento. 2.2 Abordagens ágeis As abordagens ágeis estão cada vez mais a suscitar interesse por parte de outras áreas sem ser a área de desenvolvimento de software, apesar de terem definido e criado o conceito “agile” há quase 20 anos atrás. Estas abordagens permitem uma adaptação rápida e eficiente às mudanças do mercado e de certa forma as empresas que as adotarem ganham também uma vantagem estratégica. Sendo que também provocam um aumento de agilidade o que contribui para a diminuição do tempo de 4 desenvolvimento de novos processos, e aumenta também a flexibilidade de processos existentes que necessitam de modificações (Stoica et al., 2013). Este sub-capítulo encontra-se dividido em duas secções, a primeira que apresenta conceitos gerais sobre o tema e a segunda secção que aborda a ferramenta Scrum, que é uma das muitas ferramentas existentes dentro das abordagens ágeis. 2.2.1 Conceitos gerais As abordagens ágeis baseiam-se em métodos de desenvolvimento adaptáveis e flexíveis, enquanto que os modelos tradicionais baseiam-se numa abordagem mais rígida. Segundo Stoica et al (2013), nestas abordagens apenas se planeiam as tarefas que são claramente relacionadas às características que devem ser desenvolvidas. Sendo que, um ponto forte é a interação com os clientes enquanto que a comunicação aberta e a documentação mínima são características típicas deste ambiente de desenvolvimento ágil. Em 2001, uma reunião marcava o surgimento e propagação do paradigma de desenvolvimento de softwares ágeis, dando assim início ao documento que conhecemos hoje como “Manifesto Ágil. Este documento assenta em quatro valores e doze princípios. E segundo, Beck et al (2001) os valores ágeis são: • Indivíduos e interação entre eles mais que processos e ferramentas; • Software em funcionamento mais que documentação abrangente; • Colaboração com o cliente mais que negociação do contrato; • Responder a mudanças mais que seguir um plano. Os métodos ágeis foram projetados para usar a mínima documentação possível, de forma a facilitar a flexibilidade e capacidade de resposta às diversas alterações nas condições. Isto implica que menor planeamento e maior flexibilidade são usados em projetos ágeis do que nos projetos tradicionais de gestão (Serrador & Pinto, 2015). E os doze princípios seguidos no manifesto são: • A maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado; • Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis adequamse a mudanças para que o cliente possa tirar vantagens competitivas; • Entregar com frequência software que funciona, de poucas semanas a poucos meses, com preferência à menor escala de tempo; • Todas as pessoas envolvidas no projeto devem trabalhar diariamente em conjunto; 5 • Construir projetos envolvendo indivíduos motivados, dando-lhes ambiente e suporte necessário, e confiar que vão fazer o trabalho; • O método mais eficiente e eficaz de transmitir informações para, e entre a equipa de desenvolvimento é através de conversa presencial; • Software a funcionar é a medida primária de progresso; • Os processos ágeis promovem desenvolvimento sustentável. Assim todos os envolvidos devem ser capazes de manter um ritmo constante, indefinidamente; • Contínua atenção a excelência técnica e bom design aumenta a agilidade; • Simplicidade: a arte de maximizar a quantidade de trabalho não realizado é essencial; • As melhores arquiteturas, requisitos e designs emergem de equipas auto-organizadas; • Em intervalos regulares, a equipa reflete sobre como se tornar mais eficaz, e então ajusta e otimiza o seu comportamento de acordo. Assim, cada método ágil existente hoje assenta nos valores e princípios descritos no manifesto ágil. Por exemplo, métodos como Scrum e XP trazem esses valores e princípios, e por isso são denominados ágeis (Beck, Beedle, Bennekum, et al., 2001). Desde que o manifesto ágil foi criado em 2001, a comunidade de investigadores tem dedicado grande atenção ao desenvolvimento de software ágil. A realização do mesmo, trouxe mudanças sem precedentes no campo da engenharia de software. De facto, a transformação que o manifesto trouxe à sua volta é bastante notável. Porém, embora este crescimento incomparável tenha sido prontamente aceite por muitos profissionais, ainda há muito trabalho a ser realizado para trazer coerência ao discurso atual sobre agilidade (Dingsøyr, Nerur, Balijepally, & Moe, 2012). As abordagens ágeis contrastam com o método de gestão de projetos tradicional, realçando o design contínuo, âmbito flexível, capacidade de abraçar incertezas, interagir com o cliente e uma organização de equipa modificada. Infelizmente, evidências acumulam-se sugerindo que um processo de desenvolvimento rígido pode resultar em patologias significativas, como retrabalho excessivo, falta de flexibilidade, insatisfação do cliente, e o possível desenvolvimento total de um projeto para apenas no fim descobrir que os avanços tecnológicos eclipsaram a sua necessidade (Serrador & Pinto, 2015). Ultimamente, a atenção tem estado focada nos problemas relacionados com gestão de projetos – planeamento ágil, controlo e estimativa do projeto, racionalização de fluxo de histórias (por exemplo, Kanban), usando lean six-sigma e assim por diante. A maioria destas ideias tem vindo a gerar um número de práticas que se afirmam serem eficazes, mas falta a validação empírica destas afirmações (Dingsøyr et al., 2012). 6 2.2.2 Scrum Existem diversos métodos para aplicar as abordagens ágeis, embora cada um deles tenha uma abordagem única, todos partilham os valores e princípios do manifesto ágil. O Scrum é um deles, e é um método iterativo e incremental cujo objetivo é auxiliar a equipa de desenvolvimento a concentrar-se no objetivo estabelecido e minimizar o trabalho realizado em tarefas menos importantes. Este termo vem do rugby, e refere-se à maneira como uma equipa trabalha em conjunto para que a bola avance no campo. O Scrum concentra-se na forma como os membros da equipa de desenvolvimento devem interagir para criar um sistema flexível, adaptável e produtivo num ambiente em constante mudança (Stoica et al., 2013; Sutherland, 2016). Scrum é a ferramenta mais conhecida e a mais utilizada dentro dos métodos ágeis. Foi inicialmente criada com o propósito de desenvolver e manter produtos complexos, sendo que hoje em dia o seu uso é muito mais extenso. Atualmente, o seu uso vai desde o propósito inicial até ao desenvolvimento de veículos, escolas, governos, marketing, e quase tudo o que usamos diariamente (Schwaber & Sutherland, 2017). O scrum não é um processo, mas sim uma ferramenta onde assentam os princípios ágeis. Segundo o co-criador do scrum, Sutherland (2016) o scrum nasce no início da década de 90 e traz uma mudança radical relativamente às metodologias hierarquizadas usadas na gestão de projetos até à data. Ken Schwaber e Jeff Sutherland (2017) desenvolveram o Scrum e definem-no como, “uma ferramenta dentro da qual as pessoas podem resolver problemas adaptativos complexos ao mesmo tempo que, de forma criativa e produtiva, entregam produtos com maior valor possível” (Schwaber & Sutherland, 2017). Um pilar do scrum é uma pequena equipa de pessoas, bastante flexível e adaptativa. A estrutura do scrum procura aproveitar a forma como as equipas trabalham, dando-lhes as ferramentas para se organizarem de forma independente e melhorarem rapidamente a velocidade e a qualidade do seu trabalho. Ou seja, o resultado é este, equipas que veem a sua produtividade melhorar (Sutherland, 2016). Scrum assenta numa base firme de valores que servem como pilares para os processos (Scrum Alliance, 2012). Sendo que o scrum está dependente de as pessoas se tornarem mais competentes no uso destes cinco valores, que são: • Compromisso – ao ter maior controlo sobre o seu destino, a equipa fica mais empenhada em ter sucesso, comprometendo-se assim a atingir o objetivo da equipa; • Coragem – ao trabalhar em conjunto, a equipa sente-se apoiada e tem mais recursos à sua disposição, o que lhe dá coragem para assumir desafios maiores; • Foco – é necessário focar em poucas coisas em simultâneo, para que consequentemente se trabalhe melhor e a produtividade aumente. Desta forma, são entregues itens mais cedo e com valor; 7 • Abertura – a equipa ao trabalhar em conjunto aprende que é necessário uma comunicação aberta entre toda a equipa em relação ao trabalho necessário a fazer e aos desafios na sua execução; • Respeito – se a equipa partilhar os sucessos e falhas, estes aprendem a respeitar-se e a cultivar um espírito de entre-ajuda. Scrum é um processo em equipa, e esta é composta por três partes importantes: o prodcut owner , a equipa de desenvolvimento e o scrum master . As equipas de desenvolvimento são auto-organizadas, capazes de decidirem a melhor forma de realizar o trabalho, e multi-funcionais, pois assim têm todas as competências necessárias para realizar a tarefa sem dependerem de pessoas exteriores à equipa. Este modelo de equipa é projetado para otimizar a flexibilidade, criatividade e produtividade. Assim, e para atingir a meta estabelecida no sprint , é possível a entrega de produtos de forma iterativa e incremental, maximizando as oportunidades de feedback (Schwaber & Sutherland, 2017). O product owner tem a responsabilidade de, maximizar o valor de produto, bem como de decidir quais as tarefas a realizar por parte da equipa de desenvolvimento. Tarefas estas que provêm do product backlog , que é uma lista de ideias para o produto, ordenadas por ordem de prioridade. O scrum master é como um líder que garante que o Scrum é aplicado, sendo que também ajuda aqueles que não pertencem à equipa a entenderem as interações que são ou não úteis para a equipa. Tem também a função de facilitar reuniões e ajudar a manter a equipa no caminho certo e a ser produtiva. No entanto, o scrum master também trabalha em conjunto com o product owner de forma a auxiliá-lo na compreensão de criar e manter o product backlog (Scrum Alliance, 2012). O Scrum na sua utilização tem atividades estabelecidas, com o propósito de criar regularidade e para minimizar a necessidade de reuniões não definidas no Scrum. Estas atividades têm uma duração máxima estipulada, que são sprint , reunião diária de Scrum, revisão do sprint e retrospetiva do sprint . Um sprint inicia-se sempre por uma reunião com tempo máximo determinado. O sprint é considerado como um projeto com uma janela temporal limitada não superior a um mês, e durante o qual se cria um incremento potencialmente utilizável. Estes devem ter durações consistentes durante todo o desenvolvimento, sendo que um novo sprint começa logo após a conclusão do anterior. A reunião diária de Scrum é um evento para a equipa de desenvolvimento cuja janela temporal é limitada a 15 minutos. Esta reunião é utilizada para assegurar que o objetivo do sprint é atingido, sendo que ocorre sempre no mesmo local e à mesma hora. No final de cada sprint ocorre uma revisão do sprint . Este evento é uma reunião informal com o intuito de inspecionar o incremento e se necessário adapta-lo. E daqui resulta um product backlog revisto que define os itens prováveis para o próximo sprint . Seguidamente, ocorre a retrospetiva do sprint onde a equipa Scrum identifica o que foi bem-sucedido e o que correu mal e identifica potenciais melhorias. Isto é, a retrospetiva é uma oportunidade para a equipa scrum se inspecionar a si mesma e criar um plano de melhorias a serem executadas durante o próximo sprint . E assim está criado o ciclo de Scrum que se repete desde aqui, para cada sprint (Scrum Alliance, 2012). 8 2.3 Abordagens lean A extraordinária competitividade da indústria automobilística japonesa teve um enorme impacto no Ocidente, que achou cada vez mais difícil competir com os produtos japoneses. Esta competitividade provocou uma motivação para procurarem e pesquisarem sobre os métodos japoneses que eram desconhecidos até então. E isto resultou posteriormente no livro de Womack(1990) que concluiu que o sistema de produção Toyota era possível de aplicar em qualquer meio industrial, e assim com base neste método criou o Lean Thinking que é aplicável em diversas áreas mesmo além da indústria de produção (Green, 1999). A abordagem Lean é uma prática de produção que considera o gasto de recursos, para qualquer objetivo que não seja a criação de valor para o cliente final, ser um desperdício e, portanto, um objetivo de eliminação (Reusch & Reusch, 2013). Este sub-capítulo encontra-se dividido em três secções, de forma a apresentar conceitos gerais sobre o tema que são Lean Production e desperdícios, seguidamente de gestão de projetos Lean. 2.3.1 Lean Production O sistema de produção em massa criado por Henry Ford foi utilizado com sucesso, pois conduziu a indústria automóvel durante bastante tempo, mais de meio século e, foi um sistema adotado por quase toda a Europa e América do Norte. Este sistema assentava na produção em larga escala de produtos padronizados, com um número mínimo de mudança de produtos e com recurso a linhas de montagem. Porém, a principal dificuldade encontrada foi a adaptação ao mercado, pois havia uma crescente procura por produtos diversificados. Uma nova indústria automóvel japonesa surge desenvolvendo uma nova forma de produção, o que aliado à estagnação da produção em massa, levou ao declínio da mesma (Womack et al., 1990) Uma alternativa à produção em massa surge no Japão depois da 2ªGuerra Mundial, o sistema de produção Toyota (Toyota Production System - TPS). A base do TPS é a absoluta eliminação do desperdício, sendo que os dois pilares necessários são a criação do sistema Just-in-time (JIT) e a autonomação (ou automação com um toque humano). O sistema JIT permite que num processo de fluxo, as partes corretas necessárias à montagem alcancem a linha de montagem no momento em que são necessárias e apenas na quantidade necessária. Enquanto que, a autonomação elimina a superprodução e evita a produção de produtos defeituosos. E se somar a estes, a utilização de pequenos lotes, a troca rápida de ferramentas, a redução do tempo de produção e produtos diversificados a baixo custo, tem-se assim as bases do que é feito na empresa Toyota (Ohno, 1988). O termo Lean foi atribuído por Womack, Jones & Ross (1990), quando se refere ao Sistema de Produção Toyota, desenvolvido sob a ideia de produzir em fluxo contínuo e reconhecendo que apenas uma pequena fração do tempo total e esforço para processar um produto é que agrega valor ao cliente final. Esta abordagem era claramente o oposto do que se fazia na altura, que era um grande volume de produção 9 de produtos padronizados com um número mínimo de mudança de produtos (Melton, 2005). Segundo Womack & Jones (2003), Lean assenta em cinco princípios, conforme Figura 1: • Identificação de valor – valor apenas pode ser definido pelo cliente, e Womack & Jones (2003) descreve valor como a capacidade de providenciar no tempo certo e com o preço apropriado os produtos e/ou serviços acordados com o cliente. Logo, este é o primeiro passo para a implementação do lean thinking. • Identificação da cadeia de valor – conjunto de todas as ações necessárias para fazer um produto específico. Isto é, identificar os passos da cadeia de valor para cada tipo de produto, e eliminar todos os passos que não agreguem valor. • Fluxo contínuo – criar um fluxo contínuo pelas etapas descritas na identificação da cadeia de valor, para que o produto flua suavemente até ao cliente. • Produção puxada – à medida que o fluxo é introduzido, permitir que o cliente “puxe” o produto conforme precisa, em vez de enviar produtos que geralmente o cliente não deseja, ou seja o método Kanban. • Procura pela perfeição – conforme o valor é especificado, os fluxos de valor são identificados, as etapas com desperdício são removidas, e o fluxo e a extração são introduzidos, chega-se assim à etapa perfeição. Ou seja, iniciar o ciclo novamente e prosseguir até que seja alcançado um estado de perfeição no qual o valor perfeito é criado sem desperdício. Figura 1 - Princípios Lean Thinking O sistema de produção lean conforme descrito, consiste num complexo conjunto de ideias, incluindo melhoria contínua, estruturas organizacionais planas, trabalho em equipa, eliminação de desperdícios, e uso eficiente de recursos. O objetivo principal da produção lean é a eliminação de desperdícios (muda) (Green, 1999). Valor Fluxo de valor Fluxo contínuo Produção puxada Perfeição 10 2.3.2 Desperdícios Muda é a palavra japonesa que quer dizer desperdício, especificamente qualquer atividade humana que consuma recursos, mas que não acrescenta nenhum valor ao produto final. Tais como, erros que exijam retificação, produção de itens que acabam em stock, processamento de etapas que não são necessárias, movimentações de funcionários e transporte de mercadorias de um ponto para outro sem qualquer finalidade, funcionários parados à espera porque uma atividade não foi entregue a tempo, e bens e serviços que não atendem às necessidades do cliente (Womack & Jones, 2003). O sistema de produção Toyota é um método para eliminar o desperdício e aumentar a produtividade. Para aplicar o sistema de produção Toyota, o passo preliminar é identificar completamente os desperdícios, e Ohno (1988) foi quem identificou os sete tipos de desperdícios que são: • Desperdício de sobreprodução – produzir em quantidade maior do que a necessária para o procedimento seguinte ou para o cliente. Isto é, produzir mais do que é necessário, quando não é necessário e em quantidades desnecessárias. Este é um dos piores desperdícios, porque acaba por contribuir para os outros seis desperdícios. É uma operação que continua a produzir, quando já devia ter parado; • Desperdício de espera – acontece quando há períodos de inatividade num processo porque a atividade anterior não entregou componentes no prazo. Isto por vezes quer dizer que estas operações anteriores não agregam valor ou resultam numa sobreprodução; • Desperdício de transporte – movimentos desnecessários de material, como produtos em processamento serem transportados de um ponto para o outro, isto é, movimentação de componentes dentro das instalações. Regra geral, o transporte deve ser minimizado já que adiciona tempo ao processo durante o qual não vai acrescentar nenhum valor e pode ocorrer danos por manusear o produto; • Desperdício de processo – execução de tarefas extra que não agregam valor para o cliente final, mas que são necessárias devido à forma como o processo está estruturado; • Desperdício de stock – todo o stock que não é exigido pelo cliente atual, incluindo materiais, work-in-progress, e produtos finais. Inventário exige trabalho e espaço adicional, o que muitas vezes é um indicador de sobreprodução; • Desperdício de movimentação – movimentações desnecessárias pelos funcionários ou equipamento para se adaptarem, a um layout ineficiente, defeitos, reprocessamento, sobreprodução ou excesso de inventário. Movimentações roubam tempo e não acrescentam valor ao produto final; • Desperdício de defeitos – produtos finais que não se encontram em conformidade com as especificações do cliente, o que causam uma insatisfação do mesmo. 11 A eliminação completa desses desperdícios pode aumentar a eficiência de operação por uma ampla margem, sendo que para o fazer deve apenas produzir a quantidade necessária (Ohno, 1988). 2.3.3 Gestão de Projetos Lean Projetos são sistemas temporários de produção, e quando estes sistemas são estruturados para entregar produto enquanto maximizam valor e minimizam o desperdício, são chamados de projetos Lean. A gestão de projetos Lean é diferente da gestão de projetos tradicional em vários aspetos. Não difere apenas nos objetivos de cada um, mas também na estrutura das suas fases, na relação entre as fases e também nos participantes em cada fase (Ballard & Howell, 2003). O conceito de gestão de projetos Lean é retirado da produção Lean para a indústria da construção, em que a forma de uniformizar é uma das abordagens Lean em projetos de maior dimensão. Ainda assim, a principal definição de gestão de projetos Lean está em agregar mais valor com menos desperdício no contexto do projeto (Karim & Nekoufar, 2011). 2.4 Revisão Sistemática de Literatura A realização de uma revisão de literatura é uma parte importante de qualquer projeto de investigação. O investigador avalia o território intelectual relevante, a fim de especificar uma questão de pesquisa que irá desenvolver ainda mais a base do conhecimento sobre o tema (Tranfield et al., 2003). Uma revisão sistemática de literatura é um tipo de investigação científica, realizado através de uma avaliação estruturada da literatura com o objetivo de responder a uma pergunta específica de investigação ou aplicação com uma síntese das melhores evidências (Zumsteg, Cooper, & Noon, 2012). Desta forma, uma revisão sistemática começa com uma pergunta de investigação bem definida, onde o estudo deve ter uma extração explícita e reproduzível dos dados, e uma apresentação e interpretação crítica e adequada da informação retirada. Além disso, estes dados podem inspirar à realização de investigações futuras relacionadas com a análise de síntese (Ravindran & Shankar, 2015). O âmbito e a estrutura de uma revisão em qualquer campo variam de acordo com sua finalidade. O objetivo de uma revisão pode ser fornecer uma pesquisa de publicações anteriores, criticar o trabalho atual ou fazer projeções resumidas sobre descobertas futuras. Uma revisão pode discutir dados, opiniões ou práticas de uma região geográfica específica, pode explorar uma tecnologia ou sistema específico ou pode até ter como objetivo fornecer uma cobertura abrangente sobre um tópico. As revisões sistemáticas variam no âmbito, qualidade e relevância e podem procurar expandir os dados existentes, agrupando os resultados de uma maneira que forneça um maior grau de certeza, menos erros ou responda a uma pergunta totalmente nova usando os dados existentes (Zumsteg et al., 2012). No entanto, o objetivo de uma revisão sistemática de literatura não é apenas agregar dados e informação sobre a pergunta de investigação, é também apoiar o desenvolvimento de guias baseadas em evidências para os investigadores (Kitchenham et al., 2008). Logo, uma revisão sistemática de literatura pode ser 12 definida como uma avaliação metódica de um assunto de acordo com o plano previamente determinado (Jones & Evans, 2000). De acordo com Kitchenham (2004), uma revisão sistemática de literatura é um meio de identificar, avaliar e interpretar todas as pesquisas disponíveis e relevantes para uma questão em particular, área ou fenómenos de interesse. Há muitas razões para realizar uma revisão sistemática de literatura, em que as mais comuns são: • Resumir a existência de uma evidência relativa a um tratamento ou tecnologia, por exemplo, sintetizar a evidência empírica dos benefícios e limitações de um específico método ágil; • Identificar lacunas numa pesquisa atual de forma a sugerir novas áreas de investigação; • Fornecer ferramentas para posicionar adequadamente novas atividades de investigação. Contudo, uma revisão sistemática de literatura pode também ser realizada para examinar a extensão de qual evidência empírica apoia ou contradiz a hipótese teórica, ou até auxiliar a formulação de novas hipóteses. Segundo Kitchenham (2004) as revisões sistemáticas de literatura requerem consideravelmente um esforço maior do que as revisões tradicionais. A maior vantagem é que fornecem informação sobre efeitos de algum fenómeno numa ampla gama de configurações e métodos empíricos. Se o estudo der resultados consistentes, a revisão sistemática de literatura fornece evidências que o fenómeno é sólido e transferível. Algumas das características que diferenciam uma revisão sistemática de uma revisão de literatura convencional são: • Revisões sistemáticas começam por definir o protocolo de revisão onde especifica a pergunta e os métodos que serão utilizados para a realizar. • Revisões sistemáticas baseiam-se numa estratégia de pesquisa definida, com o objetivo de detetar o maior número possível de literatura relevante. • Revisões sistemáticas documentam a sua estratégia de pesquisa para que, quem lê possa aceder ao rigor e integridade. • Revisões sistemáticas requerem uma explícita inclusão e exclusão de critérios para aceder a cada potencial estudo primário. • Revisões sistemáticas especificam a informação a ser obtida de cada estudo primário incluindo critérios de qualidade para avaliar cada estudo primário. • Uma revisão sistemática é um pré-requisito para uma meta-análise quantitativa. Assim, as revisões sistemáticas de literatura refletem as perspetivas, preferências e as propensões dos investigadores em relação à forma de, conceber o problema, representar as perguntas de investigação, selecionar os artigos a rever e como tratar os resultados (Sandelowski, 2008). 19 Autor Artigo e respetivo autor Número citações 26 (Procter, Rouncefield, Poschen, Lin, & Voss, 2011) Procter, R., Rouncefield, M., Poschen, M., Lin, Y., & Voss, A. (2011). Agile project management: A case study of a Virtual Research Environment development project. Computer Supported Cooperative Work , 20 (3). https://doi.org/10.1007/s10606-011-9137-z 17 27 (Nurdiani, Börstler, & Fricker, 2016) Nurdiani, I., Börstler, J., & Fricker, S. A. (2016). The impacts of agile and lean practices on project constraints: A tertiary study. Journal of Systems and Software , 119 , 162–183. https://doi.org/10.1016/j.jss.2016.06.043 16 28 (McHugh, Conboy, & Lang, 2011) McHugh, O., Conboy, K., & Lang, M. (2011). Using agile practices to influence motivation within IT project teams. Scandinavian Journal of Information Systems , 23 (2). 16 29 (Law & Lárusdóttir, 2015) Law, E. L.-C., & Lárusdóttir, M. K. (2015). Whose Experience Do We Care About? Analysis of the Fitness of Scrum and Kanban to User Experience. International Journal of Human-Computer Interaction , 31 (9), 584–602. https://doi.org/10.1080/10447318.2015.1065693 15 30 (Mafakheri, Nasiri, & Mousavi, 2008) Mafakheri, F., Nasiri, F., & Mousavi, M. (2008). Project agility assessment: an integrated decision analysis approach. Production Planning & Control , 7287 (February 2015), 37–41. https://doi.org/10.1080/09537280802360884 15 31 (Middleton, Taylor, Flaxel, & Cookson, 2007) Middleton, P., Taylor, P. S., Flaxel, A., & Cookson, A. (2007). Lean principles and techniques for improving the quality and productivity of software development projects: A case study. International Journal of Productivity and Quality Management , 2 (4), 387–403. https://doi.org/10.1504/IJPQM.2007.013334 15 32 (Baird & Riggins, 2012) Baird, A., & Riggins, F. J. (2012). Planning and sprinting: Use of a hybrid project use of a hybrid project use of a hybrid project management methodology within a CIS capstone course. Journal of Information Systems Education , 23 (3). 14 34 (Terje Karlsen, Hagman, & Pedersen, 2011) Terje Karlsen, J., Hagman, L., & Pedersen, T. (2011). Intra-project transfer of knowledge in information systems development firms. Journal of Systems and Information Technology , 13 (1), 66–80. https://doi.org/10.1108/13287261111118359 13 35 (Garcia, Pacheco, & Calvo-Manzano, 2010) Garcia, I., Pacheco, C., & Calvo-Manzano, J. (2010). Using a web-based tool to define and implement software process improvement initiatives in a small industrial setting. IET Software , 4 (4). https://doi.org/10.1049/ietsen.2009.0045 13 36 (Larson & Drexler Jr., 2010) Larson, E., & Drexler Jr., J. A. (2010). Project management in real time: A service-learning project. Journal of Management Education , 34 (4). https://doi.org/10.1177/1052562909335860 13 20 3.3 Critérios de Revisão Os critérios de revisão foram criados para identificar quais os artigos que se identificam como Lean ou ágil. Estes critérios dividem-se em analisar princípios e ferramentas associadas a cada uma das abordagens de gestão de projetos. Este subcapítulo encontra-se dividido nas duas abordagens, Lean e ágil, onde explica e descreve os critérios de revisão usados. 3.3.1 Lean Para classificar um artigo como Lean, este tem que preencher alguns requisitos. Uma das ferramentas utilizadas, que está dentro do pensamento Lean é o Kanban. O Kanban é uma ferramenta visual e prática que permite manter a produção just-in-time . Deste modo, a classificação dos artigos quanto à categoria de gestão de projetos, baseia-se nos princípios do Lean Thinking e no Kanban. O Kanban foi adicionado porque é a ferramenta mais utilizada na área, e os critérios basearam-se nos princípios do Lean porque são a base desta abordagem. Os cinco princípios criados são: • Valorizar - é necessário definir do ponto de vista do cliente o que é valor; • Cadeia de valor - onde são identificadas as etapas de fluxo de valor necessárias para cada produto, podendo eliminar aquelas que não acrescentam valor; • Fluxo - fazer com que as etapas criadas anteriormente ocorram de forma sequencial; • Puxar - à medida que o fluxo vai sendo introduzido deixar que o cliente retire valor da atividade anterior; • Perfeição - seguir este ciclo de etapas até atingir um estado de perfeição em que o valor perfeito é criado sem desperdício. Logo, através destes princípios é possível verificar quais os artigos que se enquadram em cada um deles e assim verificar a distribuição de artigos por categoria. 3.3.2 Ágil A abordagem ágil assenta nos princípios e valores do documento a que chamaram de manifesto ágil. Para classificar se os artigos analisados se enquadram nesta abordagem foram criados critérios de avaliação. Os critérios de revisão foram criados a partir dos princípios do manifesto ágil. Porém, também se adicionou o método Scrum, porque é a ferramenta mais citada e mais utilizada dentro das abordagens ágeis. Os cinco princípios criados, usados como critérios de revisão são: • Valorizar equipa - porque é importante ter indivíduos motivados no projeto; 21 • Valor do cliente - é importante satisfazer os requisitos do cliente através de entrega rápida de software; • Colaboração do cliente - a equipa de desenvolvimento deve trabalhar em conjunto com o cliente; • Software funcional - deve ser fornecido software funcional com períodos de entrega curtos, de forma a aumentar assim a agilidade; • Ajustes - onde devem ser aceites requisitos de alterações em qualquer altura do projeto. Assim, fica possível analisar quais os critérios mais mencionados e também qual é a distribuição de artigos quanto a esta abordagem. 3.4 Análise Qualitativa Na análise qualitativa foram realizadas duas codificações de categorias distintas. A primeira análise foi efetuada com base numa relação entre os princípios do Lean Thinking e do Manifesto Ágil divididos em critérios que foram previamente selecionados. A segunda análise codificou em categorias distintas as áreas de aplicação desses artigos. Na Tabela 2, estão descritas as categorias criadas que foram usadas como critérios, e podem ser observados os princípios Lean (PL1) criados, e o respetivo princípio do Lean Thinking em que se baseou. Tabela 2. Categorias criadas a partir dos princípios do Lean Thinking Descrição Princípios do Lean Thinking PL1 Valorizar Identifique o valor de acordo com o seu cliente PL2 Cadeia de valor Capturar o valor definido pelas partes interessadas do cliente; mapear o fluxo de valor e eliminar o desperdício PL3 Fluxo Flua o trabalho através do valor planeado e simplificado, adicionando etapas e processos PL4 Puxar Deixe os clientes puxarem valor PL5 Perfeição Objetivar a perfeição em todos os processos Para classificar os artigos extraídos quanto à gestão de projetos ágil, se estes se enquadram na abordagem, foram criados critérios para essa observação. Esses critérios foram gerados a partir dos princípios do manifesto ágil, e encontram-se descritos na Tabela 3 onde podem ser visualizados. Por exemplo, observando a tabela, o critério PA4 (princípio ágil 4) descrito como software funcional, 22 corresponde a três princípios. Esses são princípios do Manifesto Ágil que deram origem a este critério, sendo também o seu significado. Tabela 3. Categorias criadas a partir dos princípios do manifesto ágil Descrição Princípios do Manifesto Ágil PA1 Valorizar equipa P5: Desenvolver projetos com base em indivíduos motivados, dando-lhes o ambiente e o apoio de que necessitam, confiando que irão cumprir os objetivos. PA2 Valor do cliente P1: A nossa maior prioridade é, desde as primeiras etapas do projeto, satisfazer o cliente através da entrega rápida e contínua de software com valor. PA3 Colaboração do cliente P4: O cliente e a equipa de desenvolvimento devem trabalhar juntos, diariamente, durante o decorrer do projeto PA4 Software funcional P3: Fornecer frequentemente software funcional. Os períodos de entrega devem ser de poucas semanas a poucos meses, dando preferência a períodos mais curtos. P7: A principal medida de progresso é a entrega de software funcional. P9: A atenção permanente à excelência técnica e um bom desenho da solução aumentam a agilidade. PA5 Ajustes P2: Aceitar alterações de requisitos, mesmo numa fase tardia do ciclo de desenvolvimento. Os processos ágeis potenciam a mudança em benefício da vantagem competitiva do cliente. P6: O método mais eficiente e eficaz de passar informação para e dentro de uma equipa de desenvolvimento é através de conversa pessoal e direta. P8: Os processos ágeis promovem o desenvolvimento sustentável. Os promotores, a equipa e os utilizadores deverão ser capazes de manter, indefinidamente, um ritmo constante. P10: Simplicidade - a arte de maximizar a quantidade de trabalho que não é feito - é essencial. P11: As melhores arquiteturas, requisitos e desenhos surgem de equipes autoorganizadas. P12: A equipa reflete regularmente sobre o modo de se tornar mais eficaz, fazendo os ajustes e adaptações necessárias. As categorias listadas na Tabela 2 e na Tabela 3 foram usadas para sintetizar os princípios de Lean Thinking e Manifesto Ágil que são observáveis nos artigos analisados. Na Tabela 4 pode ser observada a lista de artigos selecionados, bem como as categorias de princípios descritas anteriormente nas tabelas 2 e 3, ou seja, categorias criadas a partir dos princípios Lean e do manifesto ágil. A esta Tabela 4 também foram adicionadas duas ferramentas para gestão de projetos Lean e ágil, que são Kanban e Scrum, respetivamente. A última coluna da tabela com o nome “tipo” refere-se a uma classificação que foi dada a cada artigo relacionado com gestão de projetos Lean com a letra L, e com gestão de projetos ágeis com a letra A. Cada artigo encontra-se classificado com uma 23 destas abordagens, com a exceção do artigo número 27 que está classificado com o tipo A/L porque se enquadra nas duas classificações. Tabela 4. Categorias de princípios do Lean Thinking, manifesto ágil e de ferramentas para gestão de projetos Lean e ágil PL1 PL2 PL3 PL4 PL5 PA1 PA2 PA3 PA4 PA5 Kanban Scrum Tipo 1 X X L 2 X A 3 X X X L 4 X X X X A 5 X X X A 6 X A 7 X A 8 X X X X X X A 9 X A 10 X X X X X X X X X X X X L 11 X A 12 X X X A 13 A 14 A 15 X X A 16 X X L 17 X X X X A 18 X X X X A 19 X X X X A 20 X L 21 X A 22 X X X A 23 X X X X X X L 24 X X X X X L 25 X X X X X L 24 PL1 PL2 PL3 PL4 PL5 PA1 PA2 PA3 PA4 PA5 Kanban Scrum Tipo 26 X X X X A 27 X X A/L 28 X X A 29 X X X A 30 A 31 X X X X X L 32 X X A 34 X X X X A 35 A 36 X X A Após observar a Tabela 4, é de notar que os artigos com o número 13, 14, 30 e 35 não tiveram nenhum princípio identificado, apesar de se enquadrarem no tema. De forma a analisar quais as categorias de aplicação presentes nos artigos, foi feito um levantamento das mesmas. Depois de feito esse levantamento e devidamente organizado é possível observar duas tabelas para o efeito, em que cada uma apresenta o número do artigo que se enquadra nessa área. Na Tabela 5, são apresentadas as áreas de aplicação dos artigos e o respetivo número de artigo que se enquadra na área. Áreas essas que são: construção, educação, produção e software. Tabela 5. Categorias de aplicação dos artigos Áreas Número do Artigo Construction 1, 16, 20, 24, 25 Education 7, 32, 36 Manufacturing 1, 16, 20, 23, 24, 25 Software 8, 10, 23, 26, 27, 29, 31, 35 25 Na Tabela 6 é possível observar que está estruturada em ferramentas aplicadas e número do artigo correspondente. As ferramentas são “case study” e “framework” , e aqui são identificados os artigos que utilizam casos de estudo como método, e por outro lado se usam ou descrevem algum tipo de “framework” ao longo do trabalho. Tabela 6. Ferramentas aplicadas nos artigos Ferramentas Número do Artigo Case study 1, 2, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 16, 17, 18, 19, 20, 23, 24, 25, 26, 28, 29, 30, 31, 34, 35, 36 Framework 1, 3, 8, 10, 11, 14, 15, 16, 17, 18, 20, 21, 22, 23, 24, 25, 26, 30, 31, 35 27 4. RESULTADOS Os resultados deste estudo estão descritos ao longo deste capítulo, nas duas secções seguintes. A primeira secção relata a análise bibliográfica efetuada conforme a pesquisa efetuada na base de dados Scopus. Enquanto que, na segunda secção está descrita a análise qualitativa dos artigos extraídos da base de dados. 4.1 Análise Bibliográfica Uma análise bibliográfica tem como objetivo a análise de dados relacionados com os artigos, e que são relevantes para investigação do tema. Este é apresentado em secções: informação geral, análise de revistas, análise de autores, análise de artigos por citações, análise de palavras-chave e por fim análise de artigos por áreas de conhecimento. 4.1.1 Informação Geral A gestão de projetos ágeis é uma área ainda com pouca informação, mas cada vez mais em crescimento devido à sua importância. Crescimento esse que é visível através dos gráficos a seguir apresentados e que surgem como resultado da pesquisa efetuada na base de dados Scopus . Figura 3 - Número de artigos publicados por ano Na Figura 3 é possível observar o número de artigos publicados por ano. Neste gráfico pode-se observar um crescimento quanto à publicação de artigos relacionados com o tema, entre os anos 2005 e 2018. E é notório o crescimento ao longo dos anos, porém o ano de 2016 foi a época que se registou com mais publicações, com 19 artigos no total. Contudo, há uma ligeira quebra no crescimento de publicações nos dois anos seguintes, no entanto é de realçar o interesse na área. 0 2 4 6 8 10 12 14 16 18 20 Número de artigos 28 Figura 4 - Número de citações registadas por ano Na Figura 4, é possível observar o número de citações realizadas por ano. Apesar de se observar no gráfico anterior que houve uma descida nos últimos dois anos quanto ao número de artigos publicados, neste gráfico observa-se que o número de citações tem aumentado de forma crescente ao longo do tempo. Em 2018 foram registadas 388 citações na base de dados. Assim, pela observação do gráfico, confirma-se que o tema tem suscitado cada vez mais interesse por parte de investigadores. Na Figura 5 é possível observar quais os países com maior impacto na publicação de artigos. Aqui está representada uma distribuição de artigos por país, de forma a entender qual o país que mais contribuiu com publicações de artigos até ao momento. De um total de 40 países apenas se visualizam 11, porque são aqueles que contribuíram com no mínimo 4 artigos. Visualizando o gráfico, facilmente se percebe que uma boa parte das publicações são dos EUA, com 37 artigos. Em seguida encontra-se o Reino Unido e a Alemanha, com 18 e 14 artigos respetivamente. Figura 5 - Número de artigos por país 0 50 100 150 200 250 300 350 400 450 2015 2016 2017 2018 Número de citações 0 5 10 15 20 25 30 35 40 Número de artigos 35 com a abordagem de (Baird & Riggins, 2012) "provide lessons learned and best practices for those who wish to provide students with an applied experience that combines waterfall (traditional) and Scrum (agile) project management techniques in their own courses” . No artigo de (Larson & Drexler Jr., 2010), também é descrito a aplicação dos conceitos de gestão de projetos ágeis num curso em que os alunos usam o que aprenderam em projetos reais com contextos sociais. Neste caso, os alunos trabalharam com instituições de caridade, em que faziam uma série de entregas parciais do projeto. 4.2.2 Categoria “Produção” Quanto à categoria de produção (“production; Manufacturing”), 6 artigos foram classificados nessa categoria sendo que todos estão relacionados com gestão de projetos Lean: (Ballard & Howell, 2003), (Sanderson & Cox, 2008), (Gao & Low, 2014), (Mejabi, 2003), (Al-Aomar, 2012) e por fim (Bryde & Schulmeister, 2012). Os 6 artigos identificados apresentam estudos de caso, nos quais foram aplicadas frameworks, conceitos e técnicas de Lean Construction , Lean Thinking e Lean Manufacturing. De entre estes artigos, 5 deles estão relacionados com Lean Construction como, (Ballard & Howell, 2003), (Sanderson & Cox, 2008), (Gao & Low, 2014), (Al-Aomar, 2012) e (Bryde & Schulmeister, 2012). De acordo com (Mejabi, 2003) no seu artigo é apresentada uma metodologia de desenvolvimento de um sistema de planeamento de produção Lean na qual, " ... has focused on longer-term planning requirements for lean manufacturing. A need clearly exists for tools that support shorter-term and more detailed approaches to lean manufacturing, particularly the estimation of more accurate improvements in performance” . 4.2.3 Categoria “Software” Na categoria de software foram classificados 8 artigos: (Lee & Yong, 2010), (Middleton & Joyce, 2012), (Mejabi, 2003), (Middleton et al., 2007), (Procter et al., 2011), (Garcia et al., 2010), (Nurdiani et al., 2016) and (Law & Lárusdóttir, 2015). Os artigos de (Middleton & Joyce, 2012), (Mejabi, 2003) e (Middleton et al., 2007) utilizam conceitos, princípios e técnicas de Lean Manufacturing que foram aplicadas no desenvolvimento de softwares. Os autores (Middleton & Joyce, 2012) descrevem uma lista onde é feita uma comparação entre os princípios e técnicas Lean utilizadas no projeto com o Scrum, que é a metodologia de gestão ágil de software mais identificada na pesquisa. Nesta relação destacam-se vantagens e desvantagens da gestão de projetos Lean comparando com a gestão de projetos ágil. No trabalho de (Middleton et al., 2007) destaca-se o uso e o sucesso da aplicação de gestão de projetos Lean numa empresa real de desenvolvimento de software. No artigo de (Lee & Yong, 2010) destaca-se o desenvolvimento distribuído de software com o uso do Scrum, incluindo uma nova arquitetura distribuída de desenvolvimento de software. Essa arquitetura era uma rede Scrum distribuída por diversas equipas em diversos locais, em que cada equipa era constituída por equipas e 36 Scrum Master. Como estas equipas não estavam localizadas no mesmo local, isto impediu a sua presença nas conversas cara-a-cara, que é um dos critérios que fazem parte dos princípios fundamentais do Manifesto Ágil: “ The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” . No artigo de (Garcia et al., 2010) é descrito o modelo de um software Web para definir e implementar iniciativas de melhoria de desenvolvimento em pequenas e médias empresas que estão em processo de melhoria de software. A partir de pontos identificados pelo modelo, uma pequena e/ou média empresa pode ser conduzida a estratégias de melhoria no seu processo de desenvolvimento. Apesar do software Web de (Garcia et al., 2010) não estar inserido dentro de uma gestão de projetos ágil ou Lean, o uso deste modelo de software permitiria a implantação de um ambiente propício a uma metodologia ágil, porque “The main objective of this research is to demonstrate that a small organization may use a Webbased tool ... and the ... model as a framework to strengthen defined agile project management practices, improve the project performance, and achieve high CMMI-DEV capability levels” . De acordo com (Procter et al., 2011), o objetivo era "... explore and understand the ‘lived work’ of software project management in the context of an application domain in which rapid development and strong user engagement are generally acknowledged as being essential for success” . Para isso acontecer, observaram as diferentes formas pelas quais a equipa se orientou durante o projeto, tentando garantir que continuassem no caminho certo de desenvolvimento e teste. Ao mesmo tempo, forneceria um serviço piloto e garantiria o envolvimento do utilizador, de modo que o projeto pudesse evoluir de acordo com os requisitos do utilizador. O artigo de (Nurdiani et al., 2016) é um estudo terciário de uma revisão sistemática de literatura, com o objetivo de consolidar as evidências empíricas das práticas ágil e Lean, bem como os seus impactos nas restrições definidas no livro PMBOK: âmbito, qualidade, cronograma, orçamento, recursos, comunicação e risco. Os resultados obtidos neste artigo sugerem que não há consenso na avaliação do impacto dessas práticas sobre as áreas de conhecimento descritas no PMBOK, porque há uma variação destas práticas que fazem com que a agregação dos resultados e uma possível conclusão sejam difíceis. Outra evidência é que estudos experimentais conduzidos por alunos que estão a aprender práticas ágeis e Lean, não afetam nenhuma das restrições de gestão de projetos. Conforme está descrito no artigo de (Law & Lárusdóttir, 2015) é realizado um estudo em relação ao desenvolvimento de software focado na experiência do utilizador (UX) considerando que existem duas linhas específicas como Agile UX e Lean UX. Os autores consideraram que estas linhas de Agile UX e Lean UX estão relacionadas com Scrum e Kanban, respetivamente. O principal resultado obtido pelos autores realça que os profissionais das empresas envolvidas no estudo não estão preocupados com a distinção entre os dois conceitos, porque concordam com a abordagem mais eficaz e eficiente para obterem a melhor qualidade, num curto período de tempo e com o menor orçamento possível. 37 4.2.4 Categorias “estudo de caso” e “framework” Nos próximos parágrafos, as categorias de estudo de caso e framework serão descritas juntas porque aparecem na maioria dos artigos. Isto é possível observar na Tabela 6 em que mostra que “case study ” tem 29 artigos e “framework” tem 20 artigos. Os autores (Carlos & Amaral, 2010), (Beckett, 2015), (Hoda & Murugesan, 2016), (Conforto et al., 2016), (Mafakheri et al., 2008) e (Tripp et al., 2016) desenvolveram frameworks através de um estudo de caso. Os autores (Carlos & Amaral, 2010), desenvolveram o seu estudo em duas empresas tecnológicas localizadas no pólo tecnológico de São Carlos, Brasil, construindo um modelo intitulado de IVPM2 (Iterative and Visual Method of Project Management) , aplicando os princípios de gestão de projetos ágeis. O modelo é estruturado em sete passos, com as abordagens conjuntas, tradicional e ágil, como referência padrão e o uso de modelos e procedimentos para atender aos requisitos do projeto. O artigo de (Beckett, 2015) descreve através de quatro casos um método hierárquico do modelo de definição de sistemas funcionais baseados nos elementos. À medida que os fabricantes avançam no fornecimento de embalagens de produtos e serviços, e à medida que as empresas de serviços proliferam, o design e a operação dos sistemas envolvem elementos mais intangíveis e a participação de uma ampla gama de comunidades profissionais. Como tal, cada uma dessas comunidades pode ter ideias limitadas sobre como cada uma delas funciona e pode usar gírias diferentes. Os casos apresentados servem para esclarecer os requisitos de negócios ou sistemas sociotécnicos durante as fases de desenvolvimento, operação e reengenharia do sistema. No artigo de (Hoda & Murugesan, 2016), está descrito um conjunto de oito desafios de gestão de projetos que foram identificados com equipas ágeis e auto-organizadas em vários níveis. De acordo com os autores, embora a literatura tenha explorado algumas questões relacionadas com a gestão, pouco se sabe sobre como o alto envolvimento de equipas ágeis e auto-organizadas influencia as atividades diárias de gestão de projetos. O estudo foi realizado com 21 profissionais ágeis em seis empresas de software que implementam scrum e XP. Como resultado os desafios encontrados foram: atrasos e/ou mudanças nos requisitos; alcançar estimativas multifuncionais e eficazes ao nível da equipa; afirmar autonomia e auto-atribuição no nível individual e falta de critérios de aceitação e dependências no nível da tarefa. Os artigos de (Lévárdy & Browning, 2009), (Leybourne, 2009), (Saynisch, 2010), (Conforto et al., 2016) e (Baird & Riggins, 2012) lidam com estudos teóricos ou aplicação de modelos conceituais, e onde tratam o termo “agilidade” para a tomada de decisão do projeto. No trabalho de (Lévárdy & Browning, 2009) é apresentado um adaptive process model que decompõe em atividades e deliverables todo o processo de desenvolvimento de um produto. Cada atividade é calculada por alguns critérios como: (i) critério de entrada; (ii) custo; (iii) duração; (iv) fidelidade; (v) efetividade; (vi) disponibilidade e (vii) valor. Esse modelo adaptativo idealizado em (Lévárdy & Browning, 2009) tende a avaliar os caminhos, iterações, custos, durações, riscos e valores envolvidos em todo o projeto; provendo subsídios para que gerentes possam realizar tomadas de decisões durante o processo. Contudo, apesar de apresentar a palavra-chave agile project management no artigo de (Lévárdy & Browning, 2009), o mesmo não utiliza 38 princípios do Manifesto Ágil, mas considera que o modelo adaptativo permite a agilidade. O conceito de agilidade em gestão de projetos é diversificado, pois não há consenso sobre a definição do mesmo, o que leva muitas vezes a que seja mal empregue por muitos investigadores. No artigo de (Conforto et al., 2016) é descrita uma análise do termo agility e seu uso na teoria de gestão de projetos. Segundo (Conforto et al., 2016): “1. Agility should be considered a project team's performance and not merely an adjective of a certain practice or method, e.g., agile methods” ; “2. The agility performance might be affected by a combination of ability to change the project plan and active customer involvement” ; “3. The agility as a team's performance indicator has different levels and it would be relevant to investigate how different levels of agility are influenced by internal and external factors, and how these levels might impact project results in different degrees and circumstances” . A improvisação também é uma característica que aparece em gestão de projetos ágeis, devido à mudança de requisitos. No artigo de (Leybourne, 2009) é tratada a improvisação com a agilidade da gestão de projetos ágeis, na qual uma equipa deve lidar com as alterações de requisitos e a capacidade de refletir os impactos da improvisação. (Leybourne, 2009), tratou de realizar uma pesquisa essencial conceitual "... and concludes with a comparative table of constructs, and their segregation into components and outputs. The growth in the recognition of improvisation as a useful addition to the armoury of the project manager stems from the shift that is taking place within the body of project knowledge generally... ". Em relação ao trabalho de (Saynisch, 2010) é descrita uma gestão de projetos de segunda ordem denominado PM-2, que incorpora aspetos do CPMCS (ICCPM), ICB3 (IPMA) e PMBoK Guide/OPM3 (PMI). O PM-2 trata de projetos de diferentes níveis e com aplicações em diferentes níveis tanto no CPMCS, ICB3 e PMBoK. Esses diferentes níveis de gestão de projetos são tratados como “ Worlds ” conceituais que devem abranger diferentes tipos de aplicações e níveis de dificuldades atuais de projetos do mundo real. (Conforto et al., 2016) apresentam uma estrutura de gestão híbrida que combina a gestão ágil de projetos e o modelo stage-gate implementado num projeto de tecnologia. Como resultado, provocam um impacto positivo no desempenho do projeto e do desenvolvimento de produtos. E desta forma, sugerem que a combinação dessas duas abordagens, para equilibrar a estabilidade com a flexibilidade, é uma solução potencial para gerir projetos de inovação em empresas de alta tecnologia. No trabalho de (Mafakheri et al., 2008) foi utilizado um modelo (framework) de auxílio à decisão demonstrada por um estudo de caso, em gestão de projetos de desenvolvimento de software. Para os autores a definição de agilidade é definida como a capacidade de um projeto de responder efetivamente a um ambiente em mudança. Isso pode incluir a capacidade de um projeto ser adaptado ao dinamismo que existe nas necessidades das partes interessadas, mudanças tecnológicas, etc. Para assegurar esta capacidade, é necessário avaliar a extensão da adaptabilidade dos projetos à mudança. Isto pode ser feito expressando a agilidade em termos de alguns parâmetros quantificáveis, como o tamanho da organização do projeto, níveis de especialização, etc. Para abordar tal complexidade, um modelo de auxílio à decisão utilizando a teoria dos conjuntos fuzzy é proposto para a avaliação da agilidade dos projetos. Por fim, (Tripp et al., 2016) articularam um modelo de projeto de trabalho que liga as práticas de desenvolvimento ágil às perceções das características do trabalho, para desta forma, melhorar a 39 satisfação no trabalho dos membros da equipa ágil. Neste estudo foram recolhidos dados de 252 profissionais de desenvolvimento de software, testaram o modelo e descobriram uma relação positiva entre as práticas de gestão de projetos ágeis e o desenvolvimento de software e as perceções dos funcionários sobre as características do trabalho. O artigo de (Larson & Drexler Jr., 2010) é caracterizado por um estudo de caso, pois são descritas as práticas para o desenvolvimento de um curso experimental de aprendizagem como um serviço para entidades sociais. Estas práticas permitiram o desenvolvimento do projeto, sendo que incorporaram ferramentas de gestão de projetos na execução de atividades e atribuições, bem como envolveram os alunos na compreensão dos conceitos de gestão de projetos e no cumprimento dos prazos. Os autores (Serrador & Pinto, 2015) usaram uma amostra de dados de 1.002 projetos de vários setores e países, para testar o efeito do uso ágil nas organizações em duas dimensões de sucesso do projeto: eficiência e satisfação geral das partes interessadas em relação aos objetivos organizacionais. O artigo de (Conforto et al., 2014) apresenta evidências de uma pesquisa exploratória sobre o uso de práticas de gestão de projetos ágil (APM) e a presença de facilitadores de APM, em 19 médias e grandes empresas de diferentes setores da indústria, que realizaram projetos inovadores. Com a pesquisa efetuada, os resultados mostram as dificuldades das empresas em usar práticas ágeis para o desenvolvimento de projetos em comparação com as práticas de gestão de projetos tradicionais. A presença de facilitadores para implementar a gestão de projetos ágil, permitiu uma gestão híbrida para as diferentes empresas. Assim, como investigação futura, os autores sugerem explorar a correlação entre as práticas e facilitadores de APM, a fim de desenvolver modelos de gestão “híbridos” para diferentes indústrias. Em (Drury et al., 2012), seis obstáculos à tomada de decisão foram identificados como falta de vontade de se comprometer com as decisões; prioridades conflitantes; disponibilidade instável de recursos; e falta de: implementação; propriedade; fortificação. Neste artigo (Drury et al., 2012) foram identificados seis obstáculos à tomada de decisão como, falta de vontade de se comprometer com as decisões; prioridades conflituantes; disponibilidade instável de recursos; e falta de: implementação; propriedade; fortalecimento. Como efeito destes obstáculos os autores identificaram a falta de uma abordagem estratégica de longo prazo para as decisões, um acúmulo crescente de atrasos no trabalho de iterações anteriores e a falta de envolvimento da equipa. (Stettina & Hörz, 2015) realizaram um estudo de caso com base em 30 entrevistas realizadas em 14 grandes organizações europeias, onde o estudo contribui para a compreensão de métodos ágeis de gestão de projetos aplicados em portfólios de projetos de tecnologia de informação. (Persson et al., 2012) desenvolveram um estudo de caso aprofundado de um projeto de software distribuído ágil e bem-sucedido com participantes de uma empresa russa e de uma empresa dinamarquesa. Ofereceram como resultado, uma análise de como o controlo foi promulgado através do contexto do projeto e na comunicação mediada pelos participantes. Na investigação efetuada por (Lei et al., 2017) foi realizada uma análise numérica com base nas respostas dadas por pessoas com experiência nos métodos do Scrum e Kanban. Os resultados sugerem que tanto o Scrum como o Kanban incentivam o desenvolvimento de projetos bem-sucedidos, e que o 40 método Kanban pode tornar mais fácil o uso de métodos de gestão de projetos. Através de um estudo exploratório (McHugh et al., 2011) analisaram equipas de projetos de tecnologias de informação na Suécia e na Irlanda, e investigaram como é que três práticas ágeis, ou seja, levantamentos diários, planeamento de iteração e retrospetivas de interação, contribuem para a motivação ou desmotivação numa equipa ágil. Contudo os autores, também identificam quais os fatores adicionais que motivam e desmotivam os desenvolvedores de tecnologias de informação. No artigo de (Fernandez & Fernandez, 2008), é descrito um estudo de práticas e aplicabilidade da gestão de projetos ágil que é comparado com as abordagens tradicionais de gestão de projetos. As referidas práticas ágeis, incluindo gestão de projetos, surgiram da necessidade de gerir projetos caracterizados pela complexidade e incerteza, com capacidade de resposta e adaptabilidade. O esforço e a flexibilidade de usar práticas de gestão de projetos ágeis e aprender a adaptar-se podem ser altamente benéficas quando confrontadas com tipos e cenários de projetos incertos. A necessidade de conseguir adaptar-se adequadamente ao projeto é crucial para o sucesso. Portanto, é preciso estar disposto a mudar, a adaptar e estar ciente da melhor forma de gerir uma determinada situação do projeto num ambiente e cultura específicos. O artigo destaca também o conceito de agilidade, refere que é a atitude de melhorar a produtividade, a qualidade, a satisfação do cliente e reduzir os custos de produção ao gerir projetos ágeis. Os autores (Terje Karlsen et al., 2011), descreveram o estudo de caso com o objetivo de identificar mecanismos de transferência de conhecimento entre empresas de desenvolvimento de software, com experiência no uso de metodologias ágeis, especialmente o Scrum. Os mecanismos mais importantes foram: pouca documentação e altamente dinâmica, equipas multifuncionais, feedback do cliente, reuniões, gestão de projetos ágil e ferramentas e técnicas de gestão de mudanças. A transferência de conhecimento entre essas empresas pode ser descrita como gestão do conhecimento, pois envolve uma preocupação com a cultura organizacional, liderança e as implicações de como um projeto ágil deve ser estruturado e gerido. 41 5. CONCLUSÃO Os projetos são indispensáveis no desenvolvimento de novos produtos, e por isso a gestão de projetos tem contribuído para a criação e gestão de valor nas empresas através da aplicação de métodos e princípios de gestão. A gestão de projetos Lean e a gestão de projetos ágil são geralmente aplicadas nos contextos de produção e desenvolvimento de software, respetivamente. A gestão de projetos Lean tem sido aplicada no contexto de produção, e possui diversas ferramentas para auxiliar o processo, sendo que o Kanban é a ferramenta mais utilizada. Por outro lado, a gestão de projetos ágil é aplicada no contexto de desenvolvimento de software em que, por exemplo, a metodologia mais utilizado é o Scrum. Estas duas novas abordagens surgem pelo envolvimento de comunidades profissionais diferentes, através de caminhos diferentes quanto às perspetivas sobre a gestão de projetos. Contudo há indícios de que estas abordagens sigam caminhos paralelos e semelhantes. Nesse sentido, esta dissertação partiu da questão de identificar semelhanças e diferenças entre as duas abordagens de gestão de projetos, Lean e ágil, e onde posteriormente se identifique lacunas ou necessidades de investigação futura nesta área. Através da pesquisa efetuada na base de dados Scopus foram retirados 35 artigos, e foram efetuadas duas análises, uma bibliográfica e outra qualitativa. Na análise bibliográfica foram utilizados dados retirados da base de dados, e onde foi possível observar os autores que mais publicações realizaram na área. Nesta perspetiva, Amaral, D.C registou 8 artigos e Conforto, E.C. publicou 6 artigos, contudo nenhum destes autores se encontra nos primeiros três artigos mais citados. Um resultado interessante obtido foi uma análise de palavras-chave, onde se registaram termos que foram repetidos até um mínimo de 7 vezes. E dessa observação retira-se que a palavra-chave mais usada é “Project Management” com 86 vezes. A segunda palavra-chave repetida 53 vezes é “Agile Project Management” . Porém, considerando o tema abordado é de realçar que a palavra-chave “Agile” foi repetida 15 vezes, enquanto que a palavra-chave “Lean” apenas foi usada 7 vezes. Quanto à análise qualitativa foi utilizada a técnica de análise de conteúdo, onde foram descritas duas codificações distintas, descritas nas Tabela 4 e nas Tabela 5 e Tabela 6. A codificação da Tabela 4 está relacionada com os princípios do Lean Thinking e do Manifesto Ágil, juntamente com as duas ferramentas mais usadas, Kanban e Scrum, respetivamente. Através da Tabela 4 verifica-se que, o artigo de (Lei et al., 2017) está classificado como gestão de projetos ágil, no entanto menciona os princípios 1 e 4 de Lean (PL1 e PL4) e a ferramenta Kanban. Quanto à gestão de projetos Lean a exceção está no artigo (Middleton & Joyce, 2012) porque menciona todos os princípios de ágil usados nos critérios da tabela, bem como a ferramenta Scrum. O artigo de (Nurdiani et al., 2016) foi considerado pertencer às duas abordagens, gestão de projetos Lean e gestão de projetos ágeis. A codificação da Tabela 5 e da Tabela 6, teve como objetivo classificar os artigos quanto a área de aplicação, levando em consideração o tipo de artigos classificados na Tabela 4. Quanto aos artigos classificados com o tipo L (Lean), que são 9 no total, chega-se a várias conclusões. Uma é que todos usaram ou descreveram alguma ferramenta para efetuar o estudo, pois na Tabela 6 é possível observar 42 que 8 artigos descrevem casos de estudo. Do total de artigos do tipo L, 5 foram aplicados na construção, 6 na produção e 3 aplicados na área de desenvolvimento de software. Quanto à análise dos artigos classificados com o tipo A (Ágil), foram identificados 25 artigos. Deste total, 21 artigos descrevem casos de estudo, enquanto que 11 artigos usam ou descrevem ferramentas, como é possível observar na Tabela 6. Já a análise quanto à categoria inserida, como se observa na Tabela 5, são 4 artigos na área de desenvolvimento de software e 3 artigos na área de educação. A exceção nesta análise, é o artigo número 27 porque está classificado como A/L, ou seja, enquadra-se nas duas classificações. Porém, este artigo encontra-se aplicado na área de desenvolvimento de software. Como futura investigação relacionada com este tema há duas pesquisas a apontar. A primeira seria fazer uma análise quantitativa dos artigos selecionados neste trabalho, de forma a complementar este estudo em que apenas foi efetuada uma análise qualitativa. E a segunda seria, fazer uma investigação de casos reais em empresas de forma a entender o que está a ser realmente aplicado. Deste modo, perceber-seia com estudos reais o que acontece nas empresas, bem como, se existem diferenças entre as duas abordagens na aplicação no dia-a-dia. 43 6. REFERÊNCIAS BIBLIOGRÁFICAS Al-Aomar, R. (2012). A lean construction framework with six sigma rating. International Journal of Lean Six Sigma , 3 (4), 299–314. https://doi.org/10.1108/20401461211284761 Baird, A., & Riggins, F. J. (2012). Planning and sprinting: Use of a hybrid project use of a hybrid project use of a hybrid project management methodology within a CIS capstone course. Journal of Information Systems Education , 23 (3). Ballard, G., & Howell, G. A. (2003). Lean project management. Building Research and Information , 31 (2), 119–133. https://doi.org/10.1080/09613210301997 Beck, K., Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., … Thomas, D. (2001). Manifesto for Agile Software Development. Retrieved May 6, 2019, from http://agilemanifesto.org/iso/en/manifesto.html Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … Thomas, D. (2001). Principles behind Agile Manifesto. Retrieved May 6, 2019, from http://agilemanifesto.org/iso/en/manifesto.html Beckett, R. C. (2015). Functional system maps as boundary objects in complex system development. International Journal of Agile Systems and Management , 8 (1). https://doi.org/10.1504/IJASM.2015.068610 Bryde, D. J., & Schulmeister, R. (2012). Applying Lean principles to a building refurbishment project: Experiences of key stakeholders. Construction Management and Economics , 30 (9), 777–794. https://doi.org/10.1080/01446193.2012.700405 Carlos, E. C., & Amaral, D. C. (2010). Evaluating an agile method for planning and controlling innovative projects. Project Management Journal , 41 (2). https://doi.org/10.1002/pmj.20089 Conforto, E. C., & Amaral, D. C. (2015). Agile project management and stage-gate model—A hybrid framework for technology-based companies. Journal of Engineering and Technology Management - JET-M , 40 . https://doi.org/10.1016/j.jengtecman.2016.02.003 Conforto, E. C., Amaral, D. C., da Silva, S. L., Di Felippo, A., & Kamikawachi, D. S. L. (2016). The agility construct on project management theory. International Journal of Project Management , 34 (4). https://doi.org/10.1016/j.ijproman.2016.01.007 Conforto, E. C., Salum, F., Amaral, D. C., Da Silva, S. L., & De Almeida, L. F. M. (2014). Can agile project management be adopted by industries other than software development? Project Management Journal , 45 (3). https://doi.org/10.1002/pmj.21410 Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. B. (2012). A decade of agile methodologies: Towards explaining agile software development. Journal of Systems and Software , 85 (6), 1213–1221. https://doi.org/10.1016/j.jss.2012.02.033 Drury, M., Conboy, K., & Power, K. (2012). Obstacles to decision making in Agile software development teams. Journal of Systems and Software , 85 (6). https://doi.org/10.1016/j.jss.2012.01.058 Fernandez, D. J., & Fernandez, J. D. (2008). Agile project management - Agilism versus traditional approaches. Journal of Computer Information Systems , 49 (2). Gao, S., & Low, S. P. (2014). The Last Planner System in China’s construction industry - A SWOT analysis on implementation. International Journal of Project Management , 32 (7), 1260–1272. 44 https://doi.org/10.1016/j.ijproman.2014.01.002 Garcia, I., Pacheco, C., & Calvo-Manzano, J. (2010). Using a web-based tool to define and implement software process improvement initiatives in a small industrial setting. IET Software , 4 (4). https://doi.org/10.1049/iet-sen.2009.0045 Green, S. D. (1999). The missing arguments of lean construction. Construction Management and Economics . https://doi.org/10.1080/014461999371637 Hoda, R., & Murugesan, L. K. (2016). Multi-level agile project management challenges: A self-organizing team perspective. Journal of Systems and Software , 117 . https://doi.org/10.1016/j.jss.2016.02.049 Jones, T., & Evans, D. (2000). Conducting a systematic review. Australian Critical Care , 13 (2), 66–71. https://doi.org/10.1016/S1036-7314(00)70624-2 Karim, A., & Nekoufar, S. (2011). Lean Project Management in Large Scale Industrial & Infrastructure Project via Standardization. Project Perspectives . Kerzner, H. (2009). Project Management - A Systems Approach to Planning, Scheduling, and Controlling . John Wiley & Sons, Inc. Kerzner, H. (2011). Project Management Metrics, KPIs, and Dashboards - A Guide to Measuring and Monitoring Project Performance . John Wiley & Sons, Inc. Kitchenham, B. (2004). Procedures for performing systematic reviews. Keele, UK, Keele University , 33 (TR/SE-0401), 28. https://doi.org/10.1.1.122.3308 Kitchenham, B., Brereton, O. P., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2008). Systematic literature reviews in software engineering – A systematic literature review. Information and Software Technology , 51 , 7–15. https://doi.org/10.1016/j.infsof.2008.09.009 Larson, E., & Drexler Jr., J. A. (2010). Project management in real time: A service-learning project. Journal of Management Education , 34 (4). https://doi.org/10.1177/1052562909335860 Law, E. L.-C., & Lárusdóttir, M. K. (2015). Whose Experience Do We Care About? Analysis of the Fitness of Scrum and Kanban to User Experience. International Journal of Human-Computer Interaction , 31 (9), 584–602. https://doi.org/10.1080/10447318.2015.1065693 Lee, S., & Yong, H.-S. (2010). Distributed agile: Project management in a global environment. Empirical Software Engineering , 15 (2). https://doi.org/10.1007/s10664-009-9119-7 Lei, H., Ganjeizadeh, F., Jayachandran, P. K., & Ozcan, P. (2017). A statistical analysis of the effects of Scrum and Kanban on software development projects. Robotics and Computer-Integrated Manufacturing , 43 , 59–67. https://doi.org/10.1016/j.rcim.2015.12.001 Lévárdy, V., & Browning, T. R. (2009). An adaptive process model to support product development project management. IEEE Transactions on Engineering Management , 56 (4). https://doi.org/10.1109/TEM.2009.2033144 Leybourne, S. A. (2009). Improvisation and agile project management: a comparative consideration. International Journal of Managing Projects in Business , 2 (4). https://doi.org/10.1108/17538370910991124 Mafakheri, F., Nasiri, F., & Mousavi, M. (2008). Project agility assessment: an integrated decision analysis approach. Production Planning & Control , 7287 (February 2015), 37–41. https://doi.org/10.1080/09537280802360884