ROLLING OUT OPERATIONS MANAGEMENT BY SCRUM: THE CASE OF CROATIAN IT COMPANY

Abstract

SCRUM is agile, a lightweight framework for managing and controlling teams working on complex product development in a rapidly changing environment. Software development community noticed a "long" history of successful supporting agile development projects. Although the SCRUM framework had a primary task to improve software engineering processes, it seems that it can be used to improve the work output of a change-driven team in any business sector. This paper is a case study of practice in one Croatian company, which already successfully uses agile principles for software development, applying SCRUM principles to daily operations in their Information Technology (IT) service desk. IT service desk was considered as a main IT support capability in the organization on the operational level of IT service management (ITSM), which refers to the entirety of activities that are performed by the organization to design, plan, deliver, operate and control IT services offered to customers. Describing specific adaptation of basic SCRUM elements to daily IT service management requirements, the paper explores the impact of a used operational framework for team performance. Specifically, whether it is applicable for that purpose use of Software Development Performance Index (SDPI index) across the key dimensions of Quality, Productivity, Predictability and Responsiveness. The case study tries to fill the lack of scientific support to growing numbers of agile methods application examples in modern organizations outside the software engineering arena.

Headnote

ABSTRACT

SCRUM is agile, a lightweight framework for managing and controlling teams working on complex product development in a rapidly changing environment. Software development community noticed a "long" history of successful supporting agile development projects. Although the SCRUM framework had a primary task to improve software engineering processes, it seems that it can be used to improve the work output of a change-driven team in any business sector. This paper is a case study of practice in one Croatian company, which already successfully uses agile principles for software development, applying SCRUM principles to daily operations in their Information Technology (IT) service desk. IT service desk was considered as a main IT support capability in the organization on the operational level of IT service management (ITSM), which refers to the entirety of activities that are performed by the organization to design, plan, deliver, operate and control IT services offered to customers. Describing specific adaptation of basic SCRUM elements to daily IT service management requirements, the paper explores the impact of a used operational framework for team performance. Specifically, whether it is applicable for that purpose use of Software Development Performance Index (SDPI index) across the key dimensions of Quality, Productivity, Predictability and Responsiveness. The case study tries to fill the lack of scientific support to growing numbers of agile methods application examples in modern organizations outside the software engineering arena.

Keywords: Agile project management, SCRUM, IT service desk, Operations management, Performance measures

1.INTRODUCTION

Traditional project management, considered as a combination of methods, techniques, procedures, rules, templates and best practices used to project activities meet the project requirements, suffers from several disadvantages (Cervone, 2011, pp. 18-22). The main one concerns the fact that requirements definitions are often so labor intensive, protracted and takes up significant project's resource. These processes are so long that by the time, because of modified requirements, they have to be changed before any development even begin. Especially, software development community found that traditional development approaches were not suitable for empirical, unpredictable and non-repeatable processes like software development (OOPSLA conference, 1995). As a response to these problems, agile project management approach was developed primarily as a tool for software companies to drive productivity. After that time, there is a large number of evidence for successful implementations of different agile methods not only in main IT projects. Their number also increase in many non-IT sectors, for example in high education (Navas and Munos-Luna, 2017), construction industry (Streule, T. at al., 2016), for managing research group (Hicks and Foster, 2010) etc. One of the most often used approaches in agile project management is Scrum framework. Some research shows that organizations that use agile methods, most often apply Scrum, or in 52% of causes (PricewaterhouseCooper, 2012; Versionone, 2011). The term Scrum has been borrowed from rugby where a scrum represents a way to restart a game after an interruption. The Scrum can be viewed as agile, a lightweight framework for managing and controlling teams working on complex product development in a rapidly changing environment. Sometimes organization for project management combined different tools, processes or ideas from more than one methods. They simply apply the methods that best fit their own operations. In practice, one method is used as a baseline, supplemented by tools and techniques from other methods. Although it is not a secret that IT companies use Scrum in everyday practice, for different activities besides project management, authors have failed to find academic examples of their application to operational management. Describing specific adaptation of basic Scrum elements to daily IT service management requirements in one Croatian IT company, the paper explores the impact of used Scrum operational framework to team performance. Specifically, whether it is applicable to this specific case, the usage of Software Development Performance Index (SDPI index) across the key dimensions of Quality, Productivity, Predictability and Responsiveness as a main team performance measure. The rest of this paper is organized as follows: the section 2 is a portrayal of basic concepts in Scrum framework, followed by section 3 where was offered a presentation of usual activities in IT service desk. Section 4 describes Scrum adaptation for rolling IT service desk operations. Section 5 explores dimensions of performance measure to apply, and section 6 presents conclusions.

2.SHORT DESCRIPTION OF THE SCRUM FRAMEWORK

The Scrum framework (shown in Figure 1.) is built on three major concepts: roles, artefacts and events. The Scrum roles are: Product Owner, the Development Teams and Scrum Master. The Product Owner knows what needs to be built to enable the project and how the sequence of builds should progress. He/she is in charge of creating, updating, prioritizing, optimizing a list of Items (Product Backlog) and tasks of what needs to be done by the Development Team. The Product Owner main responsibility should concern maximizations of the outputs based on a calculation of ROI (Return on Investment). The team is self-organizing, cross-functional while the leader's role changes depending on needs of the specific iteration (Sprint). Although the size of the team varies, a number of seven (±two) members has proven to be successful (Sutherland, 2014, pp 46.). The Scrum Master set up all the events, ensures that everyone in Team understands what has to be done in a fixed timeframe and remove any obstacles so that team can focus on their work. The Scrum Artifacts are: the Product Backlog, Sprint Backlog and Increment. The Product Backlog is prioritized list of Items divided into Tasks representing a simple and detailed description of what needs to be done by Development Team ideally during one or two weeks. The Sprint Backlog contains a number of Items that the Development Team believes can reach the state of done during a Sprint. When an Item from the Sprint Backlog is considered as done, it is removed from the Sprint Backlog and it is becoming part of the Increment. The Increment is the sum of all Items considered done (Streule at all, 2016). The Scrum Events are: the kickoff, the sprint planning meeting, the Sprint, the daily Scrum, the Sprint review meeting and the Sprint Retrospectives meeting. The sprint planning meeting roles at the beginning of each iteration (sprint). During this meeting, the Development Team guesses the amount of work for the most important elements of the Product Backlog with different techniques (like Planning Poker). The Sprint is an iteration in which the functionality or increment of the product is further developed. All product development sprints will have the same length of time for more effective measurements of the work. The new Sprint starts immediately with the conclusion of the previous one. Each sprint begins with a daily Scrum meeting (always at the same time and location), typically lasting no more than 15 minutes. In that meeting, it is expected that each member of the Development Team answers three questions about: what each of them did do since last Daily Scrum, what they are going to do until next Daily Scrum, and what obstacles they have prevents him/her to reach the Sprint goal. In that way, it is ensured that everyone can see their own progress and everyone knows what the others are working on. After each sprint, during the Sprint Review, the Increment, as a functionality created during the sprint is demonstrated to the product owner and, if needed, remakes are made to the Product Backlog. The goal of the Sprint Retrospectives meeting is the evaluation of "how was it done?" in order to suggest improvements to the process and performance. Focus on work done is made through the creation of Burndown charts. The Sprint burndown chart documents the progress of the sprint; eventually, Release burndown chart can be used for documentation of the release and the Product burndown chart document overall project progress.

The Figure 1 shows that the entire process starts with the main idea of a product/service that represents a functional and meaningful whole to meet all the needs of the customer or user. Based on the idea, a Product Owner compiles Product Backlog as a list of requirement's elements usually in the form of stories. After Product Backlog creation (which, through time is upgraded, modified and adapted), Product Owner with Scrum Development Team, decide priority from Product Backlog, plan a sprint and break out the tasks in Sprint Backlog. At the end of the sprint, all tasks/functionality with Sprint Backlog are expected to be developed, tested, documented and ready for delivery. The Sprint Review is a review of the work done. It is possible that the team did not perform certain scheduled tasks due to some external influences and such tasks are returned to Product Backlog for next sprint. Sprints are repeated until all of the Product Backlog tasks have been completed and completed. In the end, with the execution of all tasks from the Sprint backlog, it is expected to deliver a functional, tested and documented product that has achieved certain functionality. The Scrum process is finishing with Sprint Retrospective meeting which it has a goal to critically evaluate involved parties, processes and techniques used in order to suggest improvements and performances.

3.IT SERVICE DESK OPERATIONS MANAGEMENT

Operations management can be seen as a management of systems or processes that create goods and/or provide services as a combination of time, location, form, or psychological value. According to Stevenson (Stevenson, 2015, pp. 12), a key aspect of operations management is process management where a process consists of one or more actions that transform inputs into outputs. A process in service management transforms users' requirements as input to some forms of deliverables as an output. For achieving the desired outcomes, it needs to consistently apply, in a defined manner, a specific combination of controls and resources.

Specializations of these activities to IT service management is done through ITIL (Information Technology Infrastructure Library) framework using five distinct stages of Service Lifecycle:

* Service strategy ensures that organization's strategy is defined, maintained and implemented,

* Service design includes changes or improvements necessary to increase or maintain value to customers over the lifecycle of services,

* Service transition focuses on the quality and control of the delivery of a new or changed service into operations,

* Service operation supports responsive and stable services, and

* Service improvement that aligns the services with the business needs, whilst recognizing improvement opportunities and change.

IT service desk, for the purpose of this paper, can be viewed as a main IT support capability that could be a part of service operation activities defined by best practice of ITIL. We use this term intermittently with the term of IT help desk and we use that outside the ITIL standardization framework where each stage relies on specific ITIL's service principles, processes, roles and performance measures. In our case, IT service/help desk can be viewed as an internal operational IT support to organization's ecosystem built around the service lifecycle. It is a central point of communication of all IT specialists/employees in one organization. In that way, IT service/help desk is a small portion of activities that ITIL's IT service desk can perform. A balanced approach to IT service desk management, introduced by Addy (Addy, 2007, pp 29.), proposes the main key activities to ensure the operational, reactive and proactive satisfaction of business requirements (Figure 2). Operational activities addressed daily routine activities to keep IT infrastructure in functions during service lifecycle. These include IT preventive maintenance activities and specifically planned IT adjustments like database reindexing, disk defragmentation, update virus definitions etc. Reactive activities ensure the ability to respond to external/internal unplanned events or incidents and incident management is the main part of this activities. Analysis of the common issues to determine the course of action that system needs to apply to prevent their recurrence is a part of problem management activities. Continuous improvement concerns identification of opportunities to improve and change plans or performance of service activities. It is primarily in focus of the change management.

At a figure below, it can be seen that request management bridges the gap between the operational and reactive activities and problem management can be the bridge between incident and change management.

4.ROLLING IT SERVICE DESK OPERATIONS BY SCRUM

The name of IT Company is disguised to preserve confidentiality. It is a global IT company that provides mobile cloud communications services for business users. The company's size, their number of employees and the growing complexity of their solutions determines a large number of IT administrators working in service desk, organized in several divisions: Network and System Administrators, Database Administrators, Web Administrators and Telecommunication Administrators. All of them adapted agile project management principles from software engineering departments and use them for operational management. Follows the descriptions of Scrum adaptation on a daily work of system/network administrators. The division has been self-organized as a team consisting of six members responsible for tracking IT development trends that includes design, installation, configuration and maintenance of network infrastructure. Their responsibility includes supplying of equipment (hardware in general) same as Local Area Network (LAN), Wireless (WLAN) and WAN (Wide Area Network) design while understanding network technologies and protocols, server architecture and server operating systems, design and implementation of solutions, user training and customer support. Team was also responsible for account management (active directory and Email administration), software updating and licensing, troubleshooting, optimization, encryption and decryption of data storage media, backup (data storage), security aspects, control, maintenance and management of processes, protection against malicious programs, documenting activities and writing procedures, etc. Some of the above-mentioned activities belong to the main key activities of balanced best practice model (Figure 2.), ensuring the operational, reactive and proactive satisfaction of company's requirements. The Scrum Development team consists of a six individuals within the area of expertise related to networks/systems administrations. They created their own Product Backlog based on the requests that came to service desk from other divisions/projects or planned activities. Product Backlog consists prioritized list items need to be done and documented. For supporting their work, the team uses a software called "JIRA" (available at https://www.atlassian.com/software/jira/agile) where each employee is a member of a specific project/ Product Backlog. Each employee has his own control panel with visible tasks that he or she is dealing with, and these tasks are directly related to the project/division in which the employee participates. Product Backlog items are constantly changing and supplementing because of the changing nature of the IT system. Some of the Items can be planned based on team's experience in operational and proactive activities. These items will be placed at a bottom of the Product Backlog user interface with a lower priority. Usually, it takes more time and effort to execute and document them. Activities belongings to incident management that cannot be planned in advance will have the highest level of priority shown on the top of the screen (Figure 3.). Certain project tasks were divided into sub-tasks needed to perform to get a functionality of the main task. This segmentation allows easier allocation of time through multiple sprints. The numbers of items that could be done in a sprint were entirely based on the experience from the team's members, without a systematic way to do that. According to that, the sprint duration was fixed to fourteen working days because, during the sprint, the team also have their own regular operational tasks that they have to perform daily.

The goal of one sprint is to get as many Product Backlog tasks as possible. Product Backlog list is designed in a way that if the tasks are successfully accomplished they will bring new automation that will facilitate everyday work for the employees working on the project. Criteria for selecting the tasks that enter the next sprint are:

* Forward tasks from the previous sprint,

* Priority Project Tasks (High Priority Tasks),

* Priority pop-up tasks (Tasks that have emerged independently of work and have high priority),

* Remaining tasks that have not been completed for more than 15 days.

By virtue of these criteria, the team plan the sprint arranging order of assignments and a way of how to approach the problem-solving. Each team member agrees on tasks after assigning them according to their skills and responsibilities about the start and finish of the sprint. After planning all tasks appear on the Sprint Backlog. The Sprint Backlog is a list showing all tasks assigned to the particular member at the moment of sprint start.

For a better overview, the actual status of one sprint and individual tasks, a specific sprint review in Figure 4. were used. The column field labelled "TO DO" indicates tasks should be executed. The "WAIT" field, indicated the tasks not completed due to some external influence or difficulties. The "DONE" field represents tasks that are fully executed and completed. The goal of each sprint is to move as many tasks as possible from "TO DO" fields to "DONE" field in short time. Every day during the sprint, a daily stand-up meeting is held for 10 minutes where were analysed the issues from a previous day and anticipated problems for carried out during the current day. This daily meeting is an opportunity for consulting and knowledge sharing of the team members. Some members can be in remote locations around the world, and for this reason, this meeting has even greater significance for building a community and team affiliation. The Sprint review for half an hour is scheduled weekly and this is the opportunity to go deeper into the state of the sprint tasks. At that meeting, priorities and actual status are checked. Here it is decided whether a new problem will be classified as a daily activity, current sprint or backlog. Sprint retrospective is performed on a monthly basis and includes two sprints. The Retrospectives discuss the mistakes made during the sprint and changes are suggested to make certain things better planned for the future. As it can be seen in this case, the general Scrum framework was adapted to fit specific goals of system administrations where it was used only a part of the main concepts. Modification done in general Scrum framework can be seen at Table 1.

It looks like there are no exact assigned roles of Product Owner for the Scrum of IT service desk operations. The role of Product Owner is assigned to the person in the main project or its part where is defined sprint that requires specific knowledge or skills from system/network administration expertise. The Product Owner takes the client role in this case and his/her responsibility concerns delivering a maximum of required functionality for the lowest number of working hours. When a sprint appears from other projects, system administrators start their own scrum cycle. In fact, they do Scrum within Scrum. The team members play alternately the role of Scrum Master depending on the requests came to IT service desk from other projects, divisions or sprints. The functional request decomposes to tasks that becoming a part of their own Product Backlog.

During sprints, a team takes care about IT infrastructure compounding important aspects of services qualities as capacity, availability, security and continuity. In that way, the Product Backlog and Sprints have focused on functional requirements rather than on operations of services. In addition to routine or improvement IT operations, the Development team assigns a high priority to specific urgent request or problem identified from other company's projects/divisions. The absence of strictly defined roles of Product Owner increase the responsibilities of all team's members to represent the project externally to other stakeholders and to handle the tasks that appear in Product Backlog. It can be said that IT service desk has to use Scrum because the rest of the company do that in form of the projects and they found that is the easiest way to manage their work in the existing frame.

5.IT SERVICE DESK PERFORMANCE MEASURES

The Chaos report from 2016 (made by The Standish Group) shows that only 29% of all projects, irrespective of project size, are considered successful. Software development projects have better results and 37% succeeded in delivering all required features and function, on time and within budget. Agile project management can be considered to have a great impact on that project success. The measure of agile project successfulness is the functionality of the product/service, and indicators are not only limited to time, cost and quality (Ambler, 2010). Specifically, in academic literature can be found strong evidence about the relation between Scrum application and productivity, but also to other outcomes as a product/service quality, client satisfaction, cost reduction and team motivation (Kautz, K., 2014). According to Cedergen and Larson (2014), performance measurement is important as an aid to determine priorities and provide direction to the team, by highlighting how they are performing and where improvements would be most beneficial. The same authors found that traditional performance measurement based on lag measures in Scrum processes could not be applicable. In the same time, managers are not satisfied what they measure and why: they do not want measure performance for a control; instead, they want to learn how to improve actual work. From development team's point of view, in each sprint, they focus mainly on functionality, schedule, quality and team satisfaction, but not on the budget. They agree with the Scrum's benefits set out from Drury-Grogan, 2014: Scrum incorporates unpredictable events regularly through the projects, delivers cost-effective and user-driven services and deliver high-quality products faster, leading to more satisfied customers/employees. In addition to all mentioned above, they seemed to appreciate velocity, documenting the execution of a sprint, transparency, knowledge sharing and culture of collaborations. Comparison of agile team's performance could be made using the Software Development Performance Index (SDPI). SDPI represents the metrics framework for agile team performance, which has been developed at 2013. in cooperation between the Software Engineering Institute (SEI) and the Carnegie Mellon University. It provides a balanced set of team's outcome measures along four basic dimensions: Productivity, Quality, Responsiveness and Predictability. Productivity is based on throughput/ team size indicator that counts user stories and defects completed in a given time period. A quality indicator is based on defect density that count defects divided by man-days. Responsiveness is based on time in process measured by the amount of time that a work item spends in a particular state. Predictability is measured as a standard deviation of throughput for a given team over three monthly periods divided by the average of the throughput for those same three months. It seems obvious that SDPI can be applied for Croatian case of IT service desk performance measure when a team roll out their regular and planned activities. In situations when system/ network administrators become aware of occurrence an problem, urgent request or incident, they have to manage established sprints' priorities in order to fulfil new requirements. When they execute own Scrum activities, SDPI perfectly shadows their performance. Simultaneously their SDPI will have a reflection to the success factors of each project that takes their part.

Current SDPI does not count altogether this indirect endowment to the other teams' performance outside the system administration team. In the case like this, where the result of an agile teamwork is not focused on developing complex services or products, rather on improving the process and functionality, the SDPI may need to be expanded to further tailored measures. For example, a measure named "Employers satisfaction" can show a state of contentment of other teams in the organization with the cooperation achieved with IT service desk.

6.CONSLUSION: THE INVISIBLE POWER OF IT SERVICE DESK

Numerous examples of Scrum implementations can be noticed outside the world of software engineering, mostly in the situation where people produce complex product/service and where it is sought quick adaptation of priorities, depending on obstacles or changes in the turbulent environment. In case of Croatian IT Company, Scrum promotes the principles and elements of self-organization in delivering specific operational service using iterative, adaptive and incremental approach. The Scrum framework with its characteristics is like "pieces of a jigsaw puzzle". Each element, by itself, does not bring about speed and flexibility. But taken as a whole, the characteristics can produce a powerful new set of dynamics that will make a difference" (Takeuchi and Nonaka, 1986). The description of self-organized members of IT service desks that build system functionality, using the "Scrum within Scrum" framework, shows the advantages of agile principle applied to the company's operation management. If they function well and follow the company's development, almost all infrastructures' activities tend to be invisible, like in this described case. People become aware of their performance in situations where the system does not function as planned. IT service desk found practical and useful to apply the same agile framework as a rest of organization. Scrum emphasizes measures of product/service development, which cannot be visible in supporting IT service desk daily operation activities. In this specific case, Scrum only reflects improvement of actual processes and methods applied from team's members of IT service desk. Scrum application contributes to their work productivity, visibility and transparency, enable them to take a position with regard to any challenges they had to encounter and thereat they put more focus on the execution with mutual collaboration.

References

LITERATURE:

1. Addy, Rob (2007). Effective It Service Management: To ITIL AndBeyond!. Springer-Verlag Berlin Heidelberg.

2. Ambler, S. W. (2010). 2010 IT Project Success Rates. Ambysoft. Retrieved March 20, 2018 from http://www.ambysoft.com/surveys/agileSuccess2010.html#Results.

3. Cedergen, S., Larson, S.(2014). Evaluating performance in the development of softwareintensive products. Information and Software Technology. Vol. 56.616-526.

4. Cervone, H.F. (2011). Understanding agile project methods using Scrum. OCLC Systems& Services: Intenational digital library perspectives. Vol 27. No 1. 2011. pp 18-22. Emerald Group Publishing Limited.

5. Curtis, J. (2012). The Importance of a great project Manager. Retrieved April 4, 2018 from http://quotient.net/blog/2012/6/25/the-importance-of-a-greatproject-manager/.

6. Drury- Grogan, M. (2014). Performance on agile teams: Relating iteration objectives and critical decisions to project management success factors. Information and Software Technology, Vol. 56. 506-515.

7. Jurado-Navas, A, Munoz-Luna, R. (2017). Scrum Methodology in Higher Education: Innovation in Teaching, Learning and Assessment. International Journal of Higher Education. Vol 6. No 6. Sciedu Press. ISSN 1927-6044.

8. Kautz, K., Johansen, T.H., Uldahl, A. (2014). The Perceived Impact of the Agile Development and Project Management Method Scrum on Process Transparency in Information Systems Development. 25th International Conference On Information Systems Development (Isd2016 Poland). Retrieved March 25, 2018 from: http://aisel.aisnet.org/cgi/viewcontent.cgi?article=n18&context=isd2014.

9. Oja, J. (2017). Agile Project Management in Engineering, Procurement and Construction Projects: A case study of ABB Grid Integration Finland. Master's Thesis in Industrial Managemnt, VAASA 2017.

10. OOPSLA'95. (1995). Proceedings of the Tenth Annual Conference on Object-Oriented Programming Systems, Languages, and Applications. Austin. Texas. USA. October 15-19, 1995. ACM 1995. ISBN 0-89791-703-0.

11. Standish Group. Chaos report 2016. Retrieved April 4, 2018 from https://www.projectsmart.co.uk/white-papers/chaos-report.pdf.

12. Stevenson, W.J. (2015). Operations Management. McGraw-Hill Series in Operations and Decision Sciences. (12th Edition 2015). McGraw Hill. USA.

13. Streule, T., Miserini, N., Bartlomé. O., Klippel, M., García de Soto, B. (2016). Implementation of Scrum in the Construction Industry. Procedía Engineering, Volume 164, 2016, Pages 269-276, https://doi.org/10.1016/j.proeng.2016.11.619.

14. Sutherland, J. (2014). Scrum: the art of doing twice the work in half the time. Crown Business. USA.

15. Sverrisdottir, H.S., Ingasonb, H.T., Jonasson, H.I. (2014). The role of the product owner in scrum- comparison between theory and practices. Procedia - Social and Behavioral Sciences 119 ( 2014 ) 257 - 267.

16. Šiljevinac, R. (2018). SCRUM framework. (undergraduate final paper). Juraj Dobrila University of Pula, Croatia.

17. Takeuchi, H., Nonaka, I. (1986). The new product development game. Harvard Business Review, 64(1), 137-146.