Agility

Real Agile transformation case study, with Agile Fluency Model

Last updated on: Published by: Asad Safari 0

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.

(source)

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

Why the Delivering zone selected?

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

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

Second step: Conduct the Diagnostic

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

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

Third step: Exploit the opportunity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. How many bugs did you record today? 

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

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

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

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

What was a significant result?

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

1) Make adding features easy

2) Led to customer satisfaction 

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

Reported bug chart

Tangible results over five months for business:

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

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

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

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

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

What is the future of Omid?

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

Be agile and good luck

Asad Safari

Agility

5 Steps to Create an Agile Structure

Last updated on: Published by: Asad Safari 2

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.

Summary

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.

Agility

5 Steps to avoid Imposter syndrome for Agile Coaches

Last updated on: Published by: Asad Safari 4

“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 phenomenon, impostorism, fraud 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

Context:

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.

Hypotheses:

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

Goal:

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.

Metrics:

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 🙂