Introduction¶
Welcome to the agile universe¶
Did you decide to take a certification exam in Agile Project Management from the IAPM and prepare for it through self-study? Then you are exactly on the right track. In this web-based course you will learn everything you need to know about agile project management to excel in your next project and to pass the exam. So let's get started right away!
Why agile?¶
Are you still sceptical about whether an agile project management approach is the right one for you? Let's take a look at possible areas of application for agile project management:

If these examples are too specific for you, perhaps the Stacey Matrix can be useful for you to determine whether you should plan your future projects in an agile or instead in the traditional way. Is the task clear and do you also know how to implement the project? Then you should choose the traditional approach. You can learn how best to plan a traditional project on our web-learning platform for traditional project management. The less clearly the customer’s requirements and / or the implementation are defined, the more appropriate it is to choose an agile approach.

Before you start...¶
... we would like to familiarise you with this training system.
You will see the primary structure on the left-hand side of your computer screen. Here you will find the topics shown above - think of these as your main subjects. The elements of this structure build on each other, so it is advisable to work through them in chronological order. If you are working through the online course while using a mobile device, you can find the primary structure by tapping on the three lines at the top left. If you select a specific topic, the sub-chapters are displayed in a drop-down menu. Here you will find two parts: The theory section and the exercise section. In the theory section, you will find all the theoretical content that is important for day-to-day work in an agile project and for the exam. You can apply and test your newly acquired knowledge in the exercise section. Each learning unit has different lessons, which can be seen in the right-hand margin. To see the lessons in the mobile view, you must be in the respective chapter. You can access the lessons by tapping on the icon with the three dashes and three dots to the right. You can navigate through the various chapters and lessons by clicking on the terms in the outline or by using the buttons at the bottom of the page.
Explanation of symbols used:¶
Attention
Be careful, here is a common pitfall
Question
Things you should ask yourself
Information
Additional insights are given
Exercise
Test your knowledge
Solution
Shows the solution to the exercise
Last but not least: Even if this is an online course, sometimes it is not a bad idea to take notes.
Overview of contents¶
Agile project management is a wide-ranging discipline, as you can already see from the topics covered in this course:
- Agile project environment,
- Scrum,
- Kanban,
- Extreme Programming, and
- people in agile projects.
Not yet familiar with the individual terms? Don't worry, that's what you're here for. In the following chapters, you will learn everything you will need in your future professional life as a member of an agile team.
Attention
Are you preparing for the Certified Junior Agile Project Manager (IAPM) certification exam? Then only the Scrum topic is important for you. The chapters marked with an asterisk (*) in the following overview show you exactly which chapters are relevant. The other chapters are not relevant to the exam, but may still be of interest to you. All chapters are relevant for the Certified Agile Project Manager (IAPM) and Certified Senior Agile Project Manager (IAPM) certification exams.

Story: A corporate trip¶
Let's start with an introduction to the topic.
"You know," Victoria Wilson said, putting down her espresso cup and looking at her colleague Henry Abrams, "we used to try all kinds of things in software development when it came to project management, whether it was the waterfall model, the V-model, whatever, it was of little help in achieving goals. We rarely met the deadlines, and when we did, it was often achieved at the expense of quality. We don't even want to talk about the budgets, which regularly got out of hand." Her gaze passed over the large square in front of the arena, it was bathed in the warm orange light of the setting sun. She enjoyed this view. "In a monumental construction project like this one, almost everything can be calculated neatly, whether technical matters, logistics or, the use of staff and resources. With a little skill, the project managers of antiquity could even determine the time sequences on the construction site and calculate the necessary funds. That worked very well for such projects, and it still works that way for our investment projects today. Skilled project managers provided." Victoria blinked and smiled mischievously.
"Unfortunately, we regularly failed in our software development projects. In terms of project management, we had to turn everything upside down, so we had to rethink how we managed projects." "You're making me curious! Tell me how you guys thought innovatively and what you did differently", Henry answered. He leaned forward to get a better look at Verona's magnificent Roman-era amphitheatre. "We have tried to implement our software projects according to the waterfall model as well: We started with the analysis, then created the design, wrote the code and integrated it into the system. Then we tested and released the product. But as project managers we have had to get used to the fact that software development projects unfortunately cannot always be outlined with the required clarity". Victoria continued to explain, "The future is a collection of difficult challenges, good chances, unpredictable risks and great opportunities. Today we talk about the so-called VUCA world. Where VUCA is an acronym that stands for volatility, uncertainty, complexity and ambiguity and apparently our world is like that. The requirements that come from the project environment change rapidly and so do the requirements of our customers. All this has to be taken into account when "rethinking" project management."
Henry interjected: "In traditional project management, we think of the work in terms of the deliverable, the future outcome. Taking into account the stakeholders and the project environment, we write down what we want to have achieved as best we can. So we set the performance target and create a specification. In the phase and process schedule, we define the path that will take us to the goal. We calculate the necessary staff, the necessary means, based on capacity and resource plans, and the expected costs by using a cost plan. Sometimes we even try to find the necessary funds, which we present in the budget plan. We back up our plans with risk assessments, and honestly, I can't see anything wrong about that." Victoria shook her head, barely perceptible: "It isn’t that it’s wrong – it just doesn’t work for our projects. Perhaps because it squeezes our projects into something too rigid, leaving no freedom to adapt – who can say?" She shrugged her shoulders.
"Henry, I would like to show you in a few brief words the essential differences to your traditional project management concept. I'm not saying that your previous approach was wrong, I'm just saying that it needs to be complemented by a new approach. An approach that helps us solve our challenges. What is new in our software development projects, are four simple points:
-
People and their interactions are more important than processes and tools.
-
A functioning product is more important than comprehensive documentation.
-
Cooperation with the customer is more important than contract negotiations
-
Responding to change is more important than following a plan."
"That's what I call a paradigm shift! Now I see how this helps you break free from restrictive structures and handle your projects with greater flexibility.", Henry commented appreciatively. "Exactly, and that's also the reason why we call the new framework agile project management."
"So you don't need a finely worked out plan to realise the project?" inquired Henry. "Exactly, that's how it works. Our main goal is not to work off a precise plan, but to approach a functioning software that offers added value for the user step by step. But first let's capture when it makes sense to use agile project management, I'll explain it to you by using Scrum as an example." Henry looked at Victoria: "I've heard of Scrum before, it's a project management method, isn't it?" "Not quite, Henry. That's a common misconception. Scrum is not a method, it's a framework." "Can't these two expressions be used synonymously?" "Oh no. Scrum is a framework: it provides a structure with a few fixed rules that we have to stick to. Apart from these fixed rules, we have free rein. But if we don't stick to the few rules, then it's not Scrum. It is often the case that companies that claim to use Scrum and still fail, do not implement exactly the parts that bring success. In short, Scrum is a framework for developing complex products in complex environments." Henry nodded, "I see. I am now ready to find out when it will be used." "Very good. We use Scrum when we have a client, the so-called Product Owner, who tells us that he has a vague idea of the future product or service, we call that a Product Goal, but he cannot say exactly what he wants it to look like in concrete terms. To make matters worse, we, the team, do not know exactly how to achieve this Product Goal. Creating a complete project plan is therefore not possible for us at all." Henry shook his head in disapproval: "Completely without a plan? That has nothing to do with project management – it only creates chaos and anarchy!" Henry tried not to get emotional. "Calm down, Henry. Agile project management is very structured and follows clear rules", Victoria reassured him. "All right. I'm eager to hear them."
"Together we can define the project and performance characteristics in the team. These are the activities that are listed in the Product Backlog or the Sprint Backlog. The activities are called tasks, User Stories and Epics. We can identify opportunities and risks, as well as obstacles, known as impediments, prioritise activities, implement them step by step and execute them. In agile project management, we set ourselves fixed time frames, called time boxes, with a duration of two weeks, for example. Within the time box, the actual project work, the processing of items in the backlogs, takes place in so-called Sprints. The Product Owner can promptly incorporate change and correction requests and end the project when the product or service has reached the desired status and delivered the required quality. At the end of the Sprint, there must be a presentable result that is ready for acceptance. This result is called an Increment." Henry nodded slightly: "In the Sprint, you pick up speed, presumably work quickly and consistently, and drop everything that gets in the way, such as an overly rigid strategy or excessively detailed planning. Have I understood that correctly?" "Exactly, and during the project we, that is the Scrum Master - in the role of an Agile Coach, so to speak - and the team, keep our eyes open to identify and seize every opportunity that presents itself to accelerate or improve performance. The interim results are presented and discussed in the team every day. This meeting is called Daily Scrum. In any case, the results achieved are discussed with the Product Owner and, if necessary, with other stakeholders as part of a review at the end of the Sprint - in the Sprint Review - and approval for the next Sprint is obtained from the Product Owner." Henry tried to put it in his words: "So that means the original Product Goal can be implemented in iterations, in successive Sprints, and thus we achieve the performance target." Victoria confirmed this and added: "In our language, the performance goal is the sum of the Increments. At the end of a Sprint, the Sprint Goal, which was set beforehand, is achieved, including the acceptance criteria. When there is no more technical debt, all backlogs have been worked through and the Product Release has been published, the project is finished."
Henry reflected for a moment. "Besides strong communication skills, the Scrum Master and the Developers are also required to have a very flexible attitude towards the results of their work." "That's right", Victoria confirmed. "That, and the ability to organise the project under unclear constraints!" "In order to cope with the requirements, I can imagine that the Scrum Master and his team have to be willing to be experimental and consequently to be able to quickly adapt to new insights and circumstances", Henry remarked. "Did I understand that correctly? You can't predict exactly how much money or time you will need to spend on the agile project, but you deliver results in short intervals, which are agreed with the Product Owner and which can be modified, or released, by him?" Victoria nodded in affirmation. "So you have a project in which performance requirements and boundary conditions are so vague that the creation of a specification becomes difficult or even impossible. However, because without the specification there is no basis for clean project planning, the Scrum Master and his team will benefit from their expertise and communication strengths. They engage the Product Owner closely in the project and point out what they want to do during a Sprint and what result they want to achieve", Henry summarised. "Exactly, and we approach the project goal with the achieved results of the Sprints, whereby you have already correctly recognized that the number of Sprints required to achieve the project goal is not known at the beginning of the project. However, the communication between the participants, the reviews and approvals, are clearly regulated", added Victoria. "This is how agile project management has now become a crucial success factor in software development, but also in all other projects within the VUCA world."
Henry nodded affirmatively, "This is indeed a very different kind of project management than the conventional or traditional project management I am familiar with. I wish I had the opportunity to work on an agile project and use the techniques and tools." Victoria was delighted by Henry Abrams' enthusiasm. Kristin Welsh came over from the neighbouring table: "So, now you've done enough technical work, the bill for the coffee has already been paid by Dr Rogers. Now we can go to the arena and enjoy Bizet's Carmen. Our colleagues are already queuing up." Kristin pointed to her colleagues who were already standing at the entrance.
Do you feel you now have a clearer understanding of agility? We wish you good luck and enjoy learning!
As you have probably noticed...
... we use the generic masculine form solely for ease of reading. Naturally, all titles, professional designations and forms of address apply equally to all genders. We believe that anyone – regardless of gender – can be an excellent Scrum Master, Project Manager, Product Owner or Developer. That is why we want to encourage and support everyone to succeed in their role.