In the agile community, most agile practitioners just repeat, hey you need to have full self-organized, self-direct agile teams, you should delegate all decisions to teams, they should make all decisions about the market and … And start to blame leaders. I was wondering who should care about readiness and the possibility of a change?
In the agile fluency model, we call this type of teams “fluent in Optimizing zone”. Fluent Optimizing teams understand what their market wants, what the business needs, and how to meet those needs. Or, as in a startup environment, they know what they need to learn and how to go about learning it. Optimizing teams have the ability to deliver to the market, and also know what to deliver to the market.
It’s a cool idea that your team is in this stage, but this stage is not free and it depends on huge Organizational Investments, like 1- Dedicate teams 100% to particular products or markets. 2- Incorporate business and subject matter experts as full-time team members (Don’t assume one person will be enough.) 4- Give teams responsibility for their budget, plans, and results; judge them on results, not adherence to plans. 5- Enable and expect managers to work collaboratively across the organization to remove obstacles to team performance. 6- Provide coaching to managers about how high-performance, self-organizing agile teams change the nature of management work.
But the huge investment is not the only problem, sometimes this zone is not an adjacent possible. The main question here is, “Is it possible for all teams to unlock or reach this zone? What about the readiness of change?”
What is Adjacent possible?
Steven Johnson in his excellent book, “Where Good Ideas Come From” wrote that: “Four billion years ago, carbon atoms mulled around the primordial soup. But as life began, those atoms did not spontaneously arrange themselves into complex life forms like sunflowers or squirrels.
First, they had to form simpler structures like molecules, polymers, proteins, cells, primitive organisms, and so forth. Each step along the way opened up possibilities for new combinations, expanding the realm of what was possible until finally, a carbon atom could reside in a sunflower.
Great leaps beyond the adjacent possible are rare and doomed to be short-term failures. The environment is simply not ready for them yet. Had YouTube been launched in the 1990s, it would have flopped, since neither the fast internet connections nor the software required to view videos was available then.”
If your environment is not ready for a new idea, you can not transform, Evolution tends to happen within the bounds of the adjacent possible, in other words, the realm of possibilities available at any given moment.
The adjacent possible is a kind of shadow future, hovering on the edges of the present state of things, a map of all the ways in which the present can reinvent itself…the adjacent possible captures both the limits and the creative potential of change and innovation.
Steven Johnson
For most companies, Fluent Optimizing teams is not an adjacent possible, it’s not a shadow future for the present context. The idea is not coherent with the current belief system and structures. Political forces or informal networks make it so difficult to think about these changes. Possibilities are limited based on our current state, but Each step along the way opened up possibilities for new combinations, expanding the realm of what was possible until finally, a team could be fluent in optimizing zone.
The main idea here is, don’t over-focus just on optimizing teams when it’s not adjacent possible, Don’t just blame leadership or managers, Don’t waste your energy on fighting against system tendency. Sometimes current belief system is not coherent with optimizing zone, focuses on lower zones, based on my experience Focusing is an adjacent possible for many companies, It opens new doors and enables you to discover a new way of working. Upon opening this door, you’ve unlocked new possibilities. Each improvement unlocks even more improvements.
Simin was a very successful Scrum Master in the previous company, She decided to enter a new company after two years to gain new experiences. The manager who hired her, asked her, “Our team is so frustrated today and they don’t have any discipline, and I’m asking you to organize the planning, meetings, and process of the team…” She had a lot of energy, and she tried to make it happen from day one. She tried to facilitate various meetings, and …. But after a while, she felt that the team was not accepted her presence and she was completely ostracized. She was feeling miserable and she felt that she could not make the changes she had been asked to.
Have you been in this situation? How to will persuade or push the team to change?
Rule #1: Don’t try to push or inflict the change
The idea that you can push the change to the people, is a wrong idea. Think about creating an attraction around the change.
Rule #2: Don’t start the change from day one, First try to enter the team and be part of them
Most of the time, people don’t have a problem with the change, they have a problem with you 🙂
Consider this situation, somebody comes from outside and tries to save us, it seems good, but on another side, it has a message to us: “Hey miserable guys, hey incompetent guys, hey broken guys, Superman is here to help you…”
It’s really important to get to know them and let them know you before offering any help. Try to understand what is going on there, and respect what happened before you. Don’t try to say everything is broken here and you should fix things. Each system has a history, try to discover the history of that system and team.
Imagine your team is ” Undamaged, resourceful and not in need of fixing “,
The realm of agile coaching is coaches who are experts in the industry and we are we know a lot of stuff and clients hire coaches to go and help them. But We can’t believe that our team is broken. We can’t believe that they are incompetent. They unable to do anything that we’re the superhero and because of us they’re going to be great and successful and without us, they’ll fail. You have to be able to see your team as fully competent. They can do this with or without you. You have the honor of being there to partner with them and they’re great.
Rule #3: Don’t be the manager’s scrum master
Do you just follow the manager’s or your agendas? This is a common mistake between scrum masters, they are just following their agenda or the manager that hires them’s agenda.
You are part of the team, you are there to help them to be excellent. You are not here to just run the commands of managers. Start with something the team cares about.
Rule #4: Do not try to convince everyone
Most of the time we try to convince everyone and align them with us, but it’s impossible. Instead, try to start with someone who would like to try new things. Don’t try to argue about practices, most of the time these are just a sort of a waste of time. Demonstrate success and let them see the result. In many cases, you and some motivated team members need to act as a role model to show the success of practice or idea.
For example, we want to adopt code review in our development process, we can start with someone who would like to learn new things from other team members, and after a while asking her for feedback.
Don’t hesitate to share your idea with me about the change process.
In my last 10 years’ experiences, one of the buzzwords in the agile community was the self-organized teams. everyone talks about it but no one knows how to create one.
It’s all about decision making
All teams face two types of issues, decision making, and execution. When a team is not self-organized, somebody(that we call it manager) makes all decisions and the team just executes them. Whenever we want to create a self-organized team, we should delegate part of or all of these decisions to the team.
Delegation
It’s all about delegating
Management and leadership books talk about delegating authority. But if you have the experience of managing even a small team, you know how difficult it is. Delegation of any kind of decision depends on two important factors:
The level of maturity
The impacts of the decision
If you have an immature team, give them a lot of authority, the team may get into a chaotic situation and even do the opposite. In contrast, if you have an experienced team, and you do not give them any authority, it will be very tedious for them just to do tasks.
There are plenty of “shades of gray” between being a dictator and being an anarchist. Most managers think they should act like a dictator or anarchists. The etymological origin of anarchism is from the Ancient Greek anarkhia, meaning “without a ruler”, composed of the prefix an- (i.e. “without”) and the word arkhos (i.e. “leader” or “ruler”). (Wikipedia)
Delegation is a step-by-step process. You hand over accountability to other people in a controlled and gradual way. In addition, it is context-dependent. You want to delegate as much as possible but if you go too far chaos might unfold.
How to delegate in action
Delegation is not a binary thing, based on this model, there are 7 levels of delegation-level:
Tell: As a manager, I make decisions and I will tell them.
Sell: As a manager, I make decisions and I will try to sell them.
Consult: I will consult and then decide.
Agree: We will decide together.
Advice: I will advise but they decide.
Inquire: I will inquire after they decide
Delegate: I will fully delegate
Visulize current state of delegtation
The second rule of delegation is: “Delegation is a step-by-step process. You hand over accountability to other people in a controlled and gradual way. In addition, it is context-dependent. You want to delegate as much as possible but if you go too far chaos might unfold. “
The first stage of creating a self-organized team is to visualize the current state of delegation. check the following image:
1- For two or three weeks try to log your decision, for example, “Today I have hired a new team member”, “Today, I asked the team to implement a new feature”…
2- Create a delegation board in miro or mural, and visualize the current state
3- Let the team understand the current state and explain the model to them
4- Let them decide about the future state and you as the manager tells them about the impacts.
5- Review this board at the retrospective meeting and make a decision about the future state again. Delegation is a step-by-step process. You hand over accountability to other people in a controlled and gradual way.
The main idea is to delegate authority to the team as much as you can, but this delegation will be based on the context and maturity of the team. Visualizing this process will increase transparency, which can increase the level of maturity of the team.
Several years ago when I was a junior scrum master, I used to push my practices to my team, and always it created resistance against me and practices. I want to tell you the truth, It decreased my courage to test new practices in my team.
Our organizations and teams are CAS(Complex Adaptive Systems), CAS is unpredictable, emergent, and it always makes you surprise. If you don’t experiment with new practices based on your context, you will fail. You should act based on context, you can’t predict everything, and you need to experiment. This kind of system needs a fail-safe-environment, but the resistance of people can create fear in scrum masters or agile coaches to lose their courage to test new practices, especially novel practices.
After several years, I got a great idea from the concept of user-story, to help, my teams create a fail-safe-environment.
Start with Why?
Let people know why we need to implement this practice? Let’s consider some examples:
As a uber user, I want to be able to share my live location with my family, So that I can feel more secure
or my favorite user story template :
In order to feel more secure during a ride,
I want to be able to share my live location with my family
In this example, you can notice that “Share my live location ” is a feature, but the user’s need is “to feel more secure during a ride “. So as an agile team, we are going to create a sense of calm for our users. There are other alternatives to satisfy this need too:
For example “Ride Check” feature, With this feature, Uber is constantly monitoring every ride; from when it starts to when it stops, the app is paying attention to what route the driver is taking, the ride’s speed, and how long these rides are stopped for. It’s designed to pick up on abnormalities, like if a ride’s stopped for too long.
From user story to Hypothesis story as a tool to run improvement experiments
The idea is so simple, Again start whit why like user stories? Let finish pushing fantasy and buzzwords to the team. Let the team know the need and engage them in it.
A sample Hypothesis story:
It will help the team to understand why we are going to try a new experiment and what is the success criteria and If that doesn’t help to reach our goal, we can throw it away and try something else.
Don’t fall in love with practices. If that doesn’t helped us to reach our goal, we can throw it away and try something else.
The objective is a kind of north-star or desired state for us. On the Hypothesis criteria side, there are two things: Current condition, and Next Target. The current condition is our current state against our objective, This should be fact and not just judgment. for example, today we have 40 bugs per week, and this is a fact.
The Next Target is a kind of milestone that shows a small win. We need small wins to create a continuous improvement culture. Maybe zero bug state is a far target, but 4 bugs per week, looks like a reasonable target based on our current condition.
Gruanility of Hypothesis Stories:
Just like a user story you can breakdown these Hypothesis stories into small but valuable stories too, it will help you to run small experiments in a short period of time.
Let the team engage in the emergence of practices
It’s important to let the team engage in process of emerging practices. Retrospectives are a great chance to facilitate this engagement. You can raise an issue for the team, for example, show bug reports as fact and creates scenes of urgency, so set it as north start and facilitate them to find the shortest path to our north start.
Hey guys, What practices can help us to reach our target faster?
There are different facilitation techniques. For example, I used Miro as a board, and let my team write their idea, and after that with dot voting, we selected our shortest path to our next target.
Based on my experience, If you start with why, and let them engage in the emergence and selecting practices, it will decrease the resistance level and at the same, it will create a safe-fail-environment for the team to test their selected practices.
Don’t hesitate to share your experiences with me here
This month, I helped a scrum team to transform their planning and collaboration way, the way of working of different skills together as a team. I want to tell their story here and how we solved one of their tough challenges.
Problem:
Waiting and delay problem. The frontend developer had to wait for several days to get an API from the backend developer and a High-fidelity prototype from the designer. After several days she could start his task and usually, in the implementation process, she found some problems, and it caused them to went back and forth between tasks. Finally, at the end of the sprint, there was no Done Increment, so sprint reviews were useless, with no feedback loop and …
Facilitate sprint retrospective to find the solution
At the sprint retrospective meeting, the team raised this issue as the main problem, and we tried to find solutions to this challenge.
Solution 1:
“Start backend and design tasks one sprint prior to the frontend task.” It was one of the proposed solutions. Consider, We want to create a login page, so let’s break it down to 3 tasks: 1- Design of login page 2- Implement the API of login 3- Implement frontend of login.
If we postponed 1 of the tasks to the next sprint, so we will not have a Done Increment at the end of the sprint.
Based on the Scrum Guide:
“Scrum employs an iterative, incremental approach to optimize predictability and to control risk.“
This solution terminates the main purpose of the scrum, optimize predictability, and control risk. Late review= Late feedback loop. This approach will increase the risk and the cost of the change.
Late feedback = High cost of change
Sarah: “We don’t have any other alternative, …”
In addition, this kind of solution shows a big underlying problem, Waterfall, and Silo mindset in Agile’s clothing. When team members don’t care about the working software and early feedback, you should find a way to help them be agile and not just do agile.
“If you want to teach people a new way of thinking, don’t bother trying to teach them. Instead, give them a tool, the use of which will lead to new ways of thinking.” Buckminster Fuller
Solution 2: Swarming of 3 Amigos
Swarming of 3 amigos was the practice we experimented it in the next sprints. Before starting any product backlog item, 3 amigos need to swarm together. Swarm to do what?
Swarming of 3 Amigos
1- Start with low-fidelity wireframes instead of high-fidelity wireframes or prototypes
Most designers used to sit at their ivory tower and designing a high-fidelity prototype with all details and handover it to developers for implementation. So other team members need to wait for several days to get the designer’s artifacts. It will create a delay and will increase the cost of change. In most cases, they don’t accept changes or feedbacks too, because they have fallen in love with their design.
Based on this article, “A wireframe is the first visual representation of a designer’s idea. It ensures that the developers and customers get a clear understanding of the functionalities and designs that the software needs to support. Don’t be fooled. Despite their minimalism, designers can find low-fidelity wireframes, inspiring. They are flexible tools that provide room for experimentation. When team members can visualize and agree upon the inclusion of features earlier in the development lifecycle, they spare their clients additional costs later on in development.
Low fidelity wireframes are just a quick sketch that can make ideas more tangible. Lоw fidelity wireframes are usually black and white schemes or simple sketches on paper or whiteboard focused on the “big picture” of the feature or page. UI elements are shown as boxes and lines without detailed annotations.”
Remember that, one of the agile values is “Individuals and interactions”, this swarming is not just about creating a wireframe, it’s about to let them interact together and break down the silo mindset. Talk together and create a shared understanding. We use the 3 amigos practice to facilitate a conversation. Shared understanding is more important than shared documents.
The designer can start to design a high-fidelity wireframe after swarming, and other guys don’t need to wait for him.
2- Make an agreement on API Contract
It’s time to make an agreement on API contract. Today most modern software is based on API and JSON. The first step is to talk and make an agreement about API contract and so create a mock API based on the agreement. The frontend developer can start to implement the frontend of the login page without waiting to finish of backend task.
Acceptance criteria of the user story and wireframe will make it easy to create a shared API contract.
You can open your favorite editor, and type your JSON. Or you can use the on-the-shelf tools. In the next step, You can use an API mock server to test and call your Mock APIs too.
MockAPI.io is one of the great tools that you use it easily create a mock API.
Or Mock.io is another great tool that you can create a different kind of Mock APIs (Mock API for microservices, Mock JSON API, Fake JSON API)
https://mocki.io
Swarming of 3 amigos is great practice, to create a shared understating between individuals with different skills and create an agreement to make sure everyone can start it without delay. This practice is not just helping people to start their tasks together, 3 amigos swarms together to decrease the feedback loop and reduce the change cost.
Please let me know what do you think about this practice 🙂
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 the conflict. Everything went as severely as possible. This meeting was like the first presidential debate in 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.
https://www.pinterest.com/pin/185280972158957444/
It’s a really easy framework to learn, and adopt it as your favourite 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:
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)
Ali is starting to check his phone (Selected Data by Vahid)
His attention is on his phone (Meaning)
He is not paying attention to me (assumption)
He did not care about the team (Conclusion)
He is a bad team member (Belief)
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 🙂
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…
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:
Imagine…
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
or
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.
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.
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 🙂
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:
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
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”
or
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.
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.
