Agile approaches to software development, which are based on the conversational paradigm, present some interesting challenges in applying metrics and measurements. This section further expands on the challenges related to metrics within the context of Agile projects.
- Lack of focus on traditional project parameters: Estimating the key project parameters for a software project is a major challenge of project managers at the start of a software project. Agile methods sidestep this challenge by ascertaining that the cost, time, and scope in an Agile project will be arrived at "iteratively" as the project progresses. Within an Agile approach, these project parameters are not given as much importance as quality and value are. This approach can work when the Agile team members are closely aligned with each other and are operating within the project boundaries. In practice, however, with contract-based development projects cutting across projects and organizations, Agile methods provide very little opportunity for accurate estimations of these project parameters.
- Difficulty in formalizing requirements: Requirements in Agile development are mainly captured with the help of story cards. These brief descriptions of requirements, collaboratively written and pasted on a wall chart, provide the right information to the developers at the right time. However, these changing requirements present a significant challenge in terms of their measurements. A static story card is itself difficult to quantify in terms of the effort required to take it to a "done" state. Comparing two stories is also difficult as the stories differ in the way they are interpreted and developed. Also, a collection of dynamically changing stories is quite challenging to measure based on their categorization and prioritization. This is especially true within the CoE of an organization, which plans to use that data for estimating future projects. This difficulty arises because of the subjective nature of the stories, their "conversational" interpretation, and insufficient focus on formal measurements in an Agile project. This difficulty is further compounded by the lack of use of CASE tools for modeling of requirements and tracking their development.
- Uncertainty in planning the iterations: The number of iterations in an Agile approach can add uncertainty at the start of the project. This is mainly because Agile, subscribing to the Agile Manifesto, is not keen to decide on the precise number of iterations at the start of a project. This is understandable as the requirements for the project are themselves not clear at the outset. However, as the requirements start getting documented in the form of user stories, they also start giving shape to the iterations. At this stage, though, the project is on its way and the subsequent iterations are decided on the basis of how the initial iteration has progressed. This can be a very challenging situation for both project managers and the business stakeholders. This challenge of iteration planning is further exacerbated by the uncertain length of the iteration. An organization following Agile for the first time is not able to decide the iteration interval easily (Nguyen, 2009). The uncertainty in the length of an iteration is due to the up-front issue of changing requirements. Agile approaches can also give an impression that each iteration may be of approximately the same length. This is not true in practice as some iteration could have excessive story points, which could lead to longer development times. This uncertainty adds to the challenges of planning iterations in Agile.
- Multipurpose daily stand-up meetings: The daily stand-up meeting is a flagship activity within an Agile project. These short, sharp, daily meetings (based on Scrum) provide valuable information on the project status and its progress. The difficulty in terms of metrics is the differing output resulting from the meetings. Each meeting focuses on stating the achievements and identifying the roadblocks. This, in itself, works well in a synchronous team. The measures of the milestones and measures of the roadblocks can quickly become very subjective. Thus, the knowledge gained in terms of development in one project stays within that project and cannot be easily applied across other projects.
- Fuzzy measure of person-days: Estimating development within a project relies substantially on the measure of person-days (resources) for a particular requirement. Execution of sprints and iterations does not provide a concrete measure of the person-days required on a project. This measure is difficult even in traditional projects where the efforts put in by developers within a day and the quality of the output can vary. Traditional software project measures such as person-days spent and lines of code developed are shunned in Agile approaches. Hence, Agile projects end up with nonstandardized estimation of efforts.
- Continuous testing during development: Continuous testing of a product as it gets developed during a sprint/iteration has a positive effect on managing expectations. This continuous testing, however, becomes an integrated part of the development process. Furthermore, continuous integration of releases and products also implies much less separate, dedicated testing of the product. Therefore, there is very little project data that is dedicated to testing, which becomes available. Dedicated testing phases, specific user acceptance testing, nonfunctional testing, and usability testing (by walk-throughs and inspections) provide test data that can be used in project estimations.
- Subjective interpretation: Metrics are statistical data on a project that can be interpreted differently by different individuals. A person's motivation and his or her alignment with the rest of the team cannot be easily measured. Since Agile methods focus on task sharing and not on task management, the traditional way of measuring a person's performance (tasks completed) is also not used in Agile methods. The project manager, working as a leader, has to somehow arrive at a correlation between the time spent and an individual's actual productivity. This exercise can throw the measures of productivity out of balance.
- Varying development styles: Development can be carried out in many different ways within an Agile development life cycle. As Agile involves iterations, there could be small teams working on different features of the same product. Each team has the freedom to evolve its own style of development. Completion of features, their quality, and the comparison of overall output between the teams is very challenging in an Agile approach. Quality and output cannot be easily measured in a standardized manner in an Agile project.
Taken from : The Art of Agile Practice: A Composite Approach for Projects and Organizations
No comments:
Post a Comment