Resolve conflicts in Agile Teams for Scrum Masters and Agile Coaches

Almost 9 years ago, when I started my first scrum mastery role, I encountered one of my tough challenges, conflict resolution. Two members of the development team(Ali and Vahid) separately told me, we can not work together anymore. 

  • “Why do you think you can no longer work with him? ” I asked them. 
  • Ali: “He doesn’t respect me… he is a brilliant jerk… I could not be able to work with him anymore”.
  • “Ali is not a good team member, he is so lazy, and he does not care about the team… I don’t like to work with him… ”, Vahid told me.

I held a shared meeting with both of them, to help them to resolve conflict. Everything went as badly as possible. This meeting was like the first presidential debate 2020 between Joe Biden and Donald Trump. Attacking, Interrupting, Not listening. I was like Chris Wallace at this meeting, without any impact. Ali left the team at the end of the week.

This bad event was a trigger for me to start improving my conflict resolution skill. Especially this kind of workplace and personal conflicts. If your team members have a conflict in the decision-making process, you can use easily facilitation techniques, but personal conflicts are so difficult. A conflict is a situation when the interests, needs, goals, or values of involved parties interfere with one another. 

In these 9 years and while coaching almost 20 different teams, I have experimented with many practices to resolve conflicts, but I want to suggest an effective one that worked for me in different situations.

Ladder of Inference

Ladder of inference, developed by a former Harvard professor Chris Argyris. Experts using the Ladder of Inference refer to “travel” on the ladder as an important way to obtain valuable insight into how a belief or action may have developed. The practice of traveling on the ladder also provides a rich opportunity to articulate the core of those inferences with other individuals and groups, particularly ones that lend themselves to vastly different conclusions and the escalation of the conflict.

It’s a really easy framework to learn and adopt it as your favorite conflict management tool. Let me describe it with my own story. In our story, Vahid believed that “Ali is not a good team member, he is so lazy” (Beliefs) So, In meetings, he did not show respect to Vahid (Actions). On the opposite side, Vahid developed a belief about Ali for himself too and reacted to him.

Learning to “travel back down” the ladder to revisit, articulate, and communicate the original data each group holds in a certain light is key to increasing meaningful communication between members of a group or team while simultaneously managing conflicts more effectively. 

The key point is that, helps them to revisit or be aware of the root of their current beliefs. 

Let’s travel back down the ladder in action:

  1. We are in a planning meeting, Vahid is trying to explain a concept to the team to help them to break it down a complex task into small tasks, there are 6 team members there…. (Observation)
  2. Ali is starting to check his phone (Selected Data by Vahid)
  3. His attention is on his phone (Meaning)
  4. He is not paying attention to me (assumption)
  5. He did not care about the team (Conclusion)
  6. He is a bad team member (Belief)
  7. Ignore the Vahid at the during of this meeting (Action)

When we developed a belief about somebody, next time, we will just select data about him based on our current beliefs. Beliefs act as a filter for us, we did not see things that we do not intend to see. 

Our beliefs affect the data we select next time. So, After this planning meeting, Vahid just will see some actions of Ali that prove his belief. It is not interesting? More evidence will cause stronger beliefs and stronger conflict. It’s a loop.

Another big mistake is that You as a facilitator, try to just pay attention to actions and try to manipulate them. Lets, say Vahid, you should show respect to him, but Vahid created a strong belief about Ali that he is not a good team member. And the same thing happened to Ali too.

What we should do? Travel back down the ladder. 

As a facilitator, you should help them to travel back down the ladder. What happened that you think he is not a good team member? “He did not care about the team…”. Can you tell us why do you think he does not care about the team?

You can start this session by explaining the ladder of inference framework, you can use your own stories too, it creates good empathy. For example, I always use my story with my wife and how we developed a wrong belief about each other. She thought I did not care for her anymore, and I thought She is just a murmur… And how we used this ladder to understand what created this kind of belief. For example, Checking the phone at home when we are eating lunch, caused she developed this belief…

This image is a great example to show your team member.

People develop beliefs in just seconds by some limited and selected data. And these beliefs influence their actions and view of the world in the future. We should help them to be aware of the root of these beliefs, observe new data and facts, and maybe develop new beliefs.

Don’t hesitate to share your experience here with me 🙂

Best Regards

Asad Safari

Maybe you like:

You need to stop using buffer to manage unplanned work in Scrum

Dev Team: “Hey Mike (Scrum Master), We have lots of unplanned work during the last sprints, How we should handle them?”

Mike: “You can create a buffer space in your sprint plan”

Dev Team: “It looks great… Let’s do it”

What is buffer space?

Based on this story, During sprint plannings reserve some buffer in a sprint backlog. There are two ways to do this. First, you can plan a virtual backlog item of a certain size that will count towards your velocity. This is going to be your buffer. Each time a new user story or bug enters the sprint, you subtract its size from the buffer item until it reaches zero. From this point, all the new work will be rejected by the team and put to the product backlog. Second, you can simply plan fewer items than the usual sprint velocity. During the sprint, you just absorb new user stories. This difference between average velocity and forecast velocity will act as an implicit buffer.

But why buffer technique is not a good practice in most cases?

Let me tell you a real story. Some time ago, I started coaching an agile team. The team had been adopted Scrum for a while. But the manager was not at all satisfied with the team’s delivery rate per sprint. The team attributed this low delivery rate to the amount of unplanned work on each sprint. To solve this problem, the team used the buffer practice to be able to make better predictions in each sprint. But in practice, there was no significant difference.

When I started to work with this team, my initial goal was to maximize transparency to be able to answer this question, “Why do we have this amount of unplanned work?

Before taking any action, As a coach, we must have a clear understanding of the situation and, more importantly, make it clear to everyone

What did you get from this visualization?

Let’s look at the above image, I think you got the idea that why we should not use the buffer. This visualization uncovered that there is a high level of technical debt, and in fact, When you adopt buffer technique in this case, instead of solving the root of the problem, you hide it.

An old Japanese saying mentions hiding an offensively smelly object by covering it up.

This amount of bug rate certainly indicates the low level of quality of the Codebase. There is probably no automated tests. The design is very fragile, because, with each sprint as the new feature is developed, the next sprint has more bugs. You can find a pattern.

“Scrum is like your mother-in-law, it points out ALL your faults.” — Ken Schwaber

The basis of the Toyota production system and Lean is the absolute elimination of waste. Don’t Hide the Wastes, Visualize them, and solve the root problem.

When the problem is clearly understood, improvement is possible.

Sometimes (though not always) the buffer hides the root of the problem. In fact, the result will not be satisfactory, and we actually covered the problems.

The next time you encounter unplanned works, first check the 7 wastes of lean software development. Try to make them clear and visualized, and the solution will emerge itself.

While problems observed at the surface level can often be addressed with a simple readjustment, the lean mindset pushes us not to assume that every issue can be solved by simply treating the symptom or adjusting at the surface level.

In my case, After visualizing, we started to create a plan to manage our technical debt, we added a technical mentor to the team, we adopted XP practices…

Best Regards


How to use the Agile Fluency Model – Part 2

In my last post, I mentioned that I started a new agile transformation journey with a new company. I presented a visualized version of Agile fluency model that helped me on my journey. In this post, I would like to share my facilitation story with my stakeholders.

1- Help them to imagine a shared vision

Perhaps the most important thing in an agile transformation is to create a shared vision. Where do we want to go? Where is the destination؟ A shared vision will make people work together to achieve that vision, despite all the conflicts.

AgendaShift has a great practice, “True North“. I like it. As a facilitator, I asked this question from stakeholders:


Everyone able to work consistently at their best:

  • Individuals, teams, between teams, across the organization and beyond
  • Right conversations, right people, best possible moment
  • Needs anticipated, met at just the right time

What’s that like?  What new stories could you tell?

To make this imagination process easy, I borrowed the Agile fluency model‘s benefits. I collected all zone’s benefits in a group.

Ask them to prioritize these cards based on the current context.  

You can use dot voting for prioritization. Ask the group to cast their votes by placing a dot next to the items they feel the most strongly about. They may use stickers or markers to do this. As a rule of thumb, giving each participant five votes to cast works well.

Participants cast their votes all at once and they may vote more than once for a single item if they feel strongly about it. Once all the votes are cast, tally them, and if necessary make a list of the items by their new rank.

This prioritized list becomes the subject of discussion and decision making. In some cases, it may be useful to reflect on ideas that didn’t receive votes to verify that they haven’t been left behind without cause.

The result should be something like the below image:

The Agile Fluency model is designed so that we can consider each of its zones as a transformation destination. Of course, we have the option to select other zones later.

Select Target Zone based on votes:

Based on Model, The proficiencies involved in later zones tend to require more time than the proficiencies for earlier zones. The sooner a team starts working on a zone’s proficiencies, the sooner the team will become fluent in them. Agile proficiencies are also mutually supportive. Accordingly, it’s best to choose the zone of fluency you want to reach and start practicing all the proficiencies needed for that zone— and all prior zones—simultaneously.

So, in my case, they have chosen Delivering as a target, but they need to practice focusing zone’s proficiencies too.

2- Balance Target with the Investment

It’s so possible, Your stakeholders, choose the items that are not required in their context, or they would like to reach a target zone, But they are not interested in investing. An organization that expects fluency without providing appropriate support is bound to be disappointed. Even worse, insufficient support can cause a turnover and create a cynical corporate culture that hinders improvements. Before embarking on your fluency journey, be sure your organization is prepared to offer the support the journey needs.

2-1 – Visualize the Deliberate Investment

Now, Put the selected benefits on our diagram.

It’s Time to add Deliberate Investment Cards on our chart and make balance our benefits and Investments.

Deliberate investment cards

Add the selected target zone’s investment cards to chart:

What does it mean for us?

This step is the most important one, We need to make sure that our stakeholders understand the concept of each Investment Card, So I have created a template to help my stakeholders.

This ___(An investment Card)_______
In our context it means
1- _______
2- _______

For Example:

This “Provide time for lowered productivity while team members learn new skills. ”
In our context it means
1- For a period of at least 3 months, the development of the new features will be reduced
2- We need to be able to convince the company’s core investors as well 


This “Select team members with appropriate skills, background, and willingness to work together. Allocate them 100% to their team. ”
In our context it means
1- We have to hire new people
2- We need to change the process of hiring people that fits the team-working culture

3- We need to reduce or eliminate the Task switching

In this step, it’s possible that your stakeholders change their minds about the selected target zone. Maybe they choose a lower zone as a target.

I have tried to ensure that my stakeholders have a clear understanding of our destination and the investment required. They should not think that the money we give to an agile coach is our investment. In many cases, the most important investment is time.

But the story didn’t end here, I went to the teams and understood the current state of the system using the AGILE FLUENCY DIAGNOSTIC. After this step, I prepared a specific investment plan and agreed with my stakeholders. The exercises at this stage helped keep their minds ready for the investment plan.

Best Regards


How to use the Agile Fluency Model

Two weeks ago, I started a new agile transformation journey with a new company. They have several cross-functional teams. Like everywhere else, they asked me to make them agile in 3 months 🙂

So, I tried to use the Agile Fluency Model to help my main stakeholders to see what kind of agile investments their organization needs to make. Insufficient investment not only leads to slow progress, but it also creates lasting cynicism and resentment.

In order to achieve my goal, I tried to use a series of images. Using visual aids in meetings or classrooms helps improve learning by up to 400 percent.

I did not want to just explain the Agile Fluency Model to them, My goal was to figure out two things for the main stakeholders, Where we want to go, and What it will cost us? I think, explaining the Agile Fluency Model with this image, helped me to reach my goal.

Let’s explain it:

1- Agile Fluency model, Contains different Zones, “1. Focusing 2. Delivering 3. Optimizing 4. Strengthening”.

2- Each Zone, Depends on a set of agile proficiencies. and Each Zone can potentially generate specific benefits.

3- Proficiency is an observable behavior, such as “Team members consider their plan to be the team’s work, not individuals’ work.”

4- Fluent proficiency is a special kind of Proficiency: A habit of exhibiting proficiency at all times, even when under pressure.

4–1- Set of fluent proficiencies, can generate the zone’s expected benefits.

5- Fluent proficiency requires deliberate, thoughtful, day-in-day-out practice over months.

6- Deliberate practice comes from a deliberate investment in learning through practice.

When you are introducing benefits and Investments, at the same time, it will help your stakeholder to choose the right zone based on their current context. The current context is so important, Based on the current conditions we want to reach a special level of agility that helps us to be successful in our business. Unlike maturity models, where more mature is always better, the fluency model describes a collection of choices. Each zone represents a fully-mature choice.

Based on my experience, your stakeholders should understand this is their journey (Now coach journey) and They should support this journey with the right investment plan. Insufficient support can cause a turnover and create a cynical corporate culture that hinders improvements. Before embarking on your fluency journey, be sure your stakeholders are prepared to offer the support the journey needs.

In the next story, I will share How I facilitated my main stakeholders to choose the right zone and create an investment plan together. (But I need to be sure this will be valuable for you, so please let me know your feedback; And no feedback means I don’t have to keep going 🙂


Asad Safari

Maybe you like:

Real Agile transformation case study, with Agile Fluency Model

References: Agile Fluency Model

Practical Agile Transformation framework — Conduct Experiments to get there

Yaya, It’s the third part of the practical agile transformation framework that we call it Factful Agility Framework. In the first part we created a shared change vision, in the second part we understood the current condition and chosen some meaningful metrics. 

In the last part, we will exploit the change program by conducting experiments. 

Why do we call it experiments?

We are factful, so we should make decisions based on facts. There are 3 facts here:

1- We have a shared change vision, So we know the direction.

2- We assessed the current situation, So we know the current conditions. 

3- We have some hypotheses on how to reach the direction, But we are not sure, these are just hypotheses. 

These are just hypotheses

So let’s come back to our first principle: Our goal is not to implement “scrum”, “Kanban”, or even scaled ones like “SAFe”, “LeSS”, …. 

We will hire one or mix of these practices to help us to reach our own objectives. 

Develop the Experimenting mindset

It’s really important to develop the experimenting mindset in you and your team members. 

Start with yourself

“I have Scrum Master certification, So I believe that scrum will help us to reach our goal.” 

Change your word, Change your World

As a change agent, or Agile coach or … we need to change our words “In order to reduce the lead time, We will use Scrum and Kanban”.

Hypothesis Story 

You can use the Coaching Card or Hypothesis Story to frame better hypotheses. A template like this:

In order to (Our determined metrics in the second part)

We want to hire/use (a specific practice)

For example:

Hypothesis Story

With these details:

The granularity of stories: 

Like user stories, you can break down big Hypothesis stories to small stories too. You can create Hypothesis Epic <- Hypothesis Story.

Breakdown Hypothesis Story

 Develop the experimenting mindset on team members

I can guarantee that the change will fail:

1- If you couldn’t be able to develop the experimenting mindset on team members

2- If you couldn’t be able to create and visualize a great scoreboard. Great teams know at every moment whether or not they are winning. They must know, otherwise, they don’t know what they have to do to win the game.

How to develop the experimenting mindset on team members? 

As an agile coach or Scrum master you need to use all of your skills: 

This model is based on Agile Coaching Competency Framework

I will tell you how to use these skills to stick the team to the change.

Conduct a “Change Exploit Planning”

This event is designed to:

1- Stick the team to the change

2- Create a small and concrete winning plan 

3- Create an experimenting mindset

1. Prepare yourself for the event, Pre-Planning 

In this part, you need to use your Agile/Lean Practitioner skills. There are lots of Agile/Lean practices, let’s create a Practice Backlog. You can use any framework. As a template for your backlog items, you can use the Hypothesis Story too.

Practice Backlog

If you don’t have any idea about practices, you can use your assessment tools too. For example, the Comparative Agility assessment is mostly based on known practices or you can use scrum/kanban/XP checklists like this one

You don’t need to prioritize this backlog right now. Don’t forget that, in the future, we will find new practices too, so this Practice Backlog is a live artifact.

2. Train them (Optional)

This level is optional, and it depends on your team knowledge about Agile/Lean practices.

In this level, you will use your training skills. The goal of the level is, create knowledge and awareness about practices.

I suggest don’t skip this level. Why? Based on my experience, most of the teams have a very superficial knowledge of agile methods. A deep understanding of agile midset and practices can help you in later stages.

You can ask other coaches/trainers to help you in this stage too. 

3. Start Change Exploit Planning with coaching skill

It’s time to show your coaching skills. The essence of coaching based on the International Coaching Community:

  • To help a person change in the way they wish and helping them go in the direction they want to go.
  • Coaching builds awareness empowers choice and leads to change.

In the coaching stance, You should do 4 things(Idea from Toyota kata):

1- Create or Share a shared direction. If the change vision is not created by them, share the created vision and let them know what is the direction.

2- Create awareness about current conditions. Sometimes, there are people who will ask “Why we need to change?”. You can create awareness with “Our Change Vision document”.

For example, In a company, I asked the team, “Do you think, how many bugs reported last week?” They said “Almost 10- 15 bugs”. Then I presented a Jira report of production bugs “44 bugs”. “Holy sh*t, we created a crappy product!!! What we should do?!” they told me. It’s a great moment in a coaching stance. They are ready to contribute to the change program.

3- Create an agreement about the next target

Having a direction and awareness is not enough, we need to breakdown the change. Small targets but meaningful outcomes. 

The organization can be both bad and better. Progress comes bit by bit.

You can use the metrics of the change vision(Described in the second part of the Facful Agility Framework.)

For example, In the first quarter, we would like to focus on just 2 objectives:

1- Low defect rates and technical debt are beneficial to job satisfaction and morale, improving retention and productivity. (Qualitative and Lagging)

2- Bug rates (Quantitative and ~Leading)

So the team decided to use a quantitative metric(Bug rates), and they know the current condition is 44 bugs per week. But What is the next target? The team thinks the Next Target should be zero bug state.

ِDon’t forget our principle, Small changes but meaningful outcomes. “What do you think to reach 5 bugs?”.

4. Create an agreement about how to visualize the scoreboard

“People play differently when they are keeping score. If you doubt this, watch a group of teenagers playing basketball. See how the game changes the minute score-keeping begins, it’s not a subtle change.” 4 disciplines of execution

In this part, we will talk about how to visualize important metrics. You can use a big TV. let people see the progress. Sometimes you can celebrate progress in daily standups or …

4. Continue Change Exploit Planning with your facilitating skill

It’s time to show your facilitating skills. I will show how to do it easily.

Draw one or several circles on a whiteboard, then write your next target(s) in the circle. 

Next Target

As a facilitator, you should facilitate this part (You can use liberating structure too)

1- “What practices can help us to reach our target?”

You can print your practice backlog or bring it with you and let the team see it. They are free to use practice backlog or write a new practice or initiative. Ask them to write the practices on sticky notes and put them on the whiteboard.

2- “I bet you the ____(practice) ___will help us to reach our target faster”

It’s time to bet 🙂 Why Bet? Because we are not sure, but if I would like to be on something, It means “ something has a near certainty of being right”. 

A Bet = An Experiment. 

Ask guys to bet on practices. Let’s Complete this sentence “I bet you these____practices ___will help us to reach our target faster”.

You can use dot voting for betting. Ask the group to cast their votes by placing a dot next to the items they feel the most strongly about(I bet on this one). They may use stickers or markers to do this. As a rule of thumb, giving each participant five votes to cast works well.

Participants cast their votes all at once and they may vote more than once for a single item if they feel strongly about it. Once all the votes are cast, tally them, and if necessary make a list of the items by their new rank.

3- Form “Hypothesis Story” cards

In order to Decrease bug rates of a week to under 5

We want to “Write unit tests for critical features”


In order to Decrease bug rates of a week to under 5

We want to use a “Definition Of Done”

4- Select high priority practices and create a change sprint backlog

The concept of the change sprint is a period of a short time, to conduct experiments and see the result. You can map it to your current sprints and check the result in the retrospective meetings. 

Or you can create a Change Sprint with a 1-month length. You can conduct a “Change Exploit Planning” at the beginning of each change sprints. 

For change sprint backlog you can create a simple kanban board. 

Change Sprint Backlog

Ok, It’s time to exploit and adopt practices. But don’t forget our goal is not to adopt practices, we adopt practices to reach our objectives 🙂

1 more thing: Management Support and Investment 

Teams will focus on their change sprints and adopting practices, but management support is necessary. Insufficient support can cause turnover and create a cynical corporate culture that hinders improvements.

For example, When a team wants to work on quality and decrease bug rate, Based on agile fluency we know that they are trying to reach “Delivering” zone, and this zone needs some investment:

Common Organizational Investments

Provide time for lowered productivity while team members learn new skills.

Integrate non-programming technical disciplines, such as QA and ops, into the team.

Provide training in agile technical practices.

Engage skilled practitioner-coaches to mentor the team on their real-world work.



About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He has worked as an Agile coach for more than 8 years with several enterprises and startups. He has more than 14 years of experience in the IT industry as a Software Developer, Tester, and finally an agile practitioner. You can follow Asad on Twitter and LinkedIn.

Practical Agile Transformation framework - Grasp the current condition

This is the second part of the Practical Agile Transformation framework. In the first part, we created a shared change vision. The change vision, answers this question “How we want things to be?”. “Not I” “We”. A shared definition of direction and a better future.

In this story and based on the Factful Agility Framework, We want to understand the current condition. “Where are we now?”

Grasp the current condition

I got this great idea from Toyota Kata. If you took a good time to create a shared change vision, the “Grasping the current condition” will be so easy for you.

Today “Data-driven”, is a new buzzword. We would like to measure anything around us. There are lots of data out there, but just some of them will help us during the change process.

We need metrics for:

1- Understand the current condition (“Where are we now?”)

2- Understand the progress during the change process. (“Let’s celebrate, but is there any progress against our change vision?”)

So, What kind of metrics are good for us?

Metric’s quadrant will help you to choose the right metrics:

Lagging and Leading indicators

Based on the KPI Library definition

“ Lagging indicators are typically “output” oriented, easy to measure but hard to improve or influence while leading indicators are typically input-oriented, hard to measure and easy to influence.
For example, A personal goal is weight loss(Direction or Change vision). A clear lagging indicator that is easy to measure. You step on a scale and you have your answer. But how do you actually reach your goal? For weight loss, there are 2 “leading” indicators: 1. Calories are taken in and 2. Calories burned. These 2 indicators are easy to influence but very hard to measure. ”

Qualitative and Quanitivae Indicators

Quantitative data can be counted, measured, and expressed using numbers. Qualitative data are descriptive and conceptual. Qualitative data can be categorized based on traits and characteristics. (Ref)

Put all of the things to practice:

In the first part, we have created a shared vision, like the following image(Please read the first story): 

Take a look at the vision again, we can find our indicators there. Let’s map it to the metric’s quadrant.

Now, I think you have an idea of what you should do? Based on my experience some of the metrics like Bug rate or Technical debt rate are leading and lagging at the same time. 

Leading metrics will lead us to lag indicators. 

Don’t forget, We should know why we need indicators? 

1- Understand the current condition (“Where are we now?”)

2- Understand the progress during the change process. (“Let’s celebrate, but is there any progress against our change vision?”)

How to measure or asses these metrics?

There are 2 ways to measure or assess the current state:

1- Build your assessment tool

2- Use one or a mix of assessment tools

To make it easy for you, I have mapped different tools based on our sample vision:

These are just examples, there are lots of assessment tools, that you can use them. You are free to make your own assessment tool too. 

But about Agile Fluency Diagnostic, I really recommend this tool, it will help you to understand the current state and better plan the road map. 

Measure and Assess 

Each tool has own assessment technique. For example, in the Agile fluency diagnostic, we hold an assessment workshop with teams. 

Or in Comparative Agility, We send assessment link to team members, and they need to fill it by their own pace, after that we will analyze it and the tool will help us to generate a report. 

Some examples:

Visualize it

Based on my observations, visualizing is the most important part of this process. With this visualizing, you are trying to stick to the change. It’s like create a scoreboard for a team. 

“Great teams know at every moment whether or not they are winning. They must know, otherwise, they don’t know what they have to do to win the game.”


4 disciplines of execution have a great discipline: KEEP A COMPELLING SCOREBOARD

“People play differently when they are keeping score. If you doubt this, watch a group of teenagers playing basketball. See how the game changes the minute score-keeping begins, it’s not a subtle change. 

The lag and lead measures won’t have much meaning to the team unless they can see the progress in real-time. Bowling through a curtain is not that much fun. This is the discipline of engagement. People perform best when they are emotionally engaged and the highest level of engagement comes when people who score: whether they are winning or losing the game. It’s that simple.”

In this part, we will visualize the selected and assessed metrics. You can use a big TV. let people see the progress. Sometimes you can celebrate progress in daily standups or …

Let’s start the game, we will win the game 🙂 

In the next story, I will share the exploit part with you.

Please leave a comment for this story as feedback, Is this useful for you or not? Why we should continue if it’s not valuable.

If you have any question or need any help, Don’t hesitate to call me



About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He has worked as an Agile coach for more than 10 years with several enterprises and startups. He has more than 14 years of experience in the IT industry as a Software Developer, Tester, and finally an agile practitioner. You can follow Asad on Twitter and LinkedIn.

Practical Agile Transformation framework -  Start with a vision

“You should not do Agile, You should be Agile”. This is the most used buzzword by agile coaches to promote agile values. After +10 years in the agile world, I think this is a wrong approach too. 

Sometimes as an Agile coach, we are trying to sell our service, “We deliver agile coaching service to firms that help them to be Agile”. 

Based on my experience, most agile transformation failed because we did not have the right direction. Setting “Doing Agile” or “Being Agile” as a goal is not a good objective for a change program. 

This kind of change programs is buzzword centric. Agile mindset helped us to create “Customer-centric” products, but why we define a change program “buzzword-centric”? for example, “We want to implement OKR”, “We want to implement Scrum”, “We want to adopt agile”. 

So, you will hire a buzzword-coach, Trainer and she will teach us how to do this. And people will show resistance against the buzzword. 

Outcome-centric vs Buzzword-centric

A Customer-centric or Outcome-centric change program, see the change from lens of the customer and not service provider(Like agile coach). Let’s see an example.

Charles Revson, the founder of Revlon, said:

In the factory we make cosmetics; in the drugstore we sell hope.

Maybe as an agile consultant/trainer/coach, I want to sell my service to companies, but a company doesn’t want to be agile, they want to be able to do awesome things. We think agile will help them to reach the right competencies to do awesome things. 

A customer-centric change program, will focus on the outcome and not just implementing different frameworks or practices or even values

Factful Agility Framework

I did not want to create another framework, I think we have enough frameworks. But based on my experience we have 2 main issues:

1- Most of the time an alone tool cannot solve our problems and in the real world we need to mix different tools.

2- There are lots of tools out there, and it makes it hard to choose them and mix them.

After working with +15 companies and +100 teams, I tried to create a container for these tools, That makes it easy to use them or choose them. I call this container “Factful Agility Framework”.

Some tools like, “Toyota Kata”, “Agile Fluency Model”, “Agenda Shift”, “Comparative Agility”, “Evidence-Based Management Guide”, and my own tools like “Change JTBD”, “Coaching Canvas Card”.

Explore: Start with the outcome

Let’s draw an outcome-based agile change program:

How to start an agile transformation program?

We used to dive into the agile frameworks and start to implement one of them and mostly scrum. But in the Factful Agility Framework, we start to explore, “Why our customer need to be agile?”

Start with “How we want things to be”

There are various reasons to be agile. We should help managers to find their own reason. 

I created a game to help them to do it faster and easier. I called this game “Change JTBD(Jobs-to-be-done)”

1- Print or write the following cards on sticky notes: (You can add your own cards too)

2- Invite key stakeholders of the change program to a workshop.

3- Ask them to prioritize these cards based on current reality.  

You can use dot voting for prioritization. Ask the group to cast their votes by placing a dot next to the items they feel the most strongly about. They may use stickers or markers to do this. As a rule of thumb, giving each participant five votes to cast works well.

Participants cast their votes all at once and they may vote more than once for a single item if they feel strongly about it. Once all the votes are cast, tally them, and if necessary make a list of the items by their new rank.

This prioritized list becomes the subject of discussion and decision making. In some cases, it may be useful to reflect on ideas that didn’t receive votes to verify that they haven’t been left behind without cause.

The result should be something like the below image:

4- Now categorize items by the Agile fluency model. Let’s map this card to agile fluency zones:

5- Explain the agile fluency model to workshop attendees. You can use this video too. 

6- Select the right Target

The Important part of this game is selecting the right target. In our example, based on votes, the second zone, Delivering is a suitable target for us.

Similarly, while each zone has value, each zone also brings challenges. Investing in more than you need could incur organizational backlash, and could even poison people’s perception of agile ideas in general.

Think of fluency as a ride on a bus. When you get on a bus, you buy a ticket for the zone that you want to reach. A zone that’s further away isn’t inherently more valuable; it just costs more and takes longer to get to. Sometimes you’ll buy a bus ticket for the suburbs, because you want to go to a big box store. Sometimes you’ll buy a ticket for downtown, because you want to see a play. Neither is inherently better — it all depends on what you need that day.

7- Create a transformation poster 

Now ask attendees to draw a poster with the following statements: 

1- How things are today 

2- Possible Solutions

3- How we want things to be (Use fluency model)

In this example, Agile fluency is a tool that helps you to set the right target.

8- Determine Key metrics

We need some lagging and leading metrics that show our progress against targets. These are quantitative targets. 

We can create a dashboard to visualize these metrics during the exploit.

We don’t need tons of metrics, we just need a few ones that make quantitative targets more clear and measurable. 

I mapped some of the popular metrics with agile fluency zones that you can use them:

Something like this:

Now we have a shared changed vision and a good reason for the change. It shows the direction.

In the next stories, I will share how to go the next steps, “Understand” and “Explore”. 

Please leave a comment for this story as feedback, Is this useful for you or not? Why we should continue if it’s not valuable 🙂 



About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He has worked as an Agile coach for more than 10 years with several enterprises and startups. He has more than 14 years of experience in the IT industry as a Software Developer, Tester, and finally an agile practitioner. You can follow Asad on Twitter and LinkedIn.

Real Agile transformation case study, with Agile Fluency Model

Omid is a WealthTech company based on A.I (artificial intelligence) that offers intelligent wealth management solutions to customers(B2B and B2C). When I was invited to join this company, they typically expected me to implement scrum, but based on my experience implementation of scrum should not be a goal. We need to answer this question, really why should we implement Scrum? Actually what problem does it want to solve by implementing Scrum? In many cases, we do all scrum ceremonies but our stakeholders (Managers, Developers, and customers) are not happy with the result!? We can call it Fake Agile.

How did we start the Omid agile transformation journey?

At the Omid, I tried to use the Agile Fluency Model to promote agility. This model describes how to enable your teams to produce the results you need and achieve the success they crave. The Agile Fluency model has three basic steps for agility(The Agile Fluency Improvement Cycle):

1- Discover opportunities

2. Diagnosing(Understand System)

3. Exploit opportunities.

First step: Discover opportunities 

Generally, in this step, we tried to understand what the concern of the organization is. The word. What is the challenge facing the organization that thinks it needs a different approach? 

About the Omid Company, we tried to discover the opportunity during the first week by talking to technical members, product managers, and senior executives. The important point here is that everybody will tell their story and viewpoint to you. As a coach, you need to understand what the underlying issues are. For example, if daily standups are not held on time, this may not be an underlying issue. 

Let’s come back to Omid, Omid had made rapid growth in a short time, and in this growth stage, they developed many components and systems. But systems were so fragile and any changes in the system broke many things in other parts. 

This fragility caused a lot of bugs and a high rate of bugs has slowed the development of new features. At the same time, it hurts the trust level to technical members, why it takes too long to develop a small feature? Why our team is so slow? Do we need to hire some experienced developers? This fade of the trust itself had also caused problems in human relations. Even the technical guys looked at each other and their ability with suspicion. (This guy is so slow and I think we need to fire him…)

Even more so, financial profits had reduced due to the lack of proper progress of the projects, and in some cases, bugs had caused many financial losses for the company.

This is a very important point that we find the main challenge and not simply involve in malady symptoms or signs. The manager might say that I must bring a new technical force, Scrum master might say that scrum meetings aren’t held properly and so on. In this case, the main challenge was so hidden for stakeholders. Managers thought their teams were so lazy, and development team members thought they had lots of unplanned issues during sprints and they need a process to handle unplanned works. 

The identified opportunity in Omid

Improving the quality of the system to maximize customer satisfaction, stakeholders and especially team members.

While quality was our first challenge, at the same time it could also become an opportunity that led us to soar. 

Fluency zone selection based on opportunity/challenge:

The Agile Fluency model is not a maturity model, usually, in a mature model the more is better, but in this model which we have four zones, each zone has its own benefits and costs. Each zone represents a fully-mature choice. Similarly, while each zone has value, each zone also brings challenges. Investing in more than you need could incur organizational backlash, and could even poison people’s perception of agile ideas in general.

Summary of the different fluency zones:

The Focusing zone represents agile fundamentals, and fluent teams provide noticeable benefits to transparency and teamwork. Although Focusing fluency doesn’t include sustainable technology practices, it’s a great way to demonstrate success and create buy-in for further investment. It’s also a good fit for teams, such as some digital agencies, that don’t maintain their software long-term.

For teams that need to modify and enhance their software for more than a few months, Delivering fluency is often a better choice. This zone represents agile sustainability. Delivering teams have low defects, high productivity, and are responsive to business requests. Fluency here is a valuable leap forward for most teams. 

Organizations that wish to set the pace of change in their market, or who see the threat of market disruption on the horizon, will benefit from choosing the Optimizing zone. Optimizing represents the promise of agile: innovative business agility. Although it has dramatic payoffs, it also requires disruptive changes to organizational structure. Making those changes is often easiest in small, nimble organizations. 

Leaders who want to innovate management theory and practice, particularly in small- to mid-size organizations, may find the Strengthening zone to be the best fit for their teams. This zone is a possible future of agile. Cutting-edge agile practice appears to be moving in that direction. However, be cautioned that this zone requires researching cutting-edge management theory and inventing new ways of working.


Based on the chosen opportunity/challenge for Omid, we targeted the second zone, Delivering, but we also had a look at the Optimizing area that if sustained, could be our future Target, but the main focus of the course was on the Delivering zone.

Why the Delivering zone selected?

The main metric of this area, as defined by the Fluency Agility model, is: “The team can release their latest work, at minimal risk and cost, whenever the business desires.” And the other benefit is “The team has low defect rates, so less time is wasted fixing bugs and more time is invested in making improvements” On the other hand, “Low defect rates and technical debt are beneficial to job satisfaction and morale, improving retention and productivity.”

Well, these items were exactly what we needed for the opportunity we had discovered. So based on this, the second zone was selected. Important point: The Delivering area is based on the Focusing zone. That means you should also be practicing this area along the path. Well in the first week we had discovered the opportunity, and we had chosen our target, now it’s time to conduct the Diagnostic.

Second step: Conduct the Diagnostic

Agile Fluency Diagnostic is a tool for facilitators of the Agile Fluency model. This tool will help you to determine the distance between you and the zone that you targeted or in simpler words, works like a GPS to determine where you are right now and what path to reach the chosen target. 

The diagnosing of Omid teams were run in a workshop, and the results were prepared for the team and senior managers in a report. The most important function of this report is that management knows what to do to support the team on the journey, and the team itself knows how to take the path.

Third step: Exploit the opportunity

In the first step we selected our target, in the next step, we realized where we were and now it is time to move on and exploit the opportunities. This is actually the coaching phase for teams and managers.

For the first zone, we asked managers to provide the following things (the First zone was the basis of our original Target):

  • Create the right environment that focused on high efficiency (Especially team room.). 
  • Make sure that someone with expertise in the business field and familiar with customer values is available and acts as the team’s business representative. 
  • Try to overcome the obstacles of effective teamwork such as competitive rankings, individual rewards. 
  • Train managers to create the right teamwork environment and instead of managing people, seek to manage work systems.

Managers did good cooperation in all cases, for example breaking teams into product teams was one of the things we did, or the product team members sat together at the common table, or the managers instead of tracking work’s progress from individuals, tried to ask the team. Finally, we breakdown our technical department to different 5 product teams.  

At the team level, the team also started the scrum and kanban processes, sprint planning meetings, sprint review and retrospectives started. Physical boards and lots of scrum and kanban practices…

This zone was so great but was not enough for us. Unfortunately, many companies are stopping at this point, but this zone was not our targeted zone. The main target was the Delivering zone. 

Most of the manager doesn’t have a problem with spending money, but one of the biggest investments the organization will make is time. We were so lucky that we had the support of the CEO, and he was willing to trust and made the investment. This investment meant a decrease in the team’s capacity to execute new futures for several months. 

At the team level, a lot of work had to be done. The main thing was that some parts of the system had to be refactored, some parts had to be written from scratch, tests (different types had to be added to the system), but there’s a big trap here, Unlimited refactoring or over-engineering. To prevent this trap, we used a simple technique. We checked out over 100 recent bugs in the Jira. Bugs are usually good things to identify fragile components. Then, based on this evidence, we began to prepare a prioritized list of technical debts.

During sprints and based on priorities, teams started to refactor different parts and add different levels of automatic tests (unit or integration tests). Don’t forget this point, refactoring is not our goal, we should have known that this refactors would reduce bugs rate and increase the quality level? In simple words, if we couldn’t measure something, we couldn’t improve it. In the beginning, we added a bug report widget to our application that users and testers could report bugs, and these bugs were recorded automatically in Jira. The numbers in the first weeks were incredible, 30 to 45 bugs in a week.

The must crucial step in change process is to create a sense of urgency

When the first time development team members saw the above chart, it was unbelievable to them, “We really have so many bugs?” Sometimes you need to bring the real situation to the forefront to create an urgency sense, that’s all. We defined a challenge with the team, who wants to bet? Do you think we can decrease this number under four?

Team Challenge: 40 to four. Participate in this challenge 🙂

The number was visualized on a big TV in front of the teams. Now in each sprint and in any deployment, team looking to reduce that number. That means, the refactor was not because of the refactor or Uncle Bob said to write clean code, but it’s for improving quality and customer satisfaction.

Look at the impact of your work and go ahead with more power.

In this company, we had some internal users, that we called the traders, who use our application to increase the wealth of their customers. One of the interesting things we discovered was that we involved them in our daily standups. At the end of the daily standup meetings, we were calling one of them, and asking them two questions: 

1. How many bugs did you record today? 

2. In your opinion, the quality of the system is better than yesterday or not?

These questions let us knew our customer/user’s feelings about our application and at the same time it creates a really great empathy for developers. They are looking to make their customers happy with high-quality software, so any refactor or improvement should help us to reach this goal. 

The initial list of technical debts was not a fixed list and was changing during sprints. But the result was incredible. In four months, the teams were able to bring this number down to almost below 4, it has also begun working on new features too.

Actually, our technical debts list did not just contain refactoring, but also there were other technical things too, such as adding microservice monitoring, adding health checks services, and documenting important parts of the system, and so on. Or other initiatives like separating the test environment from production or create a beta-customer environment. After observing the results and reducing the bug, human relationships also improved extremely.

What was a significant result?

As I said at the beginning, the problem with the company was not the use of scrum, what the company needed was a high-quality product that would make these:

1) Make adding features easy

2) Led to customer satisfaction 

3) Developers are proud of the quality of their work.

Reported bug chart

Tangible results over five months for business:

1) Extremely reduced technical debt and the increase of the ability of the team to handle feature development 

2) Increased a tangible level of trust between team members and leaders 

3) Increased company profits due to the ability to attract and retain previous customers

Because my main beneficiary in this project was the CEO, I asked him to express their opinion on the outcome of the project in one sentence:

“You dear Asad did it well. A deep understanding of human relationships, rooting for issues rather than dealing with the foliage, continued presence in teams, and tremendous experience and understanding of the problems of teamwork in Iran, made the previous challenges that were in Omid disappeared completely. Thank you very much. “

What is the future of Omid?

Transformation is an endless journey that will have many ups and downs. Especially there is a great distance to the fluency point, so I was at the beginning of this journey with Omid’s guys and I hope this path will continue in the future by guys themselves.

Be agile and good luck

Asad Safari

Two ways for better planning and estimating

-“How is it possible to better estimate sprint backlog issues?”

-“Why do you need a better estimation?”

-“You know, In the sprint planning meeting, the team fills the sprint with lots of issues, but in the middle or at the end of the sprint we have to remove lots of them from our sprint’s plan.”

-“With better estimations, Why do you think the same thing won’t happen again?”

All over the world, most software development teams are using Scrum. They have accepted it that software development is a complex thing. So something like waterfall not works in the complex domain, and you need a tool or method or practice to solve this complex problem.

Based on my experience, most of these teams are looking for a magical way to have an accurate plan for their sprints.

In this story, I would like to share my own experience with these teams and share Factful planning framework, a tool that helps you to have

better plannings and estimations.


The main problem is that we forgot the “Problem.” At the first level, we need to check some understood assumptions. Scrum (n): A framework within which people can address complex adaptive problems.

In theory, everybody has accepted that: First. Scrum is a framework, Second- A framework to address complex problems. However, in real-world, the people act with Scrum as a project management technique. The big problem with this idea is that they forget uncertainty.

In the complex domain, you need to accept uncertainty as a reality, and you can’t ignore it.

Is it possible to plan and estimate in this uncertain world? I suggest you “Factful planning framework.”

Determine the uncertainty level with uncertainty matrix

The first thing is that the uncertainty level of product backlog items is not the same. Any item has a different level. You can determine this level with uncertainty matrix.

Uncertainty matrix is a simple tool to help you to understand your backlog’s items uncertainty level. This matrix has two dimensions.

1- What: What we should do?

2- How: How we should do it?

Grab one of your product backlog items, and look at this issue, first think about “What” dimension. Answer the following question:

Do you(or your team) know what you should do for this issue?

1- Yes, We are sure about detail, and we need to do it

2- Yes, But we are not sure about the details.

3- No, details are unknown

After, “what” dimension, think about “How” aspect. Let’s answer this question:

Do you(or your team) know how to do it?
1- Yes, We are sure about to do it(We have already experience about it)
2- Yes, But we are not sure.
3- No, we need to test different things.

After that, you can choose uncertainty level for your backlog item, for example, 2–3, it means 2 in what dimension and 3 in How aspect.

Factful planning in the scrum events

Let’s think about this example; you have a high priority item with 3–3 uncertainty level. Because this item is a top priority, you select it as one of the current sprint backlog items in the sprint planning meeting, and you ask the team to estimate it.

How should the team estimate this unknown item with a high level of uncertainty? What is the value of estimation when it is wrong?

So, Uncertainty level will help you think about the main idea of Scrum again, “Address the complex problem.”

Factful sprint planning

The first idea is to do not select items with uncertainty level 3(What or How) to implement it in the current sprint. Try to choose items with uncertainty level of 1 or 2.

What about the third level of uncertainty?

Why should we not select them for current sprint? It’s impossible to estimate this kind of items. When you choose them as committed items to current sprint, our stakeholders will think, you need to finish them in this sprint, and this is part of your commitment.

Strategies for the third level of uncertainty

Answer this question: “What can we do in this sprint to create knowledge to decrease the uncertainty level of this item?

With remembering the uncertainty, the team, instead of being committed to doing unknown issues, they will try to create knowledge and increase the certainty level.

Practices to increase certainty in “What” dimension:

1- Design Sprint

2- Talk with customer

3- Create MVF (Minimum valuable feature)

4- Take time to break down it and write acceptance criteria(like grooming meeting)

5- Functional Spikes

So, you are trying to increase the certainty level in what dimension. I met some teams that they don’t have any communication with their customers.

In some cases, just small talk with a customer can decrease the uncertainty level. Sometimes you need to create a prototype or some methods like design sprint. Sometimes you don’t have time to break down product backlog’s items or write acceptance criteria for them? Maybe you need grooming or refinement meetings.


Based on Agile Dictionary definition, Spike is a task aimed at answering a question or gathering information, rather than at producing a shippable product.

Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.

Functional Spike, This kind of spikes trying to answer a question in the functional aspect. Ex. “Do we need this button here or not?”. A functional spike can be something like that “Prototyping of asset management console.”

Practices to increase certainty in “How” dimension:

1- Technical Spike

Like functional Spike, This is a very simple program to explore potential solutions. For example, “Which library is good for SNMP scanning.”

This kind of spikes will help us to explore solutions and decrease uncertainty.

“What” vs. “How”

If you have an item with uncertainty level 3–3, What is your priority? Based on my experience, you need to start with “What,” Because “How” really depends on the requirement, and we need to determine our technology based on our requirements.

What about change?

Don’t make wrong; we can’t ignore the change. Uncertainty level can be changed over-time based our knowledge about business and technology. This practice is a simple tool to remind you about reality, “Uncertainty.” Instead of taking lots of time for an accurate plan or estimate, work hard to create knowledge at the right time.

Factful sprint review

One of the other practices of Factful planning is “Demo for.” Like the uncertainty level, you need to add a new property to your backlog’s items, “Demo for.” You need to determine at the end or during the sprint, Who should see the result of this item? Who should provide feedback to us?

In some cases and in real-world, items with uncertainty level 1–1, don’t need any specific feedback from the customer, and this can be accepted or rejected it by our product owner. But other items with higher uncertainty level needs real customer feedback.

You can not write a general thing as a demo for, like “somebody from marketing.” If you are building a feature for the internal inventory system, you need to write something like that “John, head of inventory and Sara inventory software user.”

Why “Demo for” practices?

1- sometimes, we have different items for different segments. With this practice, we know that we should get feedback from the right person.

2- Don’t waste your time to get feedback for some 1–1 item. (They will make our review meeting so dull)

3- You can send an invitation letter to them, to join you and make themselves available for you. They have time for preparation and set the meeting on their calendar.

4- You will not forget to get feedback.

Why do I call these practices Factful planning?

We need to learn to separate fact from fiction when forming our opinions. The organization can be both bad and better. Progress comes bit by bit, But without facts, our minds are occupied by feelings. This practice is part of my factful agility toolbox.

Asad Safari

About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He has worked as an Agile coach for more than 7 years with several enterprises and startups. He has more than 14 years experience in the IT industry as a Software Developer, Tester, and finally an agile practitioner. You can follow Asad on Twitter and LinkedIn.


A big company asked me to help them to implement OKR. I tried to understand why they are looking for a goal-setting system? Based on my observations and interviews, I found the following objectives: 

1- More focus on meaningful and valuable work 

2- Better alignment in the entire company

We started with training, most of the guys were happy about the new thing. After that in an iterative approach, we helped them to set their Objectives and Key results.

Now each team has 3–4 objectives and 3–4 key results assigned to any objective. Everything looked good and we knew there is room for improvement, for example, teams need to set ‘Value oriented’ key result or set personal OKRs … But they need time to practice it and we should let them try it and learn more … learning by doing. 

I remember that our objective from using OKR was “More focus on meaningful and valuable work”. To validate this idea, I tried to ask from teams, “What a special thing that you want to achieve in 3 months?”. Their answer made me surprised “Yeah we have some projects and we need to finish them …. start X project too”.

It was my mistake. I told them, each team should have 3–4 objectives. So, they did it. We need to have 3–4 objectives with some measurable key results. and mission has done 🙂

for example:

1- Increase customer satisfaction

2- Increase technical quality 

3- Improve team agility

The problem was, They have 3–4 general OKRs, But most of the teams did not think that we need to have some big achievements and we need to work together as a team to reach it. 

So I tried to help them to fix it. In one of my old clients, we had the term “OITO”, “One Important Thing Only”. What is your OITO? It means “What is your one important thing only in this quarter?”.

So, I did not want to use “OITO” in this company, “Hey guys, forget OKR and we want to use OITO”. But I tried to test it with one OKR for each team but a meaningful one. “Hey, you don’t need to convert your business as usual to OKR, You can do them in this quarter, But what is your one important thing only in this quarter?”

For testing this idea, We started with just one team that we think they don’t have so meaningful objectives. I designed a workshop based on “Celebration-5W” an so we invited all team members to a 2 hours workshop.

“Hey, welcome to our review meeting, We are going to do a different thing today. Let just forget your team objectives for 2 hours. ”

It’s some months from now, and you’re celebrating! Isn’t it wonderful to see everyone together like this? And you deserve it: over this period, you, your teams, and your entire organization have achieved far more than anyone would have thought possible. 

What makes this celebration so special? We’re going to explore that via some time travel and the classic journalistic questions of Who, What, When, Where, and Why, otherwise known as the five W’s.

“Let’s create a celebration journal together” 

Imagine… You’re celebrating! 

  • Celebrating meaningful accomplishments, objectives, goals 
  • Celebrating with everyone who helped make it happen: colleagues, suppliers, customers, … 
  • Reminding each other how you were stretched and why it was all worth it

You can use the following template for your journal or be creative and create your own:

What are you celebrating? (Key accomplishments, objectives, goals)

When are you celebrating? (The timeframe required for this significant challenge)

Who is celebrating with you? (Organisational scope/identity; others involved or supporting)

Why is this important? (The Why of the whole endeavor, not just the celebration)

So I think this is a great technique to think about meaningful accomplishments, objectives, goals. For my current client, I would like to review their OKRs to find their OITOs, and I think “Celebration-5W” can help us to do it.

I will share the next steps of OITO with you, How to convert it to projects and tasks, But I need your feedback about this, Please let me know is it valuable to continue or not. 

Asad Safari