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

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

Hello from the second post of this series I am writing about Scrum. You can reach the first post, which turned out more fun than I expected, and my other Scrum posts below.

Lessons from the Scrum Training: From Theory to Practice

The 15 hour training I attended was put together by ACM Agile and it was an enjoyable course that blended theory with practice. Many of the fundamentals of Scrum were covered, but this was not a surface level transfer of information. The training focused on teaching the tools and the methods you need to deal with problems you can actually run into in real life.

Counting me, four people from my company Lebib Yalkın Yayımları and two people from another company made six participants in total. We split into two groups of three and for two days we worked in twenty minute sprints on a sample project our trainer set, experiencing Scrum live. With that sample work and the feedback at the end of each sprint, our trainer helped us internalise Scrum even further. He also kept the training moving on a Scrum Board he built on the window out of sticky notes. At the start of the training every note sat in the TODO list; by the end they had all moved under the DONE column. Well, is there anything better than hands on training?

Day One: The Philosophy of Scrum and the Fox Adventure

The first day of the training started by building awareness of the philosophy of Scrum and of the roles inside the team. We learned what Scrum is, where it sits under the Agile umbrella and a little of its history. The leadership role of the Scrum Master in particular was covered at length. We were told why behaving like a traditional project manager is wrong and that the real responsibilities of the Scrum Master are improving communication and the process inside the team.

How critical the Product Owner is in understanding customer needs impressed me a lot. I came to understand much better how Product Backlog management should be done and how prioritisation mistakes can damage projects. Meanwhile questions kept circling in my head about several Scrum teams working on the same project at large companies. I had run into cases where more than one Product Owner managed the same Product Backlog, for example. I had questions about how those situations could be handled better.

On the first day, with the groups we had split into, we worked on a scenario in a 20 minute hands on sprint. Each group was given about fifteen cards. Every card held a PBI and its acceptance criteria. We were going to build a website that helps children get to know animals. Our group picked the fox, the other group picked some odd kind of cat. We grabbed the cards and got to work at full speed. Barış, the star developer of our team, started building our site right away. Within a few minutes the home page, the image gallery and part of the about page were ready already…

But we had made a mistake. We had overlooked how important communication with the customer is in Scrum. Neither the other group nor we had asked the customer anything. That made it plain why the work we did stayed “unfinished”. It also helped us grasp the decisive role communication plays in the process. We needed to be transparent with the user or the customer about the process and to split the work properly inside the team. Instead we dived straight into the work and skipped all of that.

Thanks to that mistake we learned first hand that starting three different things at once and finishing none of them is not real success, and that every sprint has to carry work that is one hundred percent complete, work we can call “done”. Scrum is built not only on producing, but on prioritising correctly and finishing.

Day Two: Climbing Everest and Realistic Definitions of “Done”

On the second day we did interactive exercises on how to run events such as Sprint Planning, the Daily Scrum and the Sprint Retrospective properly. I had seen Retrospective meetings turn into a formality before, even get “forgotten”. Our trainer kept stressing that these meetings are not just a “what did we do well, what did we do badly” session but a tool for the team to improve the way it works.

With the groups we had formed the day before, we worked on the “Definition of Done” over the scenario I mentioned. We made another mistake in that exercise. While building the Definition of Done we put everything on the list and turned the work into Mount Everest. This sentence from our trainer still sits with me:

Scrum does not send teams up Everest. Our aim is to keep moving with small but solid steps as the fog clears in front of us, and to change direction the moment we see we are going the wrong way.

Long story short, adding too many items to the Definition of Done can push developers harder than needed and put the Increment or the Sprint Goal at risk. Setting too few items, on the other hand, can leave holes in the software and bring back more negative feedback from testing. To find that balance we discussed it as a team and learned to build a realistic, workable “Definition of Done”.

The Definition of Done should both keep from pushing developers too hard and guarantee the quality of the product.

We learned that the Daily Scrum is not a status report meeting; it aims to inspect the progress of the team, make the points where it is stuck visible and coordinate on solutions. The real purpose of these meetings is not team members simply sharing where they are, but speeding up the removal of impediments by increasing collaboration toward the Sprint Goal. During the training I came to understand better that every team member should build a shared ground for communication around the team goals instead of only describing their own task. That awareness showed me ways to make Daily Scrum meetings more productive.

In the last part of the training our trainer, quite openly, talked about some practices that fall outside the Scrum framework but are used often among teams, as if he had mud in his mouth. He explained that practices such as Story Point, Velocity and Scrum Poker do not appear in the Scrum Guide but are widely used by teams for effort estimation or work tracking. He stressed that these tools should be avoided where possible, that teams which focus too much on metrics and estimates can drift away from producing value, which is their real purpose, and that if a measure is truly needed, items (PBI, Task) can be given a time estimate only.

He also stressed that Sprint Planning meetings running over the time box stated in the Scrum Guide can hurt productivity and team motivation. He explained how important it is to use those meetings to clarify the Sprint Goal instead of nailing down every detail. Our trainer reminded us once more that Scrum is not only about tools and that teams need to strengthen their flexibility and their communication.

Along with that, he stressed that cancelling or changing the events, artifacts or roles that form the core of Scrum by saying “this does not fit our company” is a big mistake. He said that seeing retrospective meetings as a waste of time and skipping them, for example, takes away the team’s chance to improve its process entirely.

In the same way, he pointed out that leaving the Product Backlog loosely defined or the Sprint Goals vague seriously disrupts the value producing cycle that Scrum provides.

These explanations showed us clearly why sticking to the basic rules of Scrum matters this much, and that real success comes from applying those rules correctly.

What Stood Out for Me in the Training

• The Importance of Collaboration: Seeing the Scrum framework as nothing but a tool is a mistake. Collaboration sits at the heart of Scrum; transparency and communication play a critical role in a team reaching success.

• Misunderstood Concepts: The commonly misunderstood sides of Scrum were covered too. Mistakes such as turning sprints into small Waterfall runs, or turning Daily Scrum meetings into reporting sessions, were discussed.

• Real Life Scenarios: Without naming names, the trainer brought examples from his own past experience and explained much more clearly how Scrum can be applied correctly in practice.

• The Flexibility of Scrum and the Variety of Practice: The training showed clearly that Scrum offers a framework that can be stretched to fit every team and every project. It was also stated that this flexibility does not mean ignoring the rules entirely. The components and the principles in the Scrum Guide have to be applied carefully.

• The Importance of Team Dynamics: During the training I came to understand better how team dynamics, especially a culture of trust and open communication, affect the success of a project. It was stressed, for example, that creating an environment where everyone gets equal space to speak in retrospective meetings can raise team performance.

• The Purpose of the Tools: I learned that popular tools such as Story Point, Velocity and the Burndown Chart are only aids, and that the core focus is collaboration and creating value. The training made it clear that using the tools wrongly can pull the team away from its goals.

• The Psychological Side of Scrum: In the training I noticed that Scrum contributes not only to the process but also to teams feeling better psychologically. It was pointed out that teams having the freedom to manage their own work and taking pride in what they do are important factors that raise performance. It was also mentioned that delivering pieces of product that are 100 percent complete and ready for the customer, and ticking a mental box by saying “done” for some feature, actually feels good psychologically.

• Prejudices and Wrong Assumptions: It was stressed again and again that thoughts such as “this does not fit our company” go against the spirit of Scrum. The training showed that Scrum is flexible enough to be adapted to any industry and any project, and that assumptions like these usually block the chances a team has to grow. You will be surprised, but you can find Scrum being applied in very different industries around the world, car manufacturing included.

The Biggest Lesson from the Training

The training made me understand that Scrum is a change of mindset beyond being a framework. Embracing a culture of communication, transparency and continuous improvement plays a critical role in the long term success not only of projects but of teams as well.

If anyone is going to ask “how did you understand this much in 15 hours?”, I recommend they take a Scrum training. 😊

Our Trainer’s Books

I wish I had taken a photo of what was on our table when the training started. You should have seen the gifts!

1. A soft sweet, a stress ball,

2. A nice, lined notebook,

3. Cute and stylish Agile themed stickers, ready to decorate your laptop,

4. A really nice ballpoint pen, soft in the hand, the kind that makes you want to keep writing,

5. Play dough (yes, you read that right: play dough. The brand everyone knows, too.),

6. Tea and filter coffee brewed in a black Moccamaster (this is not a collaboration). Sadly the coffee came from sour Ethiopian beans.🙄 I thought about coming in early one morning and injecting a nice Sumatra into the poor bodies of my team and the training company, but sadly I could not get up that early.

7. Pastry snacks for the morning,

8. Sticky notes,

9. And of course the real subject of this part of my post: the books of our trainer Mehmet Bey.

1. Scrum: Bir Dönüşüm Hikâyesi (Scrum: A Story of Transformation)

This book by Mehmet Yitmen is practically a guide for people who want to start applying Scrum. It tells the story of an imaginary corporate company meeting Scrum and going through a transformation, and it tells it well. Along the way it covers the obstacles you can run into in Scrum practice, where those obstacles come from and how to get past them.

The book opens with a toxic, unpleasant environment at this imaginary corporate company: projects run with the Waterfall model finish later than the effort estimates promised, the developers put in a lot of overtime yet the projects are delivered more and more incomplete, the work that does get delivered does not meet what the business unit asked for, and nobody is happy. Hakan from the PMO comes over to press Kenan from the software team about a piece of work and, although they are normally friends, Kenan says he is busy without even looking at Hakan’s face. Hakan is aware that the company is on the wrong path and he is not angry at Kenan. He starts looking into whether there is a better project management model and comes across Scrum.

The real story starts there. Hakan digs into Scrum more and more. He talks to his manager first, then to the software team. The software team says they want to try Scrum and accepts Hakan’s offer to form a team wholeheartedly. Then convincing the business unit is what is left. They struggle to agree at first, but in the end they get a Product Owner from the business unit too. The group that acted furthest from Scrum at the start was the business unit, and the unit that wanted to use the internal reporting software first turned out to be that same business unit. Of course I cannot retell the whole book in a Medium post. Get it and read it; I recommend it.😊

The most striking side of this book is that it focuses on practical problems and how to solve them instead of on theory. When I read the book after the training, I noticed I dwelled on these points in particular:

• Dealing with Resistance: It describes how teams that resist the change of mindset in moving to Scrum should be eased into the process with training, pilot projects and success stories.

• Realistic Expectations: It stresses that Scrum calls for a steady learning process rather than a fast one, that it can create uncertainty at the start, but that it makes a difference when applied correctly.

• Cultural Fit: It points out that Scrum has to be brought in line with the company culture and that values such as trust and open communication have to stay in the foreground.

• Sprint Review: It touches on how important it is to show a working piece of product in these meetings and to have stakeholders give feedback actively.

• Daily Scrum: It describes how team members sharing where they are stuck, instead of giving a progress report, plays a key role in reaching the Sprint Goals.

• Team Dynamics: It stresses that clarity between the roles is critical, especially for the Product Owner to route the requests coming from the customer correctly.

This book is a useful resource both for people who want to move to Scrum and for teams already using Scrum who want to improve their process.

2. Scrum: Usta Sorulara Uzman Cevaplar (Expert Answers to Sharp Questions)

This book is an excellent guide for people who have deeper questions about Scrum and are looking for answers to the difficulties they meet in practice. In it, Mehmet Yitmen clears up the most frequently asked and most confusing Scrum questions with short, sharp answers. I am attaching the questions from the book here. The questions alone are enough to make you wonder about the answers:

1. Agile or Scrum? What is Agile, what is Scrum? What is the difference between Agile and Scrum? Is applying the Scrum process enough to embrace the agile approach?

2. Who is this Product Owner? What are the role and the responsibilities of the Product Owner? On what basis, and how, should a Product Owner be chosen?

3. Who is this Scrum Master? What are the role and the responsibilities of the Scrum Master? Does the Scrum Master have to be a full time role?

4. Iteration: two weeks or three weeks? What is a Sprint? On what basis should the Sprint length be set? How much time should be given to the Sprint meetings?

5. Sticky notes or technology? Which demand management and work tracking tool suits Scrum best? Once we start using a program, should we keep using the physical Scrum Board as well?

6. Do we always need Retrospective meetings? What should we do to make our Retrospective meetings productive and effective? Is it a problem that we end some meetings without finding an improvement action? Would it cause trouble if we held the Retrospective every few Sprints instead of every Sprint?

7. We apply Scrum, but? There are many elements that make up the Scrum framework (Scrum Master, Product Owner, Sprint Planning, Daily Scrum and so on). We want to use Scrum but we do not want to use all of these components. Is that possible?

8. Productivity or efficiency? Not everyone on the Scrum team is always 100 percent occupied throughout the Sprints. Is that not poor use of resources? To be more efficient, should we not keep these people busy with other work instead of letting them idle? When the company does not have enough resources as it is, can the existence of idle people be acceptable?

9. What about the project manager? As a project manager I cannot work out what my role is in Scrum. How are the responsibilities split between the project manager and the Scrum teams?

10. Specialisations and dependencies on people: What should you do when the Scrum team does not hold all the skills needed for the product or the project it will build, when there are not enough people with certain skills or specialisations inside the company, and when several projects or teams are trying to reach the same people?

11. What happens to the managers? In an organisation that is trying to grow its agile approach and uses Scrum widely, are managers needed? What should the job of the managers be in such an organisation?

12. Fixed scope, fixed budget and fixed end date? Is it possible to work with Scrum under classic software development contracts? If Scrum can be used in that case, what are the upsides and the downsides?

13. Scrum outside the digital world? Is Scrum only a management tool for software teams? How is Scrum used outside software teams?

14. How much are we embracing the agile approach? Where do we look to see that?

The questions I was most curious about were explained here in more detail than in the training, as if they were being spelled out for a five year old. So the more I read, the better I understood Scrum.

Question 12 was one of the ones I was most curious about, for example: what is the effect of a fixed budget, a fixed scope and a fixed end date on Scrum? Being an engineer, I like to question things. Of course I was also extremely curious about how we can tell to what degree we have embraced the agile approach. As a mid level manager, every time Mehmet Bey said in the training that “there are no vertical managers in Scrum, everyone is equal on the horizontal”, I kept sighing inside, “I had only just become a manager, what do we do now?” Do we always need a Retrospective meeting, and does an action item have to come out of it? As someone who already wears two hats (as you can guess, Scrum Master and Developer), the place and the importance of those two hats was covered really well and in detail under “Who is this Scrum Master?”.

If I have to write down a few of the answers from the book briefly:

• When you work with a fixed scope and a fixed budget, you need to focus on the outputs of each iteration to keep the flexibility of Scrum.

• The horizontal structure in Scrum makes it easier for the team to take responsibility, and I noticed that my role as a manager needs to become more supportive. As both team lead and Scrum Master, I also made it a priority for my team to understand the work better during planning and to plan more accurately. If they got stuck anywhere, I made a point of being “there” and lending a hand.

• As both a manager and a Scrum Master, I had to be more reachable so that problems could be solved earlier. I installed Teams, our internal communication app, on my phone as well, so the moment my team sent a message both the phone and the computer would shake the house.

• Many of the concepts Mehmet Bey brought up often in the training are explained in more detail in the book. Even though I found the idea that “everyone is equal in Scrum” strange at first, for example, the book explains very well how this horizontal structure can work successfully.

On many topics like these, this book helped me cement the theory I learned during the training and make more conscious decisions in practice. It is a very effective guide, especially for people new to Scrum and for the difficulties professionals run into often. Thank you so much both for writing these books and for giving them to us, hocam. 😊