How I Earned My PSM I Certificate #1: What Is Scrum?

The image was put together in Canva with the logo, font and badge provided by scrum.org.

Welcome! 😊

I met Scrum for the first time at one of the companies I worked for. Back in those years (2016-2017) that company took pride in being one of the best Scrum practitioners in Turkey. Some of the things we did, Scrum Poker included (I will get to those in the later posts), felt overblown and unnecessary to me, yet with its right and wrong ceremonies we were still trying to apply Scrum by the book.

When I first met Scrum I was surprised at how complicated it looked. In my first Sprint Planning meeting I got the feeling that everyone was talking non stop but nobody was reaching a solution. That day I understood that applying Scrum correctly matters just as much as understanding it. The process settled in over time and our planning got sharper. Our velocity went up. As I watched Scrum being practised at other companies over the years, I realised how valuable it is to understand this framework and to use what it teaches.

After the Scrum Master training run by ACM Agile Türkiye, which I attended under the leadership of Mehmet Yitmen, I passed the PSM I (Professional Scrum Master) exam and earned my certificate! 💪 The process was not only about passing an exam for me; while it deepened my theoretical knowledge, it also showed me how far some of the habits we had built up over the years had drifted from the essence of Scrum.

In this series I will share what Scrum is, what this training and our trainer’s books added to me, what I learned during the exam process and the bad practices I observed in my past jobs. If you want to apply Scrum more effectively, this series, which doubles as a comprehensive Scrum guide, is for you. I will write four connected posts and their titles will be:

1. How I Earned My PSM I Certificate #1: What Is Scrum?

2. How I Earned My PSM I Certificate #2: The Training We Took and Our Trainer’s Books

3. How I Earned My PSM I Certificate #3: The Exam Process, Using AI and Tactics

4. How I Earned My PSM I Certificate #4: Scrum at the Companies I Worked For

I will link them here as they go live, of course. Let’s get started!

The image is taken from scrum.org

Scrum and Planting Trees

Picture a group of people: saplings and shovels in hand, working to grow a forest. How would Scrum run this?

First a “Definition of Done” would be agreed on: “The roots of every tree must be fully covered with soil and 5 litres of water must be poured over it.” In the first Sprint a few saplings would go into the ground, and in the next Sprint the team would hold a retrospective on how to do the job faster.

What if it were Kanban? It would say “the saplings that are ready keep getting planted” and create a continuous flow.

What if we used waterfall? We would first pin down the spot for every sapling, then spend days digging the soil, and maybe plant those saplings years later. What do you think, would the forest have dried out by then? 🌱🌳

What Is Scrum?

Scrum is a framework used to manage complex projects. It is often the choice in the software development world, but thanks to its core principles and the way it works it can be applied in other industries too, and there are plenty of examples of that. Scrum is not a rigid method; it is a framework that guides teams. It rests on core principles such as adaptation, inspection and transparency.

The core purpose of Scrum is to keep up with fast change and to deliver products that carry value to the customer as early as possible. Unlike most traditional methods, Scrum puts flexibility first and lets teams keep learning and become more productive.

The Origins of Scrum and How It Grew

Scrum was built in the early 1990s by Jeff Sutherland and Ken Schwaber. First presented at a conference in 1995, the approach drew on the ideas in The New New Product Development Game, the paper Hirotaka Takeuchi and Ikujiro Nonaka published in 1986. That paper explained how teams could work in a more flexible, creative and adaptable way.

Sutherland and Schwaber adapted those ideas to software development and shaped the Scrum framework we know today. The first Scrum Guide, published in 2010, defined that framework and started guiding the whole world.

The Three Pillars of Scrum

• Transparency: The Scrum process and the work that comes out of it must be visible both to the people doing the work and to the people who benefit from it. Scrum’s core artifacts, the Product Backlog, the Sprint Backlog and the Increment, support transparency. Low transparency can lead to wrong decisions and raise risk. Transparency is also the precondition that makes healthy inspection possible.

• Inspection: Scrum artifacts and progress toward the goals must be inspected regularly. These inspections make it possible to catch unwanted deviations and problems early. With the five events it defines (Sprint Planning, the Daily Scrum, the Sprint Review, the Sprint Retrospective and the Sprint), Scrum gives inspection a rhythm. For inspection to mean anything, though, transparency has to be there.

• Adaptation: If a process drifts outside acceptable limits or the product that emerges does not meet expectations, it has to be corrected right away. That adaptation should happen fast, before it causes further deviation. When the Scrum team learns something new through inspection, it has to be able to update its process accordingly. Self managing teams make adaptation easier and keep the process efficient.

The Building Blocks of Scrum

The Scrum team is the smallest and most fundamental unit of Scrum. A Scrum team is made up of one Scrum Master, one Product Owner and the Developers. There are no sub teams or hierarchies inside a Scrum team.

Scrum Roles

The whole Scrum team is responsible for creating a valuable and useful Increment (a finished piece of the product) in every Sprint. Scrum defines the responsibilities inside the team clearly:

• Scrum Master: Makes sure the team stays true to the principles of Scrum and improves its process within the Scrum framework; helps get impediments out of the way.

• Product Owner: Owns the decisions about the product, keeps customer and user needs in sight, and is responsible for maximising the value of the product that comes out of the Scrum team’s work.

• Developers: The people who build the product. They are the people committed to creating any part of a usable Increment in every Sprint.

Scrum Events

Every event in Scrum is an opportunity to inspect and adapt the Scrum artifacts. These events are designed specifically to make the required transparency possible. Skipping even one of them means losing chances to inspect and adapt. Ideally all events are held in the same place and at the same time to cut down complexity. In short, the Sprint itself and the other events held inside the Sprint create the steady rhythm of Scrum:

• Sprint: The event where ideas turn into value, the heartbeat of Scrum. Sprints are fixed length to create consistency; that length can be one month or less. A new Sprint starts the moment the previous one ends.

• Sprint Planning: The Product Owner brings proposals on how the value and usability of the product could be raised in this Sprint. The Developers talk with the Product Owner and pick the items they can take into the Sprint. To create a finished piece of the product (an Increment) that meets the Definition of Done, they plan the work needed for each selected Product Backlog item. While doing that, Product Backlog items are usually broken into pieces that take a day or less. In short, the goal of the Sprint is set and the work for the Sprint is planned.

• Daily Scrum: The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and to adapt the Sprint Backlog by rearranging the planned work as needed.

• Sprint Review: The meeting where the work finished by the end of the Sprint is inspected. During this event the team and the stakeholders go over what was done in the Sprint and what changed in their environment. Based on that, the attendees work out together what to do next. The team should keep this from turning into a presentation.

• Sprint Retrospective: The meeting where the team looks at its own process and finds ways to improve it.

Artifacts

Scrum’s artifacts represent the work done or the value produced. They are designed to maximise the transparency of key information, so that everyone who inspects them has the same basis for adaptation.

• Product Backlog: An ordered and living list of what is needed to improve the product. It is the single source of the work taken on by the Scrum team.

• Sprint Backlog: A plan made by the Developers, for the Developers. It is a highly visible, real time picture of the work the Developers plan to get done during the Sprint to reach the Sprint Goal.

• Increment: A concrete step toward the Product Goal. Each Increment is added on top of the previous ones and is verified thoroughly so that all Increments work together. To deliver value, an Increment has to be usable.

Scrum may look simple in structure, but putting it into practice takes discipline and dedication. Being a framework that every team can tailor is one of the things that make Scrum this popular and this effective. Of course a framework used by this many teams and people cannot be explained in full in a piece this short; applying it is not as easy as it looks either.

In short, the eleven core elements in the Scrum Guide can be grouped under three headings:

1. Roles: Scrum Master, Product Owner, Developers

2. Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, Sprint

3. Artifacts: Product Backlog, Sprint Backlog, Increment

That is Scrum in a nutshell. For more detail you can look at the Scrum Guide:

So, are there no other project management techniques? Even under the Agile umbrella there are plenty of project management approaches. In this part of the post I want to say a few words about a couple of agile project management models such as Kanban and Extreme Programming, how they differ from Scrum and where they overlap with it. And, as tradition demands, at the very end let us put Waterfall down and hate it together. 😠

Scrum vs Extreme Programming

Extreme Programming (XP)

Similarities: Both aim to deliver value to the customer quickly and to adapt to changing requirements. They encourage working in short cycles (iteration in XP, sprint in Scrum) and they both target continuous improvement.

Differences:

• Focus: Scrum focuses on managing the process inside the team and on team dynamics, while XP focuses more on engineering practices. In XP, technical practices such as Test-Driven Development (TDD), Pair Programming and continuous integration take the front seat.

• Change Management: In Scrum the Sprint Goal stays fixed while the scope of the Sprint can be renegotiated with the Product Owner when needed. In XP, changes can be absorbed more flexibly during an iteration.

• Roles: XP does not define roles as sharply as Scrum does. Instead of a strict split of duties between team members, flexibility of roles is embraced.

Example: XP’s TDD approach literally settles the “which came first, the chicken or the egg?” question. Developers write the egg (the test) first, then build the chicken (the code). Say you are building a web app. Let us assume the password in the login form has to be at least 8 characters. First you write your test: “it should fail if a password shorter than 8 characters is entered.” Then you write the code that passes that test. What comes out of this method is not just a working chicken but a solid one! 🐓

Scrum vs Kanban

Similarities: Scrum and Kanban both push for making the work and the process visible, and both aim to raise the productivity of teams. Both approaches put collaboration and continuous improvement first.

Differences:

• Time Management: Scrum runs on Sprints, fixed time boxes, while Kanban focuses on continuous flow. In Kanban, instead of planning the work to be done inside a set period, the workflow is managed throughout the process.

• Planning: In Scrum, Sprint Planning happens at the start of every Sprint. Kanban has no mandatory planning event at fixed intervals; new work can be pulled into the flow as capacity opens up.

• WIP (Work in Progress) Limits: Kanban stands out with WIP limits that cap how many items can be worked on at any given moment. Those limits help keep work from piling up and improve flow by making bottlenecks visible. In Scrum, WIP limits are not mandatory. In a way, developers also have a clearer head because the number of items in progress at once is capped.

• Roles and Rules: Kanban does not define distinct roles and events the way Scrum does. That makes Kanban a more flexible option for teams that want to improve the process they already have.

Example: One of the best ways to understand Kanban’s continuous flow is a fast food restaurant. While the kitchen staff make burgers one after another, the cashier keeps taking orders. Imagine only 5 burgers are allowed to be in preparation at the same time to balance the throughput of the kitchen (the WIP limit). Once the kitchen hits that capacity, new orders do not move into preparation until room opens up. That is roughly the logic of Kanban: continuous flow, clear limits and a controlled workflow. Now I am hungry… 🍔

Scrum vs Waterfall

Similarities: Scrum and Waterfall are so different that the only thing they share is being project management models. Waterfall is of course not under the Agile umbrella, because it is not agile.

Differences:

• Approach: Waterfall is a linear and sequential process; you do not move to the next phase before the current one is finished. Scrum is iterative and agile; a usable Increment is created in every Sprint.

• Change Management: Waterfall is a model where requirements are largely nailed down upfront and changes are kept to a minimum. Scrum is open to change and takes change on board as part of the process.

• Customer Involvement: In Waterfall the customer usually steps in at certain phases, while in Scrum feedback is collected from stakeholders at the end of every Sprint and that feedback becomes part of the process.

• Speed and Flexibility: Waterfall follows a fixed and sequential process, while Scrum offers continuous improvement and the room to adapt to change.

Example: We can compare Waterfall to putting up a building. The whole design, the materials and the costs are largely settled before construction starts. If the customer turns up during construction and asks “shall we widen that balcony a bit?”, making that change can now be far harder and costlier. You may have to rework the related parts of the project. In software projects this can turn into a full nightmare. This is where Scrum makes the difference: you can reconsider the size of the balcony in every Sprint. 🏗️

An even more absurd example came to mind: when you lay railway track, you use Waterfall of course. A train that does not run means nothing to a passenger. The passenger does not care how the rails were laid, only that the train works and gets them where they are going. Nobody has ever seen potential passengers called over during track laying and asked “look, are we laying these well?” Maybe Émile Zola was watching track work for inspiration while writing La Bête humaine (The Beast in Man), and Ayn Rand while writing Atlas Shrugged. That does not mean Scrum was being applied while those rails went down. Fine, I have gone way too far; I will stop here and wrap the post up.

How did you learn Scrum?

What did you struggle with during Scrum events?

Did your daily meetings turn into status reports too?

In this post I focused on the building blocks of Scrum. In my next post I will share what the ACM Agile Türkiye training added to me and the practical knowledge I picked up from Mehmet Yitmen’s books. Stay tuned!