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:
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?
Let’s have an example. Imagine the team’s mission is to reduce “Transaction Infraction” in a bank which is beyond a daily basis. The team has to reduce the number of financial violations. It is about doing a meaningful job. Now, team members have a great reason for celebrating… If I was one of them, I would have enjoyed it 🙂
5. Repeat and repeat and repeat
The repetition of the names and mission in different events is the secret of survival otherwise, they will soon be forgotten. In this situation, team leaders, managers, and product owners play an important role.
Next step is to show it in different places, for instance, on mug or badge of team members.
Is it over?
In fact, this is the beginning of a great change. We are always learning. When teams grow or some parts do things that are not in the same direction or there are dependencies on other teams, it could be a sign of birth (creating another new and small team).
For example, the Orka did not exist at the beginning. The Oxygen team had two large baskets, one to develop open banking platform, and second to provide information services to different groups and companies.
Due to team expansion, one of the baskets was broken down and a new team called “Orka” was created. In this new team, there are people from different groups (operations, data, etc.) to complete an end-to-end process. First, speed up service delivery, and secondly, reduce hand-over.
What is the next step?
The next step is to move on toward our meta — Cross-functional and self-organized teams. Teams with minimal hand-overs that can move toward their mission.
The basis of agile organizations is small teams, teams with a mission and a distinct identity. The task of the organization’s leaders is to define a mission for the teams, remove the obstacles they face, and help them achieve their goals.
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.