Episode 186 (Audio): The Agile Manifesto for Project Managers (Free)

Play Now:

This episode is sponsored by:

In this episode of The Project Management Podcast we are going to review "The Manifesto for Agile Software Development". It is better known by the simpler name The Agile Manifesto and you can find it at http://agilemanifesto.org/.

The focus of our review of the manifesto is (of course) going to be on agile project management - in particular: what does the manifesto and its 12 principles mean for our work as PMs in an Agile environment.

I hear from a lot of project managers wanting scrum agile project management training, and before you move on to the more advanced topics, it's important to get the foundations right, which is exactly what this episode will help with.

I am going to give you my personal thoughts on this by analyzing the manifesto itself and then looking at each of the 12 principles and relating them to a PM's work. Whether you are using scrum project management, or have taken on the role of project manager in SAFe Agile or are working (or plan to work) in any other agile environment, this episode is a great introduction to the basic principles.

This episode is available both as a video and also as an audio-only version. Stop by at www.pm-podcast.com to download the version you want. Agile project management with scrum is a growing topic for agile practitioners, so this episode is one you won't want to miss!

Correction: At 19:45 I attribute the "Theory Y" to Ouchi. That is incorrect. "Theory Y" is from McGregor.

Episode Transcript

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.

Podcast Introduction

Cornelius Fichtner: This is The Project Management Podcast™. We bring project management to beginners and experts. Find us on the web at www.pm‑podcast.com or send your emails to This email address is being protected from spambots. You need JavaScript enabled to view it..

Cornelius Fichtner: Hello and welcome to Episode #186. I am Cornelius Fichtner. This is The Project Management Podcast™ recorded in the beautiful town of Solothurn in Switzerland, nice to have you with us.

In this episode, we are going to take a look at the Agile Manifesto. And in particular, we are going to take a look at what the Agile Manifesto means for us as project managers.

This episode is available both as an MP3 audio file and also as a video file. So if you are listening to the audio and would like to see the video, come to the website; and if you’re watching the video and you would prefer hearing just the audio, well, come also to our website.

So why are we taking a look at Agile in this presentation? Well, as many of you probably know, we here at The Project Management Podcast™, we also have several PMP® Exam prep products like The Project Management PrepCast™. Loosely stated, the PMP Exam is largely based on a waterfall-like approach. This year, PMI has announced that they will be offering an agile certification. And of course, this interests me as a trainer, as a trained of PMP Exam as well as a trainer of general project management know-how here on the Podcast. That’s why I have decided that I’d like to also bring you a number of episodes about agile methodologies and interviews with project managers who use agile approaches here on the Podcast.

“It’s about time!” many of you are probably thinking. And to start this journey into agile, we have to go all the way back to the beginning of agile movement to the Agile Manifesto to be precise. Well to be really precise, it’s the Agile Manifesto, no sorry, it’s the Manifesto for Agile Software Development. That’s what it’s called. And today, it’s simply known as the Agile Manifesto at www.agilemanifesto.org. We are going to take a look, short look at the history really, really short then we will review the manifesto itself and then we’ll jump into the discussion of the 12 principles that go along with the manifesto. And because this is The Project Management Podcast™, we are going to in this review have a strong focus on project management. What does this Agile Manifesto, what does the manifesto itself the 12 principles mean for us as project managers?

So here is the promised very short history of the Agile Manifesto. It all started in a skiing lodge, in a skiing lodge where 17 proponents of various software development methods met to discuss better ways in which they could indeed manage these software development projects. Today, these 17 folks are known as the Agile Alliance. The manifesto itself was then released at the end of this 3‑day meeting. It was February 11^th to February 13^th, 2001 and on the February 13^th, they released the manifesto. The manifesto itself is very short. You’re going to see that in just a moment. It contains core values and principles. If you really want the in-depth history and why the person from England said: “You know, agile might not be the best word to choose here.” Well, then, why don’t you go to www.agilemanifesto.org/history.html and read the complete history of how the Agile Manifesto came to be.

Here is what the Agile Manifesto actually says: “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.”

Alright, now that you’ve seen the manifesto and heard the manifesto, you saw that there were four core principles there or statements rather in the center. Let’s take a look at these four, things that are valued higher than other things and see what this means in regards to interpreting it for us project managers here.

The first one, we value individuals and interactions over processes and tools. This means that we as project managers have to get used in an agile environment to let the team, the development team and users cooperate together collaboratively and we as project managers, we have to be able to foster these interactions between the individuals on our project.

The second statement: “Working software is valued over comprehensive documentation.” It’s quite clear. We as project managers need to focus on delivery. However, remember that the statement at the bottom clearly said there is value in the items on the right so comprehensive documentation or documentation in general, there is value in documentation. So don’t abandon documentation and don’t say that agile projects are projects where you just simply don’t document this stuff. That is not true. Quite in the contrary, documentation is something that is needed but it doesn’t actually have to be all comprehensive or we don’t have to create a comprehensive documentation that is 6 tons in weight at the beginning of our project.

The next statement was that we value customer collaboration over contract negotiation. This is something that I have personally done throughout my project management career. So to me, this is really not anything that is too new. I used to put the customer vision at the center of my projects and I managed the relationships between me and the team, me and the customer, the end user was important, not the contract. And you won’t believe how often the contract was, yeah, it’s a piece of paper and if really things go totally down the drain then we’re going to go back to it. But you know it’s only a small problem. Let’s try to work together collaboratively here and focus on that so the relationship that you have, the friendship in some cases even with the customers has really helped me a lot in my projects so I am in full support here of this one.

Then the last of these four statements was that we value responding to change over following a plan. For a project manager, this means that well, change is inevitable so go ahead and let the customers change their mind. Allow them to change their minds because believe me or not, they’re going to do it anyway no matter what you do. So instead of putting all of these change management plans into effect that try to minimize change or try to push change away, allow change to happen. Use methodologies that are change friendly, that enable you to take these changes, welcome the changes and implement them into the product that you’re building for your customer.

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.