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.


Notes

/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).

Kommentare

Beliebte Posts aus diesem Blog

Klartext statt Konsens - wie Meetings wieder was bewirken

Bessere Kommunikation ist Lippenstift fürs Protokoll. Kennst Du das: Das Meeting läuft, Energie ist da, der Knoten platzt - und jemand sagt: "Wir müssen besser kommunizieren!" Alle nicken. Jemand schreibt's auf. Und was passiert damit?  Nichts . Warum? Weil "besser kommunizieren" keine Handlung ist. Genauso wenig wie: "mehr Verantwortung übernehmen", "offener Feedback geben", "konstruktiver diskutieren", "proaktiver sein", "mehr miteinander reden", "transparenter werden", "Verständnis füreinander zeigen". Alles klingt gut. Aber ohne Klartext bleibt’s ein Vorschlag - nett im Protokoll, aber ohne Effekt auf den nächsten Arbeitstag. Kein konkreter Schritt, keine sichtbare Veränderung. Keiner der's macht. Es ist eine gute Absicht ohne Konsequenz. Wir haben kein Problem Verbesserungen zu identifizieren.   Die wahre Herausforderung ist selten das Finden von Verbesserungen. Es ist das Konkretisie...

Die Profi-Tools im Windows-Explorer

Haben Sie bei der Urlaubsvertretung sich manches Mal geärgert, wenn Sie Dateien gesucht haben, die ein Teammitglied abgelegt hat? Die Suche im Explorer funktioniert tadellos, aber manchmal sollte man den Suchbegriff noch ein bisschen genauer fassen können. Z.B. mit UND oder ODER oder NICHT... Das geht so einfach, dann man von alleine kaum drauf kommt:

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Was macht ein agiles Project Management Office (PMO)?

Was macht eigentlich ein Projektmanagementoffice, insbesondere wenn es auch agile Projekte in der Organisation gibt? Muss man es abschaffen, wenn alle Projekte agil umgesetzt werden? Was machen die Personen, die im PMO tätig sind? Hier ist ein Vorschlag für eine agile Ausgestaltung eines PMO.

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.

Erfahrung mit Vibe-Coding - und warum das keine Teamprobleme löst

Die KI-Werkzeuge zum Erstellen von Werkzeugen für die tägliche Arbeit werden immer besser. Die selbstgestrickten Tools erleichtern die eigene Arbeit. Aber für den Einsatz im Team fehlt noch etwas.

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.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.

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?