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

Transparenz als Schlüssel zum Erfolg: 20 Reflexionsfragen für moderne Organisationen

Transparenz ist das Herzstück erfolgreicher Teams. Sie schafft Vertrauen und fördert Zusammenarbeit. Wenn alle Zugang zu den notwendigen Informationen haben, können sie fundierte Entscheidungen treffen und gemeinsam Lösungen erarbeiten. Dies führt zu höherer Effizienz, schnelleren Entscheidungsprozessen und besseren Arbeitsergebnissen. Transparenz ist mehr als ein Schlagwort – es gilt, sie greifbar zu machen, ein gemeinsames Verständnis davon zu entwickeln und es in die Praxis umzusetzen. Wie das gelingt und welche Vorteile es für Euer Team und Eure Organisation bringt, erkunden wir im Folgenden.

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.

Zu viel zu tun? Planen Sie Ihre ideale Woche

Wir hören immer wieder, dass Teams zu viel zu tun haben. Aber woher wissen wir eigentlich, was zu viel genau bedeutet? Hier ist ein ungewöhnlicher Tipp: Treffen Sie Annahmen über eine gute Menge. Planen Sie eine ideale Woche.

Wenn dein Team die Anforderungen blockt: 12 Tipps für Product Owner*innen

Liebe Product Owners, wir müssen reden. Schon wieder eine Anforderung, die im Nirgendwo landet? Zeit, das Ganze anders anzugehen. Ihr kennt das Spiel: Anforderungen sind ausgearbeitet, und doch läuft es im Team holprig. Was fehlt? Oft sind es Klarheit, realistische Erwartungen und ein bisschen Fingerspitzengefühl. Doch keine Sorge! Mit ein paar praktischen Tipps könnt ihr Missverständnisse vermeiden, Blockaden umgehen und den Entwicklungsprozess so richtig in Fahrt bringen – natürlich in Zusammenarbeit mit eurem Scrum Master. Hier sind zwölf Regeln, die euch helfen, das Team auf Kurs zu bringen und das Chaos in produktive Zusammenarbeit zu verwandeln. Wir zeigen dabei auch, wo der Scrum Master unterstützen kann, damit ihr eure Rolle als Product Owner noch besser erfüllen könnt. Häufige Stolperfallen: Warum Anforderungen oft scheitern Bevor wir ins Eingemachte gehen, kurz zu den typischen Stolperfallen. „Klare Anforderungen“? Klingt gut, scheitert aber sehr häufig an der realen Praxis. ...

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.

Pragmatisch oder nur “Quick and Dirty”?

“Wir müssen aber pragmatisch vorgehen”, drängt der Kollege. Hm… Im Wörterbuch finde ich für “pragmatisch” in etwa: sachbezogenes, praktisches Handeln. Klingt gut. Leider zeigt sich in meinen Erfahrungen, dass pragmatisch für viele doch eher “quick and dirty” bedeutet. Es soll schnell fertig werden. Aber auf welche oder wessen Kosten? Wo ist die Grenze? Warum steht “praktisch” im Konflikt mit einem langfristigen “Nützlich”? Muss das sein?

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.

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.

5 Gründe, warum wir jetzt über die Zukunft nachdenken sollten

Wer hätte im Jahr 2019 gedacht, dass so viele Menschen heute im Home-Office arbeiten können und dass die Firma trotzdem funktioniert? Wer hätte damals gedacht, dass wir heute wie selbstverständlich KI-Werkzeuge nutzen können? Ich will mich nicht der Aussage anschließen, dass sich die Welt immer schneller dreht. Es ist egal, wie schnell sie sich dreht, weil es sich immer lohnt, über die Zukunft nachzudenken. Und das muss nicht kompliziert sein.

Meetings in Scrum Teams: Mehr Fokus, weniger Kontextwechsel

  Meetings in Scrum Teams: Mehr Fokus, weniger Kontextwechsel  „Wir arbeiten agil“ – das bedeutet für viele von uns: Daily Stand-up am Morgen, dann Refinement, dazwischen eine Demovorbereitung, später noch ein kurzes Scrum of Scrums (SoS) und am Nachmittag ein Community-Meeting. Gleichzeitig soll ich an meinen Sprint-Aufgaben arbeiten. Wenn dir diese Situation bekannt vorkommt, les dir gerne meinen Beitrag an. Hier sprechen wir über den Einfluss von häufigen Kontextwechseln auf die Arbeit in agilen Teams und zeigen Best Practices, um diese Wechsel zu minimieren. Viel Spaß & Let’s grow, Michi.  Foto von Matt Bero auf Unsplash