Direkt zum Hauptbereich

First time right is teamwork at it’s best

“First time right” is one of those principles so simple, yet powerful, that once you’ve heard it, it’s hard to imagine an alternative. Would we ever have reason to advocate “first time wrong”? It is nevertheless hard to achieve consistently. It’s even tough to get most in an organization to adopt it as a working attitude, despite the fact that everyone says, “I’m doing my best.” So, let’s look at these three little words in a team context—for they are fundamentally about teamwork.

“First time right” means no more than creating correct quality at each step in a process. That way, the next station in the process only works on things properly made by the preceding one, and so on. Ideally, I get it right on my first try, and my working conditions must enable that. That’s clearly the most efficient way to work. But, more importantly, “first time right” is a refusal to pass on poor quality to the rest of my team. That way, the team pulls together on the same rope. Poor quality just doesn’t arise, and the end product passes all tests. 

The phrase “first time right” originated within the Lean quality movement that itself drew its lessons from the Toyota Production System./1/ In tackling waste in all its forms, Toyota figured out that it was more efficient long-term to stop and correct any errors immediately. With their andon cords, a worker would halt the entire assembly line if he spotted a bad weld. Only once they eliminated the root cause would they restart production. A famous story relates how in the 1990s Toyota could produce a Lexus car in 19 hours, ready for delivery. An equivalent E class Mercedes needed 54 hours, with 30 hours invested in quality corrections **after** production. Avoiding poor quality seems like an obvious goal. Toyota’s success owed itself to understanding waste holistically and to embedding Kaizen (continuous improvement) into the company culture.

A team issue

As a basic principle, “first time right” can be applied both to manufacturing and services and in any situation. But, there are two prerequisites: we must define a standard and we have to be able to measure it. Without a standard, there is no “right”. Without measuring it, the judgment is just subjective./2/ Most importantly, agreeing, using and testing standards are fundamentally team issues. There are two facets, one mechanical and one organizational.

Mechanically, setting a standard means little more than specifying the properties a product must have to be considered correct. From its Latin origin, the word “quality” itself means “characteristic”. So, we are just defining what something is in a measurable way. Furthermore, the measurement method must be reliable. Whether we are testing a weld’s tensile strength, the numbers in a spreadsheet, a server build or whatever, the method must produce consistent results that all stakeholders accept. With that, we know whether we have fulfilled the requirements. But, these are just the mechanics.

Organizationally is where things get interesting. In the paragraph above, I used terms like “considered correct”, “reliable” and “accept”. All of these terms rest upon agreements among the stakeholders. Right quality doesn’t emerge out of the ether, it arises only when people commonly agree the standard and the measurement method. The agreement can occur at team level, for example in a common “way of working” document. Or, it can extend all the way to international norms: where would we be without the accepted definition of a meter?/3/ To underscore the point: we can define our standards any way we want, but we must agree them. Physical limitations, laws, market conditions, profitability etc. set boundaries, but the quality of our products and services are for us to decide among ourselves. Framed as a matter of agreement, adhering to standards makes one a team player. “First time right” means upholding the promise we make to each other and ourselves. 

Some exceptions may be allowed. Nowadays, we call this waste “technical debt”, a term that nicely highlights the future financial obligation: someday we will bear the costs of reduced quality. Thus, technical debt means short-term compromises, such as enduring some minor bugs, inefficient code or an incomplete module, for the benefit of faster delivery. Within an agile context, we can then evaluate the users’ experience and pivot the product to meet their needs better./4/ We accept technical debt consciously for the sake of a higher goal. 

While tolerable in a project or development context, technical debt—first time wrong, to call it by name—is harder to bear in the context of repeatable processes. With repetition, we should be able to eliminate it long-term. Worse, many times, no one even consciously decides to take it on. We just accept the errors as if they were a fact of life./5/ The key to success lies not in fixing single cases, but in creating a continuous improvement culture that says, “We value quality. We strive always to improve. We are honest about our mistakes. We are willing to invest in quality.”

Getting to first time right

Clearly, teams face serious challenges in living up to their own ambitions for right quality. Modern enterprises are complex entities. The complexity obscures a team’s  contribution within the value chain, thereby making it hard to know what “right” should be. Moreover, economic constraints limit their room to maneuver. Teams must also surmount real obstacles. A lack of resources, knowledge or efficient processes can make doing “first time right” seem impossible, unless the team takes the time to engage the issue holistically and look self-critically at the causes. The lesson of lean and agile companies shows, however, that “going slow to go fast” pays off in the end. Adopting Kaizen as an ethos leads to cultural benefits as well by empowering the team. By valuing improvement, the team’s frustration is channelled positively and creatively, rather than hopelessly pushing stones up the hill like Sisyphus.

The main hindrances to attaining “first time right” are as follows. The remedies are rather obvious, if not always easy:

1. A standard has not been set or it has become outdated.  The remedy: Define or renew it. “Customer value” should lead all thinking.

2. The standard was not accepted by all or not communicated. The remedy: Seek agreement. Explain why it is important. Communicate it.

3. The standard is not being followed. The remedy: Enforce, within the team, the team’s agreements to itself. Listen to objections and evaluate them objectively. Every member of the team should be empowered to tell a colleague (or boss), “hey, remember what we agreed”. 

4. The conditions for meeting the standard have not been established. The remedy: Create them, iteratively through continuous improvement.

The last point may incur significant investment in changing processes or other structures. As a long-term investment, it will take time. Toyota, again, is famous for whittling its machine switch-over times from first from days to hours and eventually to minutes. But, the patience and discipline will reap rewards in the end.    

Despite it origins in manufacturing, “first time right” is not about over-engineering service organizations into robotic monstrosities. It’s also not about perfection. A standard need not be sky high to meet customer’s needs and expectations. “First time right” is a work ethic, indeed, a teamwork ethic. It’s a promise that a team makes to itself.


/1/ I couldn’t locate the original usage of “first time right”. The history of Lean/Agile, including TPS is rich. Ohno, Shewart, Deming, and Juran are just the most well known contributors. As my friend Jan has shown, its roots go back the early nineteenth century. See, most recently, Jan Fischbach, “150 Jahre Scrum,” Agile Verwaltung (blog), August 12, 2021, https://agile-verwaltung.org/2021/08/12/150-jahre-scrum/, and his series of short presentations on Lean’s leading thinkers at leanbase.de: https://leanbase.de/onlineacademy/lernmodule.

Some of the best literature on Lean: Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Cambridge, Mass: Productivity Press, 1988); Jeffrey K. Liker and Karyn Ross, The Toyota Way to Service Excellence: Lean Transformation in Service Organizations (New York: McGraw-Hill Education, 2017); Jez Humble, Joanne Molesky, and Barry O’Reilly, Lean Enterprise (Beijing: O’Reilly, 2015); Mike Rother, Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results (New York: McGraw Hill, 2010).

 /2/ There are cases where a subjective judgment may be the best measurement method available. Here, scoring methods are used to enhance the reliability. Service organizations get into trouble when they believe that quality is merely subjective. Waiting times, correctness and completeness of an order etc. can all be measured.

/3/ The current definition of the distance traveled by light in a vacuum in 1/299,792,485 of a second doesn’t have to be. We could have said “in two seconds”, which would have merely doubled it’s length.

/4/ Eric Ries, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (Crown Business, 2011).

/5/ To err is human, of course. No human process can be expected to reach six sigma. But, we are talking here about repeatable errors and the fundamental attitude of improvement.  For an interesting “human sigma” approach, see John H. Fleming et al. “Manage Your Human Sigma” Harvard Business Review, (July–August 2005).


Beliebte Posts aus diesem Blog

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

"Wollt Ihr die totale Konkurrenz?!" - Nein, danke. Ich will lieber Erfolg, ich will spielen!

Es wird Zeit, dass wir uns daran erinnern, um was es wirklich geht: Dass wir gemeinsam gestalten, spielen und auch gemeinsam gewinnen. Und was wir riskieren, wenn wir das ignorieren.    

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

Die Krankheit des Besser-Wissens! Drei powervolle Fragetechniken und eine Haltung zur Heilung.

Kennst Du das: Du betrittst einen Raum und bist Teil einer Situation, hörst eine Problembeschreibung, siehst eine Aufgabe oder list eine Anfrage. Auf jeden Fall weisst Du mit einem Blick, einem Satz, einem Augenzwinkern sofort Bescheid. Du weisst: um was es geht was das Problem ist wieso das passiert ist was als Nächstes passiert und oft auch was dann (nicht) zu tun ist So wie mit dem Video hier: Ziemlich klar oder? Was für Gedanken gehen Dir durch den Kopf? Vielleicht sowas wie Oh weh!, Unfall!,  gibts Verletzte?  Oder Gehts denen gut? Wo ist das passiert? Viel Spass beim Flottmachen! Etc, etc... Auf jeden Fall aber: Was für ein Malheur! - oder irgend etwas Anderes in der Art. oder? Anderes Beispiel. Schau Dir mal folgendes Bild an und les im Geiste die beiden Reihen vor: A-B-C 12-13-14 oder? Unser Geist beruft sich auf sein Wissen und gibt uns in sekundenschnelle seine Annahme, seine Interpretation, seine Projektion der Wirklichkeit ein. Und die ist in dem Video oben nunmal ein ver