Project 5 - Achiever Papers

Agile Project Management Approaches Course Project

Part One: Consider Incorporating Agile into Your Work

Now that you have had a chance to examine some of the critical characteristics of agile and you have seen its evolution from the software development realm into other applications, you can consider how you might incorporate an agile approach into your own work.

Answer the following questions, using as much space as you need.

. Review the Agile Manifesto. How does it support or reflect your understanding of the role of project management in helping deliver value to the customer and the organization?

2. Review the twelve principles of agile. Which of them are most applicable to your practice of project management?

3. What would you need to do differently to incorporate an agile approach into your project management work?

4. If you were to adapt your work to be more agile, how would you change your approach to project schedules? What would you do differently?

5. If you were to adapt your work to be more agile, how would you change your approach to creating and managing budgets? What would you do differently?

[Type text] [Type text] [Type text]

CEPM505: Agile Project Management Approaches

Cornell University College of Engineering

Part Two: Comparing Agile to Traditional

Traditional project management and agile are very different conceptual paradigms. It’s the characteristics of the project that will dictate the right structure for project planning, management, and control. For this part of the course project, you will identify a project you managed in the past that you think would have fit one or the other philosophy better.

Answer the following questions, using as much space as you need.

1. Briefly describe the project you have chosen to analyze here.

2. Based on your understanding of traditional project management versus an agile approach, identify which approach would have suited this particular project better. Offer a rationale for your choice.

3. What do you see as the advantages of using the approach you’ve chosen?

4. What might be some of the disadvantages of using the approach you’ve chosen?

5. Describe the project management approach you would take for this project: a command and control style, or a responsive and adaptable style. Why? Explain your thinking.

Part Three: Considering the Flavors of Agile

You will be best positioned to incorporate the different attributes of adaptable project management approaches into your work if you can think critically about what each offers to you and make sound decisions about when your projects’ characteristics demand them. In this part of the course project, you will demonstrate your understanding of the different flavors of agile.

Answer the following questions, using as much space as you need.

1. Lean is, philosophically, a little different than agile. It offers some control. It asks you to try to eliminate waste everywhere you can. How do you see the principles of lean being helpful to you in your work?

2. Scrum is an implementation of lean. Do you have a project you could use scrum on? How do you think using scrum for that project might help you? Why would scrum make sense in that context?

3. If you don’t have a project for which scrum would be helpful, then describe the kind of project you think it would it make sense for.

4. What might a project backlog look like in your work? Try to design a backlog for your purposes. What would you want to include? Note: Rather than listing work items in a backlog, focus on the properties of the backlog items, i.e., the column headings in a table, as opposed to the row titles. For example, the reference number, title, completion status, etc.

5. Describe your understanding of how lean principles help to complement project management efforts.

6. How do you think an understanding of kanban and extreme programming will help you in your project management efforts? Offer your ideas.

7. What kind of soft skills do you think a project manager coming from a more traditional environment would need in a lean environment? Remember that they can’t act the same way. Lean is not based on command and control; it’s based on individuals making choices and decisions. The project manager is more of a facilitator than an enforcer. What soft skills would be necessary?

CEPM505: Agile Project
Management Approaches

What you’ll do

Explore the underlying philosophy of using an agile approach
to project management
Apply lean principles in the project management arena
Recognize how lean principles complement and rightsize
project management concepts

Relate lean to agile concepts
See why scrum and extreme programming are implementations
of agile
Determine how the characteristics of a project dictate the right
structure for project planning, management, and control

Course Description

Traditional project management assumes that a project
manager can identify all the requirements of the work to
be done in advance, create a massive project network,

build a schedule, and manage it all until the team meets every deadline.
But sometimes you don’t know all the details of the work to be done at
the beginning of the project. How do you scope the work, create a
schedule, and plan the appropriate resources in that case?

Agile offers project managers a different approach. Agile creates a
system designed to be flexible when you don’t know all the requirements
upfront. Sometimes in project management work, you try to manage work
that’s totally new and need an adaptable approach to identify and
complete work as you go along. It’s more effective to work iteratively and
incrementally toward customer needs that are evolving over time. In this
course, from Linda K. Nozick, Director and Professor of Civil and
Environmental Engineering at Cornell, students will examine the theories

CEPM505: Agile Project Management Approaches
Cornell University

behind adaptable project management approaches and will find ways to
apply elements of agile, lean, scrum, and extreme programming to
projects in their own workplaces.

This course is designed for the seasoned project manager seeking an
introductory understanding of adaptable project management approaches
and how they might be applied to various projects. It is not meant to
address the overarching organizational infrastructure that would be
needed to effectively support a company-wide agile or lean initiative. This
course does assume that the student has project management
experience or has had exposure to traditional project management
approaches.

Linda K. Nozick

Professor and Director of Civil and
Environmental Engineering
College of Engineering, Cornell University

Linda K. Nozickis Professor and Director of Civil and Environmental
Engineering at Cornell University. She is a past Director of the College
Program in Systems Engineering, a program she co-founded. She has
been the recipient of several awards, including a CAREER award from
the National Science Foundation and a Presidential Early Career Award
for Scientists and Engineers from President Clinton for “the development
of innovative solutions to problems associated with the transportation of
hazardous waste.” She has authored over 60 peer-reviewed publications,
many focused on transportation, the movement of hazardous materials,
and the modeling of critical infrastructure systems. She has been an
associate editor for Naval Research Logistics and a member of the
editorial board of Transportation Research Part A. She has served on two
National Academy Committees to advise the US Department of Energy
on renewal of their infrastructure. During the 1998-1999 academic year,
she was a Visiting Associate Professor in the Operations Research
Department at the Naval Postgraduate School in Monterey, California.
Professor Nozick holds a B.S. in Systems Analysis and Engineering from
the George Washington University and an M.S.E and Ph.D. in Systems
Engineering from the University of Pennsylvania.

CEPM505: Agile Project Management Approaches
Cornell University
© 2018 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners.

Author Welcome

This course focuses on alternative models for project delivery.
Throughout this course, we will discuss the ideas of agile and lean and
we will talk about how the role of the project manager, in fact, is different
under these different ideas for project delivery.

Table of Contents

Module 1: Consider Incorporating Agile into Your Work

1. Module One Introduction: Consider Incorporating Agile into Your
Work

Watch: What Is Agile Project Management?

Watch: What Is the Agile Manifesto?

4. Watch: Exploring the Four Parts of the Agile Manifesto in Detail
5.

Read: The Twelve Principles of Agile

Tool: The Agile Adaptation Worksheet

What Agile Offers You

Incorporating Agile

9. Course Project, Part One: Considering Incorporating Agile into Your

Work
10. Module One Wrap-up: Consider Incorporating Agile into Your Work

Module 2: Compare Agile to Traditional

1. Module Two Introduction: Compare Agile to Traditional
2.

Watch: Examine Some Advantages of Agile

Watch: Consider Some Disadvantages of Agile

4. Read: Traditional Project Management vs. an Agile Approach
5. Watch: What Is the Role of the Project Manager in Agile?
6.

Comparing Agile to Traditional

Project Management Challenges

8. Course Project, Part Two: Comparing Agile to Traditional
9.

Module Two Wrap-up: Compare Agile to Traditional

Module 3: Consider the “Flavors” of Agile

1. Module Three Introduction: Consider the “Flavors” of Agile
2.

Watch: Looking at the Flavors of Agile

Tool: Map the Attributes

Watch: Examine Scrum

Read: A Detailed Look at Scrum

Watch: Examine Extreme Programming

Read: A Detailed Look at XP

Watch: Examine Lean

Watch: Examine Kanban

10.

Considering the Flavors of Agile

11.

Watch: Agile vs. Lean

12. Tool: The Adaptable Project Management Approaches Action Plan
13. Course Project, Part Three: Considering the Flavors of Agile
14. Module Three Wrap-up: Consider the Flavors of Agile
15.

Read: Thank You and Farewell

Module 1: Consider Incorporating
Agile into Your Work

1. Module One Introduction: Consider Incorporating Agile into Your
Work
2. Watch: What Is Agile Project Management?
3. Watch: What Is the Agile Manifesto?
4. Watch: Exploring the Four Parts of the Agile Manifesto in Detail
5. Read: The Twelve Principles of Agile
6. Tool: The Agile Adaptation Worksheet
7. What Agile Offers You
8. Incorporating Agile
9. Course Project, Part One: Considering Incorporating Agile into Your
Work
10. Module One Wrap-up: Consider Incorporating Agile into Your Work

Back to Table of Contents

Module One Introduction: Consider Incorporating
Agile into Your Work

Using an agile approach to project management doesn’t
mean that you won’t still need traditional project
management tools such as a Gantt chart, budgets,
agreed-upon deliverables, and controls of some sort. It’s
not a free-for-all. The difference here is a philosophical

difference and a difference in approach and implementation. And it’s
really not a question of your personal preference when it comes to
deciding whether you will use a traditional project management approach
or an agile one. The nature of your project will drive the need for one
versus another. In this module, you will examine what agile means and
consider what it offers you. You will have an opportunity to discuss with
your peers when agile is the most appropriate choice, and you will
access a helpful worksheet that will aid you in adapting agile ideas for
your own use.

Back to Table of Contents
CEPM505: Agile Project Management Approaches
Cornell University
© 2018 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners.

Watch: What Is Agile Project Management?

As a project manager, you want to be able to respond nimbly to customer
needs. The idea of being agile is that you deliver to the customer
incrementally, in small pieces, and make needed adjustments along the
way. Professor Nozick explains more.

Transcript

Let’s talk about agile project delivery. And let’s start this discussion by
talking about what the word agile means. I suspect you’ve heard the word
agile related to project management and project delivery but let’s begin
one step further back that says, “What’s the word really about? What
does agile actually mean?” Well, it means to move quickly and easily.
And that’s an important set of attributes—quickly and easily— because
when you keep that in your head, it really does match the philosophy
behind agile project delivery. It’s really important to understand, as we
talk through this, that agile is a very different mindset than traditional
project management. And, as we talk about it, keep in your head some of
the characteristics that come to the surface when we talk about it and
then compare them to your thinking when it comes to project
management and more traditional command and control and project
delivery.

So, for agile project management, that is a method that’s really focused
on a delivery experience for a project that’s both iterative and
incremental. Okay, those are very important words: iterative and
incremental. And you’ll see, as we continue this discussion, what a very
large role they play in the agile paradigm. Agile also emphasizes the idea
of flexibility; the idea that the team needs to be learning all the time, that
team—individuals learn and the teams learn over time, and that everyone
is sensitive to the idea that customer needs evolve. Not that they’re
frozen in time and you’re somehow controlling the evolution in their
needs, but, here, you’re being sensitive to how they evolve so that you
can better meet those needs. So, a project delivery process where the
focus is on incremental delivery is a big difference, conceptually, than a
more traditional viewpoint that would say you have large deliverables but

they occur on an infrequent basis. This idea that you’d have a—
continuously delivering to your customer, paired with a discussion about
customer needs over time, compared to having a system where you
deliver—relatively infrequently—big chunks of stuff, but you sort of
understand what’s needed up front. Okay? These are very different
paradigms. Okay?

Now, what’s the benefit in all this? Why is it good to have incremental
delivery? Well it also—it depends on the project environment you’re in
the middle of managing or are involved in participating in. If it’s a very
well understood project, with well understood customer needs, that’s one
thing. But what happens if you’re in a situation where a customer needs
are not that—maybe the customer themselves doesn’t actually fully
understand them. Or they work in a very dynamic environment and, in
fact, the needs are evolving as time goes on? If you have a much more
incremental method for delivery, you’re much more likely to get a hold of
what those customer requirements look like and their changing character
over time and be able to integrate them into the deliverables.

Whereas, if you have to do it all up front and customer requirements
really are changing and you really do need to meet those, this is going to
get kind of difficult. But if you have a process that’s much more
incremental, the stuff you have to change and as you move forward,
you’re more flexible about how to get those needs in. If you’re going to
work in that kind of an environment, okay, that you’re going to need to
have more incremental delivery and be much more tolerant of customer
need changes or evolution, well, you’re going to have to think a little bit
differently about how your teams are going to function. You’re not going
to be able to have such a rigid system around them. In fact, you’re going
to have to have much more decentralized decision making.

So, you’re going to have to have individuals that are more empowered,
okay? That they can learn very quickly and they can make changes to
what needs to be done and they’re comfortable with making those kinds
of changes. That’s a different kind of burden on the employee or on the
team member. So, this means that you’re going to wind up taking these
individuals and then integrating them into teams that are very dynamic.
And, since the work is changing on a somewhat regular basis, as you
learn more about it, they’re going to have to be able to self- organize to

accomplish that work. So, this is now a pretty different picture than a
much more structured project delivery mindset.

Watch: What Is the Agile Manifesto?

As Professor Nozick explains, the Agile Manifesto was written in 2001. It
identifies four key principles that initially guided software development but
have grown to have applications beyond software. Professor Nozick
discusses the applicability within the context of project management.

In the Agile Manifesto is written, “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.
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.”

Transcript

So, let’s talk a little bit about the roots of agile. One of the important
things you’ll stumble upon when you learn about agile and the roots of
agile, is something called the Agile Manifesto. This was developed in the
early 90s. And this was, really, a reaction to frustration that was being
experienced in the information technology industry, trying to deliver
working software in the 90s. The ideas in this are not limited to software,
but that’s just where it got its roots. And if you think about it, generally,
there’s challenges in software development of creating the customer
requirements up front, not having them evolve.

All those issues do come. They really are quite potent in the software
industry. And so, it’s not so unreasonable that this would have come out

of that kind of an industry. So, anyway, the core principles are relevant
beyond software in the Agile Manifesto and they’re worth thinking very
carefully about. So, what are they? So, this manifesto stated “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 a
comprehensive documentation, 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.”

So, just for a moment, let’s look at this more carefully. So, notice it says,
this doesn’t imply that what’s on the right is unimportant. You’re not going
to get away from documentation. Okay. You’re going to need to
document in the software field. In other fields, how you do your analysis?
Documentation is an important thing, but you’re not documenting to
document, okay? What you’re trying to do— this is meant to emphasize
getting product to the customer that’s high quality. That’s the most
important. It doesn’t mean you won’t document, of course not. It just
means you’ll keep it in balance with what you need to do the job well.

Watch: Exploring the Four Parts of the Agile
Manifesto in Detail

The Agile Manifesto has four parts: four key values that drive the
philosophy and its implementation. Professor Nozick will examine each of
these four parts in some detail and discuss what each of them indicates
for project managers who seek a more nuanced understanding.

Part One

What does it mean to say we value individuals and interactions over
processes and tools?

Transcript

So, let’s unpack the phrase, “individuals and interactions over processes
and tools.” So, for a project to be agile, the processes and the tools can’t
dictate how the project unfolds— how the delivery unfolds of the project.
In fact, it’s got to be the people and the interactions that are driving the
system and the processes and the tools are being used to support their
needs. So, it doesn’t mean we get rid of the processes and the tools.
That’s not what this is about. It’s that we always think of which ones we’re
going to adopt and how we’re going to use them with a clear eye towards
what they would do to help individuals and teams interact. And so, now
this word interaction, let’s make sure we look at this for a moment too.
Agile is really about being responsive to customers evolving needs,
project evolving needs. One person is not going to be able to do all of this
all by themselves.

This idea of supporting interactions between people with diverse skill
sets, that’s what’s going to be very important to be able to keep up and
make this really come to fruition. Think of it. This is a fairly high-bar
performance— being able to be very responsive and flexible. These are
hard things to do. And so, we’re going to need to have a team with
different people with different skills, interacting together very efficiently so
this can be done in a very successful way. So, highly productive
interactions is what we’re really about among individuals, and using

processes and tools to support that. That’s really what they’re trying to
say with individuals and interactions over processes and tools. There’s
really a lot of meaning in what seems like a very simple phrase.

Part Two

What does it mean to say we value working software over
comprehensive documentation?

Transcript

Okay, let’s unpack the next one, “working software over comprehensive
documentation.” It’s—since most people don’t particularly like to do
documentation very much, it’s very natural to say, “Okay, this means the
documentation is not important.” That’s really not the point of this
statement, okay? This statement is really in a different spot. It means the
focus should be on working software or, put this in another context, a
working something for the customer. It doesn’t have to be software,
okay? Creating product for the customer that works or is high quality,
that’s the goal. Your going to need to do documentation to support that
effort. And so you need the documentation to be done well, but just in the
size and the amount that’s needed to support the creation of that value
for the customer.

That’s a very important concept. The idea that, your eye is on the prize.
The prize is creating the working thing the customer needs; the reason
the customer is engaged with you. Honoring that and creating that value
stream over time, that’s your goal. In the process of doing that, you’ll
need to do a number of things— a number of things will have to happen
to support that. Documentation is a very important thing in the software
industry and in other industries. It doesn’t mean that that’s a goal in and
of itself. That is something done to support the deliverable. Okay, so I
think that the most important element, from my perspective, when I read
this is, “Gee, what we really should be focused on is, what is it that
produces that value to the customer, the deliverable to the customer and
makes that a good quality thing that they will want to engage with us on?”
Now, what are the things that need to be done to support that? Make
sure they’re done well in the size and the amount of effort that’s
necessary.

Part Three

What does it mean to say we value customer collaboration over contract
negotiation?

Transcript

Okay. Now, let’s unpack the one “customer collaboration over a contract
negotiation.” So, this is where all those words about flexibility come in,
okay? Agile assumes that you’re in more of a partnership with a client—
a collaborative relationship— rather than some kind of an arm’s length
negotiation to have something built that will be given to you, okay? That’s
a different perspective. Those two are very different ways of looking at a
situation. Okay? From a partnership to something being sold, this means
— a partnership means— things are going to evolve over time and you’re
okay with some ambiguity at the beginning and that ambiguity will get
resolved as this partnership becomes more solid, and feedback occurs,
and learning occurs on all sides.

Okay. This value is, in fact, a signal in what environments do we really
think of agile. This idea that customer collaboration really needs to be at
the forefront. That’s a signal about when you would think of agile versus
a more traditional project management structure. Okay. So, customer
collaboration over contract negotiation. This is an acknowledgment of a
particular kind of reality that exists on some kinds of projects.

Part Four

What does it mean to say we value responding to change over following
a plan?

Transcript

Responding to change over valuing a plan. So, this is our fourth value
from the Agile Manifesto. It’s really easy to look at that and say, “Well,
gee, this means I can stop worrying about all those plans. I’m a little tired
of those plans anyway.” No, that’s really not what this means. That was

not what they had in mind. It doesn’t mean you stop making plans. You’ll
always make plans. It means that we shouldn’t— when we make those
plans and as we execute the project, we shouldn’t be stubbornly insisting
that the project perform— project activity always move back in line with
the plan. Okay?

Because, in some environments, when you would be using agile, in fact,
that plan will need to evolve over time as our understanding of the project
needs evolve. Okay? This is a big conceptual difference that we need to
pay very close attention to. We think very carefully about when you adopt
an agile kind of philosophy, it is saying that it is really because of a need
to have this flexibility. So, this idea that plans evolve over time and being
at peace with that, that’s an important characteristic of working well in an
agile environment. President Eisenhower once said, “Plans are nothing
and planning is everything.” I think this is still important to this day.
Actually, in a traditional project environment, you will plan and replan.
Unless that work is just very straight up easy and everyone works like a
robot, you will be doing some replanning. As your customer— as you
move into environments where your customer requirements are very
dynamic, you’ll do more replanning. Okay?

And that’s okay. You just got to have that mindset that this is okay. What
you’re after is quality to the customer, understanding the financial
elements of all of this, understanding the timelines, understanding what is
expected and what your people need to be successful. As long as you
think of the end game it’ll be more clear what your action should be. Is
moving back in line with the plan actually the right thing to do because
you are in a much more controlled world? Or is it a place where you
really do need to be much more flexible and rethink that plan in a much
more substantive way.

Read: The Twelve Principles of Agile

• The twelve principles of agile
expand on the four key points

• These principles will help you
respond to change rather than
follow a plan

The twelve principles of agile were authored by the same people who
wrote the Agile Manifesto, and they have offered them publicly for
anyone to use.

“We follow these principles:

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

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

©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair
Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron
Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland,
Dave Thomas. This declaration may be freely copied in any form, but only in its entirety through
this notice.
Back to Table of Contents
CEPM505: Agile Project Management Approaches
Cornell University
© 2018 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners.

Tool: The Agile Adaptation Worksheet

• Use the The Agile Adaptation
Worksheet

It’s true that the Agile Manifesto was written for use within the domain of
software development. How can you use the Agile Manifesto in your own
work, even if you don’t work in software development? You can adapt it
for your own work in ways that you think will help to shape your policies,
protocols, and team philosophy. You may want to use its ideals to guide
your conversations with customers. Its principles have been attached
here as a worksheet so that you can consider its guiding principles and
think about how they might inform and improve your own project
management practice.

https://s3.amazonaws.com/ecornell/content/CEPM/CEPM505/CEPM505_tool-agile-adaptation-worksheet x

What Agile Offers You

Instructions:

You are required to participate in all of the discussions in this course.

Discussion topic:

Create a post in which you identify 2-3 ideas of what an agile approach
can offer to the practice of project management. How do you think it
might be helpful to you?

Instructions:

Click Reply to post a comment or reply to another comment. Please
consider that this is a professional forum; courtesy and professional
language and tone are expected. Before posting, please review
eCornell’s policy regarding plagiarism (the presentation of someone
else’s work as your own without source credit).

https://s3.amazonaws.com/ecornell/global/eCornellPlagiarismPolicy

Incorporating Agile

Answer the following questions regarding incorporating an agile approach
into your project management efforts.

You must achieve a score of 100% on this quiz to complete the
course. You may take it as many times as needed to achieve that
score.

Course Project, Part One: Considering Incorporating
Agile into Your Work

What does agile mean to you? How might you use it in your own practice
of project management to deliver better results for your project, team,
organization, and customers? In this part of the course project, you will
address these questions by putting your understanding of an agile
approach alongside your own project management work and identifying
areas of compatibility.

Completion of this project is a course requirement.

Instructions:

Download the Adaptable Project Management Approaches Course
Project.
Complete part one.
Save your work.
You will not submit your work now. You will submit your completed
project at the end of the course for instructor review and credit.

Before you begin:

Review the grading rubric for this assignment. Please review eCornell’s
policy regarding plagiarism.

https://s3.amazonaws.com/ecornell/content/CEPM/CEPM505/CEPM505_course-project x

https://s3.amazonaws.com/ecornell/global/eCornellPlagiarismPolicy

Module One Wrap-up: Consider Incorporating Agile
into Your Work

As discussed, there are certain conditions under which an agile approach
would suit your project best. You will still need traditional project
management tools such as a Gantt chart, budgets, process, plans, and
controls. An agile approach is not a free-for-all. You have now had a
chance to examine the philosophical differences between a traditional
project management approach and agile. You have explored what agile
means and considered the benefits and flexibility it offers you. You have
had an opportunity to discuss with your peers when agile is the most
appropriate choice, and you have accessed a helpful worksheet that will
aid you in adapting agile ideas for your own use.

Module 2: Compare Agile to
Traditional

1. Module Two Introduction: Compare Agile to Traditional
2. Watch: Examine Some Advantages of Agile
3. Watch: Consider Some Disadvantages of Agile
4. Read: Traditional Project Management vs. an Agile Approach
5. Watch: What Is the Role of the Project Manager in Agile?
6. Comparing Agile to Traditional
7. Project Management Challenges
8. Course Project, Part Two: Comparing Agile to Traditional
9. Module Two Wrap-up: Compare Agile to Traditional
Back to Table of Contents
CEPM505: Agile Project Management Approaches
Cornell University
© 2018 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners.

Module Two Introduction: Compare Agile to
Traditional

In what ways is agile project management similar to and
dissimilar from a traditional approach? You will want to
understand the nuances of the similarities and differences
so that you can make appropriate choices about when,
and under what conditions, each one would best meet the

needs of your project. It will be the project, and not your personal
preferences, that will dictate which approach will be most effective. Now
you will have a chance to compare and contrast different models. You will
see why agile won’t always be the best choice; it does have some
disadvantages in certain conditions. And you will have a chance to
examine how the roles and the responsibilities of the project manager will
change, depending on which approach you are working with. You will
also have an opportunity to discuss relevant challenges with your peers,
and you will complete the second part of your course project, in which
you draw critical comparisons.

Watch: Examine Some Advantages of Agile

Agile project management has some clear advantages to offer project
managers, as Professor Nozick explains. You want to be aware of what
these are so that you can make sound decisions about when to adopt an
agile approach.

Transcript

So, there are some important advantages to agile. If you think about
incremental delivery. If you think about what that will cause; that will tend
to drive a much closer bond with the customer. Because, every time you
deliver something, that’s a basis for more communication; what did they
like about what you delivered, what did they not like?

In fact, as you plan what you’re going to deliver, you’re going to have
conversations with the customer about what they need. Okay? Each
incremental delivery actually provides contact with the customer. And that
contact is a way to create things that are much closer to their needs.
This, in turn, creates a much closer bond between the customer and
yourselves— and your project team. If you can contrast that with a
traditional project structure, if you think about it from the client’s
perspective, you fade from view. Because you go off and do your work,
and then you come back after some substantial period of time and say,
“Voila! Here it is.” During that time that you’re not regularly interacting in a
very close way with a customer, that customer’s environment changes,
okay? And so, you make some risks there. There is some risk there, that
what you do is out of date, that they will have forgotten, and then they’ll
be in a new context. And when your stuff comes back, they’ll look at that
and go, “Well, that’s not really my context today.” And that
communication won’t have occurred for you to head that off. Okay?

So, that’s a big advantage to having these smaller deliverables on a
much more frequent basis. Okay? It also helps create an environment
where change is easier to accommodate. Okay? So, if you’re delivering
relatively frequently, it’s easier to work new things in or to shift the
direction. When you’re spending large periods of time away and then you

get a new change, this can be sometimes very difficult to deal with.
Okay? It’s also very easy in the agile paradigm— or at least much easier
—to tolerate this ambiguity in what the customer needs and allows— this
sort of a structure allows that ambiguity to be worked out incrementally as
you deliver stuff to the customer. That lets the end goal crystallize over
time, as opposed to having a clear sight of what that is at the very
beginning of the project. That’s a very different situation. Okay?

So, agile, it emphasizes the human element, because you’re not going to
do this in a rigid system. Like, you’re not going to be that flexible in a rigid
system. So, it’s going to emphasize the human elements of your team,
and how well your team functions. Okay? A shared ownership of really
trying to make these be responsive, and to deliver, regularly, value-
creating tools, value- creating content. This is going to create a need for
shared ownership because, if you need a really strong command and
control system, after you get new changes all the time, you’re going to be
doing— redoing everything over and over again. You are going to need
people that can very easily interact and can very easily take those
evolving— this evolving target, and turn it really quickly into real work that
will create product. If you need to lose a lot of time to reshift your human
capital, this is going to be a difficult thing. So, teams that— individuals
that learn well, that are good with continuous improvement, are really
good at interacting with each other— this is going to be a very important
set of things to do. Okay?

So, an advantage of agile, from a business perspective, is, to be effective
at it, you have to be good at— your team has to be good at saying, “What
do we need to do?” And then doing it. As opposed to, “Well, we always
do it this way so, of course this is the way we’re going to do it this time.”
Okay? So, it’s a very different— think about the mindset change there.
This has people running fast but do doing it very well. Versus: here is a
process. We always operate this way. This is how I always do my job.
Okay? So, this is an advantage of agile if you think about it. But it does
create a need for investment in human capital.

Watch: Consider Some Disadvantages of Agile

Now that you have had a chance to examine agile and the benefits and
advantages it may offer, you will consider some of the disadvantages that
may come with using an agile approach. Under some conditions, it won’t
be the best approach for you.

Transcript

So, you might ask, “Are there really any disadvantages of agile?” Well,
there are a few. And I wouldn’t say they are disadvantages that take agile
off the table. They’re just things you need to be aware of. Okay? So that
you have good mitigation in place.

So, here’s an example. You bring a new person onto a team, an agile
team. Well, it’s not as easy to integrate that person into the team
because there’s a lot of investment in human capital. A lot of information
is actually in their heads. Okay? And there’s not a lot of rote ways of
doing things. Okay? And much less is written down. So, bringing a new
person onto the team, that process of bringing them on to the team, that
ramp up to make them efficient and effective as part of the team— that
can take longer in an agile world. Also, let’s think about shorter delivery
windows. We talked about how nice that is from a customer perspective.
Or how nice that could be from a customer perspective; how good that
could be in terms of being able to incorporate change and all of that. Let’s
think about the effect on the human. When you start delivering more
frequently, you can get a lot more stress on your employees. Okay?
Because employees are now working on a much more regular basis to
deliverables that are shorter. Okay?

Shortening deliverables makes people nervous. When things are
delivered— are due—in a very short period of time, or a relatively shorter
period of time, all things equal, this can be a more stressful situation.
Okay? So, you have to be aware of that. You have to be aware of how
much stress your employees are under and what kinds of things you can
do to mitigate that and make the process work better so that they are
under less stress. Another thing is that, if you’re really going to deliver

after each one of these iterations in agile, you’re going to have more work
for people who do Q.C. for example, quality control, prior to delivery. All
those folks are going to have to get ramped up on a more frequent basis
to do quality control work. Okay?

And another thing you got to be careful of is the documentation can be
lacking. Why did I say that? We had this value that says working software
over documentation. Well, if people feel very stressed and they’re very
much running quickly to get things happen, get things done, so they’re
rushing and rushing and rushing, the first thing they may go a little thinner
on is documentation. Okay? So, that’s one place where you might look
for a sign that, in fact, this is moving so fast our people are having trouble
keeping up. Are they getting that kind of a thing done? Okay? So, paying
attention to those kinds of details is very important.

Read: Traditional Project Management vs. an Agile
Approach

• A traditional approach suits
known deliverables, defined
scope, defined methods, and little
ambiguity

• An agile approach suits ambiguity
and unknowns

There are key differences between agile project management and
traditional project management. Let’s compare and contrast the two
approaches.

You could think of a traditional project environment as saying, “I know the
scope of this project; the customer has explained what they need from us.
I need to develop a budget and a timeline, and then I need to manage to
that because the scope is known.” That’s kind of a traditional project
management world.

In other instances, the customer might say, “I have some money available
and I have a time frame, and I generally need something that
accomplishes the following things, but I’m not sure exactly what to ask for.
Can you help me?” You then strive to accomplish as much as possible to
meet their goals, understanding that those goals are likely to change over
the course of the project. That’s a little more of an agile
“flavor.”

The traditional model for project delivery is often called the waterfall
model, in which the work flows in a logical sequence (shown here from
left to right).

The idea is that it’s linear; one thing proceeds logically after another. It
begins with a concept and initialization phase, followed by definition and

planning, execution and control, and closeout. There are many different
labels you could put in those boxes, but it’s generally a linear process.

Agile is a different approach. It’s not linear, meaning the work does not
flow in a straight, direct line from conception through execution to
closeout. As you move through the process of doing the work, you take
on chunks of it at a time. You go through an iterative process of planning
to do one chunk of work, then executing it and controlling that chunk of
work, delivering it, and then doing the next chunk. You go through the
steps of planning-execution-control-delivery and repeating this process
until you complete, and then you do closeout.

The word delivery used in this context doesn’t need to be taken literally.
In some environments, it really is delivery. In some instances of agile, at
every one of the iteration cycles there is a deliverable. In other contexts,
there is no delivery per se, but the work is at the level of maturity at that
point that it could be delivered.

(These are generally very important business questions: When do you
actually deliver? And how much do you deliver? Agile acknowledges that
more frequent deliveries is better. But is it at every single iteration or not?
That’s a different question, and one that you will have to discuss and
address for your projects.)

In the linear process of traditional project management, you know where
you are right now; you know where you need to go, and you map out how
to get there. Once that map has been created, you try to stay on that
path. And if you stray off it, you figure out how to get back on it. In this
linear process, you have a clear road map that you are capable of
building with your level of knowledge at the beginning of the project. Agile

takes the opposite position: you refine the map as you go.

Which one’s better? Do I only really need to understand one of the two of
these? Or do I need to understand both?

You need to understand both. The approach you choose will depend on
the nature of the project.

In some environments, traditional will make a lot more sense, as is the
case when:

You have a very good understanding of the product.
There’s a very good understanding of what the customer needs.
It is really well organized; you could march the team through the waterfall
model process.
The scope is clear.
The deliverables are clear.
The methods needed are understood.

Agile will work better when you’re not in that situation, as is the case
when:

There’s a lot more ambiguity around scope.
The deliverables aren’t nearly as clear.
The methods may not be understood. (Given that you don’t know the
deliverables, you probably don’t know the methods that you’ll use to
achieve them. )

A Blended Example

Does this mean you’re in a situation where it’s a bifurcation: it’s either
traditional or agile? It’s not that easy. There are some environments
where you would want to blend the two. Integrating the two is a good
choice in some instances. There is some conceptual value to think about
how you could do so.

It could be that some parts of the project are more uncertain than others.
In places where there’s more uncertainty, an agile approach is likely to
work better. And more of a traditional approach will work better in the

places where you understand more. It also could be that you have an
agile process, but on top of that agile process, you impose some of the
more traditional project management structure.

Watch: What Is the Role of the Project Manager in
Agile?

Part of your responsibility, when using an agile approach, will be to
change your mindset from one of maintaining control over the project and
the team members toward a mindset of facilitating work. Professor
Nozick explains.

Transcript

So, the role of someone who has been a project manager as they step
into the agile world. This is a complicated question because they’re
conceptually very different environments. In a traditional project manager
role, that’s a lot about control— organizing and control. An agile world is
much more about facilitation.

So, in an agile world, team members and teams, the idea is that they
should be empowered to experiment about how to do things. And then
they should make choices. and those choices should lead to frequent,
high- quality deliverables of something of value to the customer. Whether
each deliverable is actually delivered, that’s a separate decision entirely.
But, this whole philosophy is really about team members being
empowered and teams being empowered. The idea that people would be
self-organizing and individuals take ownership— that’s a very different
world than a more traditional project management world where it’s a
much more controlled: you do this, I watch you do this, you get done with
this, move on to the next thing. So, the project manager— the role that’s
left for that kind of a person is really supporting these individuals to be
able to achieve that level of performance, and supporting teams so that
they can achieve this level of performance and independence. So,
independence in an agile world is a good thing because we need that
level of performance to really deliver in a very complicated world.

So, traditional focus has been on control and efficiency and the speed of
getting a task done. That’s a big shift for the project manager into a role
much more focused on supporting and empowering, leading to the right
work being done effectively. So, this idea of the right work being done

effectively, that’s something being discovered as we learn more about
what needs to be done. So, that’s a very different thing than in a project
management world where you have the scope defined up front, you have
the requirements up front, to a world where, in fact, the right work being
done will be discovered over time. And then people are fast enough,
efficient enough, independent enough, have enough skill, that they can
go in and, as parts of teams, really produce valuable deliverables on a
regular basis.

Comparing Agile to Traditional

Answer the following questions as you compare an agile approach to a
traditional project management approach.

You must achieve a score of 100% on this quiz to complete the
course. You may take it as many times as needed to achieve that
score.
Back to Table of Contents
CEPM505: Agile Project Management Approaches
Cornell University
© 2018 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners.

Project Management Challenges
Instructions:
You are required to participate in all of the discussions in this course.
Discussion topic:

Create a post in which you identify what you see as the single biggest
challenge facing project managers who are trying to adapt to an agile
approach. What would you recommend that might help? Offer 1-2 ideas.

Instructions:
Click Reply to post a comment or reply to another comment. Please
consider that this is a professional forum; courtesy and professional
language and tone are expected. Before posting, please review
eCornell’s policy regarding plagiarism (the presentation of someone
else’s work as your own without source credit).
Back to Table of Contents
CEPM505: Agile Project Management Approaches
Cornell University
© 2018 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners.

https://s3.amazonaws.com/ecornell/global/eCornellPlagiarismPolicy

Course Project, Part Two: Comparing Agile to
Traditional

As discussed, it is the specific characteristics of the project that will
dictate the right structure for project planning, management, and control.
In this part of the course project, you will have an opportunity to make a
comparison. When will agile make the most sense? When will a
traditional approach make the most sense?

Completion of this project is a course requirement.
Instructions:

Download the Adaptable Project Management Approaches Course
Project, if you have not already done so.
Complete part two.
Save your work.
You will not submit your work now. You will submit your completed
project at the end of the course for instructor review and credit.

Before you begin:
Review the grading rubric for this assignment. Please review eCornell’s
policy regarding plagiarism.
Back to Table of Contents
CEPM505: Agile Project Management Approaches
Cornell University
© 2018 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners.

https://s3.amazonaws.com/ecornell/content/CEPM/CEPM505/CEPM505_course-project x

https://s3.amazonaws.com/ecornell/global/eCornellPlagiarismPolicy

Module Two Wrap-up: Compare Agile to Traditional

As you have seen, an agile project-management approach has some
similarities to and some dissimilarities from a traditional approach. It will
be the project, and not your personal preferences, that will dictate which
approach will be most effective. By understanding the nuances of the
similarities and differences, you will be better positioned to use either one
and to make appropriate choices about when, and under what conditions,
each one would best meet the needs of your project. In this module, you
compared and contrasted different models. You had a chance to examine
how the roles and the responsibilities of the project manager will change
depending on which approach you are working with. You also had an
opportunity to discuss relevant challenges with your peers, and you
completed the second part of your course project, in which you drew
critical comparisons.

Module 3: Consider the “Flavors” of
Agile

1. Module Three Introduction: Consider the “Flavors” of Agile
2. Watch: Looking at the Flavors of Agile
3. Tool: Map the Attributes
4. Watch: Examine Scrum
5. Read: A Detailed Look at Scrum
6. Watch: Examine Extreme Programming
7. Read: A Detailed Look at XP
8. Watch: Examine Lean
9. Watch: Examine Kanban
10. Considering the Flavors of Agile
11. Watch: Agile vs. Lean
12. Tool: The Adaptable Project Management Approaches Action Plan
13. Course Project, Part Three: Considering the Flavors of Agile
14. Module Three Wrap-up: Consider the Flavors of Agile
15. Read: Thank You and Farewell

Module Three Introduction: Consider the “Flavors”
of Agile

You have had a chance to examine the ways that agile
differs from a traditional, linear, command-and-control
style of project management. But agile doesn’t indicate
one rigid approach. There are many variations on this
theme and several ways you might adapt some elements

of an agile philosophy for your own use to get better results on your
projects. Now you will examine some of the different “flavors” of agile,
including scrum and extreme programming (XP). You will also be
introduced to the core ideas in lean and the kanban management
structure. Lean is a set of ideas that were developed in the context of
manufacturing but can be used in the project management context and
are complementary to the core ideas of agile. You will work through its
different attributes and consider which are the best options for your
implementation needs. You will also complete your graded course
project, in which you will find practical applications for agile approaches
in your project work.

Watch: Looking at the Flavors of Agile

What does it mean to say “there are different flavors of agile”? Professor
Nozick explains more and discusses the two key approaches that we’ll
focus on here.

Transcript

So, there are many different flavors of agile, for want of a better word.
There are many different ones. They all share the same perspective. The
most important thing, I think, to come away with, is understanding the
mindset of agile, and how the mindset of agile differs from a traditional
project management mindset. To illustrate a couple of these flavors, we’ll
talk about scrum and extreme programming. But it’s important to realize
that an instance of agile in a company may be a modified version of one
of these flavors that fits that company’s business particularly well.

Tool: Map the Attributes

• Use this helpful Map the
Attributes Worksheet to guide
your work

Professor Nozick will discuss several different implementations and
approaches, along with their critical characteristics. You want to be able
to identify when each of the options might help you in your project work.
Not every approach will suit every project; they are significantly different
in terms of their guiding philosophy and application. As you review the
critical teaching in this module, work through the accompanying
worksheet on this page to find applicability in your own project
management efforts.

https://s3.amazonaws.com/ecornell/content/CEPM/CEPM505/CEPM505_tool-map-the-attributes x

Watch: Examine Scrum

Scrum is a simple framework for completing complex project work.
Originally developed for software development, scrum is now widely used
within many different contexts, as Professor Nozick explains.

Transcript

So, scrum is an instance of agile. Okay? So, let’s talk about scrum. The
work to be done for the project under the scrum paradigm is all put into a
product backlog list. And what that is, is it’s a vision for the project. Think
of it as a list of work packages, a list of things that have to be done to
finish the project.

Now, you might say, “Hey, wait, you just told me I have to know all this
upfront.” This is where this agile part comes in. That list is dynamic. And
what you do is, you put the most important work elements on the top of
that list and the less important ones on the bottom. Okay? So, inside your
organization you will have a product owner that’s in consultation with the
customer and they will do some prioritizing so that they can maximize the
value created to the customer over time. So, give them as much as they
can. Value-wise, put the more valuable things at the front. So, the
product backlog is constantly being updated and refined and the scrum
master— I know I’m using a lot of words, we’ll talk about them carefully
as we go— the scrum master will help with this. Okay?

So, this concept, conception and initialization phase in the waterfall
model, that core thing is being— big piece of that becomes this product
backlog list. Okay? So, the things on top are more valuable. The things
on the bottom are less valuable. It doesn’t mean the things on the bottom
are easier and the ones on the top are harder. It’s a prioritization. Okay?
The things that the customer values more are things they understand
they need. The things at the bottom are things they may not know as
much about or may need some more evolution. And so, when you’re
going to go ahead and start working on pieces of the project, you’re going
to flesh out the things that are more important first.

So, the things at the top of the backlog list, there will be more information
that’s fleshed out about them— unless that needs to be clarified. The
idea is that you may found out some of those features that are a little
lower on the list, in fact, you find out they are not needed and— or their
cost is too much to justify the benefit— to be given the benefit— the
benefits don’t justify the costs you would incur. So, the backlog list, things
will go off that list. You just won’t complete them because they’re not
worth it. New things will come on because the customer didn’t realize it
and it turns out, as you learn more and more, is a very important thing to
do. And, in those cases, the benefit does justify the cost.

So, now let’s get to the iteration part. We’ve kind of dealt with this fluidity
in the requirements and the idea that the requirements will evolve over
time. And we’ll handle that by identifying work packages. The most
important we’ll do first. And the ones that we see that don’t seem to be as
important will go to the bottom. And, as we get more clarification, we’ll
either find out they’re more important and we need to have them and we’ll
build them— continue to flesh them out—or we’ll drop them off the list or
new things will be added. Okay, so you have that management of that
whole product backlog process. Okay? And then the work’s going to get
done via these iterations. They’re called sprints and scrum.

Each sprint is an iteration of the work and it’s done in a fixed time limit.
Okay? I think a month or so. Think sprint equals iteration, equals fully
self-contained little project. That’s a nice way to, I think, imagine how
scrum works. You constitute your—you’re managing this backlog of work
and you’re taking a mini project off the top, which is the most important,
based on the customer owner’s feedback, okay? And you’re then doing it.
And you’re learning a lot while you do it. And that whole process helps
you understand how to make that— how to improve that product backlog
of work so the next mini project can be done in the most valuable section
of the work. Okay? That’s out there that you see, that’s out there. Okay?
The sprint is done by a development team. Okay? That—the team that
supports that work is self-organizing and they have all the skills needed
to do the work. Okay?

There is someone called a scrum master. They make sure that the scrum
philosophy— the scrum methodology—is understood by everybody and
followed. Okay? Think of it as: they help support the process, support the

work of the team with process that will actually help them be more
effective. And they’re always looking at what’s effective, what can be
done to make them more effective. So, they support the team. They also
support the project owner. Okay? They make sure that the project goals
are understood, or the evolving goals are understood. That the backlog—
the work in the backlog—is well communicated to the team, okay? And
they support the development team so that they’re very effective. So, the
scrum master has a very important role in this whole process: the idea
that they’re going to make sure the methodology is understood and that
people are following it, okay? They’re supporting the project owner
because they’re making sure everybody understands what the project
customer actually needs. And they’re communicating that. And, of
course, the backlog— the work backlog—has that information in it. And
then they’re also supporting the development team so that they can be
effective. Okay?

So, think: product backlog list, implement a sprint, groom the product
backlog list, implement a sprint. That’s kind of the core idea of how scrum
operates. So, let’s talk a little bit more about a sprint, okay, because this
is the mechanism through which the work will actually achieve— will be
achieved. Okay? So, the first thing is there’s a planning meeting. So,
you’re going to go into a sprint, which is going into an iteration, and
there’s going to be a planning meeting. And that planning meeting will
bring the stakeholders together. Who are the stakeholders? The product
owner, the team—because they’re going after the work— and the scrum
master. And they’re going to conclude what’s going to be worked on from
the backlog. Okay? And what’s going to be delivered— what will be
delivered at the end of the sprint. Okay?

So, there is an understanding of what the goals are— a crystal clear
understanding. Then it’s up to the development team to figure out how
they’re going to organize themselves to do the work. And, so, they’ll do
this work through the sprint execution phase. There’s something called a
daily scrum. The idea is that it’s very important for the team to get
together and meet every morning. They’ll do that—or daily— for 15
minutes or so. So, it’s meant to be a very quick meeting so that people
are synced up. What’s everyone done since the last meeting? What are
they going to do today? Are they having any problems? Okay?

So, it’s not meant to be a long, long, long meeting that cuts into a lot of
time. It’s meant to efficiently pass information, okay, from one person to
the next. At the conclusion of the sprint, there will be a review of the
product because they’ve now added some new functionality to that
product. And then they’ll review the process and see if the process could
have been done better. So, now you could think of this process as:
product backlog list, visit that. Get it in shape. Have a planning meeting
and figure out what you’re taking off to do in this next sprint. Go sprint.
Then review the product as it stands at that point now that you’ve added
the content that was created during the sprint. Then you review the
process. Can you learn anything? Learning is a very big part of being
agile. Okay? Learning as rapidly as possible because if you don’t learn
you’re going to make same mistake twice. Right?

So, reviewing the process and then going back to the product backlog
list, doing whatever you need to do to groom it, and then sprint—
sprinting again. So, this structure— if you think about it—means that
there’s a little mini project and that’s really what’s underway at—all the
time. Well, the project could have very large scope and one mini project
may not be enough. You may not be able to do a scrum meeting with that
many people because the scope is so big. Okay? In this case you will
have scrums of scrums. Okay? So, you’ll have that— you’ll still be
grooming this product backlog list. But now, instead of just having a
planning meeting of how you are going to implement the scrum— what
work you’re going to do, I should say, and what need that’s achieving for
the customer.

Instead of just doing that in a single— for a single thing that’s a
development team kind of—worth of work, you’ll have a planning meeting
of— which will figure out what a bunch of scrums might be doing. What
one, two, three, four scrums will be doing. And then, each of those
scrums will go off and do their own planning meeting. They’ll do their own
sprint. They will do their own review. And then, when they’re done, when
each one of those scrums is finished, then there’ll be a bigger review to
look at all the work across all the scrums that were completed. Okay?
And then you’ll review the process that went through— all the scrums
went through.

So, you get much more complexity. But, for a bigger project, you will

have more than a single mini project underway at a time. You’ll have
several of them. Okay? So, this will require more organization. Okay?
More collaboration. So, does the project manager role still exist in scrum?
That’s an important question. It honestly doesn’t exist the way it was
before in a traditional model. But there are roles in scrum where the work
to be done is very consistent with the skills of a traditional project
manager. Okay? So, think about the scrum master. That’s a person who
understands the process for scrum, and understands how to
communicate that to individuals, and knows how to see that it’s being
followed.

That would be a skill set that a traditional project manager would be quite
good at. Okay? But they are a facilitator to the actual work being done.
Okay? The product owner is another place for a project manager. A
project manager has lots of skills that would fit in that project— product
owner role. Okay? The idea to understand the forest for the trees. The
understand of how to— what priorities look like. Okay? The idea of how
to communicate to a customer themselves to a team—that sort of stuff.
Okay? When the project requires multiple scrums, you have a lot of room
for a traditional project manager in a lot of ways because you have a lot
of coordination. Okay? You don’t have the command and control you had
before— that kind of falls away, to some degree, in a in a scrum
environment.

But that idea that you’re going to communicate and have teams
communicate seamlessly together without just sinking everybody under
the weight of that communication. The idea that you are going to manage
budgets. These are things that are very, very important when projects get
complicated in the agile world, okay? And so, that’s a place where project
manager skills could come in very handy. So, in the traditional command
and control structure of a project manager is not so much in the agile
world. But those skills that are behind a successful project manager, they
have very, very important role in a scrum world and in an agile world.

Quick check: Under what conditions is scrum most helpful:
when there are many work items and the team needs help

prioritizing them or when you have a detailed project
network with precedence constraints?

Scrum helps with prioritizing. The product owner does the prioritizing to
maximize the value created. The product backlog list is constantly
updated and/or refined, and the scrum master helps with this.

Read: A Detailed Look at Scrum

• Scrum has applications in many
kinds of project management
work

• The role of the project manager
changes in a scrum approach,
but the key skills that have made
you successful in a traditional role
will serve you well in scrum

As we take a detailed look at scrum and the advantages it offers, we can
begin with some definitions. A scrum includes sprints. Each sprint is an
iteration of the work and is done within a fixed time limit. Think of a sprint
as a fully self-contained little project.

Backlog

In scrum, someone manages a backlog of work. (While backlog in a
general context means work that has piled up and has been neglected or
not attended to, in the scrum world, it simply means a list of activities;
there is no negative connotation to the word backlog in scrum.) The
project managers take a mini project off the top of the backlog, and that’s
the most important work to be done based on the customer or project
owner’s feedback. The team then does the work and is learning about the
customer’s needs throughout the process. That whole process helps the
team understand how to improve that product backlog of work so that the
next mini project can deliver the most value.

Scrum Master

Scrum includes a role of a scrum master, who is the person who makes
sure that the scrum philosophy, the scrum methodology, is both
understood and followed by everybody. The scrum master is there to

help support the process and to support the work of the team with a
process that will actually help them be more effective. The scrum master
is always looking at what’s effective and asking what can be done to
make them more effective. They support the team as well as the project
owner and make sure everyone understands what the project’s customer
actually needs and is the one who communicates that. The scrum master
makes sure that the project goals are understood or the evolving goals
are understood and that the work in the backlog is well communicated to
the team.

The scrum master has a very important role in this process. He or she
has to:

Make sure the methodology is understood
Make sure that people are following the methodology
Support the project owner
Implement a sprint
Support the development team so they can be effective

Sprint

A sprint is the mechanism through which the work will actually be
achieved. The sprint is done by a development team. The team that
supports that work is self-organizing; they have all the skills needed to do
the work.

First, there’s a planning meeting that brings the stakeholders together.
The stakeholders are the product owner, the team doing the work, and
the scrum master. They’re going to determine what’s going to be worked
on from the backlog and what’s going to be delivered at the end of the
sprint. There is a clear understanding of what the goals are. Then it’s up
to the development team to figure out how they’re going to organize
themselves to do the work. They’ll do this work through the sprint
execution phase.

Daily Scrum

The daily scrum is a quick meeting every morning. It is essential in scrum
for the team to get together and meet each morning for about 15 minutes

to make sure that people are synced up. Questions include the following:
What’s everyone done since the last meeting? What’s everyone going to
do today? Is anyone having any problems? It’s not meant to be a long
meeting that cuts into a lot of work time; it’s meant to efficiently pass
information from one person to the next.

Iterations

At the conclusion of the sprint, there is a review of the product. The team
has added some new functionality to the product and now needs to
review the process to see if anything could have been done better. You
can think of this process as a product backlog list visit. The team should
have a planning meeting to figure out what should be done in the next
sprint. Then they sprint again. They then review the product as it is at that
point. Once content has been added that was created during the sprint,
the team reviews the process. It is important for the team to ask at this
point if they can learn anything from what has happened so far. Learning
is a very big part of being agile, and you want to learn as rapidly as
possible. If you don’t learn, you will likely repeat mistakes.

Again, the team is reviewing the process and then going back to the
product backlog list, doing whatever needs to be done to groom it and
then sprint again. With this structure, there’s a mini project underway at
all times.

The project could have a very large scope. The team may not be able to
do a scrum meeting with so many people if the scope is particularly big.
In this case, it’s best to have scrums of scrums. The team should still be
grooming the product backlog list, but rather than having a planning
meeting on how to implement the scrum and what work to do, you should
ask what need that is achieving for the customer.

And instead of just doing that for a single item, there would be a planning
meeting to figure out what multiple scrums should be doing. And then
each of those scrums would split off and do their own planning meeting,
followed by their own sprint, followed by their own review. And then when
they’re done and each one of the scrums is finished, there should be a
larger review to look at all the work across all the scrums that were
completed. Finally there would be a review of the process all the scrums

went through. In such a case there is much more complexity involved,
which requires more organization and more collaboration.

The Role of the Project Manager

Does the project manager role still exist in scrum? That’s an important
question. The project manager’s role doesn’t exist the way it did before in
a traditional model, but there are roles in scrum where the work to be
done is very consistent with the skills of a traditional project manager.

For example, consider the scrum master, who again, is the person who
understands the process for scrum and understands how to
communicate that to individuals, and also knows how to see that it’s
being followed. That would be a skill set that a traditional project manager
would be quite good at. They’re now a facilitator to the actual work being
done. The product owner is another place for a project manager. A
project manager has lots of skills that would fit in that project product
owner role. The idea here is to understand the big picture, to understand
how to identify what priorities look like and how to communicate to a
customer, to a team, and so forth.

When the project requires multiple scrums, there is room for a traditional
project manager due to the need for coordination. There isn’t the
command and control like before; that falls away, to some degree, in a
scrum environment. But that idea of having teams communicate
seamlessly together and to manage budgets, and so forth, are very
important when projects get complicated in the agile world. Those skills
that are important in a successful project manager still have a very
important role in a scrum world and in an agile world.

Watch: Examine Extreme Programming

Another project management approach to consider is called extreme
programming, or XP. Originally designed for use in software-development
contexts, it has some similarities with scrum but some key differences, as
Professor Nozick explains.

Transcript

So, just to show you a second flavor of agile, we’ll talk a little about
extreme programming. So, extreme programming was really centered
around software development. Scrum is more process focused and it can
be applied to a variety of different kinds of projects in addition to
software. XP was really designed with software in mind.

Again, it’s iteration based. It’s an agile method. Same core idea of having
iterations and having the work done in iteration. It also works off a
prioritized list of requirements. It also focuses on empowering individuals
and teams. XP identifies five—the philosophy of XP has five key values.
And one thing I think is very valuable when thinking about these values,
is what—they reinforce the mindset of agile, okay? When you think about
these values— same thing when we talked about scrum, we talk about
agile in general, the agile manifesto— they are a very different mindset.
And you have to have that mindset to operate well in that environment
because it’s not really an environment riddled with rules. So, you have to
make decisions that are consistent with those kinds of values.

So, let’s talk about the XP values. So, one of them is communication,
with a big emphasis on the word honest. Honest is important so it’s easy
for everyone to understand what’s really been done, and what needs to
be done, and how long it will take. So, if people aren’t honest, it’s very
easy in these agile systems to get into trouble. So, communication is very
important, with an emphasis on being honest. Feedback. Feedback is a
cornerstone of an agile philosophy. The idea is the sooner the feedback
occurs, the more likely it is you can get that product done correctly and
done quickly. So, in a software world under—getting that feedback is
important so that what’s developed is what needs to be developed and

whatever issues are in the code, they get fixed. That no one’s hiding
things.

Another key value is simplicity. The easier, the more simple— simplicity
doesn’t mean trivial. Adapting the simplest solution to your problem or the
simplest solution to meet the customer requirements, that’s a very good
thing. Because the more complicated something is, the more difficult it is
to build, which means the more expensive it will be and the more difficult
it is to fix when problems are found. So, simplicity is a core value in XP.
Courage. Courage is the forth value in XP or one of the values in XP. If
something isn’t good enough, have the courage to say it— don’t ignore it.
And get it fixed. And none of this can work without mutual respect. So,
the five key values: communication with a heavy emphasis on honesty,
feedback, simplicity, courage, and showing respect. So, there are
important practices in XP. There are practices that are process-,
customer-, developer-, centric. And there are things that focus on the
code. And there are things that are focused on software process.

So, think of it as practices that are more process oriented, things that are,
really, can find a software process, and things that are code based. And
this is a little bit detailed. If you’re not in the software world this is not an
instance of agile that you’re necessarily going to become involved in. But,
it’s useful to see instances of different flavors of agile because it gives
you a better sense of the underlying, subtle philosophy that you really
have to internalize to be good at implementation of it. So, let’s start at the
simpler level, “code centric,” because code is simpler in terms of the
hierarchy between that software process and then the process of the
entire project. So, making that—one of the code centric practices in XP is
the idea that you make the code— the design for the code, the
architecture of the code— as simple as you can so it’s easier to develop
and it’s easier to change when needed. So, that’s simplicity in the code.

The idea of refactoring code, that is, taking code that’s already been
written and making it better— making it simpler or making it easier to deal
with. And then, also, developing and using coding standards so that
everyone’s code is in the same—done in the same—philosophy makes it
much easier to find bugs. Generally, the person who wrote the code is
not the one finding the bug some amount of time later. Software process
centric things like, so, instead of just one person writing code all by

themselves, putting two people together to write code together—that’s
called pair development. So, you have a driver and you have a navigator.
These pairs are often fluid. People are always with the same person
forever. They actually mix people up over time. And that’s a good thing to
do. The idea that the code is owned by the crowd as opposed to an
individual person. And test-driven development. Those are some
practices of XP that are software process oriented. And if we go up
another level, you can think of ones that are customer slash developer
centric.

So, having the customer have a voice on the team, for example. That’s a
very key process. That’s a key element of agile—the customer voice.
Having releases on a regular schedule that’s manageable. That the
process of planning for— when I say manageable, that it’s at a
unsustainable pace. That people really can get those releases done with
a reasonable level of stress as opposed to everybody running around
with their hair on fire all the time. So, there are primary roles in XP and
then there are support roles. Primary roles are the customer and the
developers. Support roles—a coach in the XP process, for example. A
manager slash a tracker of what’s been accomplished, what needs to be
accomplished and all of that.

Quick check: How is XP similar to scrum?

XP works from a prioritized list of requirements, like scrum, and it focuses
on empowering individuals. XP emphasizes five core values:
communication, feedback, simplicity, courage, and respect.

Read: A Detailed Look at XP

• Examining XP helps you
understand the subtleties of
adaptable approaches

• XP is code-, process-, customer-,
and developer-centric

This examination of extreme programming (XP) is a little bit detailed, but
we have a good reason for examining it here. If you’re not in the software
world, this is not an instance of agile that you would necessarily be
involved in, so why should you concern yourself with it?

As you expand your understanding of adaptable project management
approaches, it’s useful to see instances of the different flavors of agile. It
gives you a better sense of the underlying, subtle philosophy that you
really have to internalize to be good at any implementation of it.

There are four important practices in XP: being code-, process-,
customer-, and developer-centric. There are things that focus on the
code and there are things that are focused on software process. So think
of it as practices that are more process oriented, things that can find a
software process, and things that are code based.

So let’s start at the simplest level: code-centric. This is the idea that you
make the code, the design for the code, and the architecture of the code
as simple as you can. That makes it easier to develop and is easier to
change when needed. This is what is meant by “simplicity in the code.”

You will hear people talking about the idea of refactoring code; that’s
simply taking code that’s already been written and making it better,
making it simpler, or making it easier to deal with. And then, also,
developing and using coding standards so that everyone’s code isn’t the
same is done in the same philosophy: it makes it much easier to find
bugs. Generally, the person who wrote the code is not the one finding the

bug.

Process-centric means that instead of just one person writing code all by
themselves, two people are paired together to write code. This is referred
to as pair development. There is a driver and a navigator. These pairs
are often fluid, meaning people are not always with the same person long
term. Mixing people up over time is best. The idea is that the code is owned
by the crowd, as opposed to an individual person, in a test-driven
development.

Regarding the idea of customer-centric and/or developer-centric, the idea
is that having the customer have a voice on the team is key. That’s a key
element of agile: the customer voice. Being developer-centric means that
you have a process in place to make sure you can execute releases on a
regular schedule that’s manageable, at a pace that people can sustain
without an unreasonable level of stress.

In XP, there are primary roles and there are support roles. Primary roles
are the customer and the developers. Support roles are coaches in the
XP process, for example, a manager and a tracker of what’s been
accomplished and what needs to be accomplished.

Watch: Examine Lean

Now Professor Nozick will lead an exploration of lean, which was
originally created for use within the manufacturing realm. It emphasizes
eliminating waste and focusing on simplicity, visibility, and continuous
improvement.

Transcript

Let’s talk about lean. So, lean is a philosophy that’s focused on
eliminating waste. Where did lean come from? Well, lean came out of the
manufacturing sector; it originated in manufacturing. And what was
considered waste is trying to control inventory, overproduction, scrap,
rework. Because none of these things you can get money from the
customer for. Right?

So, these are things that don’t generate value in and of themselves. So,
the idea within lean is focus on eliminating waste and all the sources of
which waste can occur in the manufacturing enterprise. Lean also
includes the idea of continuous improvement. And the idea is that that
continuous improvement will help you eliminate waste because it will
increase efficiency and it will increase quality. So, concepts that go with
lean. At the forefront is this philosophy of eliminating waste wherever it is
because waste is not something you can charge for. Build in quality.
There is a philosophy out there—a historical one— which says, we test
quality into our product. And that just generates a lot of waste. It does.
So, don’t just test until what remains is high quality. The idea is do it right
the first time. Build the quality in at the beginning. That will minimize
rework and minimize scrap. Lean also has a focus on the whole and not
just optimizing the parts. So, a lean concept is to optimize the whole and
not just think about the pieces in isolation but understand how they all fit
together, so when you don’t bring them all together, all of a sudden
nothing fits, and you’ve got to rework everything. Okay?

So, lean has its eye on: what are you trying to do? And optimizing the
whole. And then, taking that into each of the elements, so each of the
elements is created with as little waste as possible. It also talks very

directly about simplicity. Because it’s very hard to build things that are
complicated. It’s much easier to build things correctly that are simple.
Right? So, you only want as much complexity as you need to actually do
the job, nothing more. Visibility. It’s hard to find mistakes if you can’t find
them. If the work is not clear enough, simple enough, that it’s visible.
Okay? So, visibility is very important to lean. Continuous improvement
and flexibility. So, those are the important, some of the important
concepts that lean is based on.

Quick check: Would a lean approach ask you to deliver
work frequently and gather feedback often or wait until all
the work is complete and wait for feedback at the end?

Lean asks you to support continuous improvement, eliminate waste, and
reduce rework by building in quality the first time rather than waiting to

test everything at the end.

Watch: Examine Kanban

Kanban is conceptually different from the iterative and incremental nature
of agile, as Professor Nozick explains. It has applications for many kinds
of project management work.

Transcript

Now let’s talk about kanban. Let’s start with what’s called a Kanban
Board. So, this is a chart, a mechanism, to create, effectively, three lists.
The work backlog, which is the work to be done, so it’s a list of stuff to be
finished; a list of what’s being worked on right now; and a list of all the
work that’s completed. So, all work will be in one of three places: in the
backlog, work in process, or completed work. The working process list is
quote unquote “capacitated.” So, you can’t stuff all the work backlog onto
the work in process list. Okay?

In this example, I only have two slots for work in process. So, once those
two slots are taken up, no more work can be done at that point.
Something needs to come off that work in process list and move to
completed before I can bring more work on. So, kanban is what’s called a
pull system. Once a piece of work is completed, it triggers a pull to initiate
the next piece of work to come into work in process. So, this has a very
manufacturing feel to it. Right? This idea of work in process; that’s a very
common manufacturing term. Conceptually, this is quite a bit different
than the iteration philosophy and agile. But they try to achieve the same
thing.

So, iterations are a mechanism to limit work in process. Okay? The
kanban has slots on board. Scrum has sprints. Okay? That eliminates,
that moderates how much work can be done at the same time. Okay?
Iterations are work are—in agile, are linked to a working piece of a
project, a something delivered. That concept doesn’t really exist in
kanban. No such concept is— nothing like that is required for the
increment of work that’s going to be pulled into work in process. So, why
do we have this? Why limit work in process? Well, the obvious reason is,
it improves visibility. If everything is being worked on at the same time, its

hard to figure out what’s broken.

So, you’ll generally get— find it easier to figure out where the problems
are, and then fixing those problems. Also, it’s going to be easier to adapt
to change. So, if you’re doing a controlled amount of work at a time,
when something goes wrong, you can figure it out. When you need to
change something, it’s doesn’t touch as much stuff. It’s also way easier to
implement continuous improvement. Okay? Because you’re studying a
smaller amount of work, but you can do it in more detail. And then, as
you learn something, you can implement it to the next piece of work.
Okay? So, this—limiting work in process, does make sense.

Quick check: Why does kanban seek to limit the amount of
work that’s in process?

There are four reasons that kanban seeks to limit work in process: to
improve visibility; to reduce rework, on the theory that problems will be
found and solved quickly; to make adapting to change easier; and to

make it easier to implement continuous-improvement methods.

Considering the Flavors of Agile

Answer the following questions regarding the flavors of agile.

Watch: Agile vs. Lean

Professor Nozick offers a comparison of agile vs. lean, as well as an
exploration of what a hybrid agile-lean approach might look like.

Transcript

So, let’s compare and contrast agile and lean. So, agile. The primary
focus is on quick feedback through these iterations. And the positive
impacts of this are understanding evolving customer requirements and
being able to integrate them. This will support a closer interaction with the
customer. Shorter development cycles make it easier to find problems
sooner, as opposed to waiting and finding out much later on that there’s
something wrong. Lean, on the other hand, has the singular focus on
eliminating waste. Okay? And a systems level focus as well. So, think
agile, think: iteration. Lean, this is very simplistic. Think: eliminate waste.
So, in big projects, under agile, there’s going to be many iterations
underway at the same time. You’re going to need to coordinate them.
And this is where the two can be complimentary because they are not the
same thing. Lean and agile are different. Okay? But they can be very
complimentary. Lean’s emphasis on the system level; that’s a very useful
idea when you have to coordinate stuff together. Okay? And that can
lead to a hybrid agile/lean model. Okay?

So, I think it’s important to understand the waterfall model itself and how
it compares and contrasts with agile, and how lean compares and
contrasts with the other two. Okay? Because they each have something
very important to offer. In some environments it will be clear which one is
the dominant way to go. And in some situations you’ll think about
blending them together. Okay? And that’s a very important set of
concepts. That you think about the waterfall model as this traditional,
linear process where you have much more knowledge of what’s going on.
Agile, being very responsive to customer needs and being very iteration
focus. And lean kind of looking at a big system and going, “Okay, what
am I trying to do? And let’s do it with the least waste as possible.” All of
those perspectives are useful and they have a role. And the project’s
really going to dictate how you use those concepts.

Tool: The Adaptable Project Management
Approaches Action Plan

• The Adaptable Project
Management Approaches Action
Plan

You may find it helpful, now or in the future, to apply the different
paradigms presented in this course to your project management efforts.
You can use the action plan made available on this page to guide your
efforts in this regard. Consider what you hope to achieve and how the
strategies presented here might help.

https://s3.amazonaws.com/ecornell/content/CEPM/CEPM505/CEPM505_action-plan x

Course Project, Part Three: Considering the Flavors
of Agile

You have had a chance to explore some of the flavors of agile, the critical
characteristics of each, and the different benefits they offer to a project
manager. Now you have a chance to apply these concepts to your own
work and provide an analysis of how the different approaches might help
you in different circumstances.

Completion of this project is a course requirement.
Instructions:

Download the Adaptable Project Management Approaches Course
Project, if you have not already done so.
Complete part three.
Save your work.
Review your completed project, then click the Submit Assignment
button on this page to attach your completed course project document
and send it to your instructor for evaluation and credit.

https://s3.amazonaws.com/ecornell/content/CEPM/CEPM505/CEPM505_course-project x

https://s3.amazonaws.com/ecornell/global/eCornellPlagiarismPolicy

Module Three Wrap-up: Consider the Flavors of
Agile

You have had a chance to examine the ways that agile differs from a
traditional, linear, command-and-control style of project management. But
as you have seen, agile doesn’t mean one rigid approach. There are
many variations on this theme and lots of different ways that you might
adapt an agile philosophy for your own use to get better results on your
projects. In this module, you examined some of the different flavors of
agile, including scrum and extreme programing. You also explored the
ideas of lean and an implementation of lean for project management
called kanban. You accessed a tool to help you map the different
attributes of each, and you considered which are the best options for your
implementation needs. You also completed the final part of your course
project and an action plan to guide your efforts on the job.

Linda K. Nozick
Professor and Director

Civil and Environmental Engineering
Cornell University

Congratulations on completing “Agile Project Management
Approaches.”

I hope this course has given you insight into different ways that you
might approach the challenges of project management, and that the
concepts and strategies presented here put you in a better position to
serve your projects and your organization well.

From all of us at Cornell University and eCornell, thank you for
participating in this course.

Sincerely,

Linda K. Nozick
Read: Thank You and Farewell
Back to Table of Contents
CEPM505: Agile Project Management Approaches
Cornell University
© 2018 eCornell. All rights reserved. All other copyrights, trademarks, trade names, and logos are the sole property of their respective owners.

Table Of Contents
Module 1: Consider Incorporating Agile into Your Work
Module 2: Compare Agile to Traditional
Module 3: Consider the “Flavors” of Agile

Turn in your highest-quality paper
Get a qualified writer to help you with

“ Project 5 ”

Get high-quality paper

NEW! AI matching with writer