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.
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 🙂
“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”.
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 🙂
Regards
Asad
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.
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.
