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.
-“How is it possible to better estimate sprint backlog issues?”
-“Why do you need a better estimation?”
-“You know, In the sprint planning meeting, the team fills the sprint with lots of issues, but in the middle or at the end of the sprint we have to remove lots of them from our sprint’s plan.”
-“With better estimations, Why do you think the same thing won’t happen again?”
All over the world, most software development teams are using Scrum. They have accepted it that software development is a complex thing. So something like waterfall not works in the complex domain, and you need a tool or method or practice to solve this complex problem.
Based on my experience, most of these teams are looking for a magical way to have an accurate plan for their sprints.
In this story, I would like to share my own experience with these teams and share Factful planning framework, a tool that helps you to have
better plannings and estimations.
Problem
The main problem is that we forgot the “Problem.” At the first level, we need to check some understood assumptions. Scrum (n): A framework within which people can address complex adaptive problems.
In theory, everybody has accepted that: First. Scrum is a framework, Second- A framework to address complex problems. However, in real-world, the people act with Scrum as a project management technique. The big problem with this idea is that they forget uncertainty.
In the complex domain, you need to accept uncertainty as a reality, and you can’t ignore it.
Is it possible to plan and estimate in this uncertain world? I suggest you “Factful planning framework.”
Determine the uncertainty level with uncertainty matrix
The first thing is that the uncertainty level of product backlog items is not the same. Any item has a different level. You can determine this level with uncertainty matrix.
Uncertainty matrix is a simple tool to help you to understand your backlog’s items uncertainty level. This matrix has two dimensions.
1- What: What we should do?
2- How: How we should do it?
Grab one of your product backlog items, and look at this issue, first think about “What” dimension. Answer the following question:
Do you(or your team) know what you should do for this issue?
1- Yes, We are sure about detail, and we need to do it
2- Yes, But we are not sure about the details.
3- No, details are unknown
After, “what” dimension, think about “How” aspect. Let’s answer this question:
Do you(or your team) know how to do it? 1- Yes, We are sure about to do it(We have already experience about it) 2- Yes, But we are not sure. 3- No, we need to test different things.
After that, you can choose uncertainty level for your backlog item, for example, 2–3, it means 2 in what dimension and 3 in How aspect.
Factful planning in the scrum events
Let’s think about this example; you have a high priority item with 3–3 uncertainty level. Because this item is a top priority, you select it as one of the current sprint backlog items in the sprint planning meeting, and you ask the team to estimate it.
How should the team estimate this unknown item with a high level of uncertainty? What is the value of estimation when it is wrong?
So, Uncertainty level will help you think about the main idea of Scrum again, “Address the complex problem.”
Factful sprint planning
The first idea is to do not select items with uncertainty level 3(What or How) to implement it in the current sprint. Try to choose items with uncertainty level of 1 or 2.
What about the third level of uncertainty?
Why should we not select them for current sprint? It’s impossible to estimate this kind of items. When you choose them as committed items to current sprint, our stakeholders will think, you need to finish them in this sprint, and this is part of your commitment.
Strategies for the third level of uncertainty
Answer this question: “What can we do in this sprint to create knowledge to decrease the uncertainty level of this item?”
With remembering the uncertainty, the team, instead of being committed to doing unknown issues, they will try to create knowledge and increase the certainty level.
Practices to increase certainty in “What” dimension:
1- Design Sprint
2- Talk with customer
3- Create MVF (Minimum valuable feature)
4- Take time to break down it and write acceptance criteria(like grooming meeting)
5- Functional Spikes
So, you are trying to increase the certainty level in what dimension. I met some teams that they don’t have any communication with their customers.
In some cases, just small talk with a customer can decrease the uncertainty level. Sometimes you need to create a prototype or some methods like design sprint. Sometimes you don’t have time to break down product backlog’s items or write acceptance criteria for them? Maybe you need grooming or refinement meetings.
Spike
Based on Agile Dictionary definition, Spike is a task aimed at answering a question or gathering information, rather than at producing a shippable product.
Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.
Functional Spike, This kind of spikes trying to answer a question in the functional aspect. Ex. “Do we need this button here or not?”. A functional spike can be something like that “Prototyping of asset management console.”
Practices to increase certainty in “How” dimension:
1- Technical Spike
Like functional Spike, This is a very simple program to explore potential solutions. For example, “Which library is good for SNMP scanning.”
This kind of spikes will help us to explore solutions and decrease uncertainty.
“What” vs. “How”
If you have an item with uncertainty level 3–3, What is your priority? Based on my experience, you need to start with “What,” Because “How” really depends on the requirement, and we need to determine our technology based on our requirements.
What about change?
Don’t make wrong; we can’t ignore the change. Uncertainty level can be changed over-time based our knowledge about business and technology. This practice is a simple tool to remind you about reality, “Uncertainty.” Instead of taking lots of time for an accurate plan or estimate, work hard to create knowledge at the right time.
Factful sprint review
One of the other practices of Factful planning is “Demo for.” Like the uncertainty level, you need to add a new property to your backlog’s items, “Demo for.” You need to determine at the end or during the sprint, Who should see the result of this item? Who should provide feedback to us?
In some cases and in real-world, items with uncertainty level 1–1, don’t need any specific feedback from the customer, and this can be accepted or rejected it by our product owner. But other items with higher uncertainty level needs real customer feedback.
You can not write a general thing as a demo for, like “somebody from marketing.” If you are building a feature for the internal inventory system, you need to write something like that “John, head of inventory and Sara inventory software user.”
Why “Demo for” practices?
1- sometimes, we have different items for different segments. With this practice, we know that we should get feedback from the right person.
2- Don’t waste your time to get feedback for some 1–1 item. (They will make our review meeting so dull)
3- You can send an invitation letter to them, to join you and make themselves available for you. They have time for preparation and set the meeting on their calendar.
4- You will not forget to get feedback.
Why do I call these practices Factful planning?
We need to learn to separate fact from fiction when forming our opinions. The organization can be both bad and better. Progress comes bit by bit, But without facts, our minds are occupied by feelings. This practice is part of my factful agility toolbox.
Asad Safari
About the Author:
Asad Safari is an Enterprise Lean/Agile Coach. He has worked as an Agile coach for more than 7 years with several enterprises and startups. He has more than 14 years experience in the IT industry as a Software Developer, Tester, and finally an agile practitioner. You can follow Asad on Twitter and LinkedIn.
I’m an Enterprise Agile coach in a big company with more than 30 software development teams. In recent days, one of the scrum masters told me, “I’ve read some articles about SAFe 4.6, and it seems a cool agile framework. I think we need to use SAFe in our company and …”.
I asked him, “Wow looks great, and think about this idea, What’s the #1 struggle we have in our company that we want to solve it with SAFe 4.6?”
“Hmm, You know, we have collaboration problem. There are lots of dependencies between departments and it makes everything slow and … The SAFe has a PI planning meeting and lots of roles and we can resolve our dependencies and create better alignment.”
“ People don’t want quarter inch drills. They want quarter inch holes”
Based on my observation and experience, Most of the companies try to use SAFe to create better alignment, collaboration and resolve dependencies.
People Don’t want SAFe, They want keep all teams align and deliver value faster
This story is not about that SAFe is a bad or good tool, SAFe has lots of good things but for our job, I think it’s a heavy and wrong solution. We can create better alignment with less cost and in a more effective way.
Why it’s heavy?
There are lots of roles, ceremonies, layers, artifacts and…. Many Agile practitioners think that SAFe is not Agile.
Dave Snowden: “SAFe is to Agile as Six Sigma is to Innovation and Sharepoint is to Knowledge Management A refusal to realise that the world is complex and an attempt to impose inauthentic order to development.”
Or based on Ron Jeffries, “If everyone in the organization were to read the fine print in SAFe, then the organization might very slowly evolve to the level of effectiveness that real Agile provides. That’s not going to happen. Managers and executives are too busy to read the fine print. They are too busy doing their job to study how to do their job. They will too easily fall into old patterns of management behavior, and when they do, SAFe will be installed in a fashion that won’t just fail to support Agile, but that will suppress it.”
Why SAFe is the wrong solution for creating alignment?
In SAFe there’s an event called: PI planning. It’s a kind of secret sauce for SAFe to create alignment and resolves dependencies. The following image is a result of a good PI planning. (They call it program board which created after 2 days PI planning meeting)
I think this image is a terrible thing. Most of the SAFe consultants say, “It will solve your dependencies…”. Visualizing dependencies is a great thing, but you need to resolve it. Some of the dependencies, will not be resolved by just talking in a PI planning meeting. “We will do it for you on sprint 2…”.
The best question or action in this state is “Why we have these dependencies?”. I got the following things as the root cause in our company:
For resolving dependencies, just talking about them in the PI planning is not a good solution. You need to change the structure of the organization, create real cross-functional teams based on small business domains.
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 Symbolsfor 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 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.
