Polytechnic University of the Philippines

PUP Open University System

Anonas St., Sta. Mesa Manila

CM 651 Project Management

WRITTEN REPORT NO. 1

AGILE PROJECT MANAGEMENT

Submitted by:

TONIO, LOWIE JAY T.

Submitted to:

DR. MANUEL M. MUHI

January 2018

0
 TABLE OF CONTENTS

INTRODUCTION ......................................................................................................................................................... 2

OBJECTIVES ................................................................................................................................................................. 2
WHAT IS AGILE PROJECT MANAGEMENT ........................................................................................................ 3

TRADITIONAL PROJECT MANAGEMENT AND AGILE PROJECT MANAGEMENT ................................. 4

The Waterfall Methodology – Traditional Model ............................................................................... 4
The Agile Methodology .............................................................................................................................. 6
Comparison between WATERFALL and AGILE Methods: ............................................................... 8
Traditional Project Management VS Agile Project Management ................................................. 9
Making the Choice Between Agile and Waterfall ............................................................................ 10

History of the Agile Manifesto ................................................................................................................................ 12

The Four Values of The Agile Manifesto ............................................................................................... 13
The Twelve Agile Manifesto Principles .................................................................................................. 15

The Main Agile Aspects: ........................................................................................................................................... 17

Agile Project Development Cycle ......................................................................................................................... 17

Agile Project Management – APM Lifecycle and APM Framework .......................................................... 18

Agile Project Management Life Cycle ................................................................................................ 20
Agile Project Management Framework: ........................................................................................... 20
Envision Phase: ........................................................................................................................................ 22
Speculate Phase: .................................................................................................................................... 22
Explore Phase: ......................................................................................................................................... 22
Adapt Phase: ........................................................................................................................................... 23
Close Phase: ............................................................................................................................................. 23
Popular Agile Frameworks.................................................................................................................................... 24
SCRUM METHODOLOGY ....................................................................................................................... 25
Scrum Strengths ...................................................................................................................................... 27
Scrum Weaknesses ................................................................................................................................. 27
AGILE PROJECT MANAGEMENT APPLIED TO CONSTRUCTION ............................................................. 28
Agile for Construction .............................................................................................................................. 30
ARTEFACT AND PRACTICE ANALOGIES BETWEEN AGILE AND CONSTRUCTION ............ 31

Conclusion................................................................................................................................................................... 32
References .................................................................................................................................................................. 33

1
INTRODUCTION

So what is project management? How does it differ from simply "management" and

how does project management in the workplace differ from a personal project such as

refurbishing a house? And, of course, could it be the type of career that will suit you?

Project management is essentially aimed at producing an end-product that will effect

some change for the benefit of the organization that instigated the project. It is the initiation,

planning and control of a range of tasks required to deliver this end product, which could be

a physical product, it could be new software or something less tangible like a new way of

working.

A key factor that distinguishes project management from just management is that it

has this final deliverable and a finite timespan, unlike management which is an ongoing

process. Because of this a project manager needs a wide range of skills; often technical

skills, certainly people management skills and good business awareness.

OBJECTIVES

1. To discuss Agile Project Management

2. To compare Agile Project Management with Traditional Project

Management

3. To describe the Agile Methodology and Scrum Methodology

4. To discuss the application of Agile Methodology in Construction

2
AGILE DEFINITION

Agile is a time-boxed iterative approach to project delivery that builds project

incrementally from the start instead of delivering it all at once near the end.

WHAT IS AGILE PROJECT MANAGEMENT

Agile project management is an iterative methodology, which is ideal for dynamic

working environments and makes quick delivery of the products possible. Agile project

management methodology focuses on bringing continuous improvements, gives flexibility

and ensures delivery of high-quality results before the deadline.

Just as in Agile Software Development, an Agile project is completed in small

sections. These sections are called iterations. In Agile Software Development, for instance,

an iteration refers to a single development cycle. Each section or iteration is reviewed and

critiqued by the project team, which should include representatives of the project's various

stakeholders. Insights gained from the critique of an iteration are used to determine what the

next step should be in the project.

3
TRADITIONAL PROJECT MANAGEMENT AND AGILE

PROJECT MANAGEMENT

The Waterfall Methodology – Traditional Model

Waterfall is a linear approach to software development. In this methodology, the

sequence of events is something like:

1. Gather and document requirements

2. Design

3. Code and unit test

4. Perform system testing

5. Perform user acceptance testing (UAT)

6. Fix any issues

7. Deliver the finished product

In a true Waterfall development project, each of these represents a distinct stage of

software development, and each stage generally finishes before the next one can begin.

4
There is also typically a stage gate between each; for example, requirements must be

reviewed and approved by the customer before design can begin.

There are good things and bad about the Waterfall approach. On the positive side:

 Developers and customers agree on what will be delivered early in the development

lifecycle. This makes planning and designing more straightforward.

 Progress is more easily measured, as the full scope of the work is known in advance.

 Throughout the development effort, it’s possible for various members of the team to

be involved or to continue with other work, depending on the active phase of the

project. For example, business analysts can learn about and document what needs

to be done, while the developers are working on other projects. Testers can prepare

test scripts from requirements documentation while coding is underway.

 Except for reviews, approvals, status meetings, etc., a customer presence is not

strictly required after the requirements phase.

 Because design is completed early in the development lifecycle, this approach lends

itself to projects where multiple software components must be designed (sometimes

in parallel) for integration with external systems.

 Finally, the software can be designed completely and more carefully, based upon a

more complete understanding of all software deliverables. This provides a better

software design with less likelihood of the “piecemeal effect,” a development

phenomenon that can occur as pieces of code are defined and subsequently added

to an application where they may or may not fit well.

Here are some issues we have encountered using a pure Waterfall approach:

 One area which almost always falls short is the effectiveness of requirements.

Gathering and documenting requirements in a way that is meaningful to a customer

is often the most difficult part of software development, in my opinion. Customers are

sometimes intimidated by details, and specific details, provided early in the project,

5
 are required with this approach. In addition, customers are not always able to

visualize an application from a requirements document. Wireframes and mockups

can help, but there’s no question that most end users have some difficulty putting

these elements together with written requirements to arrive at a good picture of what

they will be getting.

 Another potential drawback of pure Waterfall development is the possibility that the

customer will be dissatisfied with their delivered software product. As all deliverables

are based upon documented requirements, a customer may not see what will be

delivered until it’s almost finished. By that time, changes can be difficult (and costly)

to implement.

The Agile Methodology

Agile is an iterative, team-based approach to development. This approach

emphasizes the rapid delivery of an application in complete functional components. Rather

than creating tasks and schedules, all time is “time-boxed” into phases called “sprints.” Each

sprint has a defined duration (usually in weeks) with a running list of deliverables, planned at

the start of the sprint. Deliverables are prioritized by business value as determined by the

customer. If all planned work for the sprint cannot be completed, work is reprioritized and the

information is used for future sprint planning.

As work is completed, it can be reviewed and evaluated by the project team and

customer, through daily builds and end-of-sprint demos. Agile relies on a very high level of

customer involvement throughout the project, but especially during these reviews.

6
Some advantages of the Agile approach are easy to see:

 The customer has frequent and early opportunities to see the work being delivered,

and to make decisions and changes throughout the development project.

 The customer gains a strong sense of ownership by working extensively and directly

with the project team throughout the project.

 If time to market for a specific application is a greater concern than releasing a full

feature set at initial launch, Agile can more quickly produce a basic version of

working software which can be built upon in successive iterations.

 Development is often more user-focused, likely a result of more and frequent

direction from the customer.

 For more Agile Development benefits

And, of course, there are some disadvantages:

 The very high degree of customer involvement, while great for the project, may

present problems for some customers who simply may not have the time or interest

for this type of participation.

 Agile works best when members of the development team are completely dedicated

to the project.

 Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s

possible that some items set for delivery will not be completed within the allotted

timeframe. Additional sprints (beyond those initially planned) may be needed, adding

to the project cost. In addition, customer involvement often leads to additional

features requested throughout the project. Again, this can add to the overall time and

cost of the implementation.

 The close working relationships in an Agile project are easiest to manage when the

team members are located in the same physical space, which is not always possible.

However, there are a variety of ways to handle this issue, such as webcams,

collaboration tools, etc.

7
  The iterative nature of Agile development may lead to a frequent refactoring if the full

scope of the system is not considered in the intial architecture and design. Without

this refactoring, the system can suffer from a reduction in overall quality. This

becomes more pronounced in larger-scale implementations, or with systems that

include a high level of integration.

Comparison between WATERFALL and AGILE Methods:

WATERFALL AGILE

Serialized Process A previous phase has to be Iterative approach with task

completed before starting the broken into small increments

next phase

Planning Far in Advance Product no longer match reality Plan for what we know and we

by the time they are released have left sufficient allowance in

our plans for what we don’t

know

Lack of Visibility Teams don’t realized they are Teams don’t realized they are

8
 behind schedule behind schedule

Project Timeline Planned at the start. If one Allows the development effort

phase is delayed all other to get feedback from the

phases are also delayed costumer throughout

Static Requirement Requirement cannot be Scope is never closed;

changed or modified in middle Continual reassessment of

requirement priorities by the

business

Traditional Project Management VS Agile Project Management

9
Making the Choice Between Agile and Waterfall

So, how do we choose? First, we change the game a little (which is what most

software development organizations do) by defining our own process. At Segue, it’s called

our Process Framework, and it’s a variation on the traditional Waterfall methodology. Our

modifications include use of prototyping where possible to provide the customer a better

view of their finished product early in the design/development cycle. This helps to improve

the team’s understanding of requirements and communication with the customer. After the

primary framework of the application is completed per high level requirements, we continue

to develop and also to reach out to the customer for refinement of requirements. In this way,

we strive to be as iterative as possible without compromising our overall system architecture.

We consider the following factors when considering which methodology to use:

10
11
The factors above are not equally weighted; each is assessed depending on the individual

project and circumstances.

Once we’ve decided which basic methodology to utilize, we can further refine the

process to best fit our project goals. Ultimately, although the way in which we do our work is

important, delivering a solid and maintainable product that satisfies our customer is what

really counts.

History of the Agile Manifesto

The Agile Manifesto and the Twelve Principles of Agile Software were the

consequences of industry frustration in the 1990s. The enormous time lag between business

requirements (the applications and features customers were requesting) and the delivery of

technology that answered those needs, led to the cancelling of many projects. Business,

requirements, and customer requisites changed during this lag time, and the final product did

not meet the then current needs. The software development models of the day, led by the

Waterfall model, were not meeting the demand for speed and did not take advantage of just

how quickly software could be altered.

In 2000, a group of seventeen “thought leaders,” including Jon Kern, Kent Beck, Ward

Cunningham, Arie van Bennekum, and Alistair Cockburn, met first at a resort in Oregon and

later, in 2001, at The Lodge at Snowbird ski resort in Utah. It was at the second meeting

where the Agile Manifesto and the Twelve Principles were formally written. The Manifesto

reads:

“We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

“Individuals and interactions over processes and tools

Working software over comprehensive documentation

12
 Customer collaboration over contract negotiation

Responding to change over following a plan

“That is, while there is value in the items on

the right, we value the items on the left more.”

The Four Values of The Agile Manifesto

The Agile Manifesto is comprised of four foundational values and 12 supporting

principles which lead the Agile approach to software development. Each Agile methodology

applies the four values in different ways, but all of them rely on them to guide the

development and delivery of high-quality, working software.

1. Individuals and Interactions Over Processes and Tools

The first value in the Agile Manifesto is “Individuals and interactions over

processes and tools.” Valuing people more highly than processes or tools is easy to

understand because it is the people who respond to business needs and drive the

development process. If the process or the tools drive development, the team is less

responsive to change and less likely to meet customer needs. Communication is an example

of the difference between valuing individuals versus process. In the case of individuals,

communication is fluid and happens when a need arises. In the case of process,

communication is scheduled and requires specific content.

2. Working Software Over Comprehensive Documentation

Historically, enormous amounts of time were spent on documenting the product for

development and ultimate delivery. Technical specifications, technical requirements,

technical prospectus, interface design documents, test plans, documentation plans, and

approvals required for each. The list was extensive and was a cause for the long delays in

development. Agile does not eliminate documentation, but it streamlines it in a form that

gives the developer what is needed to do the work without getting bogged down in minutiae.

Agile documents requirements as user stories, which are sufficient for a software developer

13
to begin the task of building a new function.

The Agile Manifesto values documentation, but it values working software more.

3. Customer Collaboration Over Contract Negotiation

Negotiation is the period when the customer and the product manager work out the

details of a delivery, with points along the way where the details may be renegotiated.

Collaboration is a different creature entirely. With development models such as Waterfall,

customers negotiate the requirements for the product, often in great detail, prior to any work

starting. This meant the customer was involved in the process of development before

development began and after it was completed, but not during the process. The Agile

Manifesto describes a customer who is engaged and collaborates throughout the

development process, making. This makes it far easier for development to meet their needs

of the customer. Agile methods may include the customer at intervals for periodic demos, but

a project could just as easily have an end-user as a daily part of the team and attending all

meetings, ensuring the product meets the business needs of the customer.

4. Responding to Change Over Following a Plan

Traditional software development regarded change as an expense, so it was to be

avoided. The intention was to develop detailed, elaborate plans, with a defined set of

features and with everything, generally, having as high a priority as everything else, and with

a large number of many dependencies on delivering in a certain order so that the team can

work on the next piece of the puzzle.

With Agile, the shortness of an iteration means priorities can be shifted from iteration

to iteration and new features can be added into the next iteration. Agile’s view is that

changes always improve a project; changes provide additional value.

Perhaps nothing illustrates Agile’s positive approach to change better than the concept of

Method Tailoring, defined in An Agile Information Systems Development Method in use as:

“A process or capability in which human agents determine a system development approach

for a specific project situation through responsive changes in, and dynamic interplays

14
between contexts, intentions, and method fragments.” Agile methodologies allow the Agile

team to modify the process and make it fit the team rather than the other way around.

The Twelve Agile Manifesto Principles

The Twelve Principles are the guiding principles for the methodologies that are

included under the title “The Agile Movement.” They describe a culture in which change is

welcome, and the customer is the focus of the work. They also demonstrate the movement’s

intent as described by Alistair Cockburn, one of the signatories to the Agile Manifesto, which

is to bring development into alignment with business needs.

The twelve principles of agile development include:

1. Customer satisfaction through early and continuous software delivery –

Customers are happier when they receive working software at regular intervals,

rather than waiting extended periods of time between releases.

15
2. Accommodate changing requirements throughout the development process –

The ability to avoid delays when a requirement or feature request changes.

3. Frequent delivery of working software – Scrum accommodates this principle since

the team operates in software sprints or iterations that ensure regular delivery of

working software.

4. Collaboration between the business stakeholders and developers throughout

the project – Better decisions are made when the business and technical team are

aligned.

5. Support, trust, and motivate the people involved – Motivated teams are more

likely to deliver their best work than unhappy teams.

6. Enable face-to-face interactions – Communication is more successful when

development teams are co-located.

7. Working software is the primary measure of progress – Delivering functional

software to the customer is the ultimate factor that measures progress.

8. Agile processes to support a consistent development pace – Teams establish a

repeatable and maintainable speed at which they can deliver working software, and

they repeat it with each release.

9. Attention to technical detail and design enhances agility – The right skills and

good design ensures the team can maintain the pace, constantly improve the

product, and sustain change.

10. Simplicity – Develop just enough to get the job done for right now.

11. Self-organizing teams encourage great architectures, requirements, and

designs – Skilled and motivated team members who have decision-making power,

take ownership, communicate regularly with other team members, and share ideas

that deliver quality products.

12. Regular reflections on how to become more effective – Self-improvement,

process improvement, advancing skills, and techniques help team members work

more efficiently.

16
 The intention of Agile is to align development with business needs, and the success of

Agile is apparent. Agile projects are customer focused and encourage customer guidance

and participation. As a result, Agile has grown to be an overarching view of software

development throughout the software industry and an industry all by itself.

The Main Agile Aspects:

Flexibility: The scope of work may change according to new requirements.

Work breakdown: The project consists of small cycles (known as Sprints in Scrum).

Value of teamwork: The team members work closely together and have a clear vision

about their responsibilities.

Iterative improvements: There is frequent reassessment of the work done within a cycle to

make the final product better.

Cooperation with a client: A customer is closely engaged in the development and can

change the requirements or accept the team’s suggestions.

Prioritizing flexibility and rapid turnaround, the Agile approach offers the following

benefits, according to the recent research:

 Ability to manage the changing priorities (88%)

 Increased team productivity through daily task allocation (83%)

 Better project visibility due to the simple planning system (83%)

Agile Project Development Cycle

Agile methodologies take an iterative approach to software development. Unlike a

straightforward linear waterfall model, agile projects consist of a number of smaller cycles –

sprints. Each one of them is a project in miniature: it has a backlog and consists of design,

implementation, testing and deployment stages within the pre-defined scope of work.

17
 At the end of each sprint, a potentially shippable product increment is delivered.

Thus, with every iteration new features are added to the product, which results in the gradual

project growth. With the features being validated early in the development, the chances of

delivering a potentially failed product are significantly lower.

Agile Project Management – APM Lifecycle and APM

Framework

18
 As companies and organizations are making their move towards agile, the value of

Agile Certification and the demand of agile certified practitioners have greatly increased by

the day. Agile Project Management uses agile methodologies such as scrum, extreme

programming and XP practice and so on within agile development towards successful

completion of projects. Let’s take a look through agile methodologies and agile project

management life cycle processes, wherein these methodologies are used.

Agile is like an umbrella that uses various specific agile methodologies which can be

broadly classified as lightweight approaches and fuller approaches. Examples of Lightweight

approaches are Scrum, Extreme programming and Lean and so on. And examples of fuller

approaches of Agile are Dynamic Systems Development Method DSDM Atern, Agile unified

process and so on. Of these methodology the scrum methodology dominates.

Agile methodologies share many practices used in the development process. The most

important practice shared by all agile methodologies is - they all work in an incremental and

iterative manner, wherein the requirements are stack-ranked and prioritized. The team works

on the requirements in priority order, in short time-boxes called iterations.

19
Agile Project Management Life Cycle

The process of Agile Project Management can be classified in the following way

according to PMBOK

 Initiating: Occurs only once at the beginning of a project or phase

 Planning: Being iterative, it occurs at the beginning of the project as well as the

beginning of each iteration

 Executing: Executes through iterations and so each iteration will see

execution activity peaking somewhere in the middle

 Controlling: Controlling is about checking progress against plan and taking steps to

bring things back on track – it would happen hand-in-hand with execution

 Closing: Bring projects to orderly closure – would typically happen only once at the

end of a project or phase.

Agile Project Management Framework:

Agile Project Management Framework is a modern agile framework that covers the

entire lifecycle of a project. APM framework was introduced by Mr. Jim Highsmith in the

book, Agile project management – creating innovative products.

20
 It defines APM framework as a series of steps that takes a project from an initial vision

of product to the final delivery of product. There are five different phases of Agile Project

Management framework that occurs within a project development. Below are the phases of

APM framework:

ENVISION Determine the product vision and project scope, the project

community, and how the team will work together

SPECULATE Develop a feature-based, milestone, and iteration plan to deliver

on the vision

EXPLORE Deliver tested feature in a short timeframe, constantly seeking to

reduce the risk and uncertainty of the project

ADAPT Review the delivered results, the current situation, and the

team’s performance, and adapt as necessary

CLOSE Conclude the project, pass along key learning’s and

celebrate

21
Envision Phase:

The envision phase is the initial phase of project management within an APM

framework. In general, after approval of a business case, the agile key members are

involved in the envision phase where they collaborate to create the compelling vision for a

project. Envision phase identifies customer’s vision of the project, decides the key

capabilities required in the project, set the business objectives of the project, identifies the

quality objectives of the project, and identifies the right participants and stakeholders of the

project and plans how the team will deliver the project.

Speculate Phase:

In the Speculate phase, the product vision into a backlog of requirements is translated,

the overall approach to meet the requirements is realized and a high level release plan for

the product is presented. There are two key activities in the Speculate phase:

1) The team must come up with at least an initial understanding of the

requirements for the project. Each feature will be further broken down into one or

more “user stories” for the team to discuss and estimate. The requirements also

have to be prioritized so that the team knows in what order to start working on

them.

2) The second aspect is to determine a high level milestone based plan that

speculates how long it would take to create those features. This planning

happens at multiple levels such as release level, wave level and iteration level.

Explore Phase:

As the name suggest, in this phase agile team members explores various

alternatives to implement and fulfill the requirements of a project. In this phase, work

deliveries and testing takes place. Here, the product vision needs to be transformed to a

release plan and then to the respective iteration plan. The team works in an iterative manner

in the explore phase that means, they take a sub-set of the product’s features or stories and

22
accept it into a plan for an iteration. Then it will proceed to work on the development for the

stories. It goes hand-in-hand with the adapt phase, wherein the team learns from the

experiences of development and the feedback from the customer.

Adapt Phase:

In the adapt phase, the agile team reviews the results of execution, the current

situation, performance of the team against the plan and adapt as per the requirements.

Adaptation can be changing the approach to project, changing the process, changing the

environment, changing the project’s objectives and so on as per the requirements of the

customers. Taking feedback, acknowledging it and adapting to the situation based on the

feedback is the major work of this phase.

Close Phase:

This is the last phase within agile project management framework. It concludes the

project in an ordered manner capturing the project’s key lessons.

23
Popular Agile Frameworks
Agile is an umbrella term for a vast variety of methodologies and techniques, sharing

the principles and values described above. Each of them has its own areas of use and

distinctive features. Before discussing the most popular framework in more detail, let’s look

at their key features.

24
SCRUM METHODOLOGY

Arguably the most structured framework of the Agile methods, Scrum was first

introduced in the 1986 as a way for "teams to work as a unit to reach a common goal,"

according to its inventors Hirotaka Takeuchi and Ikujiro Nonaka. Scrum takes parts of

Traditional and Agile project management ideas, and combines them for a structured yet

flexible way to manage projects.

Like Agile, Scrum breaks projects up into tasks that are completable on their own,

and then assigns each a "sprint"—two to four-week slots of time dedicated to ship that phase

of the project, with daily sprints to ship some part of that phase. It's that focus on time that

makes Scrum a bit more like TPM, bringing more structure to the Agile idea.

Then, to make sure the project is progressing as expected and meeting goals that

may have changed along the way, Scrum requires a reassessment—and potential project

changes—at the end of each sprint. It also divides responsibilities into three roles: the

Product Owner (PO), the Scrum Master and the Team.

The Product Owner, who should be deeply familiar with all aspects of development,

makes sure that everything aligns with business goals and customer needs with a mile-high

view of the overall project. The Scrum Master is the team cheerleader—a liaison between

the PO and the rest of the team—who makes sure the team is on track in each individual

25
sprint. The Team then is the people working in each sprint, dividing the tasks and making

sure everything is shipped.

With all this management and focus on deadlines, Scrum's main structure revolves

around 5 meetings: Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review and

Sprint Retrospective.

 Backlog Refinement Meeting (also called "Backlog Grooming"): This meeting is

much like the planning phase of TPM, and is held on day one of each sprint—you'll

look over the tasks left in the project, things left behind from previous sprints, and will

decide what to focus on. The PO makes the call on how to prioritize tasks, and this

ultimately determines how efficient the sprints are.

 Sprint Planning Meeting: Once the PO decides what to focus on, this meeting helps

the team understand what they'll be building and why. You could share "user stories,"

describing features from the customer's point of view, or could simply divide tasks for

each team to work on during the sprint.

 Daily Scrum Meetings: Simple daily meetings that should only last about 15

minutes, Scrum meetings are a way for team members to update each other on

progress. This meeting is not the time or place to air issues—those will go to the

Scrum master outside of the daily meetings—but instead is a place to keep the ball

rolling.

 Sprint Review: Since a potentially shippable item is expected at the end of each

sprint, the Scrum framework naturally places an emphasis on review. Team

members will present what they've completed to all stakeholders. While this meeting

pushes accountability, its goal is to make sure that the sprint's completed items

match up with business and user goals.

 Sprint Retrospective: Held immediately after the sprint review meeting, the Sprint

retrospective is full of collaborative feedback. Looking at successes and hold ups,

everyone decides what is working (what they should continue doing) and what isn't

26
 working (what they should stop doing). This should inspire the focus of the next

sprint.

Where other project management systems might look like they simplify your projects and

make them seem more manageable, Scrum can at first glance look overwhelming. You'll

need to delegate responsibilities and plan extra meetings—but that overhead can help

ensure your projects are successful and stay on track. It's a structured way to make sure

everything gets done.

Scrum Strengths

Scrum is designed for projects that need parts of the project shipped quickly, while

still making it easy to respond to change during the development process. With so many

meetings and ways to delegate tasks, it's also great to use when parts of the team may not

be as familiar with a product's context (i.e. developers from different industry backgrounds

working on a system for the financial sector). You'll always have someone looking out for the

project as a whole, so if each person on the team doesn't understand the entire project,

that's OK.

For each site iteration, the designers would test new features, forget the ones that

didn't work out and move on to new functionalities. Most of the benefits the Netflix team saw

with Scrum was the ability to "fail fast." As opposed to launching one massive redesign with

many components, their bi-weekly incremental design changes were easy to track; if

something went awry, they knew exactly what it was tied to—and could fix it, fast.

Scrum Weaknesses

Like Netflix, you may experience downfalls of Scrum, such as upset designers who

saw their beloved work chucked after testing showed it didn't work—especially when the

testing comes so quickly and some may feel that the new ideas would work with more time.

27
You might also have trouble adjusting if your team is accustomed to long release cycles—or,

depending on your work, you might find shipping so often isn't necessary.

Scrum's meetings and management overhead can also be overkill for some projects,

turning into something where you're more focused on planning sprints than you are on

actually getting work accomplished during them.

AGILE PROJECT MANAGEMENT APPLIED TO

CONSTRUCTION

In general, agile is more applicable to the execution portion of a construction

project, as there still has to be some fairly serious upfront planning. Major changes late in a

construction project are generally hard to do efficiently. Also, the key principle of incremental

delivery of value in the form of working software does not translate well to

construction. However, agile concepts such as customer collaboration and responsiveness

to change have a place in a construction project. Lean methods applied to construction are

beneficial in regards to creating material and information flows, maximizing value generation,

and the use of plan-execute-and-control paradigms.

Once the overall design and master schedule for the project has been created, then

a method known as the Last Planner System can take that master schedule and provide a

process for breaking work down into smaller units that can be executed more iteratively:

28
:

Construction projects are not inherently complex, but because of the challenges

encountered during execution they can become complex. This is because of changes in the

design, availability of resources, materials, information and site access. As a result it is

difficult to maintain an up-to-date work plan and plans rarely reflects the actual sequence in

which tasks are completed. Consequently, the majority of construction tasks that are

completed are based on tacit knowledge and improvisation at the operational level. This

makes managing critical path activities by setting and following priorities very difficult.

29
Agile for Construction

Construction is often used as an example to explain the differences between

software development and other work types. In these examples software development is

considered to be a complex process that is sensitive to input variation, non-linear and not

repeatable. Conversely, construction is explained as a simple linear process. While this is

partly true and construction projects are not complex in the same way as software, they do

share some similarities in the complexity that arises in field execution.

Agile methods have emerged as a means on minimising the risks of complexity and

ensuring the greatest possible value can be delivered. The key principles and practices in

Agile that help reduce risk associated with complexity are based on empirical control,

continuous monitoring and heuristics. Apart from the differences in design, a majority of the

Agile principles and practices that address complexity are directly applicable to construction

project execution.

30
ARTEFACT AND PRACTICE ANALOGIES BETWEEN AGILE AND
CONSTRUCTION

Analogies between Agile and construction can be made in terms of artefacts and

practices. The value in these comparisons is to identify similarities and understand

differences leading to improved sharing of practices between industry disciplines.

The weekly work plan is similar in many ways to an iteration/sprint. It provides a

framework for prioritising and planning work, measuring and monitoring progress, and

capturing lessons learned for improvement. Within the weekly work plan the key practices of

daily standup meetings, customer review/site inspection and retrospective/lessons learned

are very similar.

The primary unit of work that is used for defining scope and measuring progress is

the user story/work package. Here there are some differences in that a work package can be

fully defined using WorkFace planning practices, unlike a user story that is typically used as

the basis for a conversation between customer and team to clarify exact requirements.

Progress in an Agile project is measured using completed user stories, similarly

construction progress can be measured by completion of work packages. Therefore it is

31
possible to represent progress of a construction project in simple form like a burn down/up

chart.

Conclusion

The advantages of agile project management and particularly the Scrum-based

approach is its simplicity. Within an agile project, roles are clearly defined and do not cross

boundaries. Features can be completely developed and tested in short iteration cycles.

Because each team members bears major responsibility for their part of the project,

ownership of the project is more broadly based. The methods of agile project management

enforce extensive communication, which helps teams organize more effectively. This,

ultimately, can lead to greater productivity for everyone involved.

However, some cautions are in order before embarking on a project managed with agile

methods. Frequent communication does not mean that no documentation is required and

without adequate oversight, a project could degenerate into “undisciplined hacking” because

documentation is not maintained. It is also difficult for novice agile project managers to

enforce some of the most important facets of agile methods, such as no changes during a

sprint. In order to effectively implement an agile approach, all parties involved including

upper management must be committed to the process.

Nonetheless, agile project management is one of the most effective means of enhancing the

development cycle within projects. By focusing on eliminating unnecessary bureaucracy,

process, and practice in managing the project, the methodology makes it possible for all

parties to eliminate administrivia and actually do productive work.

If you want to reap the aforementioned benefits of agile project management

methodology then you will have to learn how to use it effectively. Agile project management

helps you to be more flexible, reduce risks, improve productivity, create a revenue stream

and reduce costs.

32
References

A guide in the Project Management Body of Knowledge (4th ed.)(2008) Newtown Square,

PA: Projects management Institute

A guide to the Project Management body of Knowledge (5th ed) (2013)Newtown Square,

PA: Projects Management Institute;

Altexsoft. (2017). Agile Project Management: Best Practices and Methodologies.

Retrieved from https://www.altexsoft.com

AIMS Education – UK. (2015, April 26). What is Agile Project Management? Agile

Definition, Methodology and Scrum | AIMS Lecture. Retrieved from

https://www.youtube.com/watch?v=lP8vjBrswSs

Guay, Mattew. Project Management 101: The Complete Guide to Agile, Kanban, Scrum

and Beyond. Retrieved from https://zapier.com/learn/project-management/project-

management-systems

Karkar, Haresh. (2011, May 2). Overview of Agile Methodology. Retrieved from

http://www.pmi.org/-/media/pmi/documents/public

Kim, Don. (2012, May 14). The Agile Triangle. Retrieved from

https://www.projectmanagement.com

Mueller – hanson, R.A. White, S.S., Dorsey, d. W. & Pulakos, E.D. (2005) Training

adaptable leaders: Lesson from Research and Practice. Arlington, VA: U.S. Army

Research Institute for the Behavioral and Social Science.

MIT OpenCourseWare. (2015, December 10).Agile Project Management. Retrieved from

https://www.youtube.com/watch?v=nrfl6GAQy2s

Pratt, Mary k and Torode, Christina. Agile Project Management. Retrieved from

http://searchcio.techtarget.com

PMI’s Pulse of the Profession. (2017). Success Rate Rise – Transforming the high cost

of low performance. Retrieved from http://www.pmi.org/-/media/pmi

33
Project Management Videos. (2014, October 20). Agile Project Management: Scrum &

Sprint Demystified. Retrieved from

https://www.youtube.com/watch?v=DvBKevrItcc&t=310s

Stacey, R. (1996) Complexity and creativity in organization. San Francisco, CA: Berrette-

Koehler Publishers;

Slinger, M., & Broderick, S. (2008). The software project manager’s bridge to agility.

Upper Saddle River, NJ: Addison-Wesley.

Sliger, Michele. (2009). Agile Project Management for PMP’s. Retrieved from

https://www.slideshare.net/VersionOne

Klein, Chris. (2016, May 13). Agile Construction Management. Retrieved from

https://blog.versionone.com/agile-construction-management/

Smith, Adrian. (2011, September 22). Agile and Lean Applied to Construction. Retrieved

from http://ennova.com.au/blog/2011/09/agile-lean-compared-applied-construction

34