Is Your Organization Truly Agile? Find Out With These 3 Mega Issues!

CI Agile Team
If an organization calls itself Agile, there is a simple way to check if they are genuinely practicing agility in a way that maximizes productivity and delivers real business results.

Use these three mega issues to determine if your organization has the characteristics of a good Scrum or Agile system!


#1 Prioritization

What does it mean to prioritize in Scrum?

Every team has a product backlog that is tied to organizational priority.  This backlog should be very clear and ordered in each sprint, providing direction for the team to know what to do and when to do it. Teams can align their efforts and tasks to deliver work as required when the product backlog is tied to organizational priority.

The goal in Scrum is always to eliminate work unrelated to the company’s priority. Those are wastes.  If it does not bring direct value to the company, we do not want to waste our efforts on it. 

Without prioritization, some common problems arise: 
  • Team members are frequently taken to start new projects
  • Unable to agree on the priorities 
  • Sprint execution constantly disrupted due to changes in priority


In a fragmented system, team-level prioritization not aligned to the centralized priority will not contribute to delivering the desired business outcomes.

We simply cannot succeed as a company if everyone in the company is working in a silo mentality, just doing their own thing and not focused on delivering the greater outcome.

Always remember to connect the team’s priorities to your organization so that when your organization decides to change, the teams change with it.


#2 Working Product

The second thing that you want to check is the working product. Why is it essential to have a functional product every sprint? According to multiple research data points cited by Dr Jeff Sutherland, if we discover problems that we must fix after the sprint, we incur 24x the cost than if we fix it within the same sprint. 
Ideally, every team should deliver high-quality, working, integrated products that provide significant value in each sprint. It is not a team-by-team thing; rather, it is a collaboration of all team members in the work system. In a multi-team environment, it is usually insufficient for one outstanding team to move things forward for the entire organization. 
Typically, we hear these common problems:

  • “We didn’t have time to finish testing the product during the sprint!”
  • “We created a product, but it wasn’t what the users wanted!”
  • “Calls to the help desk doubled after we released the product!”
When we start to hear this from our team members, it probably means that we don't have an effective way to deliver the working product at every sprint. 
With that said, it can be challenging to get a working product every sprint. We are dealing with humans!
We can’t always be clear; we make mistakes and change our minds



#3 Organizational Refactoring

The third mega issue is organizational refactoring. Organizational refactoring means that the team and ‘teams of teams’ should be easily changed and optimized to address shifting business needs. With new technological advancements and rapid evolution, businesses are constantly changing. The teams and “teams of teams” should be easily changed and optimized to address such needs. 
This is what the opposite of organizational refactoring looks like:
• “Those are my people. You can’t take them!”
• “My bonus relies on the existing structure; fewer people = smaller bonus.
• I expect my staff to follow my instructions without questions!”
The goal here is to be able to refactor your organization based on changing business needs. It is critical because if we can do that, we will drastically reduce the delay costs! 
The third mega issue is organizational refactoring. Organizational refactoring means that the team and ‘teams of teams’ should be easily changed and optimized to address shifting business needs. With new technological advancements and rapid evolution, businesses are constantly changing. The teams and “teams of teams” should be easily changed and optimized to address such needs. 
This is what the opposite of organizational refactoring looks like:
• “Those are my people. You can’t take them!”
• “My bonus relies on the existing structure; fewer people = smaller bonus.
• I expect my staff to follow my instructions without questions!”
The goal here is to be able to refactor your organization based on changing business needs. It is critical because if we can do that, we will drastically reduce the delay costs! 


Interested to explore more about Agile transformations and what we do to address the mega issues in Scrum? Click here to learn more!
Created with