Continuous improvement activities and how to carry them out remotely

Training activities are very precious to stay updated with technological innovations, train hard skills, improve processes, and create contamination and cohesion among different teams.

For this reason, at Mia‑Platform we have a dense continuous training calendar that involves the different roles.

Continuous improvement is a concept that comes from afar: from the Japanese Kaizen. Kaizen comes from KAI (change, improvement) and ZEN (good, better) and is the commitment to always make small changes and improvements that can benefit every employee throughout your organization. Small continuous changes can lead to profound innovation and tangible benefits for all.

Furthermore, the theme of continuous improvement is part of the Agile methodology, which is based precisely on continuous adaptation and continuous improvement both individually and by the team.

Continuous improvement activities arise from the specific needs of an organization. What we have identified for us are learning, comparing, aligning, sharing, and growing.

Therefore, we started by involving some of the roles in our company: Product Owners, Scrum Masters, and Developers. Thus, we structured a calendar of meetings.

In this article, we want to share our activities so they can be an inspiration to other companies that want to add these moments into their routine. In this particular historical circumstance, the continuous improvement activities have been adapted to the remote mode. Besides being a way to improve their skills, continuous improvement activities can be enriched in their importance as a moment of cohesion despite the distance.

In order to write this article, we interviewed some of the people who take care of the activities of continuous improvement at Mia‑Platform: Livia Rossetto, People & Culture; Federico Oldrini, Tech Leader; Antonio La Salandra, Scrum Master; Francesca Carta, Product Owner.

For developers

Mob Programming

All the brilliant people working on the same thing,
at the same time, in the same place,
and on the same computer.

Woody Zuill

Mob programming is a development approach where all the teammates collaboratively work to deliver a high quality product, by using one tool at the same time. 

Mob programming is one of the activities that Mia‑Platform developers do to make continuous improvement.

The following activities are organized at team level: responsibility for the organization and supervision of the contents are entrusted to the team’s Tech Leader, who is a more senior figure. However, the individual meetings are guided in turn by the different team members, who thus could offer contents and experiment how to manage a group moment.

There is no fixed schedule. The only rule is that it is a technical training event.

Usually, in a Mob Programming, you can:

• Make a review about something previously developed;
• Improve a piece of code that has already been written;
• Study something new;
• Solve a problem together.

Rarely, it can happen to carry out more didactic/theoretical mob programming sessions; however, some practical aspects are usually preferred.

Mob programming can also be conducted cross‑team. Knowledge exchange can be enriched by the different experiences that the different teams face on the various projects. A single mob programming can be organized for two teams, or one team can join another’s mob programming and make its contribution there.

How do you remotely manage continuous improvement activities for developers?

Carrying on the remote continuous improvement activities is certainly a challenge to face. But it is also a great opportunity to keep up to date with the team, keep in touch, and further improve your skills. 

Face‑to‑face communication simplifies mob programming. But if you want to experience it remotely, then it will be important to pay more attention to the following aspects:

• Event timetable: it is always better not to put this event at the end of the day or at the end of the week. Collaboration and involvement of everybody are important with maximum attention. Participating in a mob programming session can give stimulus for our work that can be immediately put into practice even on the same day.
• Contents: it is fundamental to carefully choose the contents and be prepared. In addition, it is important to choose content that is relevant to everyone even remotely, which is not too complex to be followed, and on which the moderator is well prepared to avoid wasting time.

Kata

A Kata is a programming activity that helps sharpen skills through practice and repetition. 

The term was first introduced into literature by Dave Thoms in the book “The Pragmatic Programmer” and it refers to the concept of kata in martial arts. 

Katas are one of the activities of the continuous improvement program at Mia‑Platform. It is an activity that is often done in pair programming sessions. It has been hard to run it remotely! But once the formula was found, it was efficient and stimulating despite the new participation method.

How to remotely run a Kata

In this case, we chose a topic that could be run without the pair programming. And it helped run the Kata remotely. 

The chosen topic was refactoring. In a nutshell: the decoration of the code without changing its functionality, in other words, understandable, maintainable, etc..

This kata was inspired by a talk by Martin Fowler, one of the top refactoring experts, and it was organized by providing everyone with a piece of code that needed improvement according to known technique and following your own intuition. 

Therefore, no preliminary instructions were provided about the possible evolutions that the code would have had. 

The kata followed two phases:

• Phase one: everyone could freely refactor, with the only limitations of using one of the four previously chosen languages – javascript, java, kotlin, python. Each teammate wrote down the chosen refactoring actions on Miro. Behind the scene, Luca Marzi, coordinator of this kata, took care of organizing the various activities in groups of topics to prepare the discussion that followed later.

Once the refactoring time was over, the participants discussed their choices. From this phase, a glossary emerged and now it can be generally adopted for the merge request or for the mob programming sessions.

• Phase two: the second phase was harder. The refactoring gains more value when the code must evolve and, therefore. The group faced some evolutive features. Each teammate was able to evaluate the quality of their own refactoring based on the evolutionary requests and discussed them with others. Then, everyone uploaded their version on GitLab. 

The tools used for the kata were: 

• Miro: to record the refactoring activities, organize ideas, and facilitate the discussion;
• Google Meet: to virtually meet;
• Google Chat: to share comments without disturbing the group call. 

For Scrum Masters

Scrum Masters meet for continuous improvement activities as well: two meetings per month and each of them lasts one hour.

Scrum Masters usually meet the following week of the individual team retrospective to discuss what emerged from the meetings, evaluate the most relevant points, and find solutions to any problems that arose.

This also becomes an opportunity to discuss how the retrospective itself is managed: a retrospective of the retrospectives.

Moreover, regarding the continuous improvement of Scrum Masters, the individual meetings are focused on a specific theme, namely one of the moments of the Scrum: sprint opening, standup, backlog refinement, etc.

For each meeting, there is a different owner who is responsible for making a theoretical study on the topic and bringing points of attention that can start the discussion. Then, the practical plan of how certain moments are managed within each team is combined with the theoretical study.

The output sought is not to define the same guidelines for all teams. But to be all aligned on a theoretical level to better manage different needs that may emerge in each team. Each team, which varies in number, type of project, and skills, may have different needs that deserve flexibility which, however, must be accompanied by solid theoretical knowledge.

How do you remotely manage the continuous improvement activities for the Scrum Masters?

At Mia‑Platform, to be honest, we were in the process of starting these series of meetings just when the quarantine began. We have decided to start the continuous improvement activity even remotely, with the support of the tools we have available.

Shared files, e.g. Google Sheet, are proving to be valuable allies for managing meetings, together with video communication tools such as Hangouts.

For Product Owners

Even Product Owners periodically meet for continuous improvement activities. Let’s see how it works for them.

Mia‑Platform Product Owners meet once a month for a moment of horizontal training. As we have seen for the others, for each meeting there is a moderator who, by turn, gets ready with some material to share and gives ideas for a moment of discussion and debate.

Some of the topics that are addressed during these meetings are: improving the writing of user stories, how to make meetings more effective, new models and management frameworks, and much more.

One of the last meetings, which was managed remotely, was about writing user stories. The owner of the meeting shared a short presentation for the team, which was followed by a moment of discussion about how to write user stories, what would be the best method to adopt and how this can be declined to team and project needs.

How do you remotely manage the continuous improvement activities for the PO?

In this period, we are experimenting with new ways of managing our training activities.

There are some very important points of attention that emerged from the meeting among our Product Owners. And they are as follow:

• The length of the meeting can be reduced to get to the point as soon as possible, where everyone is involved and can participate;
• Write the feedback on a shared document: this makes it easier to follow the discussion and make your own contribution. 

POs and Tech Leaders: efficient meetings for the continuous improvement activities of the product

A final short chapter needs to be dedicated not only to the continuous improvement of people and teams but also to the activity of continuous improvement of the product.

This activity is very structured, more than the others because it is more recurring and shorter.

The Tech Leaders of all the teams meet the Product Owner and the Tech Leaders of the R&D team once a week. During the week before the meeting, the Tech Leaders collect feedback, requests, and points to consider. The meeting lasts 30 minutes and each Tech Leader has a moment to present. The R&D team concludes with an update on product advancements.

It becomes of fundamental importance, for this meeting, that everyone arrives well prepared so that everyone has the necessary time to express themselves and to go out with outputs.

In a remote work context, it may be even more useful to share the material before the meeting and carry out the meeting with the video on. The latter aspect, if there are not too many to participate, can greatly facilitate communication and involvement.

In conclusion, the activities of continuous improvement, if actually carried out with a structure and periodically, allow you to make those small changes that in the long run bring great innovation both to the product and to the corporate culture – as a workplace environment and effective processes.

We are aware that a face‑to‑face modality facilitates any training moment. At the same time, finding the right balance to remotely carry out some activities can bring many benefits both for individual training and team cohesion.

Our suggestion is to try to experiment with a calendar of continuous training – starting from small groups – and then expand your training activities offer.