One of the indicators of complexity in a project is the number of potential communication channels. It is considered that there is a significant number of potential communication paths between team members and stakeholders, which grow exponentially with the increase …
Do you know what Poka-Yoke is? It is one of the most effective methods of work standardization that can be used in any organization.
Lean Management adopted various principles and methods that originated as part of the Lean Manufacturing methodology, and Poka-Yoke became one of the most effective methods of work standardization, applicable in any sphere of production or services.
The idea used in this method, the prevention of errors and defects, is very versatile and has proven its effectiveness.
Meaning and Origin of Poka-Yoke
The term Poka-Yoke (ポカヨケ, poh-kah yoh-keh) was coined in Japan in the 1960s by Toyota industrial engineer Shigeo Shingo. Shingo also developed and formalized Zero Quality Control, a combination of Poka-Yoke methods to rectify potential defects and check the source to prevent defects.
Initially, the term was pronounced as “baka-yoke,” meaning “protection against foolishness,” but it was later changed due to offensive connotations. Poka-Yoke now means “error-proofing” or, more literally, the prevention (yokeru) of unintended errors (poka).
Poka-Yoke ensures that the correct conditions exist before performing a step in any process, primarily preventing the occurrence of defects. Where this is not possible, Poka-Yoke serves a detective function, eliminating defects at the earliest stage of the process.
Poka-Yoke is any mechanism in a lean production process that helps avoid mistakes. Its goal is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.
Examples of Poka-Yoke Application
In a broader sense, this is also a constraint defining behavior, like a step in a process that prevents incorrect work.
One of the most common examples is a driver of a manual transmission car having to press the clutch pedal (a process step – Poka-Yoke) before starting the engine. The interlock prevents unintended movement of the car.
Another example is an automatic transmission car with a selector that requires the car to be in “Park” or “Neutral” before starting.
They act as constraints defining behavior because there are actions that must be performed before the car is allowed to move. Over time, the driver’s behavior adapts to the requirements through repetition and habit.
Other examples can be found in childproof electrical outlets or a washing machine that won’t start unless the door is properly closed to prevent water leakage. These types of automations do not allow errors or incorrect operation from the very beginning.
In Summary
The Poka-Yoke technique is one of the most valuable gems in the crown of Lean Management. It is a way to ensure quality without the actual quality assurance process, primarily aimed at preventing defects.
Poka-Yoke can be implemented in any industry and has numerous advantages, the most important of which are:
– Helps get it right the first time
– Over time, makes errors impossible
– It is cost-effective
Errors are normal; just don’t repeat the same mistake again and again. To avoid repeating the same mistakes, specific checks or procedures need to be implemented, and that’s where Poka-Yoke techniques come in.
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)
The Six Sigma method enhances the efficiency of project processes and elevates product quality by reducing defects and various risks.
The term “6 sigma” signifies virtually defect-free production. By controlling the production process, one can identify areas that need improvement even before defects arise.
This method emerged in the 1980s when Motorola specialists developed and applied it in their operations. Soon, Six Sigma became effectively utilized by other companies.
**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!
A bureaucrat, considering himself overloaded, hires two subordinates to do his job. He can’t share it with his already working colleagues, nor can he hire one subordinate and share it with him – no one needs competitors. The story repeats as his employees hire employees for themselves. Now seven people are doing the work of one. Everyone is very busy, but neither the work speed nor its quality increases.
**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.