Assignments

CEPM505_course-transcript.pdf

Home >English homework help >Assignments

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

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.

CEPM505: Agile Project Management Approaches Cornell University

Table of Contents

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

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

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

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

Module 1: Consider Incorporating Agile into Your Work

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

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

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

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

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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."

©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.

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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.

CEPM505: Agile Project Management Approaches Cornell University

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

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

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).

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

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

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

Module 2: Compare Agile to Traditional

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

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:

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

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

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

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

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

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.

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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?

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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?

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

Considering the Flavors of Agile

Answer the following questions regarding the flavors of agile.

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

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.

CEPM505: Agile Project Management Approaches Cornell University

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

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.

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

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

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

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.

Back to Table of Contents

CEPM505: Agile Project Management Approaches Cornell University

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

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