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

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

Hello from the fourth and last post in my series about Scrum. You can find the other posts in the series below:

I'm now at the eighth company of my career. I think it's eight, anyway. I don't feel like opening my social security record on e-Devlet to count them right now. Big or small, almost all of them were trying to do Scrum. Some applied every practice fully and correctly. One even focused on metrics like Scrum Poker, velocity and burndown charts and claimed to be the company that does Scrum best in Türkiye! But I have to admit that over the years I saw us apply Scrum wrongly or only halfway at many of the companies I worked for. Here are some of the mistakes I noticed along the way:


1. Misunderstood Roles

The lines between the Scrum Master, Product Owner and Developer roles were sometimes blurry and sometimes completely ignored. For example, at five of the companies I worked for, the Scrum Master role went to the analyst on the development team. A Scrum Master is not just the person who opens work items or tasks in tools like Jira, Azure or Trello, assigns them to people, schedules meetings and starts Sprints. The Scrum Master's most important job, listening to the team's impediments and removing them, was very often forgotten in these places.

Please don't pile so much onto analysts, dear reader, because theirs is actually a very hard job. They need to pay close attention to detail, be open to everyone's questions at any moment, know the answers and be able to give them right away. Near the end of a Sprint, an analyst can't answer a developer's question with “Oh, we didn't think of it that way, what should we do?” And to the managers who think, “The analyst won't have much to do anyway, let them do the Scrum Master job too”… You're very smart, congratulations.

At one company I worked for, the Product Owners kept passing customer requests straight to the developers, and the priorities in the backlog went out the window. 3 different projects, 3 POs and, in some periods, not enough developers. The result? Chaos. One day, when the 3 POs came to me with different priorities, I went to the CTO and said, “Could they please talk among themselves and agree on the priority? I no longer know which project to keep up with.”

I also worked at companies that had neither a Product Owner nor a Scrum Master, where the boss (or my manager) said, “Yeehaw! I'm the PO and I'm the Scrum Master too, anyone got a problem with that?” Approaches like this ignore Scrum's basic principles and are among the biggest problems that drag down a team's productivity and motivation. Fine, two hats I can live with. I'm wearing two myself these days, and it looks like I'll keep wearing two, but three is simply not possible.

Lesson I Learned: Clearly defining each role's responsibilities and protecting those boundaries is a must. The roles in Scrum are not just names; they are the basic building blocks that organize how a team shares the work. When these boundaries are not clearly set, chaos in the team is unavoidable. And when every role does its own job, it doesn't just improve the process, it also builds trust and transparency within the team.


2. Events Turning into a Formality

Scrum's events are designed to strengthen a team's communication and improve how it works, but sometimes they turn into a formality. For example, instead of being a place that boosts collaboration, the Daily Scrum could become a boring routine where everyone takes turns saying “what I did, what I'll do.” Especially when team members didn't bring up where they were stuck, these meetings were seen as nothing more than a waste of time. In the example scenario in our trainer's book, the team wanted to drop the Daily Scrum too.

In the same way, Sprint Retrospectives weren't taken seriously enough at some of my companies. People held Retrospectives just “to have talked about something” and usually ended the meeting without agreeing on any concrete action items. As a result, teams missed chances to improve how they worked and kept repeating the same mistakes. At some companies these meetings were seen as unnecessary and canceled altogether. That went completely against Scrum's principle of continuous improvement.

Another problem I often ran into was Sprint Reviews turning into a “presentation show.” A setting where stakeholders gave no real feedback and developers made excuses for unfinished work undermined Scrum's principles of transparency and adaptation.

In big teams, Sprint Reviews can run longer than they should, the order can get mixed up and the team can lose focus. I saw plenty of that too. When more than one team works on the same project, joint meetings with 50-60 people in the room can get even more out of hand. In the training we were told that the “Definition of Done” would be set jointly. As 5-6 Scrum Teams, we held the Sprint Review together as well, and you'd hear things like:

“One second, let me share my screeeen. Technical problem, guys, let Alp show it instead.”
“I'm on another branch right now, someone else go first, I'll show mine later.”
“My code is too messy right now and I can't roll it back either, let Alp show it instead.” (That last one is the go-to line of the last-minute crowd who aren't following the meeting and are busy finishing their work in the background. 😊)

To stop dealing with all these problems, the Developers started recording videos and showing them in the Sprint Review. It actually turned out better and faster. The idea came up during a Sprint Retrospective. Well! Scrum is there to solve problems.

In some teams I worked with before, Sprint Planning dragged on for far too long. In 4-hour meetings everyone ran out of energy and nobody remembered what they had planned. In the end, work was planned incompletely or wrongly, and we longed for productive Sprints where everything got done on time and nothing was carried over to the next Sprint.

Lesson I Learned: Scrum events are not a “checklist”; they are tools for improving team dynamics and solving problems. Raising impediments openly in the Daily Scrum, and defining and following up on concrete action items in Retrospectives, makes the team more successful. Also, understanding the real purpose of the Sprint Review and actively involving stakeholders improves product quality and lifts team motivation.


3. Sprints Turning into Mini Waterfalls

At 2 companies I worked for, we thought we were doing Scrum, but without noticing, our Sprints turned into mini waterfalls. The first week was analysis, the second week development and the last week testing. Work that wasn't ready by the end of the Sprint was either moved to later Sprints or an “extra Sprint” was invented for it. This went completely against Scrum's goal of delivering a potentially releasable product every Sprint. On top of that, when work was accepted as “done” without being tested or checked against the “Definition of Done,” technical debt piled up and made the project even more complex.

This problem usually came from old work habits, wrong expectations from management, the processes of other teams we depended on, work squeezed in mid-Sprint and the team not fully adopting basic practices like the “Definition of Done.” Doing the steps one after another instead of in parallel made Sprints lose their real meaning and turn into a project management model built around a delivery date.

Lessons I Learned

  1. I've been saying it since the first post, and so does Scrum: At the end of every Sprint, let's focus on delivering a finished and tested product.

  2. Testing is part of development; it shouldn't be left for later.

  3. Running analysis, development and testing side by side can make it easier to reach the Sprint Goal.

  4. Spotting waterfall tendencies and stopping them is the Scrum Master's responsibility.

  5. Discuss the causes of these tendencies in Retrospectives and decide together how to improve.


4. A Missing Definition of Done

At many companies I worked for, the “Definition of Done” was either ignored completely or written in so much detail that it was nearly impossible to follow. As a result, work that looked finished was actually “not done.” For example, code was written but not tested. Documentation was either never written or not good enough to hand to the customer. Worse, at the end of the Sprint the team couldn't agree on when a piece of work really counted as “done.”

This gap hurt not only product quality but also trust within the team. One team member thought their work was finished while another saw the same work as incomplete. Disagreements like these made Sprint goals harder to reach and lowered team motivation. And leaving testing to a separate phase made technical debt pile up and product quality drop.

Overly detailed Definitions of Done were another trap. Too many criteria put an unnecessary load on the Developers and made it harder to focus on the real work. For example, to finish a module we were asked to write every test scenario it needed and think through every possible user case. This made Sprint goals too ambitious, and they were never met.

Lessons I Learned:

  1. Make Clear and Realistic Definitions: The Definition of Done should be simple and practical enough for the team to follow.

  2. Include Testing and Documentation: Tests and the necessary documentation are must-haves in the definition.

  3. Reach Agreement as a Team: Everyone on the team should agree on the criteria for calling a piece of work “done.”

  4. Use It to Improve: The Definition of Done is not just a checklist; it's a tool for improving team dynamics.

  5. Bring It into Retrospectives: Regularly check how well the definition works and update it when needed.


5. Leaving Stakeholders Out of the Process

At many companies I worked for, Sprint Reviews stayed limited to team members and stakeholders were left out. Yet these meetings are a key chance to share how the product is coming along and to get feedback from stakeholders. Held as a formality or without stakeholders, they kept us from getting important feedback about how the product actually works. Problems were only noticed after the product went into use, which led to slow fixes like taking work back and correcting it or redoing it from scratch.

At Lebib Yalkın Yayımları, encouraged by my manager, we showed an internal app we were building to its users at every Sprint Review and collected their feedback. Thanks to that feedback:

  • We made our product more user-friendly and a better fit for what people asked for.

  • Motivation in the team went up and the Developers felt more ownership of the product.

  • Our bond with the users grew stronger, and we got to hear their voice while building the product.

  • We showed users ahead of time how their way of using the app would change, had them test it and even taught them.

  • We built the right product and avoided unnecessary features.

  • We prioritized work more accurately in the following Sprints.

  • We got the chance to spot users' possible frustrations with the app early and act quickly.

  • Thanks to this project and its Sprint Reviews, we saw more clearly how much regular stakeholder involvement helps product development.

Of the two checks in software development, validation and verification, validation is the critical stage where stakeholders are directly involved. Whether we are building the right product is one of the most important questions in software, and the people who can answer it are the stakeholders. Leaving them out makes this validation step useless and can lead to a product that doesn't meet users' expectations. On top of that, the lack of feedback drags the process out, wastes resources and can drain the team's motivation. Regular contact with stakeholders is a must for preventing these problems and making the product succeed.

Lesson I Learned: Regularly involving stakeholders in events like the Sprint Review doesn't just improve product quality; it also builds trust at every step and lifts team motivation. Taking stakeholders' feedback into account both strengthens the validation process and shows the real value of teamwork.


6. Poor Communication and Ego Problems

In some teams I worked with, people focused more on individual success than on working together. Everyone was busy finishing their own work, but because of poor communication, the work as a whole never came together. Worse, ego clashes between team members got in the way of sharing ideas and solving problems. This both lowered the team's performance and made it harder to finish projects on time.

Ego problems usually came from a lack of leadership in the team or from poor guidance. Some team members hid their problems, or assumed the work was done and didn't mention what was missing. This culture of secrecy created distrust both in the process and between team members. A Scrum Team can only succeed when its members trust each other and communicate openly; in an atmosphere like this, the team was doomed to failure and a tense, troubled place to work.

Poor communication hurt not only the team's performance but also the quality of the product. When problems weren't caught early, the bugs grew and pushed the project into a dead end. Problems like these can only be solved by communicating more and building trust within the team.

Lesson I Learned:

  1. Encourage Open Communication: Create an environment where everyone can share their ideas freely.

  2. Don't Hide Problems: Team members should be able to share their problems openly instead of hiding them.

  3. Manage Ego Clashes: Keep an eye on team dynamics to prevent ego wars and step in when needed.

  4. A Culture of Trust and Collaboration: Build a team culture based on trust and collaboration, because that is the foundation of a successful Scrum Team.


7. Unrealistic Sprint Goals

At almost every company I worked for, I saw plenty of mistakes in Sprint Planning. Let me list a few:

  • If you start planning without asking about time off during the Sprint, some work will inevitably be left half done. Always ask the team beforehand whether anyone has planned leave. If it's an emergency or a health problem, then the work, the company and Scrum can all wait. Otherwise, let the team know about your leave and do your job.

  • Overly ambitious goals were set without considering people's capacity. This came back at the end of the Sprint as unfinished work carried over to the next Sprint and low team motivation.

  • Work left half done and taking much longer than estimated, mostly because junior Developers estimated before fully understanding the work, is something I ran into many times, and something I did myself too.

  • If dependencies on other teams or integrations with third parties are not taken into account when setting Sprint goals, work can be delayed. These dependencies must be considered during planning and the workflow should be built around them.

  • In some teams, work isn't shared fairly: a few people get overloaded while others take on less. This upsets the balance in the team and affects individual performance. Work should be shared evenly, based on each team member's skills and capacity.


8. Ignoring Technical Debt

At a few companies I worked for, technical debt was usually pushed aside by short-term goals and deadline pressure. Later on, this made the code more complex, projects harder to manage and bugs more frequent. As technical debt piled up, building new features became slower and more expensive. On top of that, it led to lower motivation in the team and a habit of constantly “patching things up.”

Ignoring technical debt lowers product quality and team productivity in the long run. Bringing this debt up in Sprint Planning and Retrospectives and paying it off regularly, even if slowly, both lifts team motivation and keeps the project sustainable.

Lessons I Learned:

  • Add technical debt to your Sprint goals regularly. This keeps the debt from piling up and keeps the project healthy in the long run.

  • Bring up technical debt in Retrospectives to get to its roots. For example, if a bug keeps coming back, take action to find the root cause and fix it.

  • Catch technical debt early with code reviews and automated tests. Set coding standards so the team stays consistent.

  • When adding new features, think about how maintainable the code will be, not just about short-term wins.

  • Keep a tool or list for tracking the debt. Review it regularly and put the critical items first.


Conclusion: Full of Lessons for the Sprints Ahead

With this series, I tried to share the experience I gained, the lessons I learned and the challenges I faced on my way to the PSM I certificate. I saw that the mistakes made when applying Scrum in practice, and the lessons learned from them, are just as valuable as Scrum's basic principles.

Scrum is not just a method; it's a framework that improves team dynamics, strengthens communication and creates a value-focused way of working. But understanding and applying this framework correctly is critical for long-term success. As I've stressed many times throughout these posts:

  • Drawing clear lines between roles prevents chaos and builds trust in the team.

  • Keeping events from turning into a formality and supporting a culture of continuous improvement makes the team more productive.

  • Setting realistic Sprint goals lets the team work at a sustainable pace.

  • Not ignoring technical debt and cleaning it up regularly protects both team motivation and product quality.

  • Involving stakeholders in the process is an important step toward building the right product.

Every challenge brings a new lesson and a chance to grow. Finding solutions to the problems you face with Scrum will enrich your team culture and make your work more efficient.

By the way, what's that look? You were expecting me to name companies and trash them in this post, weren't you? Of course I won't! 😄 Every company has its own dynamics and challenges. The goal of this post is to put the processes and the lessons ahead of names. Moving forward by learning from mistakes is what brings real success, for teams and for individual careers alike.

Here's to getting a little better every Sprint with the lessons we learned from the one before.

Thanks, and happy Sprints! 🚀