Strategic use of Scrum framework on BPMS projects

i Strategic use of Scrum framework on BPMS projects João Fernando Campos Mendes Pires Dissertation presented as partial requirement for obtaining the master’s degree in Information Management MGI ii NOVA Information Management School Instituto Superior de Estatística e Gestão de Informação Universidade Nova de Lisboa STRATEGIC USE OF SCRUM FRAMEWORK ON BPMS PROJECTS By João Fernando Campos Mendes Pires Dissertation report presented as partial requirement for obtaining the master’s degree in Information Management, with a specialization in Information Systems and Technologies Management Supervisor: Professor Vítor Manuel Pereira Duarte dos Santos, PhD September 2021 iii ABSTRACT It is rare to find nowadays a business methodology that does not involve any kind of technology, whether in the research or development phases. One methodology that rises above the others when it comes to business processes is BPM. This type of methodology when added a specific software with BPMS integrated becomes highly beneficial to implement. Nevertheless, there are always flaws and gaps that could be filled. On the other hand, software development companies have grown exponentially since the digital transformation was accepted. One reason for that is the working methodology these types of companies follow, as they are known as Agile companies. What this document aims to present is enough artefacts and pros for Scrum, an Agile framework, to rule BPMS projects and minimize the current failures. This dissertation follows a design science research approach to apply multiple analytical methods and perspectives to create an artefact. The type of evidence within this methodology is a systematic literature review, to attain insights into the current state-of-the-art research of BPMS projects and Scrum. Thereby, the systematic literature review shall be used to pinpoint, analyse, and comprehend the obtainable empirical studies and research questions. This approach supports the main goal of this dissertation, to develop and propose evidencebased practise guidelines for the implementation of the Scrum framework on BPMS projects strategy. KEYWORDS Project Development; Scrum Framework; BPM Methodology; Agile BPMS; Design Science Research iv INDEX 1. Introduction ....................................................................................................................... 1 1.1. Background and Problem Identification .................................................................................. 1 1.2. Motivation ............................................................................................................................... 3 1.3. Research Questions ................................................................................................................. 4 1.4. Objectives ................................................................................................................................ 4 2. Literature Review .............................................................................................................. 5 2.1. Business Process Management ............................................................................................... 5 2.1.1. Theoretical Background and Concepts .......................................................................................... 5 2.1.2. Lifecycle ......................................................................................................................................... 6 2.1.3. Business Process Management Systems ....................................................................................... 8 2.1.4. BPMS Projects Features ................................................................................................................ 9 2.1.5. BPMS Project Techniques ............................................................................................................. 9 2.2. Agile Methodology ................................................................................................................ 11 2.2.1. Theoretical Background and Concepts ........................................................................................ 11 2.2.2. Lifecycle ....................................................................................................................................... 12 2.2.3. Agile Frameworks ........................................................................................................................ 13 2.3. Scrum & BPMS ....................................................................................................................... 17 2.3.1. Search Strategy ........................................................................................................................... 17 2.3.2. Search Results ............................................................................................................................. 18 3. Methodology ................................................................................................................... 21 3.1. Design Science Research (DSR) .............................................................................................. 21 3.2 Design Science Research Implementation ............................................................................ 22 3.3 Specialist Interviews Design .................................................................................................. 24 4. Framework for the use of Scrum on BPMS Projects ........................................................ 26 4.1. Assumptions .......................................................................................................................... 26 4.2. Proposal ................................................................................................................................. 26 4.2.1. Scrum on BPMS Projects Concept ............................................................................................... 26 4.2.2. Conceptual Model and Hypotheses Development ..................................................................... 26 4.3. Use Case Simulation .............................................................................................................. 31 4.4. Validation .............................................................................................................................. 33 4.5. Discussion .............................................................................................................................. 34 4.6. Revised Framework for Implementation ............................................................................... 36 5. Conclusions ...................................................................................................................... 36 5.1. Synthesis of the Research ...................................................................................................... 36 5.2. Research Limitations ............................................................................................................. 36 5.3. Future Work .......................................................................................................................... 37 Bibliography ............................................................................................................................ 38 v LIST OF FIGURES Figure 1 – BPM Lifecycle (Dumas et al., 2013) .......................................................................... 7 Figure 2 - BPMS Architecture (Dumas et al., 2013) ................................................................... 8 Figure 3 - Agile SDLC Lifecycle (Anurina, 2021) ....................................................................... 12 Figure 4 - Scrum Framework (Scrum.org, 2021) ..................................................................... 15 Figure 5 - PRISMA Flowchart ................................................................................................... 17 Figure 6 - DSR Methodology Model (Peffers et al., 2007) ...................................................... 21 Figure 7 - DSR Method Implementation (Peffers et al., 2007) ................................................ 22 Figure 8 - Artefact Example Structure ..................................................................................... 23 Figure 9 - Scrum BPMS cycle used by OBS in the Process Transformation project ................ 33 vi LIST OF TABLES Table 1 - Scrum Roles and Artefacts guidelines in BPMS project types .................................. 27 Table 2 - Description for each BPMS project type regarding Product Backlog ....................... 28 Table 3 - Description for each BPMS project type regarding Sprint ....................................... 28 Table 4 - Description for each BPMS project type regarding Sprint Backlog .......................... 28 Table 5 - Description for each BPMS project regarding type Project Tracking Software ........ 29 Table 6 - Description for each BPMS project type regarding Scrum Meetings ....................... 29 Table 7 - Description for each BPMS project type regarding Sprint Review ........................... 30 Table 8 - Description for each BPMS project type regarding Product Owner ......................... 30 Table 9 - Description for each BPMS project type regarding Scrum Master ........................... 30 Table 10 - Description for each BPMS project type regarding Project Team .......................... 31 Table 11 - Revised Strategy ..................................................................................................... 35 vii LIST OF ABBREVIATIONS AND ACRONYMS AI Artificial Intelligence BPM Business Process Management BPMS Business Process Management System BPR Business Process Reengineering CEO Chief Executive Officer CFO Chief Financial Officer CIO Chief Information Officer COO Chief Operations Officer CRM Customer Relationship Management DBMS Database Management System ERP Enterprise Resource Planning HR Human Resources IoT Internet of Things IT Information Technology KPI Key Performance Indicator ML Machine Learning PRISMA Preferred Reporting Items for Systematic reviews and Meta-Analysis PTS Project Tracking Software SDLC Software Development Life Cycle TOGAF The Open Group Architecture Framework UML Unified Modelling Language WFMS Workflow Management System XP Extreme Programming 1 1. INTRODUCTION The problem that this study is proposing to solve is introduced in this section. Firstly, the two methodologies are going to be introduced, with a brief explanation of both BPM and Agile. Within the context identification, it is also mentioned the motivation and the reasons that lead to the research of this topic. Then, the already existent research regarding the linkage between those methodologies is briefly explained since they are a baseline for this topic. Furthermore, the objectives are defined for a clearer perspective from the target audience to inform them better what is going to be done in this study. 1.1. BACKGROUND AND PROBLEM IDENTIFICATION In the current days, where every company and industry in the world are facing a huge problem in their hands that is to continue to create value during the pandemic, all the employees from IT companies had to start to work in different ways (Brynjolfsson, Rock, et al., 2020). To keep creating value during the lockdown, the work methodologies adopted by these companies had to be more focused on the quick interaction between workers and to ease the documentation part of the processes instead of following a normal project plan with all the baseline requirements (Moon, 2020). One relevant example comes when companies invest in BPM systems development, they want guarantees that there is no need to increase the budget during the project and that client’s requirements are going to be fulfilled for a better acceptance (Thompson et al., 2009). Regarding BPMS projects, there is an obvious choice when it comes to mind all the work methodologies that would stand out during this outbreak, that is the Agile Methodology. This methodology is commonly adopted by the software development industry, where a more dynamic way of work is predominant (Matharu et al., 2015). Four main values give Agile the perfect opportunity to be one of the most successful methodologies nowadays: Individuals and Interactions over Processes and Tools; Working Software over comprehensive documentation; Responding to change over following a plan & Customer collaboration over contract negotiation (Poppendieck & Poppendieck, 2003). Overall, these four values describe perfectly what is necessary for software development. Although there is a lack of bureaucracy involved (Denning, 2016), in times like Covid-19 where social distancing is mandatory in extreme cases and remote work is the solution, Agile values fit perfectly. Moreover, Agile methodology sums up also twelve principles for a better understanding of is culture: Customer satisfaction; Welcome change; Deliver frequently; Working together; Motivated team; Face-to-face; Working software; Sustainable pace; Good design; Simplicity; Self-organization & Reflect and Adjust (Beck et al., 2001). Inside this methodology, some frameworks can be adopted to accomplish its principles (e.g., XP, Lean), but the one that is going to be focused on in this document is Scrum. The term Scrum comes from rugby when at a certain moment the referee stops the game and most of the players from both teams gather to make an orderly formation to win back the position of the ball, introduced in the Scrum by another player. This event can happen multiple times during a game of rugby (Quarrie & Wilson, 2000). 2 In a certain way, what succeeded in the sport applies to projects with this framework. Scrum’s principles say that the process should be based on gathering a team of developers and some specialists in a specific area, nominating a Scrum Master that will be responsible for reporting to the Product Owner and organize the Daily Scrums (everyday meetings to understand the situation point and keep track of team tasks) and focusing on delivering the task in time due to the deadlines. These tasks are called Sprints and most of the time they take from 1 to 4 weeks, being repeated with new tasks until the project ends (Martin, 2009). If we do not take into consideration the pandemic and remote work, there are better methodologies that can document business processes and analyse KPIs for organizations. When business and processes are mentioned in the same sentence, it is almost impossible to let BPM out of the equation since it is one of the most beneficial methodologies to organizations (Alibabaei et al., 2009). Some studies go even further and say that is CIOs top priority nowadays (Gartner, 2009). BPM is a management approach that focuses on describing, controlling, modelling and optimizing already existing business processes inside a company (Buchwald et al., 2010). It is a different working methodology from Agile since BPM focus is not on creating value, but on adding it, by optimizing processes performance to make them more efficient and minimize resource usage and hence costs (Janiesch et al., 2014). With all the competitiveness in the most diverse industries, but specifically in IT, the companies that better succeed are those who implement inside their departments managing tools that bring the best out of their facilities and resources. With that in mind, BPM methodology is considered to be a top priority for IT companies (Rudden, 2007). There are a few principles to have into consideration when applying this BPM, more specifically, ten of them: Principle of context-awareness; Continuity; Holism; Institutionalization; Involvement; Joint understanding; Purpose; Simplicity and Technology appropriation (Vom Brocke et al., 2014). Both Agile and BPM do not interfere with each other, meaning that there is some space in companies to implement them in the same scenario making them compatible (Kruba et al., 2012). Although the idea of merging the foundations of the Agile manifesto to BPM is not new, there is still a big gap of specific information regarding this topic that would be of good use to prove the benefits of this linkage. Thiemich & Puhlmann (2013) have done exceptional work suggesting this combination and explaining their benefits. In the software development field, today, most of their projects are based in Agile with the Scrum framework, leading to constant interconnections between customers and developers, minimizing the possibility of misunderstandings in the requirement phase (Rising & Janoff, 2000). Not only that, but clients can add more specifications and modify their requests throughout development so that the final version can match their expectations. 9 2.1.4. BPMS Projects Features Projects related to BPMS have to be faced gently since they are complex and have a high failure possibility compared to ERP systems. Also, BPMSs offers individual opportunities for organizations to have multiple BPM projects (Hagemans & Kelder, 2010). BPMS projects normally require a business process re-engineering and some kind of organizational change beyond traditional project management principles (Bingi et al., 1999). Additionally, BPM is considered to be a multidisciplinary methodology and requires multiple business factors to be taken into contemplation (Bandara et al., 2005), which makes BPMS implementation a continuous process consisting of multiple BPM projects (Ravesteyn & Versendaal, 2007). The objective of a BPMS project is to reach the next levels of organizational and strategic level incorporation with the technical level. For that, BPMS projects have to delegate tasks to certain people, with the right intel. It should support modelling and analysis of tasks to verify, evaluate and modify inside structures (Karagiannis, 1995). 2.1.5. BPMS Project Techniques As a tool, BPMS can assist several projects being developed or deployed. There are a few types that are exploited with the digitalization of business management techniques. In this section, there will be described some of the most. common BPMS project types, which will be included in the strategy toolbox further in this document. Process Mining With the innovations in the Data Mining and Business Intelligence sectors, it was just logical to take the step of adapting these technologies into the business process field. This type of project enables the possibility to discover, analyse and improve business processes based on event data (Van Der Aalst, 2012). All of those characteristics are exploited with the use of BPMSs, where it gives a better overview and the necessary tools for employees to work around and doing exactly the mining of their existing processes. In other words, what process mining does to achieve what is proposed, is to extract knowledge from event logs available in nowadays ISs (Van der Aalst, 2011). BPM Simulation Simulation projects are very useful to forecast close to real business cases with high efficiency. For that purpose, BPMN is the elected notation to input data into the BPMSs in use since with the right elements incorporated in it, the project’s team can achieve not only simulated processes but also model them (Freitas & Pereira, 2015). The advantage of adopting simulation projects is that it gives companies the possibility of analysing and testing different scenarios without taking any risk to the existing systems (Ribeiro & Pereira, 2014). Moreover, the utilization of simulators with BPMN 2.0. can eliminate truly a series of costs and risks that would be inherent to test. Business Process Integration To keep the business growing, there is a need of maintaining up to dated technologies and keep on technological trends. For that reason, business process integration plays a big role. As described in other research, process-oriented companies are continually integrating their processes, and process integration is a key focus for many types of reengineering and optimization activities (Wakayama et 10 al., 1998). With the hand of the BPM department, all the integrations needed can be fulfilled, using their know-how in tools such as BPMSs, business processes can be integrated very quickly and without having many downfalls (Berente et al., 2009). Robotic Process Automation (RPA) It is almost visible the progress in Artificial Intelligence and Machine Learning over the past few years. More and more sectors are automating their businesses due to these two scientific advances. Having that, it was just a meter o time until companies understood the advantages of automatizing their business processes as well. RPA is defined as a type of project which automates processes within a broad of different technologies (Hofmann et al., 2020). The aim of its implementation is, as the name suggests, to automatize processes that were previously done by employees, to reduce its repetitiveness and to liberate employees for tasks better suited only to humans (Van der Aalst et al., 2018). Of course, BPMSs have again an important role, since companies can only deepen their inside processes knowledge by utilizing software and tools capable of giving overviews and suggest improvements in those business processes. Workflow Automation This type of project focus on improving the existing workflow business processes. It is also known as a reengineering process (Georgakopoulos et al., 1995). Workflows describe business process tasks at a conceptual level for a better understanding, evaluation and redesign. They are supported by WFMS to fulfil its objective, a system that was later upgraded into the BPMS used nowadays. Process Transformation In the era of digitalization, it can be said that almost every process transformation project can be categorized as digital transformation. With the leverage of BPMS, these types of projects have some specific contexts to differentiate themselves. Firstly, it has to opt for emerging digital technologies to reconceptualise business needs, whether they are models or processes (Yoo et al., 2010). Another thing people should have in mind when working for a process transformation project is that, if the transformation is based on a BPM methodology, the outcome of the project will change dramatically inside business structures (Besson & Rowe, 2012). If companies are not willing, after the project is implemented, to train or re-educate their employees for the new working methods, then this type of project should not be the one to choose from all the BPMS project types. 11 2.2. AGILE METHODOLOGY When Agile was created, the main purpose was to provide a more appealing and simpler methodology for the software development companies (Beck et al., 2001). In the Manifesto, it was clear that the key values for this methodology were Individuals & Interactions, Working Software, Customer collaboration and Responding to change. At that time, software was emerging and becoming a vital component for companies that want to surpass their competitors (Herbsleb & Moitra, 2001). Consequently, the demand for software increased the number of companies that supply software solutions. 2.2.1. Theoretical Background and Concepts Behind the Manifesto in 2001, the seventeen software experts already had similar opinions regarding the existing working methodologies at the time. All of them agreed on four values and twelve principles that became the Agile fundamentals to companies who wanted to adopt Agile methodology. If software development organizations follow these four values, they could call themselves an Agile company. Therefore, the rules are (Beck et al., 2001): Individuals and interactions, over processes and tools; Working software, over comprehensive documentation; Customer collaboration, over contract negotiation; Responding to change, over following a plan. To fulfil these organizational values, companies should follow the twelve principles defined in the Manifesto, which are (Beck et al., 2001): • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software; • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage; • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale; • Business people and developers must work together daily throughout the project; • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done; • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation; • Working software is the primary measure of progress; • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely; • Continuous attention to technical excellence and good design enhances agility; • Simplicity--the art of maximizing the amount of work not done--is essential; • The best architectures, requirements, and designs emerge from self-organizing teams; • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. 12 2.2.2. Lifecycle As for its lifecycle, there are a few different phases that can be defined along the process whilst the principles will remain the same. For this research, the Agile Lifecycle will be divided into six main phases: Requirements, Design, Development, Testing, Deployment and Review. The completion of one full loop is called iteration. When an iteration is completed, it will start the next one. Starting with the Requirements phase, this is where the key stakeholders and users meet to identify business requirements that are relevant for the work that is starting (Sohail, 2019). Next, the Design phase is where the team discusses how to tackle the requirements and proposes the tools to achieve the best results. It can be defined which programming language to use or even the libraries that the project is going to need. The Development phase is generally the longest and it is the backbone of the cycle, where the team puts their effort into converting the design documentation into software (Feoktistov, 2020). Moving on to the second part of the cycle, the Testing phase is where the team ensures the quality of the code previously done (Thakur, 2019). There are a few types of tests that can be implemented: unit tests – testing individual methods and functions from classes, components or modules; integration tests – testing interactions with the database or making sure microservices work as expected; functional tests – focused on the business requirements of the application; end-to-end tests – replicates the user behaviour with the software in a complete application environment; acceptance tests – formal tests to verify if the system satisfies its business requirements; performance tests – checking system behaviours when it is under a significant overload; smoking tests – quick tests to check basic software functionalities (Pittet, 2021). Furthermore, in the Deployment phase, the application under development is deployed on the servers and provided to the client, either in the form of a demo or the final result. Finally, the Review Phase is where the product owner gathers with the Agile team and wrap the iteration with some questions or doubts that anyone has. When everyone is done talking about the finished iteration, the team starts approaching the next iteration, starting the cycle all over again. It is fundamental that in these team meetings everyone listens and there should not be any embarrassment from anyone. That is what the Agile methodology is all about. Figure 3 - Agile SDLC Lifecycle (Anurina, 2021) 13 2.2.3. Agile Frameworks After the definition of the Agile methodology, different frameworks diverge and differentiate themselves with some principles, regarding having always the same Agile priority: satisfying the customer with continuous deliveries of valuable software (Beck et al., 2001). In this section, there will be introduced and briefly explained not only Scrum but also three very popular frameworks: Crystal, XP and Lean. It is important to have some knowledge in other frameworks than Scrum to explain why it is the most compatible Agile approach to integrate with BPM projects. Crystal It is common to see this framework defined as a family since there is more than one crystal method. These methods are categorized and scaled by variables, which are losses due to system failure, comfort, discretionary money, essential money and life. There are known four Crystal methods arranged by colours and opacity: Crystal Clear, Crystal Yellow, Crystal Orange and Crystal Red. Despite that, only Crystal clear and Crystal orange are defined and used in software development. They have all the policy standards, documents and artefacts description and the personnel roles (Abrahamsson et al., 2017). Firstly, created by Alistair Cockburn in the early 90s when he worked at IBM, he found out that the teams he interviewed, were lacking in communication and collaboration tools (Cohen et al., 2004). That is why this set of methods focus on people collaboration. The policy standards for the Crystal clear and orange are incremental delivery of tested work product, direct user participation, automated regression testing, project progress tracking by milestones and workshops after each delivery for methodology adjustments (Abrahamsson et al., 2017). Whilst Crystal clear is designed for projects of up to six members, Crystal orange can be adopted by teams from twenty up to forty members. There are a few advantages when adopting Crystal as your Agile framework. It is almost guaranteed that the guidance that Crystal delivers will lead to effective communication, which is a key factor to success. Not only that, but this framework provides good risk management and technical practices. Unfortunately, Crystal yellow and red are still not defined so their scope is reduced by half. Crystal family lacks in design and code verification activities and it cannot give any guidance when it comes to business enterprise (Mnkandla & Dwolatzky, 2007). Extreme Programming (XP) When a software development company wants to adopt a new framework that advocates rapid iterations, rigorously tested code and close look up from the end-users, there is no better option than Extreme Programming (Beck & Fowler, 2001). This is the most widely used Agile framework from these four presented in this research (Cao et al., 2004). There are a few principles companies have to follow to implement XP: Whole Team Involvement; Planning Game; Customer Tests; Simple Design; Pair Programming; Test Driven Development; Design Improvement; Continuous Integration; Collective Code Ownership; Coding Standard; Metaphor and Sustainable Pace (Jackson et al., 2004). With all these set of principles, it is guaranteed that the organization in cause will elevate their software development to extreme levels (Beck, 2000). It is proven that XP has positive outcomes in small software projects (Murru et al., 2003). Nevertheless, it should not be seen as a framework viable to all project development organizations. Despite bringing advantages like lower management overhead, higher team productivity or shorter release cycles, the 14 application of this Agile approach is constrained by the type and size of the project, the experience of project personnel and high commitment from the customer (Cao et al., 2004). The recommendation in some researches is to not implement this framework in big projects due to insufficient architecture planning, over-focusing on early results and low levels of test coverage (Boehm, 2002). Lean This framework has grown from a primary organizational improvement, which was, reducing/eliminating waste. From the late 40s that some companies started to focus on how they could improve their revenues without investing more money (Poppendieck & Poppendieck, 2003). Due to its efficiency and importance, Eliminating Waste has become the fundamental principle of Lean and the basis for the follow-up principles. At first, it was difficult to define wastes in the current business process. Nevertheless, something that needs to be taken into consideration in software development, is that, even though there are a lot of phases required, none have more direct contribution than the analysis and coding phases (Royce, 1987). For that reason, if a software development company need to cut some wastes, it should point first to the other phases of their processes. Some examples of manufacturing wastes that could be related also to the software industry are Inventory, Overproduction, Transportation, Waiting time, Defects or Motion (Shingo & Dillon, 1989). The best approach to improve the software development environment is to amplify learning, making it the second principle of this framework. The Decision as late as possible can be a controversial principle but in fact, it can be very beneficial. Sometimes when the future is closing in an economic market it is easier to predict. Not only that but postponing the decision making also means that more facts can be gathered during that period, so the decision can be based on them and not on speculations. On the contrary, deliver as fast as possible is a must in Lean. Since there is constant interaction with the client, without fast deliveries software teams could not have reliable feedback. The remaining principles are based on the further view of the team (Poppendieck & Poppendieck, 2003). Empower the workers is a principle that translates into elevating the team’s importance. Having developers involved in the technical decisions is fundamental to achieve excellence. With the necessary tools, expertise and guidance, everyone who can share their knowledge will reach much higher development levels. In the presence of conceptual integrity, the systems will work much smoother, cohesive and it is a critical factor in creating perceived integrity (Clark & Fujimoto, 1990), making building integrity another important principle. Finally, see the whole is the last Lean principle. If there is some requirement missing, it is better to have a further overview of the project for a better decision. Scrum A very popular framework, created by Jeff Sutherland and Ken Schwaber in 1995, quickly became one of the best methodologies to leverage projects under development. As for the other types of Agile frameworks, Scrum was formalized to help the software development. One thing that distinguishes this specific framework, is that works well for any complexity or innovative scope of work (Mahalakshmi & Sundararajan, 2013). 15 The main Scrum outcomes that could be highlighted are (Marchesi et al., 2007): • Ensure high quality of products and deliverables; • Scalable from a single process to entire project; • Provide better estimates to time and cost; • Better control over project schedule and state. The people that are involved in this framework are, most of the time, the Product Owner, the Scrum Master and the Development team itself. With a low number of enrollees, the team maximizes their interaction and cooperation at a lower time and cost. The role of the Product Owner is close to what a normal client would perform. Creates and prioritizes a list of needs to be fulfilled and decides about the business value. This role can also change the software requests along with the project. Then, the Scrum Master is responsible for the implementation of the project, keeping the team focused on the goal and grant their requests whenever possible and protecting its team from external influences. It can be considered the project manager. The scrum team is a set of specialized people that can add value to what the Product Owner demanded. They have to be self-organized and have crossfunctionalities (Cho, 2008). After the definition of the roles present in Scrum, it is necessary to understand the tasks and events that this framework defines. The list of features that the Product Owner defines at the beginning of the project is called the Product Backlog. From that list, the team gathers and creates the Sprint Backlog, which is a certain number of backlog items that they compromise to accomplish until the end of the Sprint and commit the solution (Darwish & Abdelwahab, 2016). This act can be seen as the Sprint Planning. It is important to understand what a Sprint is, and it can be traduced in an iterative, timeboxed duration with fixed times (Sutherland, 2016). Normally, a Sprint duration is between two and four weeks. Every day, there is a team’s reunion that has the objective to track the progress and to see if everyone is aligned with what was defined previously, what are going to be the upcoming tasks or even if there are any obstacles. These meetings are known as the Daily Scrums, guided by the Scrum master. The Increment is a chart that shows how much work is left to do. At the end of each Sprint, there is the Sprint Review, where the work is revised and is presented to the Product Owner (Cho, 2008). It is also done a retrospective to understand what went well during this Sprint and what can be improved in the next one. A visualization of the Scrum framework can be seen in Figure 4. Figure 4 - Scrum Framework (Scrum.org, 2021) 16 This framework was adopted by so many companies that Scrum even had an impact at an academic level. Since the increase in demand for this methodology, universities saw an opportunity to educate their students so when they reached the working world, they had already worked with all the Scrum rules. The term that nowadays is used to coach students where the responsibility for the learning process is delegated from teachers to students based on Scrum operations is eduScrum (Delhij et al., 2015). With eduScrum, students can tackle complex adaptive problems, while productively and creatively achieving the learning goals that universities strive for. This approach was adopted by many Software and Computer Science Schools to prepare better their students and consequently, increase their reputation along with Software Development companies. 17 2.3. SCRUM & BPMS In this section, the concern is to do good research of the two methodologies combined. For the sake of that, a well-known research methodology will be applied to end up with the best results, which is PRISMA. This research approach has the goal of reducing and shorten already existent papers to be analysed efficiently. PRISMA method follows five phases, starting with the identification of relevant manuscripts of the domain, followed by the screening of titles and abstracts. Next, it is done an eligibility analysis of those papers which will be followed by a full-screen reading of the remaining papers. Lastly, the papers selected by the author will be analysed in detail to contribute to the cause of this research (Moher et al., 2010). 2.3.1. Search Strategy To begin the Scrum & BPMS search by the PRISMA method, a search schema was thought with to find the best suitable and already available papers and articles. As for the repositories to find them, there were used well known digital repositories such as IEEE Xplore, Science Direct, Springer and Google Scholar. For the creation of the search query, three main keywords were used linked with the Boolean connector ‘AND’, which led immediately to a plausible number of published papers (“SCRUM AND BPMS”). In Figure 5 it is presented the PRISMA flowchart. This chart illustrates the 5 phases of the manuscript’s selection process. Some manuscripts were excluded in each phase according to their conditions which led to the papers that fit better to this study’s topic. Figure 5 - PRISMA Flowchart 18 Phase 1 is the Identification of manuscripts searched in the previous mention digital repositories with the created search string. Other important information regarding all the PRISMA Phases, is that only papers are written in English, Spanish and Portuguese were selected to move forward. The number of identified publications was 449, including duplicates. The next step, Phase 2, is the Title and Abstract screening. Firstly, was applied a filter to exclude duplicates from different repositories (30 duplicates). Then, there were excluded 324 publications according to their full title visualization and based on the abstract reading, other 71 papers have been put aside. After just two out of five PRISMA phases, the number of publications was reduced by almost 20 times. Phase 3, the Eligibility process, gathered 24 manuscripts, validating them for the next filter based on the full-text screening (Phase 4). From there, it was possible to exclude 13 more manuscripts, leading to Phase 5, the Included papers, which were 10. 2.3.2. Search Results Badakhshan et al. (2019) have done a Systematic Literature Review (SLR) and an integrated framework regarding the Agile methodology and BPM. The goal of their publication was to provide enough resources and guidelines of a framework for the use of an Agile BPM. The results of the SLR were as the authors expected, agility in BPM would be beneficial to companies, enabling more flexibility and leanness. Flexibility emphasizes BPM’s continuous readiness and leanness emphasizes iterative value creation. Furthermore, the proposed framework gives an overview of how agility and BPM can interact systematically. Its main concerns were implementing Agile principles like quick reaction to change in BPM phases like Process Innovation or Process Improvement. Not only that, but it must contribute to the development of the perceived economy, quality or simplicity in the Process Change Initiation. Lastly, the framework suggests that the Agile principle of being continuously up to date when it comes to environment trends (e.g., new technology) have to be aligned with the process improvement methods, such as process mining or business process automation. Probably the most similar research to this document’s topic is the proposal from Thiemich & Puhlmann (2013), which studied both Integrated BPM (IBPM) and Scrum. IBPM focus on analysis and design, while Scrum is the best Agile methodology to deliver a holistic approach on how to get requirements implemented. To these two authors, since there are no previous studies of combining IBPM and Scrum, it seemed obvious to create a new value-adding combination to both frameworks. It was described as an Agile BPM Metamodel that could keep the BPM project big picture and be developed with all the Scrum guidelines, changing the terms Scrum Master to Agile BPM Master and some other simple modifications. All the Scrum artefacts and phases would be the same, but also, the tools and techniques of a universal BPM project. This proposed framework was put into work in September 2012, in a Service Portal Project and the known BPM and Scrum issues were overcome. There is another meta-model represented by a UML diagram, relating to business process management entities. Several entities are related to each other on the diagram presented in the article written by Zacarias et al. (2017). The meta-model proposed by the three authors reflects a combination of traditional and agile BPM through layers where business process changes are fed within daily work practices. The ultimate goal of this meta-model is to foster responsiveness in business process improvements with any frequency appropriate by the organization. Additionally, two of these authors also wrote an article regarding agile business process improvements, and it concludes that the 25 Despite the current pandemic situation, where online meetings are now more common than face-toface ones, is completely plausible to conduct the interviews in any meetings software (Zoom, Microsoft Teams, etc.). The interviewer will arrange a virtual meeting, regarding the pandemic situation in the future. In the past year and a half, it was proven that those meetings are still very productive and easier to schedule. After all, the participants will be professionals from different companies, and the probability of an overschedule would be high. This way, the invitees only need an access point and with the platform and a quiet surrounding. Overall, the objective at the end of each interview is not to have the same answers from the guests but to have an affirmation for the artefact and valid information to move forward with the thesis. 26 4. FRAMEWORK FOR THE USE OF SCRUM ON BPMS PROJECTS 4.1. ASSUMPTIONS Based on what was studied in the Literature Review, regarding BPMS projects and Scrum framework, it was defined that, for the new strategy between both methodologies to be successful, it should: - Adapt the Scrum artefacts and roles to each specific BPMS project type. There are different needs to distinguish BPMS projects, which leads to a customized approach by project type. - Have at disposal all the existent Scrum artefacts, ruler and/or roles for implementation. - Have a fully committed and trained team, both familiar with Scrum framework and BPM methodology. - Leverage the outcomes of BPMS projects by fulfilling its cons with the most known features of the Agile methodology, specifically, Scrum. 4.2. PROPOSAL 4.2.1. Scrum on BPMS Projects Concept Following the extensive study of the literature regarding BPM and Agile, in deeper and more conclusive detail, BPMS, Scrum framework, its main features, advantages of adoption, compatibility and similarities between both and room for improvement, it was possible to have a crystal-clear acknowledgement and prototype on what must be included for the proposal behind this master’s thesis: how artefacts and features of Scrum could improve BPMS projects by creating a new working strategy. Having the acknowledge that BPM projects, more specifically, BPMS, share an already very well structure and lifecycle, it is also known that there are flaws that could be reduced. The concept of merging Scrum to BPMS projects is not in vain, since the most complaints from BPM employees or any interactor of the project could be improved by some of the most iconic and beneficial features of the Scrum framework, giving that its roots came from the Agile methodology. 4.2.2. Conceptual Model and Hypotheses Development Following the defined concept, it was possible to build a framework to help to get better compatibility between Scrum and BPMS. The framework main goal is to clarify the use of Scrum in BPMS projects by propose, improve and refine the already existent Scrum guidelines to get a strong fit between the different BPMS projects typologies and the efficient use of Scrum artefacts. The defined guidelines followed a logical procedure, that took into consideration the difficulty, importance of achievement, stakeholders and average duration of each BPMS project type. The sum of each variable gives the level of procedure. 27 Table 1 - Scrum Roles and Artefacts guidelines in BPMS project types Scrum Artefacts & Roles BPMS Project Types Product Backlog Sprint Duration Sprint Backlog Project Tracking Software Scrum Meetings Sprint Review Product Owner Scrum Master Project Team Business Process Integration A B1 C D E1 F1 G H I1 BPM Simulation B2 E2 F2 I2 Process Mining B1 E1 F3 I3 Process Transformation B2 E1 F2 I4 Robotic Process Automation B1 E3 F3 I3 Workflow Automation E2 I3 28 Table 2 - Description for each BPMS project type regarding Product Backlog A Having a Product Backlog is going to be highly recommended or almost mandatory to every BPMS project. This gives a better overview of what needs to be done even before the project starts. The product backlog is not only tangible or visible but also the first interaction between the project’s representatives. It is the reference point for the project’s team and can be described as well as the first meeting where the client’s demands are noted down. Of course, over time there can be modifications and changes from those demands. Nevertheless, the Product Backlog will remain the same until the end of the project. It is very beneficial at the end to compare the final result and features to the initially proposed, granting Product Backlog an important seat in the Project Review down the road. Table 3 - Description for each BPMS project type regarding Sprint B1 Duration of Sprint is expected to be between 1 and 2 months. These types of projects, which involves a large number of interactions, process reengineering and new business models. Despite that, also it is important to give enough time for training employees on the new business models. It is important that after the BPMS project implementation, everyone inside the company is synchronized and prepared for taking advantage of the high investment. Recommended for projects with a high level of procedure. B2 Sprint duration should be between 2 weeks and 1 month. For BPMS projects where doesn’t involve excessive modifications from the business models, the time defined takes into consideration the number of interactions between the project’s team and the client. Not only that but also the intensity and importance of the projects are not crucial for the good flow of already existent business processes. Recommended to smaller projects with a lower level of procedures. Table 4 - Description for each BPMS project type regarding Sprint Backlog C Common to all projects, the Sprint Backlog is where the features and tasks are defined for each Sprint. It is a mandatory artefact so that the project team knows what needs to be done in the next time frame. Each specific task will also be assigned to different team workers. 29 Table 5 - Description for each BPMS project regarding type Project Tracking Software D Software to support and facilitate managing resources, task allocation and employee’s workload. Most of the Agile and Scrum projects use this type of tool, to have a better overview of all the Backlogs and tasks progression. It is not mandatory for the BPMS projects but is highly recommended. Table 6 - Description for each BPMS project type regarding Scrum Meetings E1 Meetings between the team’s manager and the team’s members. These meetings are very relevant to engage everyone on the working progress. It leverages feedback and interactions between stakeholders. It gives room for improvement and mods. Recommended frequency is 3 times a week. The client’s representative can also be present. Best fit for lower importance projects or projects with high progress ratio, mainly the ones which depends on machinery. E2 Frequency of meetings should be twice a week. Best match for a medium level of procedure projects, or even projects with high demand but with low difficulty. The team’s manager needs to on every meeting, as well as all the members. The product owner can also participate in them, but it is just required its presence once a week. E3 Meetings with extreme importance. These types of meetings, since it is recommended to be only once a week, should have all the stakeholders present, including the client representative. The frequency recommendation can be explained by the difficulty of each task, sprint duration and the progress slack regarding the software involved. Fits better for automated BPMS projects, together with AI, ML or simply robotics. 30 Table 7 - Description for each BPMS project type regarding Sprint Review F1 Reviews with medium impact. The presence of the client representation is not mandatory. F2 Reviews with less impact. The presence of the client representation is not mandatory. F3 Reviews with high impact given the importance of the projects. Client representation is mandatory. Table 8 - Description for each BPMS project type regarding Product Owner G Mandatory role, which can also be known as the Project Owner. It is the person who subsidizes or is the representative of the subsidiary. As well as being a stakeholder, it communicates regularly with the Scrum Master intending to make the demands clear and to know the state point of the project. It is present in diverse meetings regarding the project and Table 9 - Description for each BPMS project type regarding Scrum Master H Extremely important role. The scrum master in the Scrum framework is the most similar role to what a project manager plays in other types of projects. It is the one who connects the Product Owner to the Project’s team. It is the spokesperson of the client, describing to his team what are the demands, and if there is any change of need, it is up to the Scrum master to translate them as fast as possible. Also, it is the project’s team face. If there is any obstacle in the project, the Scrum Master should report to the client the most important information. It is relevant to add that, since the projects are based on the BPM methodology, inside each Sprint, the cycle of project development follows the BPM cycle (Process Identification, Discovery, Analysis, Redesign, Implementation, Monitoring). This way, the tasks divided by the team are related to the six phases of the BPM cycle. 31 Table 10 - Description for each BPMS project type regarding Project Team I1 The project team should be between 5 and 7 employees. Whenever a project with average dimensions and importance is in hands, the total number of stakeholders can have a big variation, depending on the company’s labour or other variables. These variables are not relevant to the framework or the guidelines. I2 The best fit for smaller and less relevant projects would be a team between 2 and 3 workers. With a smaller team, the work that needs to be done would have much fewer conditions and fewer people working on it, reducing some errors or mistakes. It leverages the communication as well between the Project Manager, which will have much more customized feedback for each member. I3 Project team for bigger projects can be comprised of between 7 and 9 workers. The total number of stakeholders must not surpass 10 people, as defined as the limit for an Agile team, including the Scrum Master. I4 When in doubt of the level of procedure of the BPMS project, this option is highly recommended. It could have a project team of between 3 and 5 people, giving space for smaller or bigger projects. Keeping the good and agile relation with the Scrum Master, the communication will still be very fluid and the errors that could occur in a bigger team are not as often expected. 4.3. USE CASE SIMULATION To test the previous metrics and guidelines, there is a need to describe a project as close as possible to a real-world case. With that purpose, the use case of a food delivery company, which requires the help of BPM specialists in process transformation, is what will be reported hereafter. TeleSushi is a sushi delivery company based in Portugal, being one of the first companies specialized in sushi delivery operating in the country. The founders opened the company because, contrarily to the case of pizzas or roasted chicken, although its increasing popularity, there were no options for sushi delivery. The company’s first store was in Lisbon and opened at the end of 2013. In 2014, they expanded to Almada; in 2015 to Oporto; in 2016 Cascais; and in 2017 they opened two more stores in Lisbon’s metropolitan area. At the moment, TeleSushi has more than 100 employees, ranging from sushiman to couriers, middle and top management staff, food engineers, as well as people working in supporting areas. The increasing competition in the food delivery market, e.g., the opening of numerous restaurants with a delivery option, and the arrival of international delivery companies, draw the attention of top managers to the need of optimizing TeleSushi internal processes, aiming at magnifying efficiency. 32 That is why TeleSushi managers got in touch with a company specialized in BPM: Optimal Business Solutions (OBS). TeleSushi current business models lack quick and responsive feedback to their customers. The restaurant is going through a difficult time handling errors and wastes that should not happen if they want to keep up with the competitors. TeleSushi has three types of ordering processes: Orders registered by phone, by the website and in person at the stores. Not only that, but their Order Processing needs improvements as well. Their proposal for OBS is to help and improve all of them, the best as possible within the agreed budget. OBS is a company that focuses on the optimization of current business processes from other firms. Provides new digital solutions during a certain amount of time, after instigating the inside of their contractors to have a better overview. Then, it takes a certain amount of time, with their IT Advisors, BPMS engineers, Developers and all their collaborators, to come up with improvements. Afterwards, there needs to be a phase where a specialist from OBS, which is probably the team leader, brings the new optimised processes to their contractor, presents the changes and gives training to their coworkers to adapt to the new IT technologies. The standout factor between OBS and the other BPM optimization companies is that their working methodology is based on a mixture between BPM and the Scrum framework. Their guidelines are different between BPMS project types since the Scrum BPMS strategy offers tips to each specific project. By the time that both parts have agreed to the contract terms and OBS could start their work, something that was mandatory was to identify which type of BPMS project they had to deal with. There were already existent business processes, therefore, the best fit should be to improve and digitalize them, nominating this type of project, a Process Transformation. Having that, the working methodology adopted by OBS for a Process Transformation BPMS project, following the Scrum BPMS strategy is not one of the most demanding ones, and the level of the procedure is around average. The nominated team from OBS consists of five people, including the Scrum Master, which is the Project Manager. Following the Scrum BPMS framework’s, the Product Backlog is mandatory, so it is the first concern of OBS’s team. For that definition, a first meeting between the project’s team and a TeleSushi manager happens. Then, the first Sprint takes place, with the Sprint Meeting for the definition of the Sprint Backlog. The Contractor manager does not need to be present, since this meeting is where the work is divided by the project team. The task division has in consideration the duration of a Sprint for a Process Transformation project, which is between 2 and 4 weeks. OBS defined the Sprint duration to be a 3-week cycle. Of course, for a better organization and overview of the project, the team used a PTS called JIRA. In this software, the team can see their tasks, monitor and chat with their team members. It is important that during the development of the transformed and optimized processes the Scrum Master and the Product Owner keep in touch frequently, so new information or new demands from TeleSushi can be talked during the Scrum meetings, which take place 3 times a week. 33 At the end of each Sprint, the final meeting is called the Sprint Review, where every project member gathers and speaks about what was done previously. Everyone must be completely honest and open to listen, so in the next Sprint, the flaws can be fixed. The presence of the TeleSushi manager is again not mandatory. Then, as it is a cycle, everything will be repeated from the Sprint Meeting to start a new Sprint. This cycle can be visualized in Figure 9. Figure 9 - Scrum BPMS cycle used by OBS in the Process Transformation project The project took the OBS team two sprints, basically around one and a half months. To declare full project closure, the process transformations need to be reported directly to the stakeholder. That final and vital task has been done by the Project Manager. This role had acknowledged the client and gave training to their employees so that they could work with the digital innovations without any doubt and improve the business process. 4.4. VALIDATION Validation was carried by scheduling individual interviews with three specialists, connoisseurs in both Scrum Framework and BPMS Project types. They were professor Paulo Proença (PRP) – software engineering professor at Instituto Superior de Engenharia do Porto (ISEP); professor Paulo Gandra de Sousa, PhD (PAG) – software engineering professor at ISEP as well as a product manager at MSG Life Iberia and last but the not the least, Joaquim Nogueira – Head of Process Architecture & Performance at a well-known Portuguese Bank. The order of the specialist follows the same order of temporary interviews. Before the interviews took place, a brief presentation was prepared with the research questions of this thesis, the main goals, as well as a table resuming the proposed framework in Chapter 4.2. Lastly, to retrieve the necessary information and feedback regarding the presented strategy, the specialists answered three questions, and their exact words are going to be transcript in the next section of this document, with due consent. 34 The three questions made were: Q1 Do you consider the proposed strategy useful? Q2 Would you consider implementing the proposed strategy? Q3 Do you have any criticism/recommendation/suggestions towards the proposed strategy? The interviews were conducted with each listed expert individually. All agreed on being recorded to write the answers to the three questions in the next chapter of this thesis. The interviews were conducted between July and August 2021. 4.5. DISCUSSION In this section, there are transcripts of the answers of each expert to the previous questions defined by the author. Everything that is written, was previously recorded and nothing is fictional nor madeup. It is of extreme importance that the discussions were truthful and the feedback positive, which in this case the author can confirm that both conditions were fulfilled. Regarding Q1, the answers were: PRP: Yes, it is useful, of course. The approach is very interesting. The methodical analysis of the entire process and having all the phases of the process very well structured and encapsulated in time, and therefore having a good linkage between all the phases of the process are the great advantages. PAG: I think, and one of the great advantages of the Scrum framework is that it is quite simple to apply to the business world. The great utility of the proposal is to turn BPMS projects that are more businessoriented, being ruled by an Agile methodology. The more strategies there are, the better. JON: Scrum can actually help BPM projects. My answer is definitely yes. Concerning Q2, the answers were: PRP: If I were in the business field instead of Accademia, I would definitely consider implementing it. PAG: Generally speaking, I'm a great apologist of Scrum as a project management methodology, by itself, as such, I think everything can be managed following the Scrum principles and rules, regardless of what we're talking about. So, I would say yes. JON: I answer affirmatively. As a matter of fact, we have already done it within the company when we transformed a credit-granting process 10 years ago. It was the first project in the company that used Scrum. We set up a Scrum team that started precisely by understanding the process (at the time we didn't have Process Mining, so everything was based on interviews). We did a set of Sprints to understand how everything worked, then we idealized a new process and started implementing it. We used Scrum throughout the entire project phase. 39 Cho, J. (2008). Issues and Challenges of agile software development with SCRUM. Issues in Information Systems, 9(2), 188–195. Clark, K. B., & Fujimoto, T. (1990). The power of product integrity. Harvard Business Review, 68(6), 107–118. Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. Adv. Comput., 62(03), 1–66. Cronholm, S., & Göbel, H. (2016). Evaluation of the information systems research framework: Empirical evidence from a design science research project. Electronic Journal of Information Systems Evaluation, 19(3), 158. Darwish, N. R., & Abdelwahab, I. M. (2016). A Security Testing Framework for Scrum based Projects. International Journal of Computer Applications, 138(7). Delhij, A., van Solingen, R., & Wijnands, W. (2015). The eduScrum guide. The Rules of the Game. Denning, S. (2016). How to make the whole organization “Agile.” In Strategy and Leadership (Vol. 44, Issue 4, pp. 10–17). https://doi.org/10.1108/SL-06-2016-0043 DeVault, G. (2018). What is a market research focus group. The Balance. Dresch, A., Lacerda, D. P., & Antunes, J. A. V. (2015). Design science research. In Design science research (pp. 67–102). Springer. Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2013). Fundamentals of Business Process Management. Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-33143-5 Feoktistov, I. (2020, November 9). Agile Software Development Lifecycle Phases Explained. Relevant Software. https://relevant.software/blog/agile-software-development-lifecycle-phasesexplained/ Freitas, A. P., & Pereira, J. L. M. (2015). Process simulation support in BPM tools: The case of BPMN. Gartner. (2009). Meeting the Challenge: The 2009 CIO Agenda. Gartner. https://www.gartner.com/en/documents/862717/meeting-the-challenge-the-2009-cioagenda Georgakopoulos, D., Hornick, M., & Sheth, A. (1995). An overview of workflow management: From process modeling to workflow automation infrastructure. Distributed and Parallel Databases, 3(2), 119–153. Gregor, S., & Hevner, A. R. (2013). Positioning and presenting design science research for maximum impact. MIS Quarterly, 337–355. Hagemans, G., & Kelder, R. (2010). How to Successfully Implement a BPMS? 15. Hammer, M. (1990). Reengineering work: Don’t automate, obliterate. Harvard Business Review, 68(4), 104–112. Hammer, M. (2015). What is business process management? In Handbook on business process management 1 (pp. 3–16). Springer. Harmon, P. (2010). The scope and evolution of business process management. In Handbook on business process management 1 (pp. 37–81). Springer. Herbsleb, J. D., & Moitra, D. (2001). Global software development. IEEE Software, 18(2), 16–20. https://doi.org/10.1109/52.914732 Herden, A., Farias, P. P. M., & Albuquerque, A. B. (2016). An Agile approach to improve processoriented software development. Computer Science On-Line Conference, 413–424. Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design science in information systems research. MIS Quarterly, 75–105. 40 Hofmann, P., Samp, C., & Urbach, N. (2020). Robotic process automation. Electronic Markets, 30(1), 99–106. Jackson, A., Tsang, S. L., Gray, A., Driver, C., & Clarke, S. (2004). Behind the rules: XP experiences. Agile Development Conference, 87–94. Janiesch, C., Weber, I., Kuhlenkamp, J., & Menzel, M. (2014). Optimizing the performance of automated business processes executed on virtualized infrastructure. Proceedings of the Annual Hawaii International Conference on System Sciences, 3818–3826. https://doi.org/10.1109/HICSS.2014.474 Jeston, J., & Nelis, J. (2014). Business process management. Routledge. Jeyaraj, A., Rottman, J. W., & Lacity, M. C. (2006). A review of the predictors, linkages, and biases in IT innovation adoption research. In Journal of Information Technology (Vol. 21, Issue 1, pp. 1– 23). https://doi.org/10.1057/palgrave.jit.2000056 Karagiannis, D. (1995). BPMS: Business process management systems. ACM SIGOIS Bulletin, 16(1), 10–13. Kruba, S., Baynes, S., & Hyer, R. (2012). BPM, Agile, and Virtualization Combine to Create Effective Solutions. ArXiv:1208.3887 [Cs]. http://arxiv.org/abs/1208.3887 Mahalakshmi, M., & Sundararajan, M. (2013). Traditional SDLC vs scrum methodology–a comparative study. International Journal of Emerging Technology and Advanced Engineering, 3(6), 192– 196. Malinova, M., Hribar, B., & Mendling, J. (2014). A framework for assessing BPM success. Marchesi, M., Mannaro, K., Uras, S., & Locci, M. (2007). Distributed Scrum in research project management. International Conference on Extreme Programming and Agile Processes in Software Engineering, 240–244. Martin, J. (2009). Agile Project Management with Scrum. In Measuring and Improving Performance. https://doi.org/10.1201/9781420084191-c2 Martins, P. V., & Zacarias, M. (2017). An Agile Business Process Improvement Methodology. Procedia Computer Science, 121, 129–136. https://doi.org/10.1016/j.procs.2017.11.018 Matharu, G. S., Mishra, A., Singh, H., & Upadhyay, P. (2015). Empirical Study of Agile Software Development Methodologies. ACM SIGSOFT Software Engineering Notes, 40(1), 1–6. https://doi.org/10.1145/2693208.2693233 Mnkandla, E., & Dwolatzky, B. (2007). Agile software methods: State-of-the-art. In Agile software development quality assurance (pp. 1–22). Igi Global. Moher, D., Liberati, A., Tetzlaff, J., & Altman, D. G. (2010). Preferred reporting items for systematic reviews and meta-analyses: The PRISMA statement. Int J Surg, 8(5), 336–341. Moon, M. J. (2020). Fighting Against COVID-19 with Agility, Transparency, and Participation: Wicked Policy Problems and New Governance Challenges. Public Administration Review. https://doi.org/10.1111/puar.13214 Murru, O., Deias, R., & Mugheddue, G. (2003). Assessing XP at a European Internet company. IEEE Software, 20(3), 37–43. Neubauer, M., & Stary, C. (2017). S-BPM in the Production Industry: A Stakeholder Approach. Springer Nature. Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science research methodology for information systems research. Journal of Management Information Systems, 24(3), 45–77. 41 Pittet, S. (2021). The different types of testing in Software. Atlassian. https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing Poppendieck, B. M., & Poppendieck, T. (2003). Lean software development: An agile toolkit [Book Review]. Computer, 36(8), 89–89. https://doi.org/10.1109/mc.2003.1220585 Quarrie, K. L., & Wilson, B. D. (2000). Force production in the rugby union scrum. Journal of Sports Sciences, 18(4), 237–246. https://doi.org/10.1080/026404100364974 Ravesteyn, P., & Versendaal, J. (2007). Success factors of business process management systems implementation. Reijers, H. A., van Wijk, S., Mutschler, B., & Leurs, M. (2010). BPM in practice: Who is doing what? International Conference on Business Process Management, 45–60. Ribeiro, M., & Pereira, J. L. M. (2014). Multi-paradigm simulation projects: The need for practical guidelines. Rising, L., & Janoff, N. S. (2000). Scrum software development process for small teams. IEEE Software, 17(4), 26–32. https://doi.org/10.1109/52.854065 Riwanto, R. E., & Andry, J. F. (2019). Enterprise Architectures Enable of Business Strategy and IS/IT Alignment in Manufacturing using TOGAF ADM Framework. International Journal of Information Technology and Business, 1(2), 7–7. Rosemann, M., & De Bruin, T. (2005). Application of a holistic model for determining BPM maturity. BP Trends, 2, 1–21. Rosemann, M., & vom Brocke, J. (2010). Handbook on business process management. In The Six Core Elements of Business Process Management. Berlin: Springer. Royce, W. W. (1987). Managing the development of large software systems: Concepts and techniques. Proceedings of the 9th International Conference on Software Engineering, 328– 338. Rudden, J. (2007). Making the Case for BPM : A Benefits Checklist. Bptrends.Com, January, 1–8. Santana, A. F. L., Alves, C. F., & Santos, H. R. M. (2011). BPM Governance: An Exploratory Study in Public Organizations. 15. Schmiedel, T., vom Brocke, J., & Recker, J. (2015). Culture in business process management: How cultural values determine BPM success. In Handbook on Business Process Management 2 (pp. 649–663). Springer. Scrum.org. (2021). The Scrum Framework Poster. Scrum.Org. https://www.scrum.org/resources/scrum-framework-poster Shingo, S., & Dillon, A. P. (1989). A study of the Toyota production system: From an Industrial Engineering Viewpoint. CRC Press. Sohail, A. (2019, April 29). Agile Project Management — Part 1: Understanding and Benefits. Medium. https://medium.com/@masads/agile-project-management-part-1-understandingand-benefits-eb079b563288 Sutherland, J. (2016). Scrum: The Art of Doing Twice the Work in Half the Time. Leya. Szelągowski, M. (2018). Evolution of the BPM Lifecycle. 205–211. https://doi.org/10.15439/2018F46 Thakur, M. (2019, June 14). Agile Lifecycle | Development Of Different Stages & Success Factors. EDUCBA. https://www.educba.com/agile-lifecycle/ Thiemich, C., & Puhlmann, F. (2013). An agile BPM project methodology. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics). https://doi.org/10.1007/978-3-642-40176-3_25 42 Thompson, G., Seymour, L. F., & O’Donovan, B. (2009). Towards a BPM success model: An analysis in South African financial services organisations. Lecture Notes in Business Information Processing, 29 LNBIP, 1–13. https://doi.org/10.1007/978-3-642-01862-6_1 Trkman, P. (2010). The critical success factors of business process management. International Journal of Information Management, 30(2), 125–134. Van Der Aalst, W. (2012). Process mining. Communications of the ACM, 55(8), 76–83. Van der Aalst, W. M. (2011). Using Process Mining to Bridge the Gap between BI and BPM. IEEE Computer, 44(12), 77–80. Van der Aalst, W. M., Bichler, M., & Heinzl, A. (2018). Robotic process automation. Springer. Vincenza, C., Giovanni, C., Michele, M., Carlo, P., Giulio, P., & Natalia, T. (2019). BPM tools for asset management in renewable energy power plants. 2019 Federated Conference on Computer Science and Information Systems (FedCSIS), 645–649. Vom Brocke, J., Schmiedel, T., Recker, J., Trkman, P., Mertens, W., & Viaene, S. (2014). Ten principles of good business process management. Business Process Management Journal. https://doi.org/10.1108/BPMJ-06-2013-0074 von Rosing, M., von Scheel, J., & Gill, A. Q. (2015). Applying Agile Principles to BPM. In M. von Rosing, A.-W. Scheer, & H. von Scheel (Eds.), The Complete Business Process Handbook (pp. 557– 581). Morgan Kaufmann. https://doi.org/10.1016/B978-0-12-799959-3.00027-6 Wakayama, T., Kannapan, S., Khoong, C. M., Navathe, S., & Yates, J. (1998). Documents, processes, and metaprocesses. In Information and Process Integration in Enterprises (pp. 1–14). Springer. Yoo, Y., Henfridsson, O., & Lyytinen, K. (2010). Research commentary—the new organizing logic of digital innovation: An agenda for information systems research. Information Systems Research, 21(4), 724–735. Zacarias, M., Martins, P. V., & Gonçalves, A. (2017). An Agile Business Process and Practice Metamodel. Procedia Computer Science, 121, 170–177. https://doi.org/10.1016/j.procs.2017.11.024 Zaouali, S., & Ghannouchi, S. A. (2016). Proposition of an approach based on BPM to manage agile development processes. 2016 Third International Conference on Systems of Collaboration (SysCo), 1–6. Zur Muehlen, M., & Ho, D. T.-Y. (2005). Risk management in the BPM lifecycle. International Conference on Business Process Management, 454–466. Page | i