Using Agile Methods for Infrastructure Projects: A Practical Experience

• Infrastructure 37.1 Introduction Agile methodologies are becoming a solid alternative in the fi eld of software development [ 1 , 2 ], as they provide support to some special needs required by these kind of projects, like reduction of “time-to-market,” adaptability and quick response to Using Agile Methods for Infrastructure Projects: A Practical Experience C. J. Torrecilla-Salinas , J. Sedeño , M. J. Escalona , and M. Mejías Abstract Agile approaches have emerged in Software Development projects during the last decade becoming a real alternative for organizations developing software. These approaches have been used successfully in several and different projects: from small teams of in-site developers to teams comprising hundreds of developers all over the world. Nevertheless, Agile approaches are not only suitable for Software Development projects, but these methodologies can also be considered to be a framework to plan, estimate and manage any kind of project s focused on quickresponse, adaptation to customers’ needs and early delivery of value to costumers. This paper presents the result of an experience dealing with using an Agile framework, based on Scrum, in an infrastructure project applied to a Spanish Public Administration. According to the results of the project, the paper takes out the main lessons learned and proposes further lines of research. Keywords Agile methodologies • Scrum • e-Government • Public Administration C. J. Torrecilla-Salinas (*) • M. J. Escalona • M. Mejías Department of Computer Languages and Systems , University of Seville , Seville , Spain e-mail: [email protected]; [email protected]; [email protected] J. Sedeño Department of Computer Languages and Systems , University of Seville , Seville , Spain Agencia Andaluza de Instituciones Culturales. Junta de Andalucía , Sevilla , Spain e-mail: [email protected] changes [ 3 , 4 ]. However, some of the Agile approaches, like Scrum, can be considered to be a framework to support project management rather than a software development methodology [ 5 ]. This fact enables thinking that Agile approaches can be used to handle any kind of project s, whenever their needs can relate to quick adaptation to changing needs and early delivery of value. Normally, the work carried out by an IT department is not only associated with software development projects, but also with technology infrastructure projects, among others, therefore the feasibility of expanding the Agile approach beyond software development can allow standardizing practices and processes among these departments, by reducing effort and cost. Based on the foregoing, this work presents the result of applying a Scrum-based Agile approach to support the processes of estimating, planning and managing an infrastructure project developed by a Spanish Public Administration, with the following objectives: assess the feasibility of using Agile approaches in IT projects unrelated to software development, with a special focus on the project management aspects and take out the main lessons learned with the project, in order to identify further lines of research. This paper is organized into the following sections. After this introduction, Sect. 37.2 offers an overview of the related work and the proposed Agile approach and Sect. 37.3 presents the project and its environment. Then, Sect. 37.4 states the results of the project and lastly, Sect. 37.5 identifi es the main lessons learned and proposes possible future lines of work. 37.2 An Overview of the Agile Framework This section presents an overview of the related work and the Agile framework used during the project. The approach was based on Scrum and included elements of Agile estimating, planning and project management techniques. Figure 37.1 summarizes it as follows: 37.2.1 Related Work Although the majority of research in the fi eld of Agile is focusing on software development projects, there are also approaches trying to use Agile approaches in other fi elds of System Development. For instance, there are approaches centered on Fig. 37.1 Agile framework the use of Agile techniques in hardware development projects included in the so called Agile System Engineering [ 6 ], but they are more focused on assessing whether Agile approaches are suitable enough for developing hardware systems than on describing the details of the management process in that project. There are also proposals regarding the use of Agile approaches for rapid hardware modeling [ 7 ], but this kind of projects are more related to the use of software to model hardware than to the assessment of Agile in non-software projects. In addition, there are other approaches dealing with the use of Agile approaches in infrastructure projects, as the one proposed by Debois [ 8 ], which describes some case studies and takes out patterns concerning the introduction of Agile in this type of projects. However, this work is not considering aspects such as how the projects are estimated, planned and managed. In our work, we present an agnostic framework suitable for different types of projects covering elements such as project estimation, project plan, project management and productivity improvement, and assess it in a non-software development project with the aim of extracting the lessons learned. 37.2.2 Scrum In 2001, a work known as the “Agile manifesto” [ 9 ] was published including the main principles and values characterizing Agile approaches. One of the most popular Agile methodologies is Scrum [ 4 ], proposed by Jeff Sutherland and Ken Schwaber [ 10 ]. It is a framework that supports product development [ 5 ] founded on an iterative and incremental approach for project management. Scrum proposes a development process divided into Sprints, time-boxed periods lasting 2–4 weeks that will be repeated during the project. The Scrum process uses an artifact called Product Backlog, containing all the features to develop during the project, ordered by priority. The team selects the features to develop and commits to it at the beginning of each Sprint, creating what is called the Sprint Backlog. The progress is checked daily once the Sprint is planned. The resultant work is reviewed in liaison with the main stakeholders after each Sprint in a Sprint demo and the development process is reviewed in a Sprint retrospective. 37.2.3 Agile Estimating and Planning Techniques Scrum does not defi ne any technique to establish and estimate the pieces of functionality that are part of the Product Backlog. Thus, some other Agile techniques are normally used to fi ll these gaps. In this particular case, the features included in the Product Backlog are “user stories” [ 11 , 12 ]. Two techniques will be used to estimate user stories. On one hand, the development team will calculate the size of each story by means of an ideal unit called “story points” [ 13 ]. The “ Planning poker ” technique will be used to perform estimates [ 13 , 14 ]. On the other hand, the value of each story will also be estimated by means of the “Value point analysis” technique [ 15 ]. For this value, the customers or their representatives should perform the estimation. With these two values, we can obtain a relation between the cost and benefi t of every user story (it is called “Return of investment” or ROI) by dividing the value in value points by the size in story points. This magnitude can be used to order the Product Backlog and establish its priority. The process of estimating and planning will be constant during the project, reserving a slot of time to review the Product Backlog content during each Sprint. This process, known as Product Backlog Grooming [ 16 ], can take up to 10 % of the available time on each Sprint. 37.2.4 Agile Earned Value Metrics An Agile-based approach to the Earned Value Management techniques [ 17 ] can be used in order to control the planned schedule and cost the project entails. These techniques deal with measuring the relationship among cost, scope and schedule along the project [ 18 ], based on calculating two main indexes, the Cost Performance Index (CPI), which measures the relation between estimated and real cost, and the Schedule Performance Index (SPI), which measures the relation between estimated and real schedule. At the end of each Sprint, the proposed Agile approach to EVM measures these indexes to calculate them, through both, the estimated and completed story points and the estimated and dedicated work hours. 37.2.5 Agile Productivity Metrics A number of productivity metrics will be used to facilitate the team’s performance process of continuous improvement. They will be obtained by means of planned and fi nished story points and dedicated work hours, with the aim of keeping a lightweight process. These data are also obtained through the EVM calculation. Metrics were proposed by Downey and Sutherland [ 19 ] and they are calculated per Sprint. The following ones will be used: • Team Velocity (in Hours) : It calculates the product of the velocity in story points by the team’s average amount of hours per story point. • Work Capacity : It deals with the total amount of hours worked by the team during a Sprint. • Focus Factor : It refers to the result of dividing the Team Velocity (in Hours) by the Work Capacity. • Percentage of Accepted Work : It is the result of dividing the hours dedicated to accepted work by the Work Capacity of the team during a Sprint. • Target Value Increase (TVI+) : It refers to the fi nished story points of certain Sprint divided by the average story points of all fi nished Sprints. 37.3 The Project and Its Environment This section presents the environment in which the project was developed, the project itself and its main results, which will be discussed in the following sections. 37.3.1 The Environment: The Regional Government of Andalusia The project presented in this paper was developed by the regional government of Andalusia, a region located in the south of Spain. Junta de Andaluc’a is the name of Andalusia’s regional government; counting with more than 200,000 employees, it is one of the main economic actors in the region [ 20 ]. This project was developed by one of the ministries of the Junta de Andaluc’a: the regional Ministry of Culture and Sport, which is in charge of developing and coordinating public policies both in the cultural and sports areas. Some of its duties are related to the management of public museums, archives, sports clubs, art galleries and theaters. It is also responsible for supporting regional cultural and sports industries, together with other public and private stakeholders. The ICT Department, one of the departments of the Ministry of Culture and Sport, is in charge of this project, being responsible for all Information Technology policies in the Ministry. It is mainly responsible for providing the entire ICT infrastructure needed to operate all Ministry internal systems. It is important to highlight that, as in the last years citizens’ demands on quick and easy access to public services have increased, governments have launched different initiatives to cover these needs, such as e-Government public services [ 21 , 22 ]. Due to the commitment of the regional Ministry on the e-Government strategy, the number of systems under the responsibility of its ICT Department has increased dramatically. 37.3.2 The TOPOS Project As it was mentioned, the ICT Department of the regional Ministry of Culture and Sport is in charge of providing the entire ICT infrastructure that supports all the Ministry systems. On the one hand, in the last years, the number of systems under the responsibility of the Ministry highly increased due to the e-Government strategy of both the regional and the national government. On the other hand, the effects of today’s economic crisis made the organization increase the efforts on costs rationalization and optimization. These two main reasons made the ICT Department of the Ministry start with a project to improve its internal infrastructure and provide a better service with fewer resources. The project was called TOPOS and it lasted more than a year, starting on January 2012 and fi nishing on February 2013. The main goals of the project were: • Reorganize the environments where the systems were deployed, including a development, pre-production and production environment for each system, using virtualization solutions. It intended to reduce the number of physical servers, in order to save space and energy consumption on the datacenter. • Uniform the version of the software products used to support the systems (operative systems, databases, application servers…), in order to reduce the maintenance costs required to run these systems. • Update the versions of some homemade software products that support the general systems of the Ministry, in order to eliminate some errors and security risks. • Clean and decommission some obsolete systems, in order to clean and free resources that could be used to support new services. • Get high availability confi guration of all e-Government services operating into the regional Ministry to improve the service offered to citizens. As TOPOS is an infrastructure project, it is affected by the business projects of the regional Ministry and their different priorities, whereby to be able to respond to possible changes on requirements and priorities, an Agile approach was established, with Scrum as a base framework. A team of fi ve members, partially working on the project and coming from both the system management team and the e-Government bureau of the ICT Department, developed the project by means of internal resources. Then, the following roles were played among the members of the team: • A Scrum Master , whose goal was to ensure the adherence of the team to Scrum practices and help it identify and remove detected errors. • A Product Owner , who tried to identify the business needs and prioritize them using the Product Backlog. • A Development Team , who aimed to develop each of the requested features during the selected Sprint. It has to be mentioned that a particular aspect of TOPOS project, as it concerned the basic infrastructure of the regional Ministry, deals with its impact both on the internal and external users (mainly citizens), for they will be affected, for instance, by services stops when performing the identifi ed tasks. This element demanded an extra effort to work in liaison with the different departments of the Ministry and also to manage changes. 37.4 Results of the Project TOPOS project started in January 2012 with the development of a business case approved by the ICT Department board. After the business case approval, a number of workshops were conducted during this month to identify its initial scope and to draft an initial project plan. An initial Product Backlog was created containing 21 user stories, with a total value of 70 story points, as a result of these workshops. The number and value of the stories varied during the project due to different aspects, such as new user’s needs or stories re-estimation after the clarifi cation of uncertainties. The Product Backlog included 23 user stories with a value of 64 story points at the end of the project. With the initial Product Backlog, the team established a Sprint length of 30 days, which would be stable during the project. Then, due to the lack of historical data, the team forecasted its velocity, estimating it in 7 story points and 137 initial available hours. Table 37.1 summarizes these estimations: Based on these initial forecast s, a project plan, which included an original cost estimation founded on story points, was developed by means of the techniques proposed by Mike Cohn [ 13 ], obtaining €25.90 as the average cost per hour. It must be pointed out that, as it was developed with internal resources, all costs cited in this paper are estimations to manage the project and not real expenditures. An uncertainty percentage was added to these estimates according to McConnell’s “cone of uncertainty” [ 23 ]. Table 37.2 summarizes the initial project plan: The usual Scrum Sprint-based cycle started after the approval of the initial project plan. Each Sprint began with a Sprint planning meeting, where, depending on the available work capacity and the business priorities, the team selected the user stories that should run during the Sprint and committed to them. Moreover, each story was divided into tasks and each task was estimated. Finally, a Sprint Backlog was developed as a result of this meeting. This artifact was the main management tool during the Sprint. Both Product and Sprint Backlog were created using Excel Spreadsheets and shared using a network folder. Before the start of the Sprint, all identifi ed tasks were uploaded in a ticketing tool called Redmine. The team members should take responsibility for the different tasks during the Sprint upon their completion. Besides, the work performed and a Table 37.1 Initialforecast velocity Available hours Estimated initial velocity Hours per story point 137 7 20 Table 37.2 Summary of initial project plan Magnitude Value Uncertainty (±25 %) Initial forecast Total story points 70 18 70 ± 18 Velocity 7 2 7 ± 2 Number of iterations 10 3 10 ± 3 Sprint length 30 days N/A 30 days Project length 300 days 90 days 300 ± 90 days Hours per Sprint 137 h 34 h 137 ± 34 h Hours per project 1,370 h 340 h 1,370 ± 340 h Cost per iteration €3,584.30 €887.01 €3,584.30 ± 887.01 Total project cost €35,843.00 € 8,870.10 € 35,843.00 ± 8,870.10 daily estimation on the remaining work was included in the tool on a daily basis. The Scrum Master was in charge of creating a Sprint burndown chart every day and distributing it among the team members. Then, the team worked on the identifi ed tasks during the Sprint, using this Sprint burndown chart [ 13 ] as a tool to track the remaining work in order to accomplish the committed work. It is worth mentioning that, the team was not physically placed, thus, it was not possible to hold the Daily Scrum meeting to coordinate the work. However, some electronic tools were used to be in contact such as the mentioned ticketing tool, wikis, emails and instant messaging tools. During each Sprint, 10 % of the available time was spent to revisit the Product Backlog intending to update estimations or priorities, for instance, in what is known as “Product Backlog Grooming” [ 16 ]. The team met twice after each Sprint: the fi rst time for a Sprint Review, to present the results of each Sprint and the other for a Sprint Retrospective, to review the process itself. It must be highlighted that retrospectives were based on the principles of Agile retrospectives [ 24 ], including techniques such as Ishikawa Diagrams, Five Whys and other innovation games. The Sprint retrospective started with a general assessment of the work performed during the Sprint, giving it a score between 1 and 5. After that, a radar diagram was developed, assessing four axis of the work: team, technology, process and environment. The team selected the most and less valuable axis and brainstormed things that should be improved or maintained. Afterwards, and using dot voting, the main problems of the Sprint and the best practices are pointed out. Lastly, Ishikawa Diagrams and Five Whys were used to fi nd the root cause of the main problems and some improvements were proposed for each root cause. These improvements were followed up during the later retrospectives to ensure the resolution of the identifi ed root causes. The project lasted 11 iterations, being fi nished in February 2013. Table 37.3 shows the fi nal project results and compares them with the initial estimations: As it can be observed, the real data related to the duration of the project and the amount of work to carry it out remained within the margins of the initial forecasts. That was not the case of the cost and dedicated hours forecasts, probably because of the absence of historical data. Therefore, this initial forecast was corrected at the end of each Sprint, as it will be shown later. Figure 37.2 shows the burnup chart of the project with the fi nished story points against the remaining story points of the Table 37.3 Project results against project estimations Magnitude Initial forecast Final value Total story points 70 ± 18 64 Velocity 7 ± 2 5.8 Number of iterations 10 ± 3 11 Sprint length 30 days 30 days Project length 300 ± 90 days 330 days Hours per Sprint 137 ± 34 h 67.72 Hours per project 1,370 ± 340 h 744.94 Cost per iteration €3,584.30 ± 887.01 € 1,777.74 Total project cost € 35,843.00 ± 8,870.10 € 19,293.95 Product Backlog, and Fig. 37.3 represents the evolution of the real velocity against the velocity planned through the different Sprints: As it is noticed in both fi gures, after the initial Sprints, the team velocity tends to stabilize and to be almost aligned with the forecasts. Table 37.4 shows the results of each Sprint, including EVM calculations: Additionally, the cost estimation per Sprint, and therefore, the cost estimation of the project, was updated at the end of each Sprint, in order to adjust them to the real data. This also entailed, as Table 37.4 represents, the updating of the estimated hours per Sprint. Due to this fact, the estimating ability of the team improved, as both CPI 80 70 60 50 40 30 20 10 0 1234567891011 Total story points in PB Finished Story points Fig. 37.2 Project burn-up chart 12 10 8 6 4 2 0 12345678910 11 Estimated velocity Real velocity Fig. 37.3 Velocity evolution through Sprints