Agile methodologies in_project_management

WHITE PAPER: AGILE METHODOLOGIES IN PROJECT MANAGEMENT

Agile Methodologies in Project Management
“Operations keeps the lights on, strategy provides a light at the end of the tunnel, but
project management is the train engine that moves the organization forward.” -Joy
Gumz

Abstract
In today's unpredictable markets, companies are feeling the squeeze to achieve more with
fewer resources in shorter periods of time. In addition to controlling operational costs, IT is
looking to increase the value of information to make the business more profitable. So,
necessity to complete and develop projects with changeable requirement ,short period of
time ,easily to manage risk , adaptability to changing market requirements has become
undeniable main principles for each organization ‘s approach .While traditional
methodologies or heavy weight with huge bulk of documentation and long term for
planning and designing significantly affects the speed of developing process and customer
satisfaction. Hence, using innovative methods for building project are important matter
which has introduced in the recent years. Light weight methodologies evolve to meet
changing technologies and new demands from users in dynamic business environment.
As a result, agile methodologies and practices emerged as an explicit attempt to more
formally embrace higher rates of requirements change.
Agile development methodologies claim to go a step further in overcoming the limitations
of traditional one and coping with high speed and high changes on relationships with
customers and responsiveness to changes of business processes.
This paper is an evaluation of the agile development methodologies. Furthermore, it
includes a discussion about the critical success factors of the agile methodologies, reasons
for its failure.A case-study gives a real-world success story.

Pravin K. Asar

Page 1

Introduction
A project is conventionally defined as a “temporary endeavor undertaken to create a
unique product or service” (Project Management Institute 2008). Alternatively, a project
can be thought of as a well-defined set of tasks that must all be completed in order to meet
the project's goals (Klastorin 2003). In a typical project, many tasks are performed
concurrently with each other. Another key feature of projects is the existence of
precedence relations between the tasks. These relations typically define constraints that
require one task to be completed before another starts.
The use of project management as a business process to deliver products and services goes
back a long time. Indeed, the building of the Egyptian pyramids is believed by many to have
been assisted by the use of simple project management principles. For much of the history
of project management, the predominant application type was engineering and
construction projects - for example, roads, bridges and skyscrapers. Another impressive
achievement is the organization of the Olympic Games using project management. This is
an example of an event project, where the project deadline is fixed and project deliverables
cannot be violated.
In today’s highly competitive and global business environment, businesses take up projects
to gain and retain competitive edge wherein project deliverables and schedules cannot be
well defined. This is mainly cause of changes in the business environments (most external
factors) and sometimes the internal factors to gain/retain competitive edge in a constantly
changing global marketplace. Figure 1 below summarizes the Porter’s Wheel of
Competitive Strategy formulation (Porter, 1998)

Figure 1: Porter’s Wheel of Competitive Strategy formulation
(Reference: Porter, Competitive Strategy: Techniques for Analyzing Industries and Competitors )

Pravin K. Asar

Page 2

In today’s high-tech world, Business relies heavily on IT and Software as a strategic tool for
success and survival. As a result many IT and Software projects are undertaken.
“Today IT is a major financial, operational, and organizational component of any
strategy”- Mische (2001)
Most of the IT projects succeed but many fail. Therapid information technology change is
not always a root cause the failure. The history of failure of information systems
development is well recorded. Literally billions of dollars have been wasted on such
projects that failed to deliver the intended deliverables. Primary cause of failure is not
always the failure to deliver the project deliverables, but the deliverables do not meet the
current needs of business. This is mainly cause of changes in the business environments
(most external factors) and sometimes the internal factors to gain/retain competitive edge
in a constantly changing global marketplace.
Why projects fail and how to align the project deliverables with ever changing goals of
business? This is a challenge all stakeholders and project manager face today.
Compared to many business processes, project management appears to be particularly
difficult, from both theoretical and practical perspectives. From a theoretical perspective,
the fundamental planning problem of resource constrained scheduling is highly intractable.
From a practical perspective, the two standard objectives in project management are
defined to be completion of the project on time and on budget. Many projects fail to meet
these two criteria, despite detailed planning and the use of modern project management
methods and tools, as most the times it difficult to define the exact requirements,
inaccurate estimates, lack of appropriate resources, etc.
Further as mentioned earlier, the failure rate of projects is higher in modern business
process management application projects than in traditional projects, due to less reliable
data and the more challenging characteristics such as changes in the core technologies,
customer’s expectations, business practices, regulatory laws and competition. Indeed, it
can be said that, despite its recent massive growth in use of IT and Software tools for
business process management, is a difficult to manage business process.
“The difference between failure and success is the difference between doing
something almost right and doing something right.” - Benjamin Franklin

Pravin K. Asar

Page 3

Five key concepts for effective project management stated by Benjamin Franklin (Phillips,
2006)are:
Deliver: Ideas are great but delivery is what projects are all about.
Manage Bureaucracy: Understand and, if possible, change the rules of your
environment. They determine the realm of potential outcomes and even likely
outcomes of your tasks and projects – even before you start planning.
Solve Easy Problems: Great results can happen in changing things that look small
and easy.
Ask for Favors: People overestimate the value of things they do for other people and
therefore feel superior and kinder towards people they’ve helped. Do People Favors:
Favors have a psychological effect on people and can build powerful bonds that go
beyond the politics of a project.
So what the business could to do something exactly right in the uncertain and ever
changing world? Does the answer lies in business agility?
Agility is a concept that incorporates the ideas of flexibility, balance, adaptability, and
coordination under one umbrella. In a business context, agility typically refers to the ability
of an organization to rapidly adapt to market and environmental changes in productive and
cost-effective ways.
Business agility can be defined as the ability of a business to adapt rapidly and cost
efficiently in response to changes in the business environment. Business agility can be
maintained by maintaining and adapting goods and services to meet customer demands,
adjusting to the changes in a business environment and taking advantage of human
resources.

PMBOK, SWEBOK and Evolution of Agile Project Management
According to the PMI, effective project management requires that the project teams be
versed in five areas of knowledge including;
1. Project management knowledge, consisting of the project life cycle, project
management process groups that cover processes for project initiation, planning,
executing, monitoring and control, and closing, and the nine knowledge areas
covering project integration, project scope, project time, project cost, project quality,
project human resource, project communication, project risk, and project
procurement.

Pravin K. Asar

Page 4

2. Application area knowledge, standards andregulations, where application areas
provide groups of projects that share important elements with the project
3. Project environment, or the cultural, political, and physical environments in which
the projects are planned and implemented
4. General management knowledge and skills as a base for building project
management skills
5. Interpersonal skills particularly in relation to effective communication, leadership,
motivation, influence, negotiation and conflict management, and problem solving.
Software Engineering Body of Knowledge (SWEBOK, 2004), provides a good framework to
software professionals to develop theknowledge to be used for software development
projects.
Waterfall model and its derivatives such as V-Shaped Model, W-Shaped Model of software
development in the early years (from 1970s until 1990s) was very rigor, mostly adapted
from traditional project management philosophy, not flexible enough to accept the changes,
and the methods used were very formal so it clearly presented that software development
had been become a very complicated process (Boehm, 2002).
At the same time the developers and customers have expected different criteria for a
particular IT and Software projects. Customers have expected software projects should
return high and fast profit with less effort (and hence less cost).The software developers
are usually looking for a successful achievement of larger number of projects in a shorter
time which meets an acceptable ROI. Besides, all businesses become more and more
dependent on IT(i.e. business pull against IT push) and IT/Softwaredevelopment and
deployment methodologies must align to business strategies. Because of high competition
that business faces with it, software customer’s needs change over the time and it requires
a change in the functionality and features of the software systems in use. In short business
drives IT for innovation, so in turn IT can steer business success.
No doubt PMBOK guide is a good framework and de facto standard but it is highly process
oriented approach. Traditional project management is mostly about meeting schedule and
cost, with not too much emphasis on meeting the desired outcome because of changing
environment (such requirements, baseline core technologies, changes in the business
processes, etc.). These are main reasons that made software developersto think of agility
concepts. Agile development process (lightweight methodologies) developed in the
mid1990s and bloomed under a non-profit organization the ‘Agile Alliance’ which was
formed in 2001. Agile Principles (Agile Manifesto, 2012) are:

Pravin K. Asar

Page 5


Table 1: Twelve Agile Principles as stated by Agile Manifesto
Twelve Agile Principles as stated by Agile Manifesto
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

Agile and adaptive approaches for linking people, projects and value(Declaration of
Interdependence, 2012) are:

Pravin K. Asar

Page 6

Table 2: Declaration of Interdependence

Declaration of Interdependence
We are a community of project leaders that are highly successful at delivering results. To achieve
these results:
We increase return on investment by making continuous flow of value our focus.
We deliver reliable results by engaging customers in frequent interactions and shared
ownership.
We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
We unleash creativity and innovation by recognizing that individuals are the ultimate source
of value, and creating an environment where they can make a difference.
We boost performance through group accountability for results and shared responsibility for
team effectiveness.
We improve effectiveness and reliability through situational specific strategies, processes and
practices.

Traditional Iron triangle, depicted in Figure 2, of project management consists of scope,
schedule and cost. In many cases, when scope changes (because of a reason such as scope
creep, false assumptions, etc.), schedule and cost varies; although project managers
attempts to lock down all three dimensions.
Agile methods are all about providing the maximum possible value and quality within the
constraints (scope, schedule and cost) of the project. Constraints are still the important
project parameters, but they not as much as the project’s ultimate goals or measure of
project’s success. Value is the primary goal and constraints may need to be adjusted as the
project moves forward to increase customer value.

Pravin K. Asar

Page 7


Figure 2: The Evolution to an Agile Triangle
Source: Agile Project Management: Creating Innovative Products, 2nd Edition, Jim
Highsmith, Addison-Wesley (2009)
The desired outcome is mostly achieved by Iterative project lifecycle model. Figure 4 and 5
below compare the traditional and agile/iterative project lifecycle models.

Figure 3: Traditional Project Lifecycle Model

Figure 4: Iterative/Agile Project Lifecycle Model
To achieve the Value, Quality and Constraints goals, Agile Project Management processes
must be established. Agile processes include three major attributes, they are:
Incremental and Evolutionary: allowing adaptation to both internal and external
events.
Modular and Lean: allowing components of the process to come and go depending
on specific needs if the participants and stake-holders.
Pravin K. Asar

Page 8

Time Based: built on iterative and concurrent work cycles, which contain feedback
loops and progress checkpoints.
To better adapt the changes within a project, a sound risk management (identification and
mitigation) is must. The primary reasons for software project failure is changes in the
requirements, rapid evolution of new-technologies (most of the time unproven) coupled
with product engineering and people issues.
In reference to the software project attributes, as defined by Software Engineering Institute
(SEI, Taxonomy-Based Risk Identification,2012), let us discuss Agile Project Methods.
Figure 1 describes how therisk attributes, as detailed in Table 1, are related tothe success
of the software project.

Figure 3: Interrelation between Project Management Activities and RBS
(Source: Agile Project Management Methods for IT Projects, Alleman, 2002)

Pravin K. Asar

Page 9

Table 3: Risk Breakdown Structure (RBS) for Software Development Projects
PRODUCT ENGINEERING

DEVELOPMENTENVIRONMENT

WORK ENVIRONMENT

1. Requirements
Stability
Completeness
Clarity
Validity
Feasibility
Precedent (business
rules)
Scale

1. Development Process
Formality
Suitability
Process Control
Familiarity
Product Control

1. Resources
Schedule
Staff
Budget
Facilities

2. Design
Functionality
Difficulty
Interfaces
Performance
Testability
Hardware
Constraints
Non-Developmental
Software
3. Code and Unit Test
Feasibility
Testing
Coding
Implementation
4. Integration and Test
Environment
Product
System
5. Engineering Specialties
Maintainability
Reliability
Safety
Security
Human Factors
Specifications

Pravin K. Asar

2. Development System
Capacity
Suitability
Usability
Familiarity
Reliability
System Support
Deliverability
3. Management Process
Planning
Project Organization
Management Experience
Program Interfaces

2. Contract
Type of Contract
Restrictions
Dependencies
3. Program Interfaces
Customer
Associate
Contractors
Subcontractors
Prime Contractor
Corporate
Management
Vendors
Politics

4. Management Methods
Monitoring
Personnel
Management
Quality Assurance
Configuration Management
5. Quality Environment
Quality Attitude
Cooperation
Communication
Morale

Page 10

By the virtue of domain knowledge gained over the period of time, software engineering
has matured and can be adapted to develop solutions for almost types of businesses and
large spectrum of project sizes.With the focus on the communication and people–centric
aspects of project management, along with the product engineering aspects, chances of
success greatly increase. The agile approach brings in a these concepts to the table.
Agile approach is very focused on people, interactive, communication between project
team and customers, pair programming of software development, prototype enhancement,
less documentation and welcoming to suitable system change requirements. In this
approach, the software system is implemented through several iterations and each
iteration or cycle adds some value to its final outcome or product. Each cycle consists of the
same activities such as requirement gathering, analyzing the system design and
development, testing and managing to collect feedback from the customers’ side
satisfaction. In this way, customers will be able to view the features of the system or
software at any time instead of waiting for it until the final product is released by the
development team. This helps the project team to cope up with the primary risk factors;
high number of user requirement and frequent changes to technology; without having to
worry about meeting a great cost at a later stage.
Qumer and Henderson-Sellers (2008) summarize the agile software development
approach as:
“A software development method is said to be an agile software development
method when a method is people focused, communications-oriented, flexible(ready
to adapt to expected or unexpected change at any time), speedy (encourages rapid
and iterative development of the product in small releases), lean (focuses on
shortening timeframe and cost and on improved quality), responsive(reacts
appropriately to expected and unexpected changes), and learning (focuses on
improvement during and after product development)”.
The authors also believe that the agile method means
“Deliver quickly, Change quickly, Change often”.

Pravin K. Asar

Page 11

Highsmith& Cockburn (2001) and Abrahamsson (2002) have identified agile methods.
1. Adaptive Software Development
2. Dynamic Systems Development method
3. Crystal methods
4. Rational Unified Process
5. Extreme Programming
6. Scrum
7. Pragmatic Programming
8. Internet Speed Development
9. Agile Modeling
10. Feature Driven Development
11. Open Source Software Development
12. Lean Development
The five agile methods which are more popular in software industry are summarized in
Table 4 using three selected aspects: key points, special features and identified weakness.
Key points detail the methods, principles, aspects or solution. Special feature describes one
or several aspects of the methods that differentiate them from others. Finally, identified
weakness relate to some aspects of a method that have been documented.

Pravin K. Asar

Page 12

Table 4: General Features and Comparison of Agile Software Methodologies
Method

Key Points

Special features

Identifiedweakness

Adaptive
Software
Development
(ASD)

Adaptive
culture,
collaboration,
mission-driven
componentbased
iterative
development

Organizations are
seen as adaptive
systems. Creating
anemergent order
out of aweb of
interconnected
individuals

ASD is more about
conceptsand culture than
the software
Practice

Dynamic
Systems
Development
Methods
(DSDM)

Applicationof
controls toRAD,
use oftimeboxing and
empowered
DSDMteams.

First truly agile
software
development
method,use of
prototyping, several
user roles :
“ambassador”,
“visionary” and
“advisor”

While the method is
available,
onlyconsortiummembers
have accesstowhite
papers dealingwith the
actual use of the method

Extreme
Programming
(XP)

Customer
driven
development,
small
teams, daily
builds

Refactoring- the
ongoing redesign of
the systemto
improve its
performance and
responsiveness too
change

While individual practices
are suitable for many
situations, overall view &
management practices are
given
less attention

SCRUM

Independen
t, small,selfOrganizing
developme
nt teams,
30-day
release
cycle
Five-step
process, objectorientedcompo
nents(feature
based
development).

Enforce a paradigm
shiftfrom the “defined
and repeatable” to the
“new product
development view of
Scrum”

While Scrum details
inspecific howto manage
the30-day release cycle,
the integrationand
acceptancetests are not
detailed

Method simplicity,
design and
implement
thesystem by
features, object
modeling

FDD focuses only
on design and
implementation.
Needs other
supporting
approaches.

Feature
Driven
Development
(FDD)

Pravin K. Asar

Page 13

Different methods represent different ways of implementing agile projects, but all are
similar in implementing agile principles and roles. Agile methods were designed to expect
and plan for requirements change, which reduces scheduling, cost and other project failure
risks associated with plan-driven methods.
Main characteristics of any agile methodologies (Awad, 2005) can be summarized as:
People Oriented- Agile methodologies consider people – customers, developers,
stakeholders, and end users
Adaptive – The participants in an agile process are not afraid of change. Agilest
welcome changes at all stages of the project.
Conformance to Actual – Each iteration or development cycle adds business value to
the ongoing product.
Balancing Flexibility and Planning – For agile design is that designers need to think
about how they can avoid irreversibility in their decisions. Rather than trying to get
the right decision now, look for a way to either put off the decision until later or
make the decision in such a way that you will be able to reverse it later on without
too much difficulty.
Empirical Process – Agile methods develop software as an empirical (or nonlinear)
process.
Decentralized Approach – Agile software development spreads out the decision
making to the developers.
Simplicity – Agile teams always take the simplest path that is consistent with their
goals. The reason for simplicity is so that it will be easy to change the design if
needed on a later date.
Collaboration – Agile methods involve customer feedback on a regular and frequent
basis. As well, constant collaboration between agile team members is essential.
Small Self-organizing teams – An agile team is a self-organizing team.
Responsibilities are communicated to the team as a whole, and the team determines
the best way to fulfill them
Several studies have shown that most of the software projects that have used agile have
met success with very little delay, failure, rejection, or ongoing expensive maintenance
(Chow and Cao, 2008). The use of agile on the industry depends on the type of
project(Hansson, 2006), project’s requirement, and also depends on the characteristics of
the company/business itself.

Pravin K. Asar

Page 14

Success Factors for Agile Methodology
The agile methodology yields wonderful results that change the overall view of the
software development process.
Chow and Cao (2008) studied the success factors that affect theagile methods and may lead
agile software development houses to be successful.Most of the factors are a result of
experiences provided from previous projects. Obviously software projects are not just a
technical concern; many other subjects should come into the picture such as the
organizational, business scope, management, people and so on. Also the attributes of the
quality, cost, time and scope of project we considered, as these the most effective attributes
that can lead us to the success or failure of implementing agile methodology.
Their study builds on a web-based survey of more than 100 companies that use agile
methods in 25 countries around the world. The focus was on the outcomes of good
implementation which granted of agile methods, where software project was rejected,
failed, overrun or delayed. This is actually what agile is intend to solve.
They concluded that most success factors can be grouping into five main categories namely
People, Organization, Project, Process and Technical factors as summarized in Table 5.

Pravin K. Asar

Page 15

Table 5: Agile Critical Success Factors(Chow and Cao, 2008)
Category

Factor Breakdown

Organizational

Strong executive support
Committed sponsor or manager
Cooperative organizational culture (instead of hierarchal)
Oral culture placing high value on face-to-face communication
Organizations where agile methodology is universally accepted Reward
system appropriate for agile
Facility with proper agile-style work environment
Collocation of the whole team

People
(Employee &
Customer)

Team members with high competence and expertise
Team members with great motivation
Managers knowledgeable in agile process
Managers who have light-touch or adaptive management style
Coherent, self-organizing teamwork
Good customer relationship

Process

Following agile-oriented requirement management process
Following agile-oriented project management process
Following agile-oriented configuration management process
Strong communication focus with daily face-to-face meetings
Honoring regular working schedule – no overtime
Strong customer commitment and presence
Customer having full authority

Technical

Well-defined coding standards up front
Pursuing simple design
Rigorous refactoring activities
Right amount of documentation
Regular delivery of software
Delivering most important features first
Correct integration testing
Appropriate technical training to team

Project

Project nature being non-life-critical
Project type being of variable scope with emergent requirement
Projects with dynamic, accelerated schedule
Projects with small team
Projects with no multiple independent teams
Projects with up-front cost evaluation done
Projects with up-front risk analysis done

Pravin K. Asar

Page 16

As we see in Table 5each category represents one point of view. Let us discuss these in
detail.

Organization Factors
Agile is a cultural issue. One of the main challenges most organization face is creating the
agile culture. This means that the nature of organization is very important here. For
example, agile is not appropriate in bureaucratic organizations. This meant that a dynamic
and fast changing organization will find agile methods very suitable for it. Agile is more
attitude than process. Emphasis is on team building high performance team to get the
desired results. Organization factors can be broken down as:
Teams' Distribution: One of the main aims of any organization is to maximize
utilization of their employee. To accomplish this task manager must have
appropriate skills to but the right employee his right place.
Commitment: The organization must deliver the final product on time without any
delay. This requires that organization must bring an initial version early which
allows the organization to get feedback early from the customer.
Creating Collaborative Culture: One of the main tasks of any organization follows
agile methodologies in its process of development is to create an excellent
collaborative culture. This requires that the organization has to follow some
procedures while accomplishing its task. To complete this task the characteristics of
employees play an important role.

People (Employee and Customer) Factor
Employee Factor
The success of a software development project is often related to people factors. In agile
methodologies, software is done "of the people, by the people, and for the people".
Organization of people, their interaction, and task reception is critical in agile
methodologies. Authors think that organization of people and their interaction is the main
factor for the success or failure of agile methodologies. In normal situation agile teams are
small (no longer than 10 people). In agile methodologies the center of attention of the team
is shifts from the tools and technology to people interaction and collaboration concerning
project.
Pravin K. Asar

Page 17

Employee Characteristics and Culture: The culture of employees and their personal
characteristics are an important role in creating a collaborative environment. It is
known that the nature of persons is difficult to change. If the organization has a lot
of employees who are not collaborative in their natures or they tend to perform
their tasks individually as they are selfish or don't like others to share them their
success. Organization must follow a policy which excludes those employees and
replaces them with others who like working as a team.
Employee Competence: Working as a team doesn't mean omitting competence. The
organization policy must encourage positive competence between employees. As an
example organization intensives can be done according to the degree of
collaboration. When the level of collaboration and communication between
employees increases the intensives will increase. In summary If the people on the
project are good enough, its means that any process will be accomplished on time. If
they are not good enough, no process will repair their inadequacy.
Training: When a new member joins the employees' team he has to work with
different partners in different locations or positions according to his qualifications.
This will give an idea about how work is done and enhance their experience. It must
be noted here that agile methodologies in it nature represent a continuous training
for all employees since their partners are always changed which means you have the
opportunity to learn from another partner.
Communication between Employees: No doubt that if employees deal with each
other without any reservations relating to exchanging their knowledge this will be
reflected on the productivity of the organization.

Customer Factor
One of the main success factors of agile methodologies is customer collaboration. Author's
opinion here is that customer collaboration and high skilled agile team equal working
software. The idea here is if you want to conduct customer satisfaction you have to work
with educated customer who knows exactly what he want. This required that the
customers are available with the software development team. Also the customers must
consider themselves a responsible element in the project that can cause success or failure.
Customer Education: Authors mean by customer education that the person
or the group of people who will deal with the organization team members who are working on producing the customer product - must have an
acceptable level of education which enables them to explain their
requirements and needs in a clear form. It’s highly recommended (if
Pravin K. Asar

Page 18

possible) those people have an information technology background or have
the necessary basic information about information technology (IT).
Knowledge of the Problem: People who are selected to work with
organization team members must know exactly what the problem in their
organization is. Their clear knowledge of the problem can shorten the
development time in producing the product.
Knowledge about Constraints and Limitations: Information Technology
specialist known that there is always constraints and limitation for every
product. Author's recommended that the person or group of people who will
deal with organization team members has some basic knowledge about
constraints in hardware and software world. This will help producers to
justify their selection of any specific hardware or software.
Experience in Business Domain: According to the authors they recommend
that customers should have basic knowledge about business domain. This
knowledge makes them realistic to identify their requirements specifically
which help to deal easily.

Process Factors
Project management process (Planning, Execution, Control, Monitor and Closing)
Planning is a psychological methodology of thinking about the tasks required to
create a desired goal. Planning is the main factor of success for any project. Also it
includes scheduling, identifying team members and leaders. Planning must be
prepared after careful and extensive research.
Execution: The execution process should be realistic and specific for a project
domain. Careful consideration and balance is needed, to yield desired results with
lots of rework, building on the success /completion of dependent milestones.
Control means using devices or a group of devices to manage, direct or regulate the
behavior of overall system. The function of control is finding the errors and
correcting them.
Monitor means setting standards, measuring actual performance and taking
corrective action. Monitoring means using a collection of information as a project
progresses. The main aim of monitoring is to improve efficiency and effectiveness of
a project. Monitoring based on targets and activities planned during the planning
Pravin K. Asar

Page 19

phase. Monitoring allows managers to keep track on progresses and provide a
useful base for evaluation.
Adapt and Close: Agile methods believe in phased and incremental delivery. So
before closing each phase of development, review (accomplishments, shortcomings, lessons learned) is recommended. This provides an invaluable feedback to
all (customer, stakeholders and team), and generally used for planning the next
phase of project deliverables (and also deciding the strategy to tackle technical
debut; a shortcoming and incomplete tasks for earlier phases).

Technical factors
Technical factors focus on the technical and procedural issues of the development process
(for instance: software design, coding, testing etc.). By implementing agility, the
developments team will not lose time and effort to produce a complex design. They put
what is necessary from the requirements into their software in a simple form.
Furthermore, more standardized structures will apply on the development process such as
code standards and quality standards. However, the technical issue will focus more on the
delivery strategies of the final product (Chow and Cao, 2008).

Project Factors
Project’s factors take us back to the environmental and the management viewpoints. The
nature (project domain) and size of the work (project scope) is very important and it will
affect the whole development process. It also includes the team response for the
requirement changes factor and the culture of working in small teams. Project factors are
strongly interrelated with other factors such as the organizational factors and people
factors.
That means project should
Support an envision, explore, adapt culture
Support self-organizing, self-disciplined teams
Promote reliability and consistency to the extent possible given thelevel of project
uncertainty
Be flexible and easy to adapt
Support visibility into the process
Pravin K. Asar

Page 20

Incorporate learning
Incorporate practices that support each project phase
Provide management checkpoints for review
Based on this discussion, we can say, most of these factors are interrelated to each other.
For instance, the organizational factor, for example, affects the people and the project
factors directly. Moreover, the improvement of the project needs improvement in the
people (customer and employee) and organization. In a contrary manner, these factors are
depending on the type of project, nature of business, organization structure and
collaborative culture. Figure 6 attempts to represent the interplay of these factors. This is
essentially a framework for successful agile method.

Figure 4: Theoretical Framework for Successful Agile Method

Pravin K. Asar

Page 21

Following the agile methods does not assure success all the time. Turk and Rump (2002),
have documented the some of the limitations of agile methods.
1. Lack of structure and necessary documentation
Many agile methods are highly prescriptive of essential practices and have
structure, though much of it is informal.
Define necessary. Much documentation required by plan-driven methods is
not used and/or hopelessly out of date. Agility focuses on producing those
deliverables that are actually needed.
2. Only works with senior-level developers
Works best with developers who can work independently (or in pairs).
A mix of senior/junior developers works just fine.
3. Incorporates insufficient software design
Incremental design with aggressive refactoring can lead to better design because
much of the design is done with better understanding of the application.
A valid criticism might be that agile implementers may be afraid to do any design
up front for fear of not being "agile" -- none of the methodologists would
recommend entirely skipping up front design.
4. Requires too much cultural change to adopt
Can be valid, but in my opinion it is worth it
5. Can lead to more difficult contractual negotiations
Definitely. This should change as more agile successes are achieved.
6. Can be very inefficient:
If the requirements for one area of code change through various iterations, the
same programming may need to be done several times over. If a plan were in
place to follow, a single area of code is expected to be written once.
Only if the plan is rigidly adhered to at the expense of actual desired
behavior, otherwise you have the same problem.
If changes do occur, agile methods handle this better than plan-driven
methods.
7. Impossible to develop realistic estimates of work effort needed to provide a quote,
because at the beginning of the project no one knows the entire
scope/requirements.
Most agile methods give you good tools to understand your velocity.
Planning is hard for all methods. This is not unique to agile methods.

Pravin K. Asar

Page 22

Agile methods, by putting software in the customer's hands early discover the
real requirements faster than rigorous, up-front planning because the customer
doesn't know what he really wants until he sees it.
8. Can increase the risk of scope creep due to the lack of detailed requirements
documentation.
Agile takes a completely different perspective to this. It focuses on scope/time
trade-offs rather than limiting scope to keep fixed time.
Customers get to make choices about the scope/time trade-off in Agile, so they
are in complete control of scope.
9. Agile is feature driven, non-functional quality attributes are hard to be placed as
user stories.
You can use whatever method you want to track quality attributes, including
traditional methods from plan-driven practices if you want.

Case Study: Microsoft’s TeamArch (West et al, 2009)
Microsoft’s TeamArch, which is responsible for the Visual Studio Team System 2010
Architect product, faced multiple challenges that interfered with its ability to rapidly
deliver a plug-in tool with the right capabilities. Some of the challenges included fuzzy
requirements, a large development organization, and widely varied target customers.
Consequently, the team responds those challenges by transforming the method it worked,
also introducing tighter customer relationships, plus agile development practices, and
more-transparent stakeholder communication. These changes, coupled with focus on
delivery, enabled the team to challenge the status quo, delivering faster and with higher
quality. In addition, the team’s practices have relevance in other technology contexts, and
many application development professionals can apply the lessons Microsoft learned
(West, 2009).
Subsequently by adopting Agile practices team focused on delivering features and
managing quality furthermore, particularly attention on understanding project’s scope and
mitigate risk .In that the team include the customer review rather than a group of
representative users which again is another advantage side of agile methodologies that
provide rapid validated customer feedback.

Pravin K. Asar

Page 23

Accordingly, introducing an agile development process revamps the Microsoft’s
TeamArch‘s experience of development process in term of what customer tries to achieve
and solutions which team delivers. In brief, productivity of team has improved, the quality
of applications was better and eventually better business satisfaction with the software
have been experienced by Microsoft‘s TeamArch team.

Scalability of Agile Methodologies
Can agile principles and methods be combined with conventional project management
framework to deliver the products and services other than just software?
Agile Methodology principles include valuing individuals and interactions over processes
and tools, working software over comprehensive documentation, customer collaboration
over contract negotiation, and responding to change over following a plan. These principles
are widely applicable to other domains.
Agile project planning is especially useful for nondeterministic projects, i.e. those where the
final configuration of the product or service being developed is not known at the start of
the execution stage and only reveals itself as a result of subsequent developments.
Examples of nondeterministic projects include NASA’s space program, research and
development, software development, and pharmaceutical drug development. There are
many well documented success stories for agile methodology in projects involving small
project teams (Objectmentor.com 2012).
However, the implementation of agile methods for large projects is more problematic. A
generic idea, forming teams of teams, has been tested but not extensively researched.
An important issue, therefore, is to what extent it is possible to model and evaluate the
scalability of agile project management methodology to traditional (heavyweight)
methodology. Such models would necessarily include both economic and behavioral
components, because of the importance that agile methodology places on interactions and
communications. An interesting potential extension would be to develop a model that could
be used, for a given project management application, to inform a choice between traditional
project management and agile methodology (Awad, 2005). The dynamic, synergistic
aspects of agile methodology would need to be included in such a model.
The key differences and discriminators in agile and heavyweight methods are summarized
in Table 6 and 7.

Pravin K. Asar

Page 24


Table 6 : Difference in Agile and Heavyweight Methodologies (Awad,2005)
Approach
Success Measurement
Project size
Management Style
Perspective to Change

Agile
Adaptive
Business Value
Small
Decentralized
Change Adaptability

Heavy
Predictive
Conformation to plan
Large
Autocratic
Change Sustainability

Culture
Documentation
Emphasis
Cycles
Domain

Leadership-Collaboration
Low
People-Oriented
Numerous
Unpredictable/Exploratory

Command-Control
Heavy
Process-Oriented
Limited
Predictable

Upfront Planning
Return on Investment

Minimal
Early in Project

Comprehensive
End of Project

Team Size

Small/Creative

Large

Table 7: Agile and Heavyweight Discriminators (Awad, 2005)
Project Characteristics

Agile discriminator

Heavyweight Discriminator

Primary objective
Requirements

Rapid Value
Largely emergent, rapid change,
unknown
Smaller teams and projects
Designed for current
requirements
Internalized plans, qualitative
control
Dedicated, knowledgeable,
collaborated, collocated onsite
customers
Agile, knowledgeable, collocated,
and collaborative

High Assurance
Knowable early, largely
stable
Larger teams and projects
Designed for current and
foreseeable requirements
Documented plans,
quantitative control
As needed customer
interactions, focused on
contract provisions
Plan-oriented; adequate
skills access to external
knowledge
Expensive
Well understood risks,
Minor impact

Size
Architecture
Planning and Control
Customers
Developers
Refactoring
Risks

Pravin K. Asar

Inexpensive
Unknown risks, Major Impact

Page 25

Agile Practitioner’s Opinions and Experience
“At a certain point, waterfall project development models force us to stop becoming
smarter” - JesperRonn-Jensen (Capgemini Ruby on Rails pioneer)
“Agility is not an intrinsic property of software or methodology and cannot be
supplied through these. Only agile-thinking management and employees will make a
business more agile.” - Max Pucher(Articlebase.com, 2007, Why SOA does not
deliver)
“While it appears that there have been many software development project
successes based on agile processes, so far most of these success stories are only
anecdotal. Empirical data comparing the effectiveness and limitations of agile and
non-agile approaches would greatly enhance our understanding of the true benefits
and limitations of agile processes.” - Turk D., France R., Rump (2002)
“When one of the agile methodologies is adapted by an organization, it changes may
impact several aspects of the organization including its structure, culture, and
management practices. Therefore, understanding organization wide ramifications of
a change phenomenon is a critical first step in planning and managing such changes”
- S. Nerur, R. Mahapatra, and G. Mangalaraj (2005)
“Software development methodologies are constantly evolving due to changing
technologies and new demands from users. Today’s dynamic business environment
has given rise to emergent organizations that continuously adapt their structures,
strategies, and policies to suit the new environment.” - Truex, D.P., Baskerville, R.
and Klein (1999)
“Increasingly companies are reporting large productivity gains and increased
business satisfaction with the system development using these approaches.” Griffiths M. (2004)

Real-world Application of Agile Methodologies
Emphasis of Agile methods is on delivering quality to customer, by looking at the project
from all angles (customers, employees, technical, process) in addition to project
management and control.

Pravin K. Asar

Page 26

West and Grant (2010) present a detailed study on how Adaption of Agile is changing the
entire organization. Author’s states
“Agile adoption is a reality. Organizations across all industries are increasingly
adopting agile principles, and software engineers and other project team members
are picking up agile techniques. While historically, management has owned
“process,” the adoption of agile methods has pushed ownership into the hands of
team members — many of whom have traditionally been skeptical of process and
methodology. Broad Agile adoption requires careful consideration”

Christopher (2000) discusses the importance of agile supply chain for competing in volatile
Markets. He concludes,
“Marketing management has not traditionally recognized the importance of logistics
and supply chain management as a key element in gaining advantage in the
marketplace. However, in today’s more challenging business environment, where
volatility and unpredictable demand becomes the norm, it is essential that the
importance of agility be recognized. Leading companies are already implementing
marketing strategies which are underpinned by a supply chain strategy designed
with agility in mind. These are the organizations that will be best equipped for
survival in the uncertain markets of the 21st century.
Cass (2012) discusses the need and advantages of agile marketing. He quotes
“The practice of agile marketing is still new, and it has dependencies different from
those of agile development. Though developers are dependent only on themselves
to complete projects, marketers often have to depend on vendors, agencies, and
developers to complete a project.”
Willeke (2011) discusses the challenges and strategies of applying agile methodology in an
academic environment. Cultural implications and quantitative results are discussed, also
provides insights for non-software industries on how agile is not a set of rules with rigid
tools; rather, it is a philosophy with a need to understand the intent of the tools in order to
identify the appropriate application for not just effective results, but maximally effective
results with a mindset for continued change.

PMI and Agile Methodology
Fewell (2009) presented the initiates by PMI community to adapt agile principles and
philosophy. Itis the effort to build an agile community within PMI is based on the hope that
it can change the world. With it wide-spread presence (over a half-million constituents) in
Pravin K. Asar

Page 27

all business sectors, PMI could be the best channel to extend the reach of agile values and
principles.
The PMI agile component is be the first impression of Agile for the vast majority of PMI’s
members, we knew that we had to set a compelling example of how Agile can deliver
business results and provide job satisfaction. Efforts are based on a passion to address the
problems/issues of daily office life that we all experience; hence a focus is on operating
practices, while recognizing the imperfections along the way. Although, this story is
incomplete, PMI is continuing to find ways to improve, ways to better reflect the agile way
and strive to “manifest Agility”.

Closing Remarks
Definitely, while verity of agile methodologies currently available, finding the most suitable
methodology that addresses the organization’s development environments needs is
extremely imperative on the agile principles and techniques.
At last but not least, it should not be ignored that a key success factor for a successful
company is an effective and efficient alignment of the way IT is supporting business
strategies and processes. Besides, as more organizations seek to gain competitive
advantage through timely, for example deployment of Internet-based services, developers
are under increasing pressure to produce new or enhanced implementations quickly.
Although, whenever a new technology is used, the early adopters are usually higher
motivated (no one like failure) so this alone may make agile projects more successful than
traditional projects.
Agile principles are being adapted in mainstream business because of the benefits,
improved quality, joint ownership of products and projects shared by all organizations.
Ultimate result is organization moves forward by embracing the changes
“Effective leaders help others to understand the necessity of change and to accept a
common vision of the desired outcome.” - John Kotter
To end our discussion, I would like to say
“Irrespective of the size of project, do it right?Meet or exceed the customer requirements.
Business will thieve.”
A task well done pays in long run.
Pravin K. Asar

Page 28

References

Abrahamsson, P., 2002, “Commitment Nets in Software Process Improvement”, Annals of
Software Engineering, Vol. 14, Numbers 1-4 (December 2002), 407-438
Agile Manifesto, Retrieved on July 1, 2012, http://www.agileAlliance.org
Alleman, Glen, Agile Project Management Methods for IT Projects, 2002, Retrieved on June
29, 2012
http://www.niwotridge.com/PDFs/PM%20Chapter%20(short%20no%20email)%20Upd
ate%202.pdf
Awad, M.A, “A Comparison between Agile and Traditional Software Development
Methodologies”, School of Computer Science and software Engineering, The University of
Western Australia, 2005, Retrieved on June 30, 2012,
http://pds10.egloos.com/pds/200808/13/85/A_comparision_between_Agile_and_Traditio
nal_SW_development_methodologies.pdf
Beck, Kent, Extreme Programming Explained: Embrace Change, Addison-Wesley, Pearson
Education, 1999
Boehm, B., “Getting Ready for Agile Methods, With Care”, IEEE Computer Society, 2002,
Retrieved on July 1, 2012,
http://sunset.usc.edu/events/2002/arr/Get%20Ready%20for%20Agiel%20Methods,%20
with%20Care.pdf
Cass, John, “What Is Agile Marketing, and Why Is It Essential to Marketing Operations?”
2012, Retrieved on July 15, 2012,
http://www.marketingprofs.com/articles/2012/7963/what-is-agile-marketing-and-whyis-it-essential-to-marketing-operations#ixzz20o7GEyDt
Chow, T and Cao, D, “A Survey Study of Critical Success Factors in Agile software Projects”,
Journal of Systems and Software archive; Vol. 81 Issue 6, June, 2008
Christopher M, “The Agile Supply Chain: Competing in Volatile Markets”, Industrial
Marketing Management , Vol. 29, No. 1, 2000, Retrieved on July 14, 2012 , http://martinchristopher.info/wp-content/uploads/2009/12/agile_supply_chain.pdf
Declaration of Interdependence, Retrieved on July 3, 2012, http://pmdoi.org
Fewell, J., "Growing PMI Using Agile", Agile Conference, AGILE '09. , 356-360, Retrieved on
July 15, 2012,
Pravin K. Asar

Page 29

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5261057&contentType
=Conference+Publications&refinements%3D4292539653%26sortType%3Dasc_p_Sequen
ce%26filter%3DAND%28p_IS_Number%3A5261036%29
Highsmith, Jim, Agile Project Management: Creating Innovative Products, 2nd Edition,
Addison-Wesley, 2009
Highsmith J., Cockburn A., 2001, “Agile software development: The business of innovation”,
IEEE Computer, Vol. 34, Issue: 9, 2001, 120-127
Klastorin Ted, Project Management: Tools and Trade-offs, Wiley, 2003
Mische, Michael, Strategic Renewal: Becoming a High-Performance Organization, Prentice
Hall, 2001
Nerur S, Mahapatra R.K., Mangalaraj G, “Challenges of Migrating to Agile Methodologies”,
Communications of the ACM - Adaptive complex enterprises, Vol. 48, Issue 5, May 2005,
Pages 72 – 78, Retrieved on July 2, 2012, http://dl.acm.org/citation.cfm?id=1060712
Phillips, Mark, “Five Project Management Keys from Benjamin Franklin”, Vertabase.com,
2006, retrieved on June 30, 2012, http://www.vertabase.com/blog/five-projectmanagement-keys-from-benjamin-franklin/
Project Management Institute, A guide to Project Management Body of Knowledge (PMBOK
Guide), Fourth Edition, 2008
Porter, M., Competitive Strategy: Techniques for Analyzing Industries and Competitors,
Free Press, 1st edition, 1998
Objectmentor.com, Agile/XP Solutions, 2006, Retrievedon July 10, 2012,
http://objectmentor.com/omSolutions/agile_intro.html
Qumer, A and Henderson-Sellers, B. “An Evaluation of the Degree of Agility in Six Agile
Methods and its Applicability for Method Engineering”, Journal Information and Software
Technology archive, Vol. 50 Issue 4, March, 2008
Software Engineering Body of Knowledge (SWEBOK), 2004, Retrieved on July 2, 2012,
http://www.computer.org/portal/web/swebok
West, D, Gilpin, M and D'Silva, D, “Case Study: Microsoft Speeds Tool Delivery with Agile
Development”, Forrester, 2009, Retrieved on July 10, 2012
http://www.forrester.com/Case+Study+Microsoft+Speeds+Tool+Delivery+With+Agile
+Development/fulltext/-/E-RES54034?docid=54034&src=56100pdf
Pravin K. Asar

Page 30

Turk D., Rump F., 2002, “Limitations of Agile Software Processes”, Retrieved on July 5,
2012, http://www4.in.tum.de/publ/papers/XP02.Limitations.pdf
Turk D., Rump F., “Agile Software Processes: Principles, Assumptions and Limitations”
Technical Report. Colorado State University, 2003, Retrievedon July 12, 2012,
http://www.cs.colostate.edu/~france/publications/AgileSE-draft.pdf
Truex, D.P., Baskerville, R. and Klein, H. “Growing systems in emergent Organizations”
Communications of the ACM, Vol. 42 Issue 8, 1999, Pages 117 – 123, Retrieved on July 10,
2012, http://dl.acm.org/citation.cfm?id=310984
West D., Grant T., “Agile Development: Mainstream Adoption Has Changed Agility”, 2010,
Retrieved on July 12, 2012
http://pmshow2012.programmedevelopment.com/public/uploads/files/forrester_agile_d
evelopment_mainstream_adoption_has_changed_agility.pdf
Willeke, M.H.H., "Agile in Academics: Applying Agile to Instructional Design," Agile
Conference AGILE 2011, 246-251, 2011, Retrieved on July 14, 2012,
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6005511&isnumber=60054
85

Pravin K. Asar

Page 31

Agile methodologies in_project_management

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Agile methodologies in_project_management

Ähnlich wie Agile methodologies in_project_management (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Agile methodologies in_project_management