Repairing broken teams. The story below shows that “the harder the team works, the more money the company will lose.” Assembly line once visited an of a company. He asked to return all the excessive work-in-progress parts to the previous process. The excess resulted in a mountain of pressed metal sheets returned to the press shop. These were the people who were producing more output than anyone else on the assembly line. It increased storage and maintenance costs. And it resulted in more costs for the hard work. Taiichi Ohno assembly line Broken Teams What is the job of a goalkeeper in football? Most people would say it is to prevent the opposite team from scoring. The real job of the goalie, as of every other player on the field, is to win the game. — Jeff Weiner An organization has yearly goals. These goals are assigned/picked by teams. The effectiveness in reaching the goal defines the success of the team. Business is successful if teams are successful in finishing their goals. Broken teams have a group of individually smart people failing in a group setting. Failing here means teams are failing to reach the goal. Diagnosis-driven prescription The first step is to understand the problem. We would have experienced people applying different solutions without understanding the problem. I have once seen a product manager suggest to me to double the capacity of quality analysts on the team, as there were complaints about the quality of the product. I refrained from doing that and eventually found that the problem was with the division of responsibility. A doctor does not prescribe different medicines to find or cure a disease. He/She checks the symptoms and diagnoses the condition. With successful detection, it becomes straightforward to prescribe the treatment. Diagnosis example Figure 1: Team is struggling to improve velocity Figure 1 shows a group trying to increase the pace to finish the goal. Without diagnosing the problem, the team adds more people to increase the productivity. Adding people slows the team. Figure 2: Zooming out the problem On further analysis by zooming out the problem, the team is trying to move against gravity. Therefore, adding more people is slowing them. Figure 3: Orienting the problem On further analysis, it shows alternate ways to increase the velocity. If the team follows the path as illustrated in figure 3, it allows the team to avoid upstream. It shows the importance of diagnosing the problem before solving it. How to diagnose? “If you don’t know where you are going, any road will get you there.” — Lewis Carroll Diagnosis: teams Does the team understand the goal and have an agreed-on approach to achieving it? What is stopping the team from achieving the expected results? One approach to understanding this is through . A good coordinator creates a safe zone for discussion and follows up on agreed actions. retrospectives Diagnosis: individuals What is stopping the individual from contributing well to the team? A good solution to this is give-and-take feedback. We run an activity called Do people recognize their responsibility to achieve the result? feedback dating. Feedback dating In feedback dating, each member of the team, meets every other member for 10 minutes and keeps on moving. In each encounter, the person gives feedback for 5 minutes and receives feedback for 5 minutes. Each person will keep notes of the comments. After meeting everyone on the team, the person takes time to reflect on the notes. It gives a good platform to recognize and share individual blockers and enablers. Diagnosis shows the cause of symptoms — the problem. ― Albert Einstein “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” The 5 minutes is exciting. Repair size and approach Eisenhower “I have two kinds of problems: the urgent and the important. The urgent are not important, and the important are never urgent.” — Repair size is categorizing the ineffectiveness in delivering the results. We are categorizing based on t-shirt sizes. The larger the size, lesser the efficiency. Repair size and approaches The team delivers on time. Sometimes, the team observes little hiccups. These are small problems which exist in groups. The team is resilient enough to recover from it. An example can be a key person in the team on medical leave for a couple of weeks which is affecting delivery. In construction analogy, this is like having a dirty floor, cleaned over time. XS (extra small): Resilience: Any building would require general maintenance. XS problems are common in teams. It is better to allow these issues to self-heal. If a particular issue is repeating, then it is better to size it as S. Repeating problems are like a room getting dirty frequently. The typical approach is to keep cleaning it. It is worth to find the source and eliminate that. The team misses a few deliveries. The team manages by putting some extra effort. An example can be a person leaving the team, which increases the load for the team. S problems require extra effort to solve them. They may be repeating XS problems. S (small): Repair: It is sometimes better to replace a leaking tap than to keep mending it. S problems are also common in teams. It is better to call out these issues and agree on action plans. Feedback dating and retrospectives are good platforms to learn the issues. The team has consistent delays in delivery. An example can be many over-promised features. The team struggles to finish the business commitments. M (medium): Restore: The default approach I have seen in a few teams is to add more people. We cannot patch a dam when it is getting flooded. One approach is to stop more water from coming, and another is to fork the source of water towards another direction. It gives us time to restore the dam. Adding more people to a stretched team will add more chaos. It is better to understand the core reason. Perhaps a fresh pair of eyes can bring better insights. Watch out for the different sources of trouble and turn one knob at a time. One option is to redirect new independent tasks to another team or form another team to address part of the issue. The team has significant problems with delivery. The group puts effort but does not deliver. It goes forward and backward. L (large): Renovate: We do not go and repair a fragile building. We renovate it. It is better not to fix multiple problems on a weak team. Fixing one produces another. It is costly too. It is better to give external support to the team and make it secure and apply changes after that. The job never gets done. XL (extra-large): Rebuild: When the foundations are weak, it is easier to reconstruct the structure. The state of the building is too fragile to repair it. XL problems have broken foundations. It is better to rebuild the whole team. Look for alternatives Avoid applying the first solution. Look for additional options. Avoiding the first solution is hard. With the first solution, we tend to fit the problem into the solution that we have experienced in the past. Bamboo boat We were traveling on a bamboo boat as shown in the picture above. It got stuck to one of the sunken trees. We started swaying harder to see if the pressure would loosen the block. One of the people stopped us and tried to find the exact place where the boat got stuck. Once he discovered that place, he asked all of us to walk to the other side of the boat, one after the other. As shown in the figure below, the weight lifted the boat on the other side. It released the jam, and the boat started moving freely. If we had put pressure, it would have cut the rope connecting the bamboos. Hold on to an solution before further analysis “Freedom from the desire for an answer is essential to the understanding of a problem.” — Jiddu Krishnamurti Case study I joined a team of 14 people as a manager. I spent one month building trust, understanding history, knowing people and their styles, and noting my observations. The team had delays in deliveries — repair size was M. Once I was comfortable, I requested for a retrospective. The team was safe to call out the problems, and they matched my notes. Two issues stood out —unclear scope and longer meetings. As this was M repair size, the approach was to restore. I nominated myself as the scope cop. We agreed on our bandwidth and the scope that we could handle every . If any important task came in between, it could only be swapped with a current task of equivalent size. It took two months to restore. 1. Unclear scope: sprint I started with . They lasted more than 90 minutes on average. My target was to get them to less than 10 minutes. We experimented a lot. We were consciously calling out for more suggestions, even when we found a solution. I am sharing few that worked well for us. We were a distributed team, and it took first 20 minutes to set up the meetings. I started arriving 10 minutes early to have everything ready before the rest of the team got to the conference room. It saved us 20 minutes every day. The next 10 minutes was general warm-up small-talk — we talked about traffic, the weather, etc. I did not ask to cut down these conversations, but I did start the meeting by giving the team my updates, and the rest of the team presented theirs. We called out repeated discussions, which saved few minutes. It took us three months restore this habit. 2. Longer meetings: stand-ups “There are three solutions to every problem: accept it, change it or leave it. If you can’t accept it, change it. If you can’t change it, leave it.” — Unknown Summary In summary, whenever you see teams with inaccurate deliveries, it is a broken team. It is essential to diagnose the reason and understand the problem. Look the problem with the perspective of organization, team, and individual. Categorize the problem and determine the repair size. Choose the approach based on the repair size. Avoid applying the first solution. Learn the problem more and keep looking for alternative solutions. Experiment and turn one knob at a time. Get your flight back to normal. Also published in . linkedin

Assembly

ATLASSIAN

Target

Velocity

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Renovating Teams

Too Long; Didn't Read

People Mentioned

Companies Mentioned

Ranganathan Balashanmugam

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Renovating Teams

Too Long; Didn't Read

People Mentioned

Companies Mentioned

Ranganathan Balashanmugam

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES