Team Improvement Techniques

In the last couple of months since Ireland announced the lockdown, our team has been performing at a high pace and have become self-organised to a large extent. As a team lead, this has allowed me the privilege of stepping back to look at the broader picture of how our team works individually and, more importantly, together. Through some exercises, I have identified some methods to gather improvement ideas that can be applied to any team.

Anyone who has been a part of a high functioning team understands that continuous improvement is not optional. In order to perform better and to keep performing, the team must identify their weaknesses and plan to strengthen or mitigate those weaknesses. These improvements remedy stress points in the team, technical debt, repetitive tasks and so forth. The mindset of continuous growth is one that must be worked on and nurtured over time. Your team is not a fine wine - it will not improve if left alone in the corner. It will go sour.

It is one thing to be told to improve something. But very often, being told to improve something does not necessarily benefit you or your team. For example, if my manager comes to me and tells me my communication is poor and he wants bi-weekly emails from now on from my team's status, all he has done is improve one of his problems, not mine. Improvements must come from within the team, and they must be gathered and executed on regularly. So the question is - how do we gather improvements that are worthwhile and specific enough to solve our problems, not someone else's?

80/20 Analysis

The Pareto Principle, most commonly known as the 80/20 rule, states that about 80% of the effects come from 20% of the causes. In layman's terms, most of the good things your team is known for doing likely comes from a small subset of your total work.

In my case, my team is known for our expertise in the upgrading of our product. How much of our work is related to this each week? I'd estimate less than 10%.

S_ide note_: This wasn't always the case. When we first formed as a team, we spent about 90% of our time on this work.

Over time our mindset of continuous improvement led us to automating away most of our problems. Here is how you can utilize the 80/20 rule to find pressure points to improve. I do this regularly by myself, and occasionally with my team.

Create a chart.

Drawing on a piece of paper or whiteboard produces far more ideas than typing on a screen. So create a chart!

What is going poorly?

Always start with the bad. What makes you stressed on a Monday? Why does your team constantly get called for customer escalations on a Sunday? What makes you cry at night? (If you're crying at night you really need this).

Copy the following table onto a piece of paper and fill it out now with any ideas you have.

20% Activity	80% Pain	Action to Remedy
Monday morning team presentation to management.	Stressful if I'm not prepped.	Give a practice run to my team on Friday.

What is going well?

This is less effective than analyzing what is poor in the team. You should prioritise fixing the bad over improving the good. There is no point in improving what your team is already good at if there are still issues that stress them.

Ask yourself - what are your team doing well? What do you need to keep doing well? What would happen if you improved these items?

Again, copy the following table onto a piece of paper and fill it out.

20% Activity	80% Reward	Improvement reward	Action to improve
Quick bug turnaround.	No weekend work.	Become the team with the lowest bug turnaround time.	Make incoming bugs a priority over stories.

You see the action columns? Take those, discuss with the team whether they agree on the actions required, and put them clearly for all to see everyday. You could create a task in your backlog that gets seen everyday on your sprint board, or print them and place them in your team's area.

Preventative Actions

Identifying Preventative Actions is something that I have recently come across. Each team in my project go through this process every 3 weeks (every sprint). Here's how it works.

A high priority bug has come into your team. You have spent all weekend pouring over it with your team, and finally came up with a solution late Sunday night, allowing your customer to continue their business as usual. Before you close the bug, there are a couple of things you need to consider and you must get answers to them. Otherwise, there will be another weekend in the future that will interrupt your team.

Why did this bug occur?

• We received a bad requirement specification from our business analysts.
• We missed a corner case in our testware.
• There were too many manual steps in the documentation which led to human error.
• We missed a critical part of our study when planning the requirement.

What correction did you apply?

• We built a patch fix and sent it to the customer.
• We clarified with the customer that the particular use case reported is not supported yet.

How will you prevent this type of issue from occurring in the future?

• We will call a 1 hour meeting with our business analyst each week to plan and clarify the feature request.
• We will build a new pipeline that will test our customer's use case each night.
• We will automate steps x,y and z in our documentation so that human error is reduced.

In my team's case, for each bug we have the following grid which we fill out.

Root Cause	Correction Applied	Preventative Action
A test case to click on the 'About' page in Firefox was missing from our GUI test suite.	Added this test case to the GUI suite.	Review GUI test cases as part of a feature sign-off in the future.

Retrospective

If your team uses the scrum framework for their work, then you will be very familiar with the retrospective. However, you do not need to work in a scrum environment to have a team retrospective.

Team retrospectives, if taken regularly, can be a valuable tool in the team's work week and is an opportunity for the team to come together and discuss the good and bad things that have happened in the past few weeks.

A retro should be scheduled on a regular basis, and you as the team lead must lead the meeting. Make sure that everyone from the team is present for the retro, and ensure that everyone is taking part and answering the questions.

What was good that you need to keep doing?

• We closed out 100% of our stories for the sprint.
• There was good communication with our management.
• We trialed pair programming this sprint - we have seen excellent results and should continue to do this.

What was bad?

• We had poor communication within the team.
  • Improvement: We will trial pair programming for a sprint.
• The QA team raised tickets with very little detail resulting in a few days of delay in closing.
  • Improvement: Create a template that you would find helpful and send it to the QA team lead. Request that they copy this template and fill it out for all future tickets.
• We allowed untested code into the production software.
  • Improvement: Revise the +2 code review criteria with the team.

The most important part of the retro is to make sure that improvements or solutions are attached to each 'bad' item that is discussed.
At the end of the retro, prioritise the top one or two improvements, and take note of them for the upcoming sprint to execute.

Improvement Backlog

To become a top performing team, each individual must be comfortable with raising and discussing improvements as part of the team's responsibilities. A team that does not have improvement ideas is a team that is not interested in improving which will lead to stagnation and a low performing team.

An improvement backlog is a list of ideas maintained and prioritised by the team. The list can be physical, like stickies on a whiteboard, or digital, like part of your jira backlog.

For example, my team created a Jira sprint and named it 'Improvement Ideas'. We have list about 50 improvement ideas, most of which are one-liners and some of which have been discussed with details and acceptance criteria attached.

Each sprint planning, we prioritise this list and take the items we feel are most valuable to us. We have a couple of ad-hoc rules for this backlog.

• Any ideas that come up in meetings are inserted as a 'one-liners' in this backlog.
• The list is regularly prioritised each sprint.
• Each idea is explained by the team member who originally raised it.
• We take 10-20% of our sprint capacity for improvements.

Keeping this backlog up to date and prioritised will ensure that your team has consistent tasks to work on that primarily help the team.

Stakeholder Feedback

Working in a team can often be like working in a bubble. It is tempting to fall into confirmation bias. The most valuable improvements you can get for your product will come from your customers and stakeholders.

Leading the team does not only include leading the people on the team. If your team are known for building the wrong thing, or if their customers are not satisfied with their part of the product, then you as the team lead have ultimately failed.

When it comes to feedback, there is nothing more valuable than your own customers' feedback. Your customers drive your product backlog. If you are in a large company, you may not have direct contact with your customers. In big companies, customers are often separated by layers of business analysts and management. This is not ideal, but it is something you can work around.

All you need is a small list of stakeholders that consistently use your product area to gain feedback from them. Talk to your managers about the customer interface and who could give feedback. In my case, we were 6 months without any contact with stakeholders that could give us valuable feedback. Eventually we were able to make friends with two guys who act as an interface to one of our company's top customers. To get those contacts, we needed to follow the breadcrumbs, bypassing the Product Owner and manager.

This stakeholder's feedback shed light on areas for improvement that we had not even considered before. Furthermore, they were able to give valuable feedback for improvement ideas we had in our backlog and help us prioritise.

It should be possible to get at least one or two stakeholders as a personal contact. Setup regular meetings with them and take note of their feedback, in particular their problems and stresses.

Feed this feedback into your improvement backlog and make them a high priority to implement as soon as possible.

Conclusion

The above techniques have helped my team and I gather valuable feedback and improvement ideas from both internal and external stakeholders. In using these techniques effectively, your team will improve dramatically and increase their performance.

Remember, it is not enough for your team to do the work they are asked to do. It is not enough to wait to be told what needs to improve. A high performing team must churn ideas continuously and critique themselves. Improvement ideas must come from every part of the team, since every part of the team has a role to play.

In a future post, we will explore how to get individuals of a team involved in forming ideas. For now, take a workshop, brainstorm on a whiteboard and keep executing.