Why do we struggle to implement Agile, and what can we do about it?

The Big Misunderstanding of Agile frameworks

A long time ago in a galaxy far, far away

The idea of assembly lines has been with us since the 1800s… Over the last centuries, we have been trying to understand how to improve efficiency and have learned that the answer lies in following best practices and creating clear, standardized processes.
The problem is that it’s no longer effective enough. But why?

• Software is not a factory but knowledge work, something we have never had in mass production before

• Everything changes, and rapidly

If all you have is a hammer, everything looks like a nail

Many professionals understood the need for a paradigm shift, so they created different Agile frameworks to promote the adoption of the Agile mindset. However, if people used to best practices and predefined processes merely adopt the frameworks, they might end up replacing old methods with new ones without truly understanding the underlying mindset.

Why can’t we just implement the framework and learn the mindset later?

Even implementing a framework by the book might help… if it’s truly followed and not altered into a half-baked custom solution without fully understanding the consequences. For example, simply renaming roles doesn’t mean people will automatically know what they’re doing.

But what does it mean in practice? Some of the frequent mistakes I saw when companies intended to implement Scrum:

• *“Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage”
  *→ Scrum Values are completely forgotten

• “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.”
  → There should be no ‘Backend team’ or ‘Frontend team’; value should be defined by customer impact.

• *“Within a Scrum Team, there are no sub-teams or hierarchies”
  *→ We should focus on having just ‘developers’ rather than distinct roles like ‘tester,’ ‘DevOps,’ or ‘backend developer.’ Team members should collaborate, taking on the roles that are most needed without compromising quality. Even if team members start with expertise in a specific area, such as backend development, they should gradually become ‘T-shaped’ professionals which means that they would learn and contribute to other areas, like testing or frontend development, through supervision, pair programming, or code reviews
  → There should also be no team/tech leader who manages the team by directing tasks or defining processes. While support roles such as agile/tech leaders are important, their focus should be on teaching and mentoring rather than managing. Hierarchical structure is not suitable for Scrum, we want the teams to become mature and manage themselves

• “For Product Owners to succeed, the entire organization must respect their decisions.” + “The Product Owner is also accountable for […] developing and explicitly communicating the Product Goal” → They should have authority over the product and guide the teams with the Product Goal. Two common issues I see:

  1. Product Owners lack authority over the product and/or focus only on a small segment of it

  2. Individuals assigned the Product Owner role from other positions don’t always understand how to manage the Product Backlog or create an effective roadmap. I have met Product Owners who were unfamiliar with even basic concepts like the Product Backlog or Sprint Backlog

• “The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint” → The Scrum team is meant to work as one, but instead of focusing on a common goal, team members often work in silos and fail to assist one another. Three possible root-causes:

  1. There is no Sprint Goal

  2. The ‘100% utilization’ mentality from traditional project management promotes constant activity in silos, such as developers coding and testers testing. This approach misplaces priorities; team members should focus on achieving shared goals through collaboration instead of just staying busy with coding or testing

  3. Lack of cross-functionality; when team members are unwilling to step outside their traditional roles, such as ‘backend developer,’ and collaborate more broadly, for example, by helping with testing

Let’s also see some examples from Kanban:

• *A Kanban board should visualize the entire value flow
  *→ Instead of following the whole flow the board only focuses on a specific part like development or QA

• Kanban limits work in progress (WIP) to enhance focus, reduce bottlenecks, and improve overall efficiency
  → Some teams may skip implementing WIP limits, which are crucial aspects of Kanban

• Kaizen (Continues Improvement) is a key aspect of Kanban→ Kanban doesn’t have a formal event like Scrum’s Retrospective, which may lead teams to overlook opportunities for self-improvement

• *Teams need a clear goal or purpose
  *→ Kanban doesn’t mandate a common goal for teams explicitly, so it can be easily forgotten. However, having a direction like Product Goal is crucial, especially when multiple teams are working on the same product. It helps ensure alignment, focus, and coordination across teams, making sure that all efforts contribute toward a unified objective

• Teams switching to Kanban simply because they can’t complete tickets within a sprint often aren’t truly adopting Kanban. Instead, they’re just trying to hide the issues that Scrum has made visible.

Well then, how can implement the Agile mindset?

Bad news, there’s no predefined recipe for this either… We need to be very patient and keep emphasizing the Agile values and principles. If anyone sees that something is not working accordingly, they should highlight it so the team can handle it more effectively next time.

Use common sense: how can you resolve something the most effective way?

Let’s look at some typical red flags that can be spotted by anyone

• *There are 8+ comments under a ticket
  *→ it can be a sign that the team avoids direct communication.
  I’ve seen a conversation going on for a month under a JIRA ticket which could have been a 10-minute call instead

• *The team is very passive, reactive only
  *→ There can be multiple reasons, but a common one is that the team is told exactly what to do and how to do it -> This prevents them from learning how to self-organize and leads them to wait for instructions rather than taking initiative.

• *Developers are only allowed to talk to their manager / the Product Owner
  *→ developers should be able to directly call stakeholders for clarification. Avoid indirect communication, as it often delays progress and causes information to be lost

Advice for leaders:

• Don’t try to solve everything; let the team fail and learn from it. Michael Jordan’s quote sums it up: “To learn to succeed, you must first learn to fail.”

• Don’t share your opinion until your team has had a chance to express theirs. They might be influenced by your views, and if you’re higher in the hierarchy, it’s natural for them to hesitate to speak up against your perspective.

• Try counting to 10 in your head before responding to or closing a question. Some people feel uncomfortable speaking up and - despite having brilliant ideas - won’t speak up until they’re certain no one else will respond.

• Show that you value and act on people’s feedback, or they may stop offering it.

What can be your next step?

1. You can learn from case studies, such as those in LeSS (where the early books focus heavily on case studies). I also have another article covering scaled agile case studies.

2. Understand the framework you’re currently using and identify what you might be missing from the original guidelines (e.g., the Scrum Guide for Scrum). Follow the Shu-Ha-Ri approach: master the rules first, then break the rules only if you fully understand their purpose and consequences.

3. Learn more frameworks to understand possible problems and how they intend to solve them. While no framework will fit perfectly for every product, knowing more options allows you to customize effectively. For example, you might use Kanban’s Work In Progress (WIP) limits in Scrum, not just to restrict column limits on the board, but also to limit new tickets added.

Let’s close with a positive thought: everything can be fixed if people are willing to learn and change. If you’re feeling overwhelmed, start with small steps! Ask why until you arrive to one root cause, and start working on that! You can also ask ChatGPT, it’s a great tool for brainstorming.

Don’t forget to celebrate what you’ve already achieved! 🎉 Like finishing this article! I hope you’ve learned something new or reinforced what you already knew.