Practices of Agile Methods in Project Management
Disclaimer: This dissertation has been submitted by a student. This is not an example of the work written by our professional dissertation writers. You can view samples of our professional work here.
Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UK Essays.
This paper describes the practices of agile methods from the viewpoint of project management.
The project management techniques are complex processes that require the understanding and coordination of several domains of knowledge.
As more and more software projects engage Agile Methods, there are emerging patterns of success and failure. With growing adoption of Agile Methods, project managers increasingly need to understand the applicability to their projects and factors that drive key project performance characteristics.
Agile Methods have advantages, especially in accommodating change due to volatile requirements. However, they also present concomitant risks with managing the many dependent pieces of work distributed across a large project.
The paper is divided into four parts. In the first part an overview of the project management and its processes and knowledge areas discussed. after that the agile methods discussed following with a short history of RAD(We should mention that just three most used and famous methodologies are discussed).
In the second part the project management approaches and a brief definition of each approach are given.
In the third part we looked at the agile methodologies from project management areas view such as cost, time, quality and risk management and we compared agile methodologies and we explained their advantages and disadvantages.
In the fourth part we discussed about combination of agile methodologies and their utilization in large and complex projects.
And finally we propose our own idea about the future of project management in agile methods.
Keywords Project Management, Rapid Development Methodologies, Agile Project Management, History of RAD, Project management approaches, Agile Performance Measurement, Investment and Risk, Agile Enterprise Framework, Agile Methodology Fit
What is Project?
- A human activity that achieves a clear objective against a time scale
- "A project is a one-shot, time-limited, goal-directed, major undertaking, requiring the commitment of varied skills and resources".
A project is a temporary endeavor undertaken to create a unique product or service. A project is temporary in that there is a defined start (the decision to proceed) and a defined end (the achievement of the goals and objectives). Ongoing business or maintenance operations are not projects. Energy conservation projects and process improvement efforts that result in better business processes or more efficient operations can be defined as projects. Projects usually include constraints and risks regarding cost, schedule or performance outcome.
What is Project Management?
Many have attempted to define project management. One example, Oisen,3 referencing views from the 1950's, may have been one of the early attempts. Project Management is the application of a collection of tools and techniques (such as the CPM and matrix organization) to direct the use of diverse resources toward the accomplishment of a unique, complex, one-time task within time, cost and quality constraints. Each task requires a particular mix of theses tools and techniques structured to fit the task environment and life cycle (from conception to completion) of the task.
Notice in the definition are included some the success criteria, The Iron triangle. Those criteria for measuring success included in the description used by Oisen3 continue to be used to describe project management today. The British Standard for project management BS60794 1996 defined project management as:
The planning, monitoring and control of all aspects of a project and the motivation of all those involved in it to achieve the project objectives on time and to the specified cost, quality and performance. The UK Association of project Management (APM) have produced a UK Body of Knowledge UK (BoK)5
which also provides a definition for project management as:
The planning, organization, monitoring and control of all aspects of a project and the motivation of all involved to achieve the project objectives safely and within agreed time, cost and performance criteria. The project manager is the single point of responsibility for achieving this. Other definitions have been offered, Reiss6 suggests a project is a human activity that achieves a clear objective against a time scale, and to achieve this while pointing out that a simple description is not possible, suggests project management is a combination of management and planning and the management of change.
Lock's7 view was that project management had evolved in order to plan, co-ordinate and control the complex and diverse activities of modern industrial and commercial projects, while Burke8 considers project management to be a specialized management technique, to plan and control projects under a strong single point of responsibility.
While some different suggestions about what is project management have been made, the criteria for success, namely cost, time and quality remain and are included in the actual description. Could this mean that the example given to define project management Oisen3 was either correct, or as a discipline, project management has not really changed or developed the success measurement criteria in almost 50 years.
Project management is a learning profession. Based upon past mistakes and believed best practice, standards such as BS 60794 and the UK Body of Knowledge5 continue to be developed. But defining project management is difficult, Wirth,9 indicated the differences in content between six countries own versions of BoK's. Turner10 provided a consolidated matrix to help understand and moderate different attempts to describe project management, including the assessment. Turner10 further suggested that project management could be described as: the art and science of converting vision into reality. Note the criteria against which project management is measured is not included in that description. Is there a paradox however in even attempting to define project management? Can a subject which deals with a unique, one-off complex task as suggested as early as Oisen3 be defined? Perhaps project management is simply an evolving phenomena, which will remain vague enough to be non-definable, a flexible attribute which could be a strength. The significant point is that while the factors have developed and been adopted, changes to the success criteria have been suggested but remain unchanged. Could the link be, that project management continues to fail because, included in the definition are a limited set of criteria for measuring success, cost, time and quality, which even if these criteria are achieved simply demonstrate the chance of matching two best guesses and a phenomena correctly. Prior to some undergraduate lectures and workshops about project management, the students were asked to locate some secondary literature describing project management and produce their own definition. While there were some innovative ideas, the overriding responses included the success criteria of cost, time and quality within the definition. If this is the perception about project management we wish those about to work in the profession to have, the rhetoric over the years has worked. Has this however been the problem to realizing more successful projects? To date, project management has had the success criteria focused upon the delivery stage, up to implementation. Reinforced by the very description we have continued to use to define the profession. The focus has been to judge whether the project was done right. Doing something right may result in a project which was implemented on time, within cost and to some quality parameters requested, but which is not used by the customers, not liked by the sponsors and does not seem to provide either improved effectiveness or efficiency for the organization, is this successful project management?
Project Management Life Cycle
The process flow of Project management processes is shown below. The various elements of project management life cycle are
- Need identification
- Closing out
a) Need Identification
The first step in the project development cycle is to identify components of the project. Projects may be identified both internally and externally:
- Internal identification takes place when the energy manager identifies a package of energy saving opportunities during the day-to-day energy management activities, or from facility audits.
- External identification of energy savings can occur through systematic energy audits undertaken by a reputable energy auditor or energy service company.
- In screening projects, the following criteria should be used to rank-order project opportunities.
- Cost-effectiveness of energy savings of complete package of measures (Internal rate of return, net present value, cash flow, average payback)
- Sustainability of the savings over the life of the equipment.
- Ease of quantifying, monitoring, and verifying electricity and fuel savings.
- Availability of technology, and ease of adaptability of the technology to Indian conditions.
- Other environmental and social cost benefits (such as reduction in local pollutants, e.g. SOx)
Initiating is the basic processes that should be performed to get the project started. This starting point is critical because those who will deliver the project, those who will use the Bureau of Energy Efficiency project, and those who will have a stake in the project need to reach an agreement on its initiation. Involving all stakeholders in the project phases generally improves the probability of satisfying customer requirements by shared ownership of the project by the stakeholders. The success of the project team depends upon starting with complete and accurate information, management support, and the authorization necessary to manage the project.
The initiation stage should include a plan that encompasses the following areas:
- Analyzing the business needs/requirements in measurable goals
- Reviewing of the current operations
- Financial analysis of the costs and benefits including a budget
- Stakeholder analysis, including users, and support personnel for the project
- Project charter including costs, tasks, deliverables, and schedule
The planning phase is considered the most important phase in project management. Project planning defines project activities that will be performed; the products that will be produced, and describes how these activities will be accomplished and managed. Project planning defines each major task, estimates the time, resources and cost required, and provides a framework for management review and control. Planning involves identifying and documenting scope, tasks, schedules, cost, risk, quality, and staffing needs.
The result of the project planning, the project plan, will be an approved, comprehensive document that allows a project team to begin and complete the work necessary to achieve the project goals and objectives. The project plan will address how the project team will manage the project elements. It will provide a high level of confidence in the organization's ability to meet the scope, timing, cost, and quality requirements by addressing all aspects of the project.
Project planning generally consists of
- determining how to plan (e.g. by level of detail or rolling wave);
- developing the scope statement;
- selecting the planning team;
- identifying deliverables and creating the work breakdown structure;
- identifying the activities needed to complete those deliverables and networking the activities in their logical sequence;
- estimating the resource requirements for the activities;
- estimating time and cost for activities;
- developing the schedule;
- developing the budget;
- risk planning;
- gaining formal approval to begin work.
Additional processes, such as planning for communications and for scope management, identifying roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also generally advisable.
For new product development projects, conceptual design of the operation of the final product may be performed concurrent with the project planning activities, and may help to inform the planning team when identifying deliverables and planning activities
Once a project moves into the execution phase, the project team and all necessary resources to carry out the project should be in place and ready to perform project activities. The project plan is completed and base lined by this time as well. The project team and the project manager's focus now shifts from planning the project efforts to participating, observing, and analyzing the work being done.
The execution phase is when the work activities of the project plan are executed, resulting in the completion of the project deliverables and achievement of the project objective(s). This phase brings together all of the project management disciplines, resulting in a product or service that will meet the project deliverable requirements and the customers need. During this phase, elements completed in the planning phase are implemented, time is expended, and money is spent.
In short, it means coordinating and managing the project resources while executing the project plan, performing the planned project activities, and ensuring they are completed efficiently.
e) Monitoring and Controlling
Project Control function that involves comparing actual performance with planned performance and taking corrective action to get the desired outcome when there are significant differences. By monitoring and measuring progress regularly, identifying Bureau of Energy Efficiency variances from plan, and taking corrective action if required, project control ensures that project objectives are met.
Monitoring and Controlling includes:
- Measuring the ongoing project activities (where we are);
- Monitoring the project variables (cost, effort, scope, etc.) against the project management plan and the project performance baseline (where we should be);
- Identify corrective actions to address issues and risks properly (How can we get on track again);
- Influencing the factors that could circumvent integrated change control so only approved changes are implemented
- In multi-phase projects,process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan.
Project Maintenance is an ongoing process, and it includes:
- Continuing support of end users
- Correction of errors
- Updates of the software over time
Monitoring and Controlling cycle
In this stage, auditors should pay attention to how effectively and quickly user problems are resolved.
Over the course of any construction project, the work scope may change. Change is a normal and expected part of the construction process. Changes can be the result of necessary design modifications, differing site conditions, material availability, contractor-requested changes, value engineering and impacts from third parties, to name a few. Beyond executing the change in the field, the change normally needs to be documented to show what was actually constructed. This is referred to as Change Management. Hence, the owner usually requires a final record to show all changes or, more specifically, any change that modifies the tangible portions of the finished work. The record is made on the contract documents - usually, but not necessarily limited to, the design drawings. The end product of this effort is what the industry terms as-built drawings, or more simply, "as built." The requirement for providing them is a norm in construction contracts.
When changes are introduced to the project, the viability of the project has to be re-assessed. It is important not to lose sight of the initial goals and targets of the projects. When the changes accumulate, the forecasted result may not justify the original proposed investment in the project.
f) Closing out
Project closeout is performed after all defined project objectives have been met and the customer has formally accepted the project's deliverables and end product or, in some instances, when a project has been cancelled or terminated early. Although, project closeout is a routine process, it is an important one. By properly completing the project closeout, organizations can benefit from lessons learned and information compiled. The project closeout phase is comprised of contract closeout and administrative closure.
This phase consists of:
- Project close: Finalize all activities across all of the process groups to formally close the project or a project phase
- Contract closure: Complete and settle each contract (including the resolution of any open items) and close each contract applicable to the project or project phase
Project Management Knowledge Areas with the Related Processes
Each of the nine knowledge areas contains the processes that need to be accomplished within its discipline in order to achieve an effective project management program. Each of these processes also falls into one of the five basic process groups, creating a matrix structure such that every process can be related to one knowledge area and one process group.
Software development projects represent an investment of resources by the project's sponsor, an investment that often yields little or no return. The Standish Group's Chaos Report 1994 states that fewer than 10% of software projects in large companies were successful. Medium sized companies do better with 16% of their software projects being successful, and small companies succeed on 28% of their software projects (Standish 1994). Given these statistics it is worthwhile to invest significant effort in Risk Management for software projects. "Research at The Standish Group also indicates that smaller time frames, with delivery of software components early and often, will increase the success rate." (Standish 1994).
Extreme Programming offers nothing to help integrate the efforts of non-software developers. Unfortunately, some advocates of Extreme Programming suggest that the efforts of technical writers, database managers, and quality assurance specialist are not required. In reality, while Extreme Programming does not explicitly describe how to integrate the work of others, the practices do not preclude the ability to integrate with other efforts. Small Releases make Integration Management a more continuous process in contrast to processes that place deployment, documentation, and testing at the end of the schedule.
At a more tactical level, the Extreme Programming practice of Continuous Integration requires that the work of software developers be integrated on a daily basis. While this practice can cause additional overhead for individual developers, it allows the team to identify problems daily that would otherwise become undiscovered rework accumulating until all developers integrate their individual work products.
Scope Management & Time Management
Ask most software development teams for a copy of their project plan and you will receive an activity list formatted as a Gantt chart. Many times these activity lists will describe several phases of activities such as Analysis, Design, Construction, and Testing. Areas of functionality will be broken out under these headings in order to assign them to specific programmers, but seldom are the assignments identified in the Gantt chart clearly traceable back to a Requirement or other specification documents. All too often, the missing item that would help a team improve their planning practices is a well-constructed Work Breakdown Structure. Extreme Programming focuses almost all of its planning efforts on building a thoughtful Work Breakdown Structure and its constituent Work Packages.
Extreme Programming does not teach Work Breakdown Structures and Work Packages explicitly, however, careful study of the Story Cards used in Extreme Programming reveals that they are almost identical to Work Packages in their key attributes.
Human Resources Management
Often one of the most challenging aspects of project management is managing human resources. For software development projects in particular this includes the complex juggling of technical tasks between individual software developers who have different individual skills, effectively treating each developer's assigned tasks as an independent subproject. This type of project plan often suffers from key resource bottlenecks and status meetings reduced to determining which individuals are falling furthest behind. Extreme Programming addresses this head-on by eliminating the dependency on individual developers. Work Packages are scheduled and authorized based on the needs of the business and the users not the needs of the software developers. All developers are cross-trained to work in all areas of the code base. Developers broaden their skills, and project managers stop worrying about keeping individual software developers for the entire duration of the project. The process maintains knowledge of the full code base in the team, not in individuals.
As programmers move from work authorization to work authorization, and often from one area of the code to another, it is easy to see that maintaining quality in the work product could be challenging. Extreme Programming requires a very disciplined design approach to allow freedom in assigning resources while maintaining high quality.
When a project manager mentions the need for improved communications on a project, software developers often immediately envision an increased number of meetings and documents. While formal meetings and written documents have their place in a communication plan there are many other tools for facilitation of communication between project participants. The Extreme Programming practices include several simple practices intended to enhance communications.
Often a Project Manager is evaluated on his or her ability to complete a project within budget. The costs include estimated cost, actual cost and variability. Contingency cost takes into account influence of weather, suppliers and design allowances.
How the 80/20 Rule can help a project manager?
The 80/20 Rule means that in anything a few (20 percent) are vital and many (80 percent) are trivial. Successful Project Managers know that 20 percent of the work (the first 10 percent and the last 10 percent) consumes 80 percent of your time and resources.
The History of RAD
Traditional lifecycles devised in the 1970s, and still widely used today, are based upon a structured step-by-step approach to developing systems. This rigid sequence of steps forces a user to "sign-off" after the completion of each specification before development can proceed to the next step. The requirements and design are then frozen and the system is coded, tested, and implemented. With such conventional methods, there is a long delay before the customer gets to see any results and the development process can take so long that the customer's business could fundamentally change before the system is even ready for use. In response to these rigid, cascading, one-way steps of Stagewise or Waterfall Models of development, Barry Boehm, Chief SW Engineer at TRW, introduced his Spiral
Model. The Spiral Model is a risk-driven, as opposed to code-driven, approach that uses process modeling rather than methodology phases. Through his model, Boehm first implemented software prototyping as a way of reducing risk. The development process of the Spiral Model separates the product into critical parts or levels while performing risk analyses, prototyping, and the same steps at each of these levels. Similarly, Tom Gilb's Evolutionary Life Cycle is based on an evolutionary prototyping rationale where the prototype is grown and refined into the final product.
The work of Boehm and Gilb paved the way for the formulation of the methodology called Rapid Iterative Production Prototyping (RIPP) at DuPont in the mid-to-late 1980s. James Martin then extended the work done at DuPont and elsewhere into a larger, more formalized process, which has become known as Rapid Application Development (RAD). RAD compresses the step-by-step development of conventional methods into an iterative process. The RAD approach thus includes developing and refining the data models, process models, and prototype in parallel using an iterative process. User requirements are refined, a solution is designed, the solution is prototyped, the prototype is reviewed, user input is provided, and the process begins again.
What is Agility?
There is no Agility for Dummies. Agility isn't a silver bullet. You don't achieve it in five easy steps. So what is it? From one view agility characterized in two statements:
"Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.
Agility is the ability to balance flexibility and stability" (Highsmith 2002).
In an uncertain and turbulent world, success belongs to companies that have the capacity to create change, and maybe even chaos, for their competitors. Creating change disrupts competitors (and the entire market ecosystem); responding to change guards against competitive thrusts. Creating change requires innovation: developing new products, creating new sales channels, reducing product development time, customizing products for increasingly smaller market segments. In addition, your company must be able to respond quickly to both anticipated and unanticipated changes created by your competitors and customers.
An example of a product development effort in which all the aspects of agility come into play is that of small, portable DNA analyzers. These instruments can be used for analyzing suspected bio-terror agents (e.g., anthrax), performing quick medical diagnoses, or undertaking environmental bacterial analysis. These instruments must be accurate, easy to use, and reliable under wide-ranging conditions, and their development depends on breakthroughs in nanotechnology, genome research, and micro-fluidics. Developing these leading-edge products requires blending flexibility and structure, exploring various new technologies, and creating change for competitors by reducing delivery time. These are not projects that can be managed by traditional, prescriptive project management methodologies.
Some people mistakenly assume that agility connotes a lack of structure, but the absence of structure, or stability, generates chaos. Conversely, too much structure generates rigidity. Complexity theory tells us that innovation—creating something new in ways that we can't fully anticipate (an emergent result) occurs most readily at the balance point between chaos and order, between flexibility and stability. Scientists believe that emergence, the creation of novelty from agent interaction, happens most readily at this "edge of chaos." The idea of enough structure, but not too much, drives agile managers to continually ask the question, "How little structure can I get away with?" Too much structure stifles creativity. Too little structure breeds inefficiency.
This need to balance at the edge of chaos to foster innovation is one reason process-centric methodologies often fail. They push organizations into over-optimization at the expense of innovation. Agile organizations don't get lost in some gray middle ground; they understand which factors require stabilization and which ones encourage exploration. For example, in a high-change product development environment, rigorous configuration management stabilizes and facilitates flexibility just as a focus on technical excellence stabilizes the development effort.
Overview and definitions
The "Agile Movement" in software industry saw the light of day with the Agile
Software Development Manifesto4 published by a group of software practitioners and consultants in 2001 (Beck et al. 2001; Cockburn 2002a). The focal values honored by the agilists are presented in the following:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These central values that the agile community adheres to are:
First, the agile movement emphasizes the relationship and communality of software developers and the human role reflected in the contracts, as opposed to institutionalized processes and development tools. In the existing agile practices, this manifests itself in close team relationships, close working environment arrangements, and other procedures boosting team spirit.
Second, the vital objective of the software team is to continuously turn out tested working software. New releases are produced at frequent intervals, in some approaches even hourly or daily, but more usually bi-monthly or monthly. The developers are urged to keep the code simple, straightforward, and technically as advanced as possible, thus lessening the documentation burden to an appropriate level.
Third, the relationship and cooperation between the developers and the clients is given the preference over strict contracts, although the importance of well drafted contracts does grow at the same pace as the size of the software project. The negotiation process itself should be seen as a means of achieving and maintaining a viable relationship. From a business point of view, agile development is focused on delivering business value immediately as the project starts, thus reducing the risks of non-fulfillment regarding the contract.
Fourth, the development group, comprising both software developers and customer representatives, should be well-informed, competent and authorized to consider possible adjustment needs emerging during the development process life-cycle. This means that the participants are prepared to make changes and that also the existing contracts are formed with tools that support and allow these enhancements to be made.
According to Highsmith and Cockburn (2001, p. 122), "what is new about agile methods is not the practices they use, but their recognition of people as the primary drivers of project success, coupled with an intense focus on effectiveness and maneuverability. This yields a new combination of values and principles that define an agile world view." Boehm (2002) illustrates the spectrum of different planning methods with Figure 1, in which hackers are placed at one end and the so called inch-pebble ironbound contractual approach at the opposite end:
Hawrysh and Ruprecht (2000) state that a single methodology can not work for the whole spectrum of different projects, but instead the project management should identify the specific nature of the project at hand and then select the best applicable development methodology. To stress the point further, according to McCauley (2001) there is a need for both agile and process-oriented methods, as there is no one-size-fits-all software development model that suits all imaginable purposes. This opinion is shared by several experts in the field (Glass 2001).
Cockburn (2002a, p. xxii) defines the core of agile software development methods as the use of light-but-sufficient rules of project behavior and the use of human- and communication-oriented rules. The agile process is both light and sufficient. Lightness is a means of remaining maneuverable. Sufficiency is a matter of staying in the game (Cockburn 2002a). He proposes the following "sweet spots" the presence of which in software development work enhances the prospects for a successful project outcome:
- Two to eight people in one room
- Communication and community
- Onsite usage experts
- Short and continuous feedback cycles
- Short increments
- One to three months, allows quick testing and repairing
- Fully automated regression tests
- Unit and functional tests stabilize code and allow continuous improvement
- Experienced developers
- Experience speeds up the development time from 2 to 10 times compared to slower team members.
In this section, the current state of agile software development methods is reviewed. The selection of methods is based on the definition proposed in "overview and definition section". As a result the following methods are included in this analysis: Extreme Programming (Beck 1999b), Scrum (Schwaber 1995; Schwaber and Beedle 2002), Crystal family of methodologies (Cockburn 2002a), Feature Driven Development (Palmer and Felsing 2002), the Rational Unified Process (Kruchten 1996; Kruchten 2000), Dynamic Systems Development Method (Stapleton 1997), Adaptive Software Development (Highsmith 2000) and Open Source Software development (e.g., O'Reilly 1999). Methods will be introduced and reviewed systematically by using a defined structure where process, roles and responsibilities, practices, adoption and experiences, scope of use and current research regarding each method are identified. Process refers to the description of phases in the product life-cycle through which the software is being produced. Roles and responsibilities refer to the allocation of specific roles through which the software production in a development team is carried out. Practices are concrete activities and work products that a method defines to be used in the process. Adoption and experiences refer primarily to existing experience reports regarding the use of method in practice and method developers' considerations how the method should be introduced in an organization. Scope of use identifies the limitations regarding each method, i.e. if such have been documented. Finally, the current research and publications are surveyed in order to get an overview of the scientific and practical status of the method.
Extreme Programming (XP) has evolved from the problems caused by the long development cycles of traditional development models (Beck 1999a). It first started as 'simply an opportunity to get the job done' (Haungs 2001) with practices that had been found effective in software development processes during the preceding decades (Beck 1999b). After a number of successful trials in practice (Anderson et al. 1998), the XP methodology was "theorized" on the key principles and practices used (Beck 1999b). Even though the individual practices of XP are not new as such, in XP they have been collected and lined up to function with each other in a novel way thus forming a new methodology for software development. The term 'extreme' comes from taking these commonsense principles and practices to extreme levels (Beck 1999b).
In the following, these phases are introduced according to Beck's (1999b) description:
In the Exploration phase, the customers write out the story cards that they wish to be included in the first release. Each story card describes a feature to be added into the program. At the same time the project team familiarize themselves with the tools, technology and practices they will be using in the project. The technology to be used will be tested and the architecture possibilities for the system are explored by building a prototype of the system. The exploration phase takes between a few weeks to a few months, depending largely on how familiar the technology is to the programmers.
The Planning phase sets the priority order for the stories and an agreement of the contents of the first small release is made. The programmers first estimate how much effort each story requires and the schedule is then agreed upon. The time span of the schedule of the first release does not normally exceed two months. The planning phase itself takes a couple of days.
The Iterations to release phase includes several iterations of the systems before the first release. The schedule set in the planning stage is broken down to a number of iterations that will each take one to four weeks to implement. The first iteration creates a system with the architecture of the whole system. This is achieved by selecting the stories that will enforce building the structure for the whole system. The customer decides the stories to be selected for each iteration. The functional tests created by the customer are run at the end of every iteration. At the end of the last iteration the system is ready for production.
The Productionizing phase requires extra testing and checking of the performance of the system before the system can be released to the customer. At this phase, new changes may still be found and the decision has to be made if they are included in the current release. During this phase, the iterations may need to be quickened from three weeks to one week. The postponed ideas and suggestions are documented for later implementation during, e.g., the maintenance phase.
After the first release is productionized for customer use, the XP project must both keep the system in the production running while also producing new iterations.
In order to do this, the Maintenance phase requires an effort also for customer support tasks. Thus, the development velocity may decelerate after the system is in production. The maintenance phase may require incorporating new people into the team and changing the team structure.
The Death phase is near when the customer does no longer have any stories to be implemented. This requires that the system satisfies customer needs also in other respects (e.g., concerning performance and reliability). This is the time in the XP process when the necessary documentation of the system is finally written as no more changes to the architecture, design or code are made. Death may also occur if the system is not delivering the desired outcomes, or if it becomes too expensive for further development.
The first references in the literature to the term 'Scrum' point to the article of Takeuchi and Nonaka (1986) in which an adaptive, quick, self-organizing product development process originating from Japan is presented (Schwaber and Beedle 2002). The term 'scrum' originally derives from a strategy in the game of rugby where it denotes "getting an out-of play ball back into the game" with teamwork (Schwaber and Beedle 2002). The Scrum approach has been developed for managing the systems development process. It is an empirical approach applying the ideas of industrial process control theory to systems development resulting in an approach that reintroduces the ideas of flexibility, adaptability and productivity (Schwaber and Beedle 2002). It does not define any specific software development techniques for the implementation phase. Scrum concentrates on how the team members should function in order to produce the system flexibly in a constantly changing environment.
The main idea of Scrum is that systems development involves several environmental and technical variables (e.g. requirements, time frame, resources, and technology) that are likely to change during the process. This makes the development process unpredictable and complex, requiring flexibility of the systems development process for it to be able to respond to the changes. As a result of the development process, a system is produced which is useful when delivered (Schwaber 1995).
Scrum helps to improve the existing engineering practices (e.g. testing practices) in an organization, for it involves frequent management activities aiming at consistently identifying any deficiencies or impediments in the development process as well as the practices that are used.
In the following, the Scrum phases are introduced according to Schwaber (1995; Schwaber and Beedle 2002).
The pre-game phase includes two sub-phases: Planning and Architecture/High level design.
Planning includes the definition of the system being developed. A Product Backlog list (see 3.2.3) is created containing all the requirements that are currently known. The requirements can originate from the customer, sales and marketing division, customer support or software developers. The requirements are prioritized and the effort needed for their implementation is estimated. The product Backlog list is constantly updated with new and more detailed items, as well as with more accurate estimations and new priority orders. Planning also includes the definition of the project team, tools and other resources, risk assessment and controlling issues, training needs and verification management approval. At every iteration, the updated product Backlog is reviewed by the Scrum Team(s) so as to gain their commitment for the next iteration.
In the architecture phase, the high level design of the system including the architecture is planned based on the current items in the Product Backlog. In case of an enhancement to an existing system, the changes needed for implementing the Backlog items are identified along with the problems they may cause. A design review meeting is held to go over the proposals for the implementation and decisions are made on the basis of this review. In addition, preliminary plans for the contents of releases are prepared.
The development phase (also called the game phase) is the agile part of the Scrum approach. This phase is treated as a "black box" where the unpredictable is expected. The different environmental and technical variables (such as time frame, quality, requirements, resources, implementation technologies and tools, and even development methods) identified in Scrum, which may change during the process, are observed and controlled through various Scrum practices during the Sprints (see the section below) of the development phase. Rather than taking these matters into consideration only at the beginning of the software development project, Scrum aims at controlling them constantly in order to be able to flexibly adapt to the changes.
In the development phase the system is developed in Sprints. Sprints are iterative cycles where the functionality is developed or enhanced to produce new increments. Each Sprint includes the traditional phases of software development: requirements, analysis, design, evolution and delivery phases. The architecture and the design of the system evolve during the Sprint development. One Sprint is planned to last from one week to one month. There may be, for example, three to eight Sprints in one systems development process before the system is ready for distribution. Also there may be more than one team building the increment.
The post-game phase contains the closure of the release. This phase is entered when an agreement has been made that the environmental variables such as the requirements are completed. In this case, no more items and issues can be found nor can any new ones be invented. The system is now ready for the release and the preparation for this is done during the post-game phase, including the tasks such as the integration, system testing and documentation.
Dynamic Systems Development Method
Since its origin in 1994, DSDM, the Dynamic Systems Development Method, has gradually become the number one framework for rapid application development (RAD) in the UK (Stapleton 1997). DSDM is a non-profit and nonproprietary framework for RAD development, maintained by the DSDM Consortium10. The developers of the method maintain that in addition to serving as a method in the generally accepted sense DSDM also provides a framework of controls for RAD, supplemented with guidance on how to efficiently use those controls.
The fundamental idea behind DSDM is that instead of fixing the amount of functionality in a product, and then adjusting time and resources to reach that functionality, it is preferred to fix time and resources, and then adjust the amount of functionality accordingly.
DSDM consists of five phases: feasibility study, business study, functional model iteration, design and build iteration, and implementation. The first two phases are sequential, and done only once. The last three phases, during which the actual development work is done, are iterative and incremental. DSDM approaches iterations as timeboxes. A timebox lasts for a predefined period of time, and the iteration has to end within the timebox. The time allowed for each iteration to take is planned beforehand, along with the results the iteration is guaranteed to produce. In DSDM, a typical timebox duration is from a few days to a few weeks.
In the following, the phases are introduced, with their essential output documents.
The feasibility study phase is where the suitability of DSDM for the given project is assessed. Judging by the type of project and, most of all, organizational and people issues, the decision is made, whether to use DSDM or not. In addition, the feasibility study phase is concerned with the technical possibilities of going through with the project, and the risks therein. Two work products are prepared - a feasibility report, and an outline plan for development. Optionally, a fast prototype can also be made if the business or technology are not known well enough to be able to decide whether to proceed to the next phase or not. The feasibility study phase is not expected to take more than a few weeks.
The business study is a phase where the essential characteristics of the business and technology are analyzed. The recommended approach is to organize workshops, where a sufficient number of the customer's experts are gathered to be able to consider all relevant facets of the system, and to be able to agree on development priorities. The affected business processes and user classes are described in a Business Area Definition. The identification of the affected user classes helps involving the customer, as the key people in the customer's organization can be recognized and involved at an early stage. High level descriptions of the processes are presented in the Business Area Definition, in a suitable format (ER diagrams, business object models, etc.).
Another two outputs are done in the business study phase. One is a System Architecture Definition, and the other an Outline Prototyping Plan. The architecture definition is the first system architecture sketch, and it is allowed to change during the course of the DSDM project. The prototyping plan should state the prototyping strategy for the following stages, and a plan for configuration management.
The functional model iteration phase is the first iterative and incremental phase. In every iteration, the contents and approach for the iteration are planned, the iteration gone through, and the results analyzed for further iterations. Both analysis and coding are done; prototypes are built, and the experiences gained from them are used in improving the analysis models. The prototypes are not to be entirely discarded, but gradually steered towards such quality that they can be included in the final system. A Functional Model is produced as an output, containing the prototype code and the analysis models. Testing is also a continuing, essential part of this phase.
There are four further outputs in the phase (at different stages in the phase).
Prioritized functions is a prioritized list of the functions that are delivered at the end of the iteration. Functional prototyping review documents collect the users' comments about the current increment, working as input for subsequent iterations. Non-functional requirements are listed, mainly to be dealt with in the next phase. Risk analysis of further development is an important document in the functional model iteration phase, because from the next phase (design and build iteration) onwards, encountered problems will be more difficult to address.
The design and build iteration is where the system is mainly built. The output is a Tested System that fulfils at least the minimum agreed set of requirements. Design and build are iterative, and the design and functional prototypes are reviewed by the users, and further development is based on the users' comments.
The final implementation phase is where the system is transferred from the development environment into the actual production environment. Training is given to users, and the system handed over to them. If the roll-out concerns a wide number of users, and done over a period of time, the implementation phase may also be iterated. Apart from the delivered system, the output of the implementation phase also includes a User Manual, and a Project Review Report. The latter summarizes the outcome of the project, and based on the results, the course of further development is set. DSDM defines four possible courses of development. If the system fulfils all requirements, no further work is needed. On the other hand, if a substantial amount of requirements have to be left aside (for example, if they were not discovered until the system was in development), the process may be run through again, from start to finish. If some less-critical functionality has to be omitted, the process may be run again from the functional model iteration phase onwards. Lastly, if some technical issues can not be addressed due to time constraints, they may be now done by iterating again, starting from the design and build iteration phase.
Other Methodologies (which are not discussed in this paper)
- Crystal family of methodologies
- Feature driven development
Methods and Materials
Project management approaches
There are a number of approaches to managing project activities including agile, interactive, incremental, and phased approaches.
Regardless of the methodology employed, careful consideration must be given to the overall project objectives, timeline, and cost, as well as the roles and responsibilities of all participants and stakeholders.
The traditional approach
A traditional phased approach identifies a sequence of steps to be completed. In the "traditional approach", we can distinguish 5 components of a project (4 stages plus control) in the development of a project:
Typical development phases of a project
- Project initiation stage;
- Project planning or design stage;
- Project execution or production stage;
- Project monitoring and controlling systems;
- Project completion stage.
Not all the projects will visit every stage as projects can be terminated before they reach completion. Some projects do not follow a structured planning and/or monitoring stages. Some projects will go through steps 2, 3 and 4 multiple times.
Many industries use variations on these project stages. For example, when working on a brick and mortar design and construction, projects will typically progress through stages like Pre-Planning, Conceptual Design, Schematic Design, Design Development, Construction Drawings (or Contract Documents), and Construction Administration. In software development, this approach is often known as the waterfall model, i.e., one series of tasks after another in linear sequence. In software development many organizations have adapted the Rational Unified Process (RUP) to fit this methodology, although RUP does not require or explicitly recommend this practice. Waterfall development works well for small, well defined projects, but often fails in larger projects of undefined and ambiguous nature. The Cone of Uncertainty explains some of this as the planning made on the initial phase of the project suffers from a high degree of uncertainty. This becomes especially true as software development is often the realization of a new or novel product. In projects where requirements have not been finalized and can change, requirements management is used to develop an accurate and complete definition of the behavior of software that can serve as the basis for software development. While the terms may differ from industry to industry, the actual stages typically follow common steps to problem solving — "defining the problem, weighing options, choosing a path, implementation and evaluation."
Critical Chain Project Management
Critical Chain Project Management (CCPM) is a method of planning and managing projects that puts more emphasis on the resources (physical and human) needed in order to execute project tasks. It is an application of the Theory of Constraints (TOC) to projects. The goal is to increase the rate of throughput (or completion rates) of projects in an organization. Applying the first three of the five focusing steps of TOC, the system constraint for all projects is identified as are the resources. To exploit the constraint, tasks on the critical chain are given priority over all other activities. Finally, projects are planned and managed to ensure that the resources are ready when the critical chain tasks must start, subordinating all other resources to the critical chain.
Regardless of project type, the project plan should undergo Resource Leveling, and the longest sequence of resource-constrained tasks should be identified as the critical chain. In multi-project environments, resource leveling should be performed across projects. However, it is often enough to identify (or simply select) a single "drum" resource—a resource that acts as a constraint across projects—and stagger projects based on the availability of that single resource.
Planning and feedback loops in Extreme Programming (XP) with the time frames of the multiple loops.
Extreme Project Management
In critical studies of Project Management, it has been noted that several of these fundamentally PERT-based models are not well suited for the multi-project company environment of today. Most of them are aimed at very large-scale, one-time, non-routine projects, and nowadays all kinds of management are expressed in terms of projects.
Using complex models for "projects" (or rather "tasks") spanning a few weeks has been proven to cause unnecessary costs and low maneuverability in several cases. Instead, project management experts try to identify different "lightweight" models, such as Agile Project Management methods including Extreme Programming for software development and Scrum techniques.
The generalization of Extreme Programming to other kinds of projects is extreme project management, which may be used in combination with the process modeling and management principles of human interaction management.
Event chain methodology
Event chain methodology is another method that complements critical path method and critical chain project management methodologies.
Event chain methodology is an uncertainty modeling and schedule network analysis technique that is focused on identifying and managing events and event chains that affect project schedules. Event chain methodology helps to mitigate the negative impact of psychological heuristics and biases, as well as to allow for easy modeling of uncertainties in the project schedules. Event chain methodology is based on the following principles.
- Probabilistic moment of risk: An activity (task) in most real life processes is not a continuous uniform process. Tasks are affected by external events, which can occur at some point in the middle of the task.
- Event chains: Events can cause other events, which will create event chains. These event chains can significantly affect the course of the project. Quantitative analysis is used to determine a cumulative effect of these event chains on the project schedule.
- Critical events or event chains: The single events or the event chains that have the most potential to affect the projects are the "critical events" or "critical chains of events." They can be determined by the analysis.
- Project tracking with events: Even if a project is partially completed and data about the project duration, cost, and events occurred is available, it is still possible to refine information about future potential events and helps to forecast future project performance.
- Event chain visualization: Events and event chains can be visualized using event chain diagrams on a Gantt chart.
PRINCE2 is a structured approach to project management, released in 1996 as a generic project management method. It combined the original PROMPT methodology (which evolved into the PRINCE methodology) with IBM's MITP (managing the implementation of the total project) methodology. PRINCE2 provides a method for managing projects within a clearly defined framework. PRINCE2 describes procedures to coordinate people and activities in a project, how to design and supervise the project, and what to do if the project has to be adjusted if it does not develop as planned.
In the method, each process is specified with its key inputs and outputs and with specific goals and activities to be carried out. This allows for automatic control of any deviations from the plan. Divided into manageable stages, the method enables an efficient control of resources. On the basis of close monitoring, the project can be carried out in a controlled and organized way.
PRINCE2 provides a common language for all participants in the project. The various management roles and responsibilities involved in a project are fully described and are adaptable to suit the complexity of the project and skills of the organization.
Capability Maturity Model, predecessor of the CMMI Model
Also furthering the concept of project control is the incorporation of process-based management. This area has been driven by the use of Maturity models such as the CMMI (Capability Maturity Model Integration) and ISO/IEC15504 (SPICE - Software Process Improvement and Capability Estimation).
Agile Project Management approaches based on the principles of human interaction management are founded on a process view of human collaboration. This contrasts sharply with the traditional approach. In the agile software development or flexible product development approach, the project is seen as a series of relatively small tasks conceived and executed as the situation demands in an adaptive manner, rather than as a completely pre-planned process.
Looking at Agile Methodologies from Project Management Knowledge Areas view
According to the PMBOK, "The objectives of Project Risk Management are to increase the probability and impact of positive events and decrease the probability and impact of events adverse to the project." The framework of the agile software development process fosters these objectives by making risk management an intrinsic part of the project lifecycle. Continuously identifying, analyzing, monitoring, and responding to risk triggers and risk events are part of the agile team's iterative planning discussions, which is to say that risks are addressed by everybody all the time. Daily stand-ups, iteration planning meetings, release planning meetings, and retrospective and review meetings are all venues for risk management activities on an agile project.
Agile teams can perform these risk management activities either overtly or organically. Overt risk management on an agile team is clearly stated as such, and things are labeled as risks, mitigation, etc. Organic risk management is that which is intrinsic to the agile process, and risk management emerges out of iterative planning and review activities. Potential risks are instead labeled as "obstacles," "assumptions," or "concerns." In the following examples I'll cite both overt and organic techniques used by agile teams.
The goal of risk management planning in the PMBOK is to create a plan that describes how the team will do risk management during the course of the project. In an agile environment there is no need to create a formal risk management plan; the method of addressing risk is built into agile procedures. The only decision the team may need to make is whether to conduct risk management activities overtly or organically.
In traditional project environments, risk identification is conducted in meetings with only a subset of the team members, who use checklists, document reviews, assumption analysis, and various other information gathering techniques to identify project risks and record them in a risk register (what we commonly call a "spreadsheet"). In an agile environment, the whole team does this exercise on an iterative basis during planning meetings, recording results on whiteboards or flipcharts. If the agile team is managing risk overtly, then an agenda item for the team to identify and prioritize risks is included as part of the meeting, with the results influencing the work that is being planned for that iteration. If the agile team is managing risk organically, then potential risks are identified as part of the agenda items "What assumptions are we making?" and "What concerns do we have?". Risks continue to be identified daily as part of stand-up meetings, either as obstacles (organic) or new risks (overt).
Traditional projects use both quantitative analysis (assigning real numbers to the costs of safeguards and the amount of damage that can occur) and qualitative analysis (using judgment, intuition, and experience in determining risks and potential losses). Agile projects generally perform only qualitative analysis, agile's short development cycles and constant reviews making this feasible and effective. The end result in both cases is a prioritized list of risks to respond to and risks to watch. In an agile environment these emerge from the planning meetings and are posted in a highly visible fashion, as a constant reminder to the team.
Risk Response Planning
Developing options and actions to reduce threats and increase opportunities is performed in both traditional and agile environments. The key difference is that in an agile environment the entire team participates in developing options and actions to reduce threats, a task that is conducted with more frequency than is common in traditional plan-driven projects. Many agile teams doing overt risk management follow Tom DeMarco and Tim Lister's recommended category breakout as explained in their bookWaltzing with Bears": Avoid, Mitigate, Contain, or Evade.
Risk Monitoring and Controlling
Risk audits, variance/trend analysis, and technical performance measurements are conducted at the end of each agile iteration as part of the iteration review meeting. This meeting provides a forum for the team to review the burndown chart, team velocity, and any other types of metrics the team may be noting. Risk reassessment occurs during the agile iteration retrospective meeting, where previous risks or concerns are revisited as part of determining changes that need to be made going forward. And finally, risks are monitored on a daily basis by the use of highly visible information radiators, such as task boards and burndown charts, which show t
Cite This Dissertation
To export a reference to this article please select a referencing stye below: