Create a real agile team with Fogg behavior model

As an agile coach, I try to help and empower companies to find their own way and move forward in their agile transformation. But there are companies that just hire me to hold a 2–3 days agile/scrum workshops for them.

I want to tell the story of one of these workshops for a company that we call it “Manko”(Not a real name). All team members, Team leads and managers participated in the workshop. There was a different type of people with different ideas and beliefs about agile:

1-Agile is a great thing and we need to follow it 2- Agile is a new fad and this trainer try to sell his gold hammer to us 3- No idea about agile and curious to learn new thing.

In my courses, I always try to reach the following goals and help the teams to stick to the change after my workshop.

1- Awareness(Why we need to change?)

2- Desire(Everyone or part of them has the desire to take part in and support the change.)

3- Knowledge (What is the Agile and different frameworks, and how they work?)

At the end of my workshops, I try to measure my result with these questions(Do they have the motivation and enough knowledge to start the change? ). 

For “Manko” case, at the end of the workshop, everybody was happy and they told me, “We will start to practice from tomorrow and …”. It was so exciting for me. 

After a while, I asked them “What is going on there?”, And in response, “Yeah, we are so busy now but trying to write user stories on Jira but developers didn’t update it … Some days we have daily standups, hmmm, not regular and…”. 

It was so surprising for me, Why such motivated guys could not succeed in their change plan? 

I thought we just need motivated guys to be able to change, and motivation can drive the change. But it was a wrong hypothesis.

The Fogg Behavior Model shows that three elements must converge at the same moment for a behavior to occur: Motivation, Ability, and a Trigger. When a behavior does not occur, at least one of those three elements is missing.

Based on this model, We have Motivated guys but low Ability and no Prompt or Trigger

Maybe you think that Why they don’t have enough ability? Why your course didn’t make them be able to work agile. 

We need to understand the difference between Knowledge and Ability. In a 2–3 days training course, You can just create knowledge for them and not the ability. Even simulations or any kind of games cannot create Ability. 

Ability comes from daily and real work. Once the knowledge(theory) is in place, then the individual needs to be supported during the actual performance (practice). They need to do it and make mistakes and learn and repeat and practice. 

For example, you are trying to write user stories together with all team members. But you don’t know how to write or breakdown stories for your real project in the banking industry. It will create frustration for team members and as a result, they will put it away 🙂 

Cognitively Demanding (Mental Effort) — People probably already have a lot to think about, so any new behavior that they are trying to take shouldn’t increase their cognitive burden too much.

So based on the Fogg model, We need to make teams be able to change their behavior. 

Hire Scrum Master/Agile Coach For fostering ability:

  • Coaching or role-modeling in the real work environment
  • Access to right tools
  • Give Feedback
  • Co-Working with a team, for example, breaking down stories together

Trigger or Prompt

Ability and Motivation are not enough to change behavior. We need to a trigger too. There are three types of the trigger, each aimed at a slightly different audience.


The spark is a trigger that comes with added motivation. It’s perfect for those who have the ability but lack the motivation. 

Our training course sometimes works as Spark trigger. When it comes to training, a spark should help a learner see the Epic Meaning in the behavior you’re asking of them. They want to know why it’s important, and it’s up to you to make them care.


A trigger that is applied when there is high motivation but low ability. It seeks to simplify the task. As an illustration, suppose that you’re trying to eat healthier but you’re not very organized. You can sign up for a newsletter that is delivered every Sunday morning to your inbox with easy-to-make, delicious recipes for healthy meals. This will prompt you to sit down with the newsletter and plan your meals for the upcoming week, right there and then.

I think in our case Scrum Master or Agile Coach can be a great trigger for the team. She can work with them daily, Send them small pieces of training, Show them how to do a task(Like breakdown story),….

For example, I was an Agile Coach in a big enterprise, We tried to use OKR in company level. We held training courses for teams about OKR. Some of them started to write their Objective and Key results in the company’s confluence. So I started to check their pages, and comment for them. 

  • “Hey, Vahid, How do you want to measure this key result “Improve the speed delivery?, Do think we have any number to measure? like Deployment count per week?” 

Or I shared good OKRs as good internal examples to other teams in our social messaging groups. 

Or One-on-One mentoring with managers to check their OKRs. Giving feedback to them …


They are ready to change. They have the motivation, they have the ability, all they need is the starting gun to fire and they’ll get going. This is just a prompt that serves as a reminder. It can be something as simple as a post-it note.

Scrum masters and Agile coaches can create ceremonies or some reminders for teams to act as a signal. For example, weekly meetings for checking and tracking OKRs. 


I think, for sticking on agility, companies need to hire or develop empowered Scrum masters or Agile coaches or any kind of agile practitioner. 

Agile coaches/Scrum master need to understand, three elements must converge at the same moment for a behavior to occur: Motivation, Ability, and a Trigger. 

If your team is not motivated about agility, let them know about the meaning and philosophy of Agile, you can ask help from external agile coaches/trainers. 

If your team doesn’t have the ability and it makes them frustrated, act as a facilitator and mentor, Work with them, Create a product backlog together. Create a safe space to learn by doing. (Company and senior leader should support you in this stage). 

Sometimes you need to act a simple reminder. Ask questions “Hey, When do you want to do grooming meeting in this sprint?”

Maybe you like:

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.

Jobs To be done in the real world

If you are trying to understand or learn about Jobs-to-be-Done and you are looking for real-world cases, there are a few real cases like“McDonald’s Milkshake”, and it’s difficult to find other examples.

In my previous article, I introduced a tool for agile coaches “Coaching canvas”. I tried to use the Jobs-to-be-done technique to create and introduce this canvas. In this post, I want to share my story with JBTD.

“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”

This is the essence of the jobs to be done. Your customers are not buying your products, they are hiring them to get a job done. (CLAY CHRISTENSEN)

So it is necessary to understand the job that customer want to get done. most of the time we just think about our product and we fall in love with it but our customer or the user just think about her job.

Charles Revson, the founder of Revlon, said:

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

In my last experience, I tried to test JBTD with coaching canvas. Coaching canvas is a tool for coaches that they can frame problems and solutions in a good format. But it’s not the main job that agile coaches want to get done. Agile coaches don’t need another tool, they want to help teams to be agile and looks valuable for them and organizations.

They “hire” this tool to make progress.

So based on this idea I started my article with this title “How to avoid imposter syndrome for Agile Coaches”. Why imposter syndrome? You know agile coaches want to help teams to be agile and looks valuable. But sometimes they are are not successful to get this job Done, and in psychological aspect, most of them will feel imposter syndrome (I’m not valuable for organization and kind of frustration).

In the classic definition of JBTD, we have different types of jobs:

Functional Jobs — the core tasks that customers want to get done

Emotional Jobs — how customers want to feel or avoid feeling as a result of executing the core functional job

Social Jobs — how customers want to be perceived by others

Something like this:

An agile coach wants to help teams to be more agile (Functional Job) She wants to look valuable in the organizations (Social Job) and Don’t feel imposter syndrome (Emotional Job).

There are lots of different canvases out there, but they hire a Coaching Canvas to get their job done.

Based on my experience, Emotional and Social jobs are over Functional jobs. But unfortunately most of the time we ignore these aspects. Over 40 billion photos have been shared on Instagram, Why people would like to share their photos? Instagram clocks up 3.5 billion likes every day.

But in the new definition of JBTD, 3 types of jobs are not a useful idea. Alan Klement, With respect to Jobs, no objective test can be created to say, “This is a social Job. That is not a social Job.” If I buy a Ferrari to impress other people, is it a “social” Job because I reference other people? Or should we rephrase it as insecurity, making it a “personal” or “emotional” Job? Take it from me, don’t waste your time trying to dissect Jobs into different types. It’s about as productive as trying to answer, “How many angels can dance on the head of a pin?”

I agree with Alan, categorizing jobs to 3 different categories is not a useful activity.

In another part of Alan’s story, “JTBD is not a framework, method, lens, or methodology. It’s not something you do. It’s something you learn.” Its purpose is to help you describe demand, not to tell you what to do about it. JTBD is about understanding what-is. It is not about creating what-should-be.

In my story, I learned about agile coaches demand and I tried to explain it with JBTD theory.

“An agile coach wants to help teams to be more agile, She wants to look valuable in the organizations and Don’t feel imposter syndrome.”

Maybe you like:

About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He works 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.

More about Coaching Canvas

In my previous story, 5 Steps to avoid Imposter syndrome for Agile Coaches, I tried to share my experience with coaching canvas and how to use it. After that, I got really great feedback from different coaches.

So I decided to share more examples. Please share your experience and your story with coaching canvas too.

Click here for Download examples of Coaching Canvas

Asad Safari

Maybe you like:

About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He works 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.

5 Steps to Create an Agile Structure

Talking about an agile organization, we actually mean a number of teams that drive the organization forward. A non-agile organization is like a warship. Even though our carrier is strong, but has little flexibility. Agile organizations are like small — line war boats moving toward the mission and goals of the organization. Being small helps to reach out to high flexibility.

Indeed, teams are the most basic fundamentals of the agile structure. Those with three main features: Being small, cross-functional, and having self-organization.

In my opinion, cross-functional and self-organizing, are highly depended on factors like “team” and “small”. We tried to do some experiments in one of the units of my client(Part of the biggest bank of the middle east) and this story is to share my experience.

In this unit, ­managed by Vahid Ramin, we concluded that the current structure was not suitable for agility (like a warship), so we decided to change the composition. (A nice characteristic of Vahid is his courage to make changes and perform experiments which, in my opinion, is one of the characteristics of the agile leaders).

What was the situation?

The group’s name was Audit & Inspection, because most of their systems were for the bank’s Audit & Inspection department. But over time, a lot of new projects were being allocated to the group. Projects from different business areas, from “Customer master data management” to “Open banking platform”. To carry out these projects, new people were added to this group, so the group was growing up. The number is approximately about 12 to 60 people (warships).

This big group did not have the concept of the team (there was no agility core). It was just a number of people trying to finish lots of project at the same time, Lots of dependencies, redo-works, hand-overs, etc. We were trying to carry out the agile ceremonies on the big group, but events such as Sprint Planning or Review were completely useless. The problem was it was so boring or ineffective.

What happened to the situation?

1. Discovering teams using business area

The first thing to do was to identify business domains, for example, a bunch of work related to inspection systems, with the scope of monitoring and detecting transaction infraction.

You may ask why do you need to find business areas? In fact, one business unit should follow a specific area. But over time many projects were assigned to this group, projects in different areas. We were forced to discover these categories because there was no specific pattern.

2. Assigning people to areas of business

The next step was to allocate existing people based on business domains. In this process, we tried to seek team members and team leaders help (the team leaders themselves were also identified in this process based on leadership skills). At this level, there was a try to have teams be under 7 or at last 9 so that the rule that groups must be small was obeyed.

3. Identity Symbols for teams

In my opinion, this is a very important step in the team building process. Like branding for a company, teams also need an identity. I got this idea from Jurgen Appelo, Management 3.0 practices. An Identity consists of the name, logo, slogan, etc.

It is very hard to have a sense of belonging to a group when the group doesn’t have a clear name and image.

If we want a person to feel part of a group and balance the needs of the group against his or her own needs, the group will need a name and image that is at least as strong as that people. 

Being a member of a group is a great feeling. Creation of small identities in the team form can help in empowering the sense of belonging to a small group, while at the same time it helps the larger group.

The names and logos which were chosen in collaboration with people themselves:

Logo and Name of teams

4. Mission over backlog and to-do list

The steps above are good, but not enough. In fact, in addition to daily tasks, teams need larger goals. At this point, it was declared, based on the scope of the business being discovered, that teams have a clear mission to answer the question “Why are we here?”.

In assigning a mission, it was tried not to focus on tasks or activities, but to think about the impact of things. What is the result of our daily activities?

Teams with mission

Let’s have an example. Imagine the team’s mission is to reduce “Transaction Infraction” in a bank which is beyond a daily basis. The team has to reduce the number of financial violations. It is about doing a meaningful job. Now, team members have a great reason for celebrating… If I was one of them, I would have enjoyed it 🙂

5. Repeat and repeat and repeat

The repetition of the names and mission in different events is the secret of survival otherwise, they will soon be forgotten. In this situation, team leaders, managers, and product owners play an important role.

Next step is to show it in different places, for instance, on mug or badge of team members.

Is it over?

In fact, this is the beginning of a great change. We are always learning. When teams grow or some parts do things that are not in the same direction or there are dependencies on other teams, it could be a sign of birth (creating another new and small team).

For example, the Orka did not exist at the beginning. The Oxygen team had two large baskets, one to develop open banking platform, and second to provide information services to different groups and companies.

Due to team expansion, one of the baskets was broken down and a new team called “Orka” was created. In this new team, there are people from different groups (operations, data, etc.) to complete an end-to-end process. First, speed up service delivery, and secondly, reduce hand-over.

What is the next step?

The next step is to move on toward our meta — Cross-functional and self-organized teams. Teams with minimal hand-overs that can move toward their mission.


The basis of agile organizations is small teams, teams with a mission and a distinct identity. The task of the organization’s leaders is to define a mission for the teams, remove the obstacles they face, and help them achieve their goals.

Asad Safari

Maybe you like:

5 Steps to avoid Imposter syndrome for Agile Coaches

Effective estimating with estimation board

About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He works 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.

Effective estimation with estimation board

There are many arguments about estimating in an agile community. Do we need to use story points, man/hour, ideal man/day, or even #NoEstimation? Today most agile teams are trying to use the story points as the main unit for estimating.

What is the story point?

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values? A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

By Mike Cohn

But the main problem is how to assign a story point to an item? This is 5 story points, but how?

Planning poker is dead, Long live Planning Poker

Based on Mike Cohn’s article, Planning Poker is an agile estimating and planning technique that is consensus-based. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The values represent the number of story points.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.

The problem is exactly here. “Each estimator privately selects one card to represent his or her estimation”, But in the real world, estimators forget the relativity of points. In my experience, when somebody assigned a 2 story points to an item, He didn’t think to “Oh, It should be two-thirds of a story that is estimated as 3 story points”, Most of the time something goes like this “This is 1 hour for me and maybe 1 hour for front-end developer, so it’s 2 story points.”

As I experienced before, Planning Poker is not an effective technique to assign story points on backlog items, because most of the time development team forget the relativity of story points and story points are useless without relativity.

In the same time, planning poker is an effective planning technique because it helps the team to have a conversation about the story and user’s needs. In the conversation about the story, you will find a new idea or even change the story or….

However Planning is over Plans, Estimating is over Estimations.

Estimation Board

Estimation board is a practice based on my experiences to improve the relativity problem of planning poker technique.

In this practice, you will just add a board (whiteboard or …) to your planning poker process. After estimating any item, you need to put it on your board. Make it visual and transparent.

Something like the following image:

Try to create columns for each category, like the following image:

Estimation board — Image 2

Keep continue estimation and planning process and update your board:

After finishing estimation, let finalize estimates based on relativity. Let team members check one column each time. For example, there are 3 items in category 2. “Are they the same size?” If not, you can move items to other columns.

This is a simple visualizing practice, but this practice will help you to improve the relativity problem.

Keep relativity all over the project/product lifecycle

You can’t change your estimation touchstone in each sprint. You need to keep this relatively in all over project’s lifecycle. So, easily you can keep the first row of this board and use it in next sprints too. It will help the team to have balanced estimation during all over the sprints or releases.

Maybe you like: 5 Steps to avoid Imposter syndrome for Agile Coaches

About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He works 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 agile practitioner. You can follow Asad on Twitter and LinkedIn.

5 Steps to avoid Imposter syndrome for Agile Coaches

“I have no idea what I’m doing?”

Have you experienced this feeling? As an Agile coach or Scrum master, you think that you are not valuable to your client/organization, and you don’t have a good feeling about your accomplishment. We call it “Imposter syndrome.”

I saw some tweets in the agile community, and this idea came to my mind that most of us have a common sense and we should talk about it.

Based on Wikipedia:

Impostor syndrome (also known as impostor phenomenonimpostorismfraud syndrome or the impostor experience) is a psychological pattern in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a “fraud”. Individuals with impostorism incorrectly attribute their success to luck, or as a result of deceiving others into thinking they are more intelligent than they perceive themselves to be.

Yes, It happened, It has happened to all of us. I’ve experienced it many times in my career.

When it comes to your mind, it makes you sad. Something like that “I have no idea what I’m doing.”

In this story I don’t want to explain imposter syndrome, I want to share my personal experience and some tested practices to solve this problem.

Several years ago, I started my journey as an agile coach in a big company. They hired me to make them agile. They had more than five development teams. We began our journey with observation and assessment phase. After that, we did training and different workshops for teams. Everything looked good for several months; you do training, guys come to you and ask about questions and recommendations, you have a good feeling, you do tangible things that are appreciated for everybody…

After some time, teams are doing their business as usual. You need to follow them, and you ask them to do some practices, but most of the time they are busy with their affairs. I fell to thinking the question that am I helpful here anymore.

Why did it happen?

It’s about factfulness. We are helping the organization, but we don’t have enough facts to show ourselves. Organizations always have some new problems, and it triggers the feeling that the organization’s performance is worse than the past.

I recommend to read the book “Factfulness: Ten Reasons We’re Wrong About the World — and Why Things Are Better Than You Think” book by Hans Rosling. In this book, Rosling suggests the vast majority of human beings are wrong about the state of the world. We need to learn to separate fact from fiction when forming our opinions.

The world can be both bad and better. Progress comes bit by bit, But without facts, our minds are occupied by feelings.

So, as an agile coach we need to be factfulness about our work and organization, but how?

Practical Factfulness for Agile Coaches

1- Focus on one or two teams

Don’t try to make all over of the organization be agile in the first try. As an agile coach, you have capacity. For larger organizations, we may need to have more than one coach.

In my case, I have focused just on two teams at the same time. Some guys said it’s a kind of sub-optimizing, and don’t do that, but it’s about focus..

2- Find three main issues or problems

Before any act or recommendation of any solution, try to find their main concerns. Why are they looking for a new way? What are they looking for agility? What has stopped them from doing a great job?

In my case, one of teams has several significant problems, but their main problem was that “The team don’t finish and deliver their committed works at the end of the sprint,” and it made their managers worried and created a cultural mistrust and … .

3- Create a coaching card

I got this idea from agile42 and I have designed a coaching canvas. It can help you to frame the problem and try to be factful.

Don’t be worry, be factful 🙂

Coaching Canvas

Download Coaching Canvas File.

You can find my real card bellow without any additional description.

Title: Team don’t finish their committed works at end of the sprint


At the end of the sprint, most items are not complete, and QA doesn’t have enough time to test everything, because most things are done in the last days of the sprint.

While a lot of work remains, some team members cannot do anything.


We think we can solve this problem with the following:

1- Decreasing team size to 5 people

2- Better user story breakdown -> Small user stories

3- Better planning meetings and Effective daily standups

4- Visualize release count per sprint on team’s board


The goal is to make the team able to publish multiple releases during a sprint and complete the most committed issues at the end of the sprint.


1- More than two releases to production in each sprint

2- Completing ~70% of committed issues

3- Not changing the length of the sprint

Metrics are so important here because they will assist us with factfulness. The recommendation is to set the metrics immediately after we have agreed on a goal, not after defining the steps. We need to make metrics clear and actionable. To say that “progress has been updated regularly” is a good beginning, but in itself, it’s not enough.

You can create this cards yourself or create it by the team. But please put indicators where the team can see it every day.

4- Share and create an agreement on coaching card with your main stakeholder

It’s a secret sauce. Somebody in the organization has hired you. Maybe she is a CTO, CPO, and CEO or…. most of them are busy guys, and after a while, they will forget what you are doing there, and they will say, why are not we agile yet?

In my case, she was CPO. She was a busy person, and I’ve needed to follow her up for finding free time.

You need to create an agreement with them on your coaching cards. Share coaching cards with them, ask them to check cards and metrics. Will they be happy if the team achieves these results? Get their idea and create an agreement with them.

5- Review results with stakeholders and teams

In each period, maybe monthly or quarterly, review results with primary stakeholders and team members. You can do it in a retrospective meeting or any other meeting.

This will help you to see your work’s results and maybe get appreciation from your stakeholders. As an agile coach, we need this kind of acknowledgments.

Link on medium

By: Asad Safari 🙂