Agile

Voice of the Customer (VoC) is a method of researching the expectations and needs of users. Companies use it to understand customer needs for products and services. This process covers everything that users say and write about the business and helps bridge the gap between expectations and the actual experience of interacting with the company.

An organization “can hear many voices” (customer, business, employees, process), but it is the voice of the customer (VoC) that is the driving force regarding what should be important to the organization and what the organization should focus on. While satisfaction with VoC needs to be balanced with the voice of the business, process, and employee, it remains the dominant voice.

First, let’s define what a customer is. A customer can be defined as an individual, organization, or entity that is a direct recipient of the production (product or service) produced by your organization. Sometimes the term stakeholder is used as a type of customer, but in reality, they are rarely direct recipients (although they are “interested” in the well-being of your organization).

An external customer directly receives your production and is the main source of your income. An internal customer is a specific department or employee in your organization who will receive your work or the work of your department. Usually, they do not pay you for your work product or services.

Now that you understand the definition of a customer, what is the voice of the customer? The voice of the customer is a structured process of directly requesting and collecting specifically stated needs, desires, expectations, and customer experience regarding the products and/or services you have provided to them.

Customer needs can usually be classified as related to quality, cost, safety, service, and delivery, and today, more and more, with social responsibility. Meeting these needs should drive the organization. The challenge is how the organization collects and synthesizes all the voices, many of which may contradict each other.

There are several sources that the organization can use when collecting VoC, including:

Direct observations

Surveys

Interviews

Focus groups

Complaints

Customer support representatives

Sales department representatives

Information collected within the organization

Industry data

Until the organization and the customer together determine what is truly important, the organization may deliver products and services that do not provide the value the customer wants and needs.

Despite the fact that the first version of the Scrum Guide was formulated in 2010, ideas of such a flexible approach were applied long before this date. And like around anything “old” and “unclear,” various myths circulate around Scrum as well. Let’s list just some of them:

Sprint Review is just a Demo

You can only release at the end of the Sprint

Scrum Master is the technical leader of the team

The maximum size of a Scrum team is 7… or 9… or 10… people

There is no planning in Scrum

Working with Scrum will make your team work faster

The role of Scrum Master is a full-time position

Everyone must stand during the Daily Scrum

You have to choose between Scrum or Kanban

Working with Scrum automatically makes you “Agile”

Because Agile and Scrum are the same thing

You need to start the project with a Zero Sprint (Sprint Zero)

**How to Conduct Remote Retrospectives and Enjoy the Process**

Let’s face it: Agile was not created for distributed teams. Early Agile teams were mostly co-located, mainly because video conferencing, chat, and other technologies that make remote work possible were primitive and clumsy at that time. Nowadays, with so many people working remotely, gathering a team in one room is unrealistic. However, this doesn’t mean that remote retrospectives are impossible; they are just a bit different.

Moreover, regular retrospectives are particularly important for distributed teams. Without everyday chatter by the coffee machine and lunchtime conversations that typically happen in the office environment, problems affecting team productivity and morale might go unnoticed until they become severe. Retrospectives are a tried-and-tested way to address these issues.

**What is a Remote Retrospective?**

A remote retrospective is simply a remote variation of the classic Agile retrospective (or “sprint retrospective” in Scrum terminology). Using video conferencing, team members reflect on what is working well and what isn’t, and then, with this in mind, determine how they can improve the situation. It’s classic continuous improvement: duplicate successes and learn from failures.

Don’t forget about team cohesion. While retrospectives are not “team-building” per se, finding solutions to problems you face together and celebrating your victories does help team members bond.

**How to Conduct a Remote Retrospective with Your Team**

**Step 1: Create a Atmosphere of Psychological Safety**

For the retrospective to be worth the effort, the entire team must be involved. As challenging as it may seem, for example, due to time zone differences, it is essential to have everyone present because every voice deserves to be heard.

Ensure that everyone is comfortable sharing their opinions without fearing judgment or punishment. While the retrospective should be effective, the goal is not to point fingers but to figure out how the team can get better.

**Step 2: Set the Agenda**

Retrospectives rely on a sense of interconnectedness and collaboration among team members, but this is often lost in a distributed environment. To address this, use Zoom or a similar video conferencing tool, and make sure everyone has their cameras on. Remember that face-to-face communication is the most practical and effective way to exchange information both within and outside the team. We communicate more efficiently when we can see each other’s faces, and since retrospective discussions can sometimes become intense, maximum team engagement is needed.

Why not experiment with virtual backgrounds on Zoom? You can even choose a session theme: colors, places you want to visit, favorite movies, etc. If virtual backgrounds aren’t popular with your team, you can try other methods:

– Ask everyone to wear their favorite hat during the conversation.
– If you use a format involving individual brainstorming, take turns choosing music for background playback during that time.
– Open the retro with a short icebreaker. Even a mundane question like “What did you have for lunch today?” can elicit a smile and make team members feel more connected.
– People might turn off their microphones when not speaking to reduce background noise. Still, encourage (or require) everyone to turn on their cameras to maintain a high level of interaction and facilitate closer communication.

You will also need to record all the ideas you share. In the office, boards are usually used for this purpose, but in a virtual retrospective, you’ll need some digital equivalent. Miro, Jira or Confluence plugins, Trello, or Mural are good options.

As for the agenda, there are many retrospective variations, but the basic format is: what went well, what didn’t go well, and what changes we’ll make in our work. However, any format gets old after a while, so don’t forget to change it. Be inventive and surprise your team. And don’t forget to ask for feedback afterward. You could even have a retrospective of your retrospectives once a year!

**Task Estimation with Planning Poker**

If you dislike estimating tasks “by eye” and desire precise results, try playing Planning Poker.

Planning Poker is a task estimation technique for Agile teams. It is conducted using cards and resembles a poker game. The method was first described in an article by one of the authors of the Agile Manifesto, James Grenning.

In the Planning Poker estimation method, the entire team, led by the Scrum Master, participates—it’s a crucial condition. The Scrum Master distributes a deck of special cards to all participants. For remote teams, various online services can be suitable, while the estimation rules remain unchanged.

The Fibonacci Numbers are often used, which is a sequence of numbers starting with two ones, and each subsequent number is the sum of the two preceding ones: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.

The deck may include cards with the following values:

– ? — uncertain answer;
– ½ — simple task;
– ∞ — infinitely long task;
– coffee break or an image of a coffee cup — a break is needed;
– cards with sizes S, M, L, or any others as needed.

Team estimation helps achieve an objective result. For example, a developer might know better how much time their work actually takes but may exaggerate its complexity to hedge and get more time. Therefore, the estimation process is always monitored by the facilitator. The idea is to consider the opinions of all team members and make the most accurate predictions.

If, after the voting, all cards are close in values, the team has estimated the task approximately the same, and it can be concluded there.

But what to do when there are contrasting differences? For example, two developers assessed the task differently: the Junior chose a card with a nominal value of 4, while the Senior chose 10. Ask each to express their opinion and listen to their arguments. You and the rest of the team will understand why they think so. For instance, the Senior may have inflated the number to get more time, although they can work faster. The Junior may have underestimated the task’s complexity due to inexperience. Usually, reality lies somewhere in between. After discussion, repeat the vote, now based on the new information.

If everyone quickly agrees, and you get the desired result, move on to the next task. If not, continue voting until the result becomes unequivocal. Your goal is the arithmetic mean of all estimates proposed by the team.

The Team Competency Matrix is a straightforward tool for determining the set of skills within a team based on specific needs. We can use this matrix to assess whether all the skills required for a project are present or if the team is actively developing them.

In teams, it’s crucial for all members to share their skills with others. Relying solely on one team member possessing a particular skill can be risky.

Imagine a scenario where a team member has an accident; if they are the sole possessor of certain project-critical skills, it could be a genuine catastrophe for the company.

Working with the matrix starts with identifying the skills required for the project and the expectations for each of these skills.

Building this skills matrix is quite straightforward because it is simple and specific. This matrix provides a holistic view of the team’s skill set.

Kaizen, or 改善 (pronounced kai-zen), represents a Japanese philosophy and practice that centers on the continuous improvement of production processes, development, supporting business processes, management, and all aspects of life.

The concept of Shu-Ha-Ri comes from the Japanese martial art of Aikido.

Shu (守): The first stage, which means that one must memorize everything exactly as the teacher shows. It requires many years of training, or else there will be no foundation for moving on to the next stage.

Ha (破): The second stage, where the learner reflects on their actions, changes the rules, tries to break them, and builds a new system of their own rules. They also learn new techniques from other teachers. Many try to do this too early, overestimating their capabilities.

Ri (離): The third stage, according to which one needs to free oneself from rules—there are no more rules, only the natural course of things (Dao). “Ri” means to rise above everything that was learned before, to create higher and more general principles.

The Shu-Ha-Ri model can be adapted not only for martial arts but is also an ideal metaphor for Agile team development.

Shu: We strictly adhere to Agile rules. We see that all Agile meetings/ceremonies are conducted, and all rules are followed. For example, the Daily Stand-up does not exceed 15 minutes, and the whole team discusses progress in achieving iteration/sprint goals.

Ha: Now that everyone is familiar with the basic rules, we can begin to improve and make amendments to them. Referring to the example above, perhaps we will review our Daily Stand-ups and change their time, or we will go through each user story instead of listening to each person in turn. Practicing this approach, we can see what works and what doesn’t. Retrospectives will greatly assist us in this.

Ri: We have departed from the “standard” structure and mechanisms and have begun to set our own rules.