Gerade in der Wikipedia über Taylor gelesen. Eigentlich ging es mir darum, dass die agilen Coaches mit denen ich gerade arbeite und zu denen ich mich auch ein wenig zähle, von dem lokalen Optimum als Antipattern zur agilen Vorgehensweise und „End-to-End teams“ aka Squads reden.
Mir schien es, dass ein End-To-End Team nichts anderes ist, als ein lokales Optimum. Ich vermute die agilen Coaches meinen mit lokalem Optimum das Optimum innerhalb eines Prozessschrittes innerhalb eines Fertigungsprozesses – aber je nach dem welche Flughöhe man so einnimmt, ist ein Squad häufig genug auch eingebettet in mehr als einen Prozessschritt bzw. Teil eines Businessprozesses. Nun ja, oder unsere Squads sind halt alle nicht richtige Squads, weil wir den Prozess der Softwareproduktion und Wartung in den Squad integrieren, anstatt den wahren End-to-End Prozess.
Egal! Mr. Taylor hat in dem Buch „Principles of scientific Management“ im Jahre 1913 folgende Sätze formuliert:
First. Find, say, 10 or 15 different men (preferably in as many separate establishments and different parts of the country) who are especially skilful in doing the particular work to be analyzed.
Principles of scientific Management, Frederic Winslow Taylor, Seite 117 ff.
Second. Study the exact series of elementary operations or motions which each of these men uses in doing the work which is being investigated, as well as the implements each man uses.
Third. Study with a stop-watch the time required to make each of these elementary movements and then select the quickest way of doing each element of the work.
Fourth. Eliminate all false movements, slow move- ments, and useless movements.
Fifth. After doing away with all unnecessary movements, collect into one series the quickest and best movements as well as the best imple- ments.
Und da fragte ich mich, ist das nicht irgendwie DevOps?
Zuerst finde einen Squad, von sagen wir mal 7+-2 Personen (andere Quellen sagen 7-12 Personen für ein optimales Team, auf jeden Fall irgendwie nicht weit weg von Taylors 10-15), welche gut darin sind Software zu bauen, zu deployen, zu testen, Anforderungen zu analysieren usw. usf.
Nun analysiere alle Prozessschritte genauestens und messe die Zeit jedes Schrittes (Kanban, bspw.). Anschließend eliminierst Du Mura, Mudi und Muda (Kaizen). Danach schaust Du auf die schnellsten und effizientesten Arbeitsabläufe und behältst diese bei.
Hm…In der englischen Wikipedia steht, dass diverse Methoden später auf Taylorismus aufsetzen, bspw. Lean. Vielleicht passen daher die Analogien zu Kanban und Kaizen so prima. Und im weiteren Sinne auch agile Vorgehensmethoden, wie sustainable pace. Der Teamgedanke war natürlich da irgendwie, zumindest in dem wenigen was ich gelesen habe, nicht präsent.
Und dann gibt es noch mindestens einen riesigen Unterschied: Taylor glaubte, dass die Analyse und das Wissen über alle Arbeitsschritte beim Management liegen müssten, damit die diese Optimierung durchführen können und dann dafür sorgen, dass diese optimalen Schritte eingehalten werden.
Das steht natürlich zum krassen Widerspruch des sich selbst organisierenden Teams was die besten Schritte selber herausknobelt. Und trotzdem wirken Teile davon sehr verwandt, vor allem mit CI/CD, wo ein hoher Automatisierungsgrad herrscht und um im alten Jargon zu bleiben, vorwiegend Roboter arbeiten. Spannend!