Ketika organisasi mencoba untuk meningkatkan cara kerja mereka, efisiensi yang lebih baik sering menjadi tujuan yang dikutip. 'Meningkatkan aliran' adalah hal lain yang mungkin Anda dengar, dengan Efisiensi Aliran menjadi ukuran yang disebut sebagai sesuatu yang perlu difokuskan oleh organisasi. Masalahnya adalah hanya sedikit, jika ada, yang berbagi banyak kekurangan metrik ini.

Baca terus untuk mengetahui apa jebakan ini dan, yang lebih penting, alternatif apa yang mungkin ingin Anda fokuskan untuk meningkatkan cara kerja Anda…

Antrian

Antrean adalah musuh aliran di hampir setiap konteks, tetapi khususnya pengembangan perangkat lunak. Ketergantungan, pemblokir, dan struktur org hanyalah beberapa yang muncul di benak Anda saat memikirkan alasan mengapa pekerjaan menganggur. Dalam dunia manufaktur Lean, Taiichi Ohno pernah menyatakan bahwa dalam proses tipikal hanya sekitar 5% yang didefinisikan sebagai aktivitas penambahan nilai . Ada juga ukuran efektivitas peralatan keseluruhan (OEE), dengan banyak lini produksi hanya 60% produktif .

Baru-baru ini, karya Don Reinertsen dalam Prinsip Alur Pengembangan Produk sering menjadi inspirasi bagi para praktisi Agile, dengan kutipan berikut yang menonjol:

Pemborosan terbesar kita bukanlah insinyur yang tidak produktif, tetapi produk kerja yang menganggur dalam antrean proses.

Banyak pemimpin pemikiran, pelatih, dan konsultan memperjuangkan penggunaan metrik yang dikenal sebagai efisiensi aliran saat melatih tim dan organisasi untuk meningkatkan cara kerja mereka, tetapi apa sebenarnya itu?

Apa itu efisiensi aliran?

Efisiensi aliran merupakan adaptasi dari metrik efisiensi proses dunia ramping . Di sinilah untuk item pekerjaan tertentu (item simpanan, cerita pengguna, apa pun taksonomi pilihan Anda) kami mengukur persentase waktu aktif — yaitu, waktu yang dihabiskan untuk benar-benar mengerjakan item terhadap total waktu ( waktu aktif + waktu tunggu ) yang dibutuhkan untuk menyelesaikan item.

Misalnya, jika kita mengambil papan Kanban tim pengembangan perangkat lunak, mungkin terlihat seperti ini:

Di mana efisiensi aliran akan dihitung seperti ini:

Standar industri mengatakan bahwa efisiensi aliran antara 15% dan 40% adalah baik.

Dalam hal memvisualisasikan efisiensi aliran, biasanya akan terlihat seperti ini:

Dalam bagan ini, kita dapat melihat frekuensi (jumlah) item pekerjaan dengan efisiensi aliran persentase tertentu, dan tampilan agregat seperti apa efisiensi aliran rata-rata.

Semuanya masuk akal, bukan? Banyak praktisi juga akan menganjurkan ini sebagai hal penting untuk diukur.

Saya tidak setuju. Faktanya, saya akan mengatakan lebih jauh bahwa saya percaya efisiensi aliran menjadi metrik yang paling tidak praktis dan overhyped di industri kita.

Jadi, apa sebenarnya beberapa masalah dengan itu?

Bukti anekdotal tentang efisiensi aliran “khas”.

Sekarang saya tidak setuju dengan ide-ide di atas tentang antrian menjadi masalah dengan banyak waktu yang dihabiskan untuk menunggu. Saya juga tidak menyangkal bahwa efisiensi aliran di sebagian besar organisasi cenderung buruk . Masalah saya datang dengan mereka yang mengutip persentase atau angka efisiensi aliran, mengutip 'standar industri' dan apa yang tampak bagus tanpa bukti yang kuat. “Saya telah melihat persentase efisiensi aliran sebesar n%” mungkin merupakan ucapan umum yang Anda dengar — #DataOrItDidntHappen harus menjadi tagar yang lebih sering untuk beberapa klaim di industri kita. Jika kami mengambil beberapa contoh di dekat bagian atas pencarian cepat Google:

• “Standar industri mengatakan bahwa efisiensi aliran antara 15% dan 40% adalah baik” — namun artikel ini tidak memiliki sumber 'industri' pendukung untuk mendukungnya
• “Sebagian besar tim memiliki efisiensi aliran antara 5% hingga 15%. Tercatat terendah sekitar 2%; maksimum, setelah banyak usaha, adalah sekitar 40%” — blog lain tanpa data sumber atau tautan ke studi (meskipun dikatakan 'direkam')
• “Efisiensi aliran serendah 2% telah sering dilaporkan oleh para manajer dan konsultan yang melapor di konferensi Lean Kanban selama 2 tahun terakhir. Pengalaman pribadi saya sendiri adalah bahwa perusahaan yang saya temui menunjukkan efisiensi aliran 5% - 15%. Setelah banyak upaya untuk melakukan peningkatan, kami melihat peningkatan ini tetapi 40% masih sangat baik” — referensi anekdot yang paling umum seputar efisiensi aliran dari David Anderson, namun sekali lagi ini hanya anekdot.

Dan kemudian tautan referensi pendukung:

Menyurvei beberapa orang di kelas ≠ 'tim scrum rata-rata'.
Sungguh mengherankan saya bahwa selama bertahun-tahun data yang dikumpulkan dalam berbagai alat, serta penekanan kami yang sering pada empirisme - tidak ada satu studi pun yang memvalidasi klaim yang dibuat seputar persentase efisiensi aliran "biasanya".

Kurangnya status menunggu

Sekarang, mengabaikan kurangnya studi yang sebenarnya, mari kita lihat bagaimana tim biasanya bekerja. Banyak tim yang tidak mengetahui atau belum mengidentifikasi status tunggu dalam alur kerja mereka:

Dalam contoh ini (yang tidak jarang) — semua status alur kerja adalah status 'aktif', oleh karena itu tidak ada cara untuk menghitung kapan pekerjaan menunggu, sehingga efisiensi aliran akan selalu 100% (dan karena itu tidak berguna!). Banyak tim memiliki ini di mana mereka sebenarnya tahu apa status menunggu mereka belum memodelkannya dengan tepat dalam alur kerja mereka.

Ketidakmungkinan mengukur waktu mulai/berhenti

Katakanlah sekarang kita telah mengidentifikasi status tunggu dan memodelkannya dengan tepat dalam alur kerja kita:

Seberapa sering (IME cukup teratur!) kami mendengar pembaruan saat meninjau papan seperti di bawah ini:

Mengharapkan pembaruan yang hampir real-time (agar mencerminkan waktu aktif vs. menunggu secara akurat) tidak praktis dan oleh karena itu angka efisiensi aliran apa pun cacat karena keterlambatan pembaruan item ini. Selain itu, ada begitu banyak perbedaan dalam pengembangan produk sehingga membuat panggilan biner, apakah sesuatu sedang aktif vs. menunggu, tidak mungkin dilakukan. Apakah memikirkan sesuatu saat berjalan-jalan adalah waktu aktif atau waktu menganggur? Bagaimana dengan eksperimen? Terlebih lagi pikirkan kapan kita berangkat kerja di penghujung hari. Tidak ada barang kami yang sedang dikerjakan, jadi bukankah semuanya harus ditandai sebagai 'menunggu' sampai hari berikutnya?

Tidak memperhitungkan pemblokir

Menjaga alur kerja yang sama seperti sebelumnya, skenario selanjutnya yang perlu dipertimbangkan adalah bagaimana kami menangani saat pekerjaan diblokir.

Item khusus ini disorot/diberi tag karena diblokir karena kami membutuhkan umpan balik sebelum kami dapat memindahkannya dalam alur kerja kami. Namun itu dalam keadaan 'bekerja' karena tidak dapat dikembangkan. Lebih sering daripada tidak, ini tidak diperhitungkan dalam perhitungan atau literatur efisiensi aliran, seperti contoh ini:

Tidak mungkin suatu item "Dalam Dev" untuk periode yang jelas dan tidak terputus dan oleh karena itu ini bukanlah gambaran realistis yang disajikan dalam hal bagaimana pengembangan produk benar-benar terjadi.

Itu NumberWang!

Bagi mereka yang tidak sadar, Numberwang adalah sketsa terkenal dari acara TV komedi That Mitchell and Webb Look . Ini adalah gameshow fiksi di mana dua kontestan memanggil nomor acak yang secara acak kemudian diberitahu oleh 'pembawa acara' untuk menjadi "Numberwang!"

Mengapa ini relevan? Nah, saat melihat item yang telah melewati proses kami dan persentase efisiensi alirannya masing-masing, yang kami lakukan hanyalah memainkan versi Agilis dari sketsa komedi yang sama.

Face ID Login memiliki efisiensi aliran 19% tetapi pengembalian kode QR hanya memiliki 9%! OMG :( :( :( Jadi apa? Itu hanya persentase angka— itu tidak berarti apa-apa! Juga, lihat waktu siklus untuk barang-barang itu, dapatkah kita secara pasti mengatakan bahwa satu barang "lebih efisien" daripada yang lain? Apakah ini memberi tahu kita tentang cara meningkatkan alur kerja kita dan di mana kemacetan kita? Tidak! Itu hanya membacakan angka dan berpikir itu berarti karena itu adalah "data".

Cacat Rata-Rata

Siapa pun yang telah membaca posting saya sebelumnya akan tahu bahwa penggunaan rata-rata apa pun dengan metrik aliran adalah cara untuk menekan tombol saya. Sayangnya, visualisasi efisiensi aliran seringkali disertai dengan rata-rata efisiensi untuk sekumpulan item pekerjaan yang sudah selesai, seperti berikut:

Menggunakan rata-rata dengan metrik apa pun adalah godaan yang berbahaya dengan informasi yang menyesatkan, dan kita dapat melihat bahwa untuk serangkaian item ini cukup mudah dilakukan:

Tiga dari lima item kami yang telah selesai memiliki efisiensi aliran yang buruk namun digabungkan menjadi satu angka yang menyinggung (jika efisiensi aliran mendekati 40% menjadi anekdot "baik" dikutip!) kami memiliki proses yang cukup efektif. Dengan menggabungkan kita kehilangan semua konteks dari item 'tidak efisien' itu dan di mana kita mungkin menggunakannya sebagai dasar untuk percakapan seputar meningkatkan cara kerja kita.

Apa yang harus kita gunakan?

Secara teori, efisiensi aliran sepertinya ide yang bagus, namun ketika Anda melihat semua alasan di atas bahwa tidak praktis bagi tim dan organisasi untuk benar-benar menerapkan dan memanfaatkannya secara efektif (tanpa setidaknya menjadi jelas mereka menggunakan data yang cacat). Lanjutkan dengan hati-hati bagi siapa pun yang menganjurkannya tanpa peringatan yang disebutkan di atas!

Metrik/penggunaan waktu Anda yang lebih baik adalah melihat data pemblokir dan mengejar data yang paling sering muncul dan/atau paling berdampak. Troy Magennis memiliki alat yang hebat untuk ini (terima kasih juga kepada Troy karena telah berbagi pemikiran tentang karya ini).

Berikut adalah beberapa contoh yang kami gunakan untuk beberapa tim kami di ASOS:

Yang kemudian dapat digunakan untuk mengurangi frekuensi terjadinya pemblokir tertentu dan melihat di mana Anda perlu fokus selanjutnya:

Dengan cara ini Anda benar-benar mengejar masalah yang dihadapi tim, yang pada gilirannya akan berdampak positif pada alur kerja. Semua ini dilakukan tanpa perlu ukuran/angka 'efisiensi'.

Apa pendapatmu? Setuju? Tidak setuju?
Saya ingin mendengar pendapat Anda di komentar di bawah…

Tentang saya

Saya Nick, salah satu Pelatih Agile kami di ASOS. Saya membantu memandu individu, tim, dan platform untuk meningkatkan cara mereka bekerja dalam kerangka kerja agnostik. Di luar pekerjaan, putra saya yang baru lahir membuat saya tetap waspada, inilah saya yang mencoba memengaruhinya untuk berbagi minat ayahnya pada sepatu kets…

ASOS sedang merekrut berbagai peran di Teknologi. Lihat semua posisi terbuka kami