Skip to content

Introduction

Welcome to the agile universe

Did you decide to take the certification exam to become a Certified Junior Agile Project Manager (IAPM) and prepare for the exam 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 Scrum to succeed in your next project and to pass the exam. So let's get started right away!

Overview of contents

Agile project management is an extensive subject area, which is why we will only focus on Scrum in this course. Below you can see the chapters of this course. You will come across these again and again when working on Scrum projects. You don't know much about the individual terms yet? Don't worry, that's what you are here for. In the following chapters you will learn everything you need to know to be well prepared for your future professional life as a Scrum Team member.

Fig. 0.1: Certified Junior Agile Project Manager (IAPM) -- An overview

Why agile?

Are you still sceptical about whether the agile project management approach is the right one for you? Let's take a look at possible areas of application for agile project management:

Fig. 0.2: In which areas can Scrum be realised?

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 rather in the traditional way. Is the task known and do you also know how to implement the project? Then you should choose the traditional approach. You can find out how best to plan a traditional project on our web-learning platform for traditional project management. The more unknown the customer requirement and/ or the implementation is, the more appropriate it is to choose an agile approach.

Fig. 0.3: Stacey Matrix: Projects between simple and chaotic

Before you start...

... we would like to familiarise you with this training system.

On the left-hand margin of your computer screen, you will see the primary structure. Here you will find the previously shown topics - consider these as your majors. The elements of this structure build upon one another, so we recommend that you work through them in chronological order.
If you are working through the online course using a mobile device, you will find the primary structure by tapping on the three dashes in the top left-hand corner. When you select a specific topic, a drop-down menu reveals the subordinate entries. Here you will find two parts: The theory part and the exercise part. In the theory part, you will find all the theoretical content that is important for the daily work in a Scrum project as well as for the exam. In the exercise part, you can practice and check your newly gained knowledge. Each learning unit has different lessons, which you can see on the right margin. To see the lessons on your mobile device, you need to navigate to the respective chapter. You can access the lessons by clicking on the icon with the three dashes and the three dots. You can browse through the different chapters and lessons by clicking on the chapters in the outline or by using the buttons on 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 of the exercise

Last but not least: Even if this is an online course, sometimes it is not a bad idea to take notes.

Story: A corporate trip

Let's now start with an introduction to the topic.

"You know," said Victoria Wilson, lowering 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 use when it came to achieving goals. We seldom kept to the time targets, 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 panorama. "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 project work." "You're making me curious! Tell me what you guys thought innovatively and did differently", Henry answered. He leaned forward to get a better look at Verona's magnificent Roman-era amphitheatre. "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 and 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 as best we can what we want to have achieved. 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 then 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's not wrong. It just doesn't work for our projects. Maybe because it constricts our projects like a corset because it's just too rigid and restricts freedom of movement, who knows?" She shrugs 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:

  1. People and their interactions are more important than processes and tools.

  2. A functioning product is more important than comprehensive documentation.

  3. Cooperation with the customer is more important than contract negotiations

  4. Being responsive to changes is more important than sticking to a plan."

"That's what I call a paradigm shift! Now I understand that this helps you to get out of a tight corset and to work on your projects more flexibly", 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. But let's first capture when it makes sense to use agile project management. We use it 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 in 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: "Totally without a plan? This has nothing in common with project management, it only creates chaos and leads to 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, the so-called 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 for example two weeks. Within the time box, the actual project work, the processing of items in the backlogs, takes place in so-called Sprints. The client 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 is obstructive, for example, a too tight strategic corset or too detailed planning. Have I understood that correctly?" "Exactly, and during the project we, that is the Scrum Master - in the function 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 fuzzy 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 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 with 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." Viktoria was delighted by Henry Abram's 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 now have a little better insight into the topic of agility? We wish you good luck and lots of fun learning!