Apakah burnout dapat terjadi saat melakukan sprint Scrum secara terus menerus? [Tutup]


93

Saya dengan startup yang cukup kecil dan kami mulai menggunakan bentuk siklus pengembangan Scrum / Agile.

Dalam banyak hal saya menikmati Scrum. Kami memiliki sprint yang relatif singkat (2 minggu) dan saya suka Burn Down Chart untuk melacak kemajuan tim. Saya juga menyukai Papan Fitur sehingga saya selalu tahu apa yang harus saya lakukan selanjutnya. Rasanya enak melepas kartu fitur dari papan, menyelesaikannya dan kemudian meletakkannya di tumpukan yang terbakar.

Namun, kita sekarang memasuki siklus rilis Sprint ke-18 dan saya mulai merasa sedikit kelelahan. Bukannya saya tidak suka pekerjaan atau rekan kerja saya, hanya saja sprint ini ... yah, sprint . Dari awal hingga akhir, saya benar-benar merasa seperti berpacu dengan waktu untuk mempertahankan kecepatan perkembangan kami. Ketika kita selesai dengan sprint, kita menghabiskan satu hari untuk merencanakan set fitur dan perkiraan sprint berikutnya dan kemudian kita mulai lagi.

Untuk orang yang bekerja dalam proses pengembangan Agile / Scrum yang matang, apakah ini normal? Atau apakah kita melewatkan sesuatu? Apakah biasanya ada waktu dalam lingkungan Scrum yang tidak ditetapkan / tidak terlacak untuk menyelesaikan beberapa hal kecil dan menjernihkan pikiran?


Saya akan melihat lebih dekat pada isi sprint daripada metodologi. Pengembangan murni (tanpa pengujian, lonjakan, ulasan kode) dapat membunuh orang setelah beberapa saat. Selain itu, scrum master harus melindungi tim dari peta jalan yang tidak masuk akal, perkiraan waktu dari tim, dll. Selama penghitungan ketersediaan, pastikan Anda memperhitungkan 10-20% waktu tidak terikat untuk memperhitungkan pertemuan yang tidak terjadwal, istirahat di kamar mandi, gangguan, dll. Kemudian rencanakan untuk apa saja dan segalanya selama upacara. Semuanya seimbang pada akhirnya.
Sinaesthetic

12
jika ini tidak konstruktif, di bagian manakah ekosistem Stackexchange sebaiknya ditempatkan?
Ryan Schultz

2
Mungkin programmer.stackexchange.com ... tidak yakin.
Kevin Krumwiede

22
Pertanyaan dengan 53 suara positif. Jawaban diterima dengan 49. Ditutup sebagai tidak konstruktif. Jelas beberapa "moderator" yang menganggap diri benar telah berhenti minum obat mereka. Lagi.
SzG

Setuju, pertanyaannya adalah seputar persyaratan untuk perencanaan kapasitas dan begitu juga jawaban yang dipilih
charo

Jawaban:


68

Ini relatif normal dan terkadang dapat menjadi keluhan anggota tim kami jika proyek berlanjut dalam jangka waktu yang lama.

Kunci dari apa yang kita bicarakan di sini adalah kecepatan yang berkelanjutan . Jika Anda dan tim Anda mampu mempertahankan kecepatan Anda dalam jangka panjang, itu luar biasa - Anda telah mencapai hiperproduktivitas yang diperjuangkan oleh semua tim Scrum.

Alternatifnya, jika Anda menemukan bahwa Anda melebih-lebihkan berapa banyak pekerjaan yang sebenarnya dapat Anda selesaikan dalam sehari, maka Anda mungkin perlu mengevaluasi ulang itu selama retrospektif Anda. Jumlah waktu produktif dalam sehari yang dipilih tim untuk dikenali saat melakukan perencanaan kapasitas untuk sprint disebut sebagai faktor fokus .

Henrik Kniberg mengatakan ini:

Faktor fokus "default" yang saya gunakan untuk tim baru biasanya 70%, karena di situlah sebagian besar tim lain berakhir seiring waktu.

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Namun, yang Anda bicarakan hanyalah momentum tanpa henti dari sprint demi sprint, belum tentu produktivitas Anda dalam sehari. Berikut beberapa saran dari hal-hal yang telah kami coba atasi itu:

  • Akhiri sprint pada hari Jumat pagi. Lakukan tinjauan sprint dan retrospektif di pagi hari dan biarkan tim mengerjakan hal lain di sisa hari itu untuk menjernihkan pikiran mereka. Lanjutkan perencanaan Sprint pada hari Senin.
  • Kami memperkenalkan gagasan "hari lab". Ini adalah hari-hari penuh tim diambil dari proyek dan mereka menghabiskan hari bekerja untuk meningkatkan keterampilan teknis mereka sendiri melalui penelitian satu sama lain dan kolaborasi pada topik teknis tertentu. Sebagian besar waktu mereka sama sekali tidak ada hubungannya dengan proyek tertentu dan memungkinkan anggota tim untuk memikirkan topik yang lebih ringan.

3
Kniberg berkata sendiri: "Faktor fokus adalah salah satu hal yang ingin saya sobek dari buku. Berhenti menggunakannya segera setelah menulis buku ..." - twitter.com/henrikkniberg/status/207853426967715841
MPV

24

Dari Wikipedia tentang burnout: "burnout sebagian besar merupakan masalah organisasi yang disebabkan oleh jam kerja yang panjang, waktu down yang sedikit, dan peer terus menerus, pelanggan, dan pengawasan yang superior"

Mereka mungkin juga memiliki gambar ikon Scrum di sebelah definisi burnout.

Jika Anda berpikir Anda dapat mengirim seseorang ke sesuatu yang lain untuk pengalihan singkat guna mengatasi kelelahan, Anda jelas belum memikirkannya. Pernah berlibur setelah kelelahan dan kembali bekerja sambil berpikir, Wah! Sekarang saya segar dan siap untuk 6 bulan lagi penyiksaan ini sampai akhirnya saya bisa istirahat lagi. Tidak, yang terjadi adalah Anda menyadari, Wow! Pekerjaanku menyebalkan. Sekarang saya benar-benar dapat melihat bagaimana pengelolaan mikro manajer saya yang bodoh, proses pengembangan hanyalah cara lain untuk mendapatkan lebih banyak dari saya dengan lebih sedikit dan hidup terlalu singkat untuk ini ... Saya harus mencari hal lain untuk dilakukan atau mengubah pekerjaan menjadi sesuatu yang tidak terlalu membuat stres .

IMHO, Scrum singkat 2 minggu harus dilarang kecuali dalam dosis kecil, tidak lebih dari 4-8 berturut-turut. Gunakan sebagai alat untuk hal-hal yang luar biasa atau kritis, bukan terus-menerus. Gunakan akal sehat.


3
Ini FUD yang konyol, Scrum tentu saja bukan tentang membuat orang menjadi lelah, sprint pendek bukan tentang bekerja 80 per minggu.
Pascal Thivent

7
Ini tepat sasaran. Lucu bagaimana para pecinta scrum mempertahankannya dengan dongeng tentang bagaimana hal itu 'seharusnya' dilakukan, tetapi sebagian besar pengembang mengalami apa yang dibicarakan OP.
kirk.burleson

2
Saya telah menyadari hal ini selama beberapa tahun terakhir dan sepenuhnya setuju dengan apa yang dikatakan di sini. Saya putus asa untuk keluar dari pekerjaan seperti ini meskipun itu mungkin berarti menjadi gelandangan untuk sementara waktu dan menggunakan tabungan. Belum lagi 'berdiri' yang ditakuti setiap pagi. Saya bangun dan berharap saya berada di tempat lain, dan saya sedang berusaha mewujudkannya.
Keterampilan M2

5
Bagi saya, scrum menyebabkan kejenuhan. Jumlah jam saya bekerja dan jumlah produktivitas yang saya miliki tidak berubah, tetapi suasana hati saya berubah. Tanpa scrum, saya menyelesaikan pekerjaan dan merasa senang melakukannya. Ketika kami menambahkan proses scrum, saya menyelesaikan pekerjaan yang sama dengan kecepatan yang sama, tetapi terus-menerus cemas dengan tenggat waktu dan rapat, jadi saya tidak lagi menikmatinya. Tidak menikmati pekerjaan Anda adalah jalan untuk berhenti. Selain itu, grafik burn-down bisa menjadi demotivasi yang luar biasa saat sprint berjalan buruk.
orfdorf

3
Saya ingin mengatakan bahwa ada banyak perbedaan antara perusahaan yang saya lihat menggunakan istilah scrum. Untuk organisasi yang paling murni, Scrum berarti mereka memperbaiki hasil kerja, tepat waktu, dan melakukan banyak perencanaan untuk memastikannya bekerja seperti itu. Untuk organisasi yang paling tidak murni, Scrum berarti Anda diharapkan untuk mengirimkan setiap dua minggu, persyaratannya terus berubah, dan Anda mendapatkan rapat manajemen mikro setiap pagi. Menurut saya, versi terakhir dari scrum terjadi lebih sering daripada yang pertama, dan menyebabkan kelelahan yang dijelaskan di atas jauh lebih cepat.
Edwin Buck

14

Anda menjadi lelah setelah 36 minggu bekerja keras; itu bukan Scrum, itu sifat manusia! Scrum tidak ada untuk membuat Anda bekerja lebih keras, itu ada untuk membantu Anda bekerja lebih konsisten dan dengan prediktabilitas yang lebih besar. Saya sering melihat orang-orang mengacaukan gejala manajemen proyek normal dengan apa yang mereka anggap sebagai gejala metodologi tangkas (misalnya, "pelanggan terus mengubah persyaratan - itu pasti kesalahan Scrum!"). Ini perbedaan penting karena tanpa mengidentifikasi penyebab Anda tidak dapat mengobati gejalanya. Secara pribadi saya akan mencari cara untuk mengurangi kelelahan seperti teknik manajemen stres. Ada banyak sekali info di luar sana tentang cara sukses dalam lingkungan yang penuh tekanan.


11

Tim yang sedang saya tangani memecahkan masalah ini dengan sangat baik. Setelah tiga sprint, kami memiliki waktu seminggu di mana setiap pengembang dapat mengerjakan apa yang dia inginkan. Proyek sampingan tersebut harus dikaitkan dengan nilai bisnis, tetapi tidak ada tekanan untuk menyelesaikannya. Ini adalah ukuran yang memungkinkan kami para pengembang untuk menjelajahi teknologi baru, tetapi juga memberi kami seminggu kerja yang lebih santai dan menyenangkan.

Ini pasti membantu saya untuk tidak kelelahan.


10

Tidak peduli proses pengembangan apa yang Anda gunakan, jika tim kehabisan tenaga, ada sesuatu yang salah. Mungkin sesederhana orang-orang yang tidak mengambil waktu liburan yang mereka butuhkan, atau bisa juga pada detail bagaimana Anda menangani scrum Anda. Tim efektif dalam jangka panjang karena setiap orang mendapatkan istirahat yang mereka butuhkan sepanjang jalan.


10

Sprint bukanlah lari 100 yard; Ini adalah satu mil (acak) dalam maraton, yaitu kecepatan yang Anda dapat pertahankan tanpa batas.

Apakah Tim Anda melakukan retrospektif di akhir setiap Sprint? Ini adalah kesempatan Tim untuk "memeriksa dan menyesuaikan" proses mereka? Sebagai ScrumMaster, saya secara teratur meminta Tim untuk menilai bagaimana 'perasaan' Tim sebagai entitas, dan apakah mereka bersenang-senang. Kami mengeksplorasi mengapa atau mengapa tidak, dan bereksperimen dengan penyesuaian dan alternatif.

Menurut pengalaman saya, anggota tim menikmati (hingga batas tertentu) 'tekanan' yang dibatasi kotak waktu Sprint. Kuncinya adalah mendekati, tetapi tidak melebihi, zona itu. Jika diperlukan, mengkalibrasi zona itu adalah titik pemeriksaan utama dalam retrospektif.

Adapun "... waktu di lingkungan Scrum yang tidak ditugaskan / tidak terlacak untuk menyelesaikan beberapa hal kecil dan menjernihkan pikiran Anda", menjaga komitmen Tim pada x% dari kapasitas yang tersedia (poin, sebaiknya, tetapi jam dapat digunakan jika perlu; dalam kedua kasus saya telah menemukan sesuatu dalam kisaran 60-70% tampaknya norma) adalah kunci keberlanjutan di dalam Sprint, dan 'hari kode bebas' sesekali bekerja dengan baik untuk di luar Sprint.


21
Mungkin mereka seharusnya tidak menyebutnya Sprint, eh? Mereka harus menyebutnya Lap.
Alex Baranosky

4
Saya yakin mereka menyebutnya Sprint untuk mencegah orang-orang di luar tim ikut campur. Sprint terdengar seperti sesuatu yang tidak boleh Anda ganggu.
Paul Tevis

Sebuah lap menyiratkan tidak ada tujuan, itu hanya satu dari banyak lagi, sprint mendefinisikan 'lari ke tujuan' yang sprintpada akhirnya adalah. Istilah ini terdengar IMHO
Jakub

2
Cukup gunakan "iterasi". Bagi kebanyakan dari kita, istilah-istilah tersebut sudah identik, tetapi "iterasi" tidak memiliki keseluruhan konotasi "lari sampai Anda mati kelelahan".
mindcrime

8

Salah satu solusinya adalah mengurangi jumlah jam dalam sehari yang dihabiskan untuk sprint.

Saya mengenal beberapa orang yang hari kerja hanya terdiri dari dua setengah jam sprint, dengan sisa hari difokuskan pada berbagai kegiatan lain: mendukung, menghilangkan hutang teknis, penelitian, dll. Kecepatan perkembangan mereka telah diatur sesuai.

Itu mungkin tampak agak ekstrim, tetapi jika saya tidak salah itu adalah perusahaan yang menguntungkan sampai guncangan ekonomi yang meluas baru-baru ini melanda.


1
Saya pikir saat ini kita sedang dalam 6 jam sprint per hari. Mungkin itu terlalu berlebihan.
mmcdole

Mungkin kedengarannya tidak banyak, tapi menurut saya ini adalah tali yang cukup ketat untuk berjalan. Jika tidak ada masalah nyata yang muncul sepanjang hari, Anda dapat mempertahankannya dengan baik, tetapi jika Anda mengalami hambatan, kecepatan Anda akan terhenti untuk hari itu.
mmcdole

Tim saya melakukan perencanaan berdasarkan 5 jam produktif per hari. Dan TBH saya pikir 4,5 jam mungkin akan lebih cocok untuk kita. Jadi menurut saya 6 jam produktif per hari itu banyak.
John Rayner

6

Kamu sedang dalam sprint ke 18 !?

Mempertimbangkan 2 minggu per sprint, itu berarti 36 minggu nonstop mengerjakan proyek yang sama. Anda juga berkomentar bahwa bekerja sekitar 6 jam setiap hari. Kedengarannya sangat banyak!

Saya tidak tahu banyak tentang metodologi tangkas (meskipun kami sebenarnya menggunakan Scrum dalam proyek kami saat ini), tetapi ada prinsip tentang jam kerja Anda (maksud saya, jumlah waktu yang Anda habiskan untuk melakukan tugas) harus 60% ~ 70%. Sekarang, menghitung lagi, jika hari kerja Anda 8 jam, dan Anda menghabiskan 6 jam untuk bekerja, Anda benar-benar menghabiskan sekitar 75% dari waktu kerja Anda. Ini bisa jadi penyimpangan kecil yang akhirnya membuat Anda memiliki perasaan itu.

OTOH, saya yakin jika proyek Anda akan memakan waktu lama untuk diselesaikan, sprint harus lebih besar, bukan 2 minggu, tetapi bukan sebulan. Pertimbangkan kurva ke bawah pada grafik kelelahan Anda: Mulailah sprint Anda dengan latihan rutin, dan kurangi aktivitas Anda pada 2 atau 3 hari terakhir sebelum sprint berakhir.

Agile bukanlah batu dengan ukiran: "bekerja lebih cepat / lebih kuat / lebih baik / lebih keras", lebih seperti langit biru dengan awan putih yang bertuliskan: "kerja bagus, indah lebih produktif". (sedikit lol di akhir milik daft punk + radiohead).


6

Saya sangat mengerti apa yang Anda katakan. Bagi Anda yang mengatakan "kecepatan Anda terlalu cepat", saya tidak yakin saya setuju bahwa kecepatan selalu menjadi masalah ketika orang kelelahan karena proses ini. Meskipun melacak semua kemajuan Anda ADALAH hal yang baik, itu juga bisa menjadi faktor stres itu sendiri (dan tidak melacak juga bisa), bukan hanya karena atasan / PM Anda akan menyertai Anda jika mereka melihat ada sesuatu yang tidak berjalan. sesuai rencana, tapi untuk dirimu sendiri. Hanya memiliki info login ini adalah sesuatu yang AKAN membuat kebanyakan orang bekerja sedikit lebih keras dari biasanya SEPANJANG WAKTU dan saya tidak yakin meluangkan lebih banyak waktu pada perkiraan waktu Anda akan memperbaikinya untuk semua orang. Saya tidak berpikir seorang motivator (seperti grafik burn down Anda) selalu positif.

Beberapa orang tidak akan merasa seperti ini, yang lainnya akan. Tidak ada SATU cara kerja yang AKAN cocok untuk semua. Tidak akan pernah, menurut saya.

Juga, jika Anda mengatakan bahwa metode dan sprint yang gesit ini tidak menjadi lebih efektif / produktif, mengapa Anda menggunakannya sama sekali? Menurut Anda, mengapa perusahaan ingin menggunakan metode ini? Bukan karena mereka menyenangkan ....

Efektivitas / produktivitas selalu datang dengan harga tertentu, menurut saya. Itu tidak muncul entah dari mana hanya dengan menggunakan metode ajaib (jika Anda mengerti maksud saya).

Satu-satunya cara bagi Anda untuk menjadi lebih efektif (berdasarkan pekerjaan dan tekanan) dan melakukan lebih sedikit pekerjaan adalah membuat orang lain mengerjakannya atau dengan mengotomatiskannya.

Menurut pendapat saya, seseorang harus selalu meninjau prosesnya dan melihat apa yang bisa diotomatiskan dan menghabiskan waktu untuk mengotomatiskan proses Anda. Otomasi datang dengan harga melakukan pekerjaan ekstra daripada melakukan "pekerjaan nyata" tetapi tidak peduli seberapa kecil tugas otomatis Anda akan selalu mendapat untung dalam jangka panjang. SELALU! Jika tidak satu hari, dalam dua hari. Tidak satu bulan, dua bulan. Bukan satu tahun, dalam dua tahun. Anda mengerti.

Namun, saya suka ide memiliki waktu istirahat untuk mengerjakan proyek pribadi. Sebagian besar perusahaan tidak akan pernah mengizinkan ini. Tapi mungkin Anda bisa membujuk majikan Anda untuk mendapatkan waktu ini untuk mengotomatiskan proses Anda dan pekerjaan ini bisa "di luar kendali sprint" untuk memberikan waktu yang Anda bicarakan untuk "istirahat" dan mendapatkan energi kembali untuk sprint baru.

Itu hanya 2 sen saya. Saya menjadi sedikit ketakutan ketika orang mengatakan metode ini tidak ada di sini untuk membuat kami lebih efektif dan bekerja lebih keras. Tentu mereka! Ketika Anda tidak memiliki jejak apa pun yang Anda lakukan, Anda akan beristirahat ketika tubuh Anda menyuruh Anda melakukannya. Ketika "segala sesuatu" yang Anda lakukan dilacak, Anda akan memaksakan diri. Atau saya mengoreksi diri saya sendiri, kebanyakan orang bekerja dengan cara ini, beberapa akan tetap beristirahat.


2

Kecepatan berkelanjutan adalah prinsip utama dari gesit. Saat melakukan praktik manajemen (SCRUM) bersama dengan praktik teknik (XP), tim dapat mengirimkan sprint demi sprint tanpa batas waktu. Namun, karena tidak bisa berarti harus.

Kedengarannya Anda membutuhkan perubahan melawan string sprint tanpa akhir yang Anda lihat di depan Anda. Sejumlah opsi bisa ditawarkan. Setiap nomor X sprint, seorang anggota tim (atau pasangan) dapat merotasi sebuah tim. Selama rotasi, Anda dapat mendukung tim lari, mengambil kelas, fokus pada serangkaian lonjakan, berlibur, dll.

Jika tim memiliki 5 pasangan, dan Anda merotasi seseorang keluar dari garis, Seseorang dapat melakukan rotasi setiap sprint ke-10 (jika satu orang) atau setiap iterasi ke-5 (jika berpasangan). Masalah anggaran dan laba atas investasi untuk aktivitas Anda perlu ditangani oleh pimpinan dan atau mitra bisnis Anda. Namun yang jelas, memiliki waktu untuk "mengasah gergaji" akan membawa keuntungan bagi tim proyek tersebut. Menjaga tim tetap segar dan fokus adalah hal yang sangat bagus. Tetapi kita harus ingat, kita dibayar dan kita perlu memberikan nilai untuk dolar yang kita peroleh.


3
Mungkin mereka seharusnya tidak menyebutnya Sprint, eh? Mereka harus menyebutnya Lap.
Alex Baranosky

2

Saya pikir Anda melewatkan sesuatu, tetapi Anda bukan satu-satunya. Seperti yang dikatakan Jim Highsmith: "Kecepatan semakin sering digunakan sebagai ukuran produktivitas (bukan ukuran kalibrasi kapasitas yang dimaksudkan) yang memfokuskan terlalu banyak perhatian pada volume poin cerita yang disampaikan."

Saya rasa itulah yang terjadi pada tim Anda. Saya sarankan membaca posting mani IMHO Highsmith ini: Velocity is Killing Agility!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.