An Empirical Study on Agile Project Management

Abstract

In project management, project parameters fixed in the initial stages constantly change during the execution of a project. This poses serious challenges to project managers in that such deviations emerge as project risks. In this light, the proposed research sees the need for agile project management. In this undertaking, different project variables that can have impact on the execution of a project will be examined. It will also identify different risk drivers that affect software risk components such as performance risk, schedule risk, and cost risk. Moreover, it will examine risk management and Systems Development Life Cycle (SDLC) of projects based on successes in practical life. The objectives are to have a deeper understanding of the risk factors and variables that can influence software development projects and to evolve appropriate techniques to deal with them in an efficient way so as to minimize the impact of such factors at different stages of the project. The study is primarily based on experience gained from different software development projects. Other data will be collected through survey, in-depth interview, and desk research.

1 Introduction

Project management has been a challenging task for managers as well as executives. It involves planning, monitoring, and control activities that encompass people, process, and events. Successful execution of a project can greatly influence the strategic objectives of any organization. Thus project management activities have been pushed to a higher-level of priority and there is a continuous effort to explore new ways of executing projects to meet organizational goals.

One of the biggest challenges the project managers confront today is that the project parameters as fixed in the initial stages do not remain constant during the execution of a project. Eventually such deviations emerge as project risks which can affect a project in many ways. In such circumstances one needs to assess the probability of occurrence of such risks, estimate its impact and prepare contingency plans and even take proactive measures to avoid them as far as possible or at least minimize their impact. Since risks can take place at any stage of project execution there is a need for agile project management in order to deliver the intended results on time. This requires agile planning, monitoring and control activities to deal with changing project scenarios on-the-fly. Agile software development methodologies promise rapid delivery and flexibility while maintaining quality.

2 Background

Agile project management methodologies are a promising new class of methodologies for software development proposed at the end of the 90’s. Such methodologies are especially suited when the system functionalities is difficult to understand during the early phase of the process. This is because of mutable market conditions, mutable environmental factors, or continuous requirements changing. Therefore, agile project management methodologies are goal-oriented: they allow to adapt the process to all these changes, reaching a goal at a time, with frequent release cycles [1]. Such methodologies are in opposition to “heavy” methodologies like the Waterfall. Moreover, agile methodology and management in software engineering has emerged as a new and promising paradigm of dealing with the current challenges of software development [2, 3]. Challenging the classic ideas and architectures of software development such as waterfall or spiral models is essential given the current trend of industrial developments, changing market and volatile underlying requirements governing the design of software [4].

Over the years, there have been many different software process models around. Many research investigations and numerous software engineering guidebooks compare and contrast the different models, see for example [5]. Moreover, there are many handbooks, ‘checklists’, and even standards available. For example, the ISO/IEC standard 12207 has a guide showing the major differences between the incremental, waterfall, and evolutionary models [6]. Those different investigations use various different comparison viewpoints of the process models, such as: suitability for different development types; suitability when poorly understood, unstable requirements; primary objectives; size, criticality, project's priorities; people factors; universal prescription vs. situational adaptation; and ease of management; means for managing different software risks (uncertainty).

The basic premises and assumptions of the traditional process models in modern software product development environments have been stretched so much that many such models have become partially unsuitable. Additionally, the growing understanding of innovation patterns and organizational learning has influenced software engineering management. Because of many unknowns and uncertainties coupled with ambitious time-to-market goals, basic serial document-driven development is often not feasible. The modern business pressures and technology advances often require responsive last-minute changes in the product contents [7]. New agile software process models address such aspects.

The current trend in software process model development advocates more adaptable and flexible ways of working, that is, moving from rigid all-defining huge organizational processes towards sketched, tailorable, agile processes. Typical way of working is to give only a few most essential practices to the project—more like a process skeleton—where the practices can gradually be added. The mental model here is mere to let the project decide about the practices whenever ready to take those into use rather than having well-set rigid model to follow [8].

Strong management is vital to the successful adoption and application of agile project management methodologies. However, it appears that there is a lack of alignment between the project management methodologies and tools of traditional project management and those of newer agile methodologies [9]. Traditional management theory assumes that: hierarchical organizational structures are means of establishing order and rigid procedures are needed to regulate change, thus organizations must be rigid and have static hierarchies; increased control results in increased order; problems are solved primarily through reductionist task breakdown and allocation; and projects and risks are adequately predictable to be managed through complex up-front planning [9].Thus, it is not surprising that the new methodologies appear informal, egalitarian and directionless in their approach to problem solving.

Overall, the agile project management approach is different from the traditional project management in the sense that emphasis is given more on identifying performance, schedule, and cost risks. Performance risks refer to the degree of uncertainty that the end product will meet its requirement specifications. Schedule risk refers to the degree of uncertainty that the project schedule will be maintained and the product will be delivered on time. Cost risk refers to the degree of uncertainty that the estimated project cost can be adhered to.

Furthermore, the agile project management approach determines the likelihood of the occurrence of the aforementioned risks, prioritizing them depending on their impact, and adopting both proactive and reactive measures to handle them. In traditional approach effort is made to eliminate the impact of risks by taking appropriate measures at an early stage of the project development lifecycle. On the other hand, agile project management techniques work with the assumption that requirements change at different stages in project’s lifecycle. Another important aspect of agile project management is that the main focus goes beyond following defined processes, rather than review and revise the techniques to meet the overall project objectives.

3 The Proposal

The proposed work is based on an empirical study on different variables that can influence software development projects. We intend to study different project variables that are typical of software projects and can have impact on the execution of a project. One of the major problems with software development projects is its intangible nature and the fast changing technological issues. Thus software development projects require special attention particularly when parameters keep changing at different stages of the development cycle.

We shall identify different risk drivers that affect software risk components such as performance risk, schedule risk, and cost risk. Different risks would require different containment procedures. In certain cases one can adopt preventive measures, whereas in certain other cases one can constantly track a project as it progresses and avoid risk situations by taking necessary steps. Yet another approach could be to allow the software development process to proceed in a natural way but whenever a risk actually occurs one has to quickly analyze its impact and take appropriate action to minimize the extent of damage. Moreover, the proposed research focuses on risk management and Systems Development Life Cycle (SDLC) of projects based on successes in practical life.

The objectives of the thesis is two fold: (1) to have a deeper understanding of the risk factors and variables that can influence software development projects; and (2) to evolve appropriate techniques to deal with them in an efficient way so as to minimize the impact of such factors at different stages of the project. The study is based on experience gained from different software development projects.

4 Methodology and Expected Outcomes

4.1 Methodology

Three main steps will be followed in the construction of the thesis. The first step is to study the state of the art in agile methodologies in order to build the goal-oriented framework for project management. The next step is to construct this framework, explaining it in detail based on the knowledge of the previous step. Third, the analysis of the proposed framework will be driven by a case study, using the example of eXtreme Programming (XP), one of the most famous and common agile methodologies in project management [10].

The first step of an XP project is the planning phase called Planning Game. Here, developers and customers will elicit requirements and define the functionalities to be developed during the project. Customers and developers will identify and isolate specific functionalities and describe them in pieces of papers called User Stories, with a business value and a priority. Effort required to implement a story will be estimated by developers, who divide stories into micro-activities, called Tasks, to be performed in 2–3 ideal working days. Moreover, developers will choose which task to develop and take responsibility for their task being completed on time.

In general, each story will require an effort of 1–2 weeks. A story will be considered complete only if all its Acceptance Tests (functional tests that guarantee the correctness of the functionalities specified with User Stories) pass. Stories will be grouped into Iterations, each one with a duration of 2–3 weeks. After a cycle of 2–3 iterations, the product will be released to the customer. In an XP project, the customer is aware that the first release will provide only some functionalities and that many releases could be necessary before all functionalities are implemented. These periods of time, indicated by [10], can vary depending on the specific project, but the idea is always the same: release cycles must be very frequent.

One of the team members will play the role of Tracker: tracking is the critical activity of measuring the team progress. The essence of tracking is the face-to-face contact with the team, to check and track what is done, what is in progress, what is in stand-by and why. In fact, the tracker asks developers questions like: Which is the status of your task? How many (ideal) days have you worked on this? How many more (ideal) days do you need before you have done? Which issues are delaying your task? This information is critical to assess whether or not the effort estimated during the Planning Game is realistic.

There are Internet based tools that can support planning and tracking in an XP project: XPSwiki and XP4IDE. XPSwiki [11] will be used to meet real needs for software businesses to collect requirements and schedules in an electronic format. Managers, developers, and customers can access XPSwiki by means of a Web browser. XPSwiki is built on top of a Wiki engine written in Smalltalk called Swiki. On the other hand, XP4IDE is an Internet based tool which connects to a XPSwiki server and provides a view of the XP process data embedded in the GUI of the IDE. XP4IDE enables the developer to view, directly integrated into the IDE, process data, User Stories, Tasks, Acceptance Tests and Artifacts, all managed and saved on the XPSwiki server. In addition, XP4IDE measures the specific time spent on User Stories, Tasks and Artifacts and sends this information to the XPSwiki server, automating the tracking activity.

Moreover, the agile project management methodology will be compared with PMI and Prince 2 to know how good and reliable it is than others. A structured focused comparison method, which constantly compares within and between data [12] will be carried out. It was articulated by [13] that the use of structured focused comparison is actually the building block for theory development. In this type of case study research, the method is focused in that it deals with only certain aspects of the cases; that is, a selective theoretical focus guides the analysis of the cases. The method of doing so is structured in that the same general questions are asked of each case in order to guide data collection, thereby making possible systematic comparison and accumulation of the findings of the cases.

4.2 Expected Outcomes

The outcome is a goal-oriented project management framework that addresses such risks as performance, schedule, and cost. Another outcome is a risk metric indicating possible risks, their category based on the severity level, probability of occurrence, impact on different risk components is proposed. This metric will be produced based on the experience gained from different software development projects. It will also be based on primary data gathered from survey and in-depth interviews, as well as secondary data and review of literature conducted through desk research. It is expected that the resulting metric will serve as a starting point to study the impact of different risk factors. It is also expected that, based on the metric, response strategies will be developed.

References

[1] M. Angionia, D. Carboni, S. Pinna, R. Sanna, N. Serra, and A. Soro, “Integrating XP project management in development environments,” Journal of Systems Architecture, vol., 52, no. 11, pp. 619-626, 2006.

[2] M. Alshayeb and W. Li, “An empirical study of system design instability metric and design evolution in an agile software process,” Journal of Systems and Software, vol. 74, no. 3, pp. 269–274, 2005.

[3] S.W. Ambler, “Agile Modeling Effective: Practices for Extreme Programming and the Unified Process,” John Wiley, 2002.

[4] Witold Pedrycz, “Quantitative logic-based framework for agile methodologies,” Journal of Systems Architecture, vol. 52, no. 11, pp. 700-707, 2006.

[5] B. Boehm and R. Turner, “Balancing Agility and Discipline—A Guide for the Perplexed,” Addison-Wesley/Pearson Education, 2004.

[6] IEEE/EIA 12207.0-1996 IEEE/EIA Standard Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207) Standard for Information Technology Software Life Cycle Processes, 1998.

[7] W. Mellis, “Software quality management in turbulent times—are there alternatives to process oriented software quality management?,” Software Quality Journal, vol. 7, no. 3-4, pp. 277–295, 1998.

[8] J.A. Highsmith, “Adaptive Software Development—A Collaborative Approach to Managing Complex Systems,” Dorset House Publishing, 2000.

[9] Sanjiv Augustine and Susan Woodcock, “Agile Project management,” url: http://www.ccpace.com/Resources/documents/AgileProjectManagement.pdf

[10] Kent Beck, “Extreme Programming Explained: Embracing Change,” Addison-Wesley, 1999.

[11] Sandro Pinna et al., “Developing a tool supporting XP process, Extreme Programming and Agile Methods,” Lecture Notes in Computer Science, Springer, pp. 151–160, 2003

[12] A. Bennett and A. George, “Research Design Tasks in Case Study Methods,” Paper presented at the MacArthur Foundation Workshop on Case Study Methods, Belfer Center for Science and International Affairs (BCSIA), Harvard University, October 17-19, 1997.

[13] A.L. George, A. L. “Case studies and theory development: The method of structured focused comparison” In P. G. Lauren (Ed.), Diplomatic history: New approaches, pp. 42–68, Free Press, 1979.