Panduan Scrum | 16. Scaling Scrum

Diterbitkan: 2022-05-16

Tim Scrum harus terdiri dari maksimal sepuluh orang. Tetapi apa yang harus dilakukan ketika sekelompok spesialis yang lebih besar perlu mengerjakan satu proyek? Atau jika organisasi memutuskan untuk mengikuti cara manajemen yang gesit? Untuk mengatasi masalah ini, pengembang Scrum mengusulkan [dilindungi email] Ini adalah arsitektur bebas skala untuk mengatur seluruh tim sesuai dengan prinsip Scrum.

Scaling Scrum – daftar isi:

  1. pengantar
  2. [dilindungi email]
  3. Scrum dari Scrum
  4. Penskalaan lebih lanjut dan masalah [dilindungi email]
  5. Ringkasan

pengantar

Begitu sebuah organisasi tumbuh, jenis masalah baru muncul. Misalnya, penurunan efektivitas karyawan yang disebabkan oleh struktur internal yang kompleks, pengambilan keputusan yang sulit atau penetapan arah. Perusahaan yang beroperasi dengan gesit di tingkat tim proyek kecil sering kali ingin meningkatkan.

Banyak perusahaan melakukannya dengan baik tanpa menskalakan Scrum. Bahkan jika banyak Tim Scrum berjalan secara bersamaan, mereka tidak memerlukan koordinasi karena grup beroperasi secara independen. Namun, ini tidak berarti bahwa ini adalah Scrum multi-tim. Kebutuhan untuk penskalaan datang hanya ketika sebagian besar organisasi mengerjakan satu produk dan dapat menyinkronkan beberapa Tim Scrumnya secara efektif.

Sebagian besar organisasi yang mengadopsi metode manajemen tangkas dalam skala besar memilih model SAFE, atau Scaled Agile Framework. Namun hari ini, kami tidak akan fokus pada AMAN tetapi kami akan membahas model berbeda yang disebut [dilindungi email] , karena menurut laporan State of Agile ke-15 dari tahun 2021, ini adalah pilihan terbaik kedua di antara bisnis yang memilih tangkas.

[dilindungi email]

Pada tahun 1996, pencipta Scrum, Jeff Sutherland dan Ken Schwaber, sedang mengerjakan sebuah proyek besar. Saat melakukannya, mereka mengalami kesulitan menjaga agar tim yang lebih kecil bekerja di Scrum tetap sinkron. Mereka menemukan cara untuk menskalakannya, yang akhirnya mereka sebut [dilindungi email]

Analog dengan Panduan Scrum resmi adalah Panduan [dilindungi email] , yang mendefinisikan cara kerja penskalaan ini sebagai:

Kerangka kerja di mana jaringan Tim Scrum beroperasi mengikuti Panduan Scrum untuk memecahkan masalah adaptif yang kompleks dan secara kreatif memberikan produk dengan nilai sebanyak mungkin.

Premis dasar [dilindungi email] adalah kesederhanaan dan efisiensi. Oleh karena itu, operasinya didasarkan pada arsitektur bebas skala. Dengan kata lain, ia menggunakan Scrum untuk menskalakan Scrum. Sedemikian rupa, tim scrum yang terdiri dari individu-individu yang bertindak sebagai Pemilik Produk, Scrum Master atau Pengembang menjadi Scrum of Scrums: sebuah tim yang terdiri dari tim-tim.

Scrum dari Scrum

Scrum of Scrums adalah tim scrum dengan orang-orang yang mengambil peran Scrum tradisional. Namun, karena tugas Scrum of Scrums adalah untuk mengintegrasikan hasil kerja dari beberapa Tim Scrum, maka diperlukan tambahan posting:

  • Tim Pemilik Produk – sekelompok Pemilik Produk yang bertemu untuk menyepakati prioritas dan menciptakan visi produk yang kohesif
  • Chief Product Owner – Pemilik Produk Scrum Team atau orang yang secara eksklusif menangani Scrum of Scrums
  • Scrum of Scrums Master – orang yang mengawasi efektivitas Scrum of Scrums.

Mereka bertemu di Acara Scrum yang sama dan menggunakan Artefak yang serupa.

Scaling Scrum

Penskalaan lebih lanjut dan masalah [dilindungi email]

Arsitektur bebas skala [dilindungi email] berarti memungkinkan penskalaan lebih dari sekali. Jika sebuah organisasi perlu mengoordinasikan tim dalam skala yang lebih besar, organisasi tersebut dapat menyiapkan Scrum of Scrums.

Namun, penskalaan Scrum, seperti metodologi manajemen lainnya memiliki kekurangan, dan dalam hal ini, mereka mirip dengan Tim Scrum dasar, hanya saja secara proporsional lebih besar. Itulah mengapa kami menyarankan untuk mengerjakan detail kolaborasi dalam setiap Tim Scrum sebelum memulai Scrum dalam skala yang lebih besar. Kami menyarankan penskalaan Scrum untuk tim berpengalaman yang memiliki pengetahuan dan pemahaman yang baik tentang nilai dan cara kerja Scrum.

scaling

Scaling Scrum – ringkasan

Scaling Scrum bukanlah permainan anak-anak. Ini membutuhkan Tim Scrum untuk mahir menerapkan prinsip-prinsip Scrum dan menyinkronkan tugas mereka dengan Tim Scrum lainnya. Oleh karena itu, pertanyaan mendasar yang harus dijawab adalah: Apakah penskalaan diperlukan? Hanya karena ada banyak Tim Scrum dalam suatu organisasi tidak secara otomatis berarti mengoordinasikan mereka akan membawa hasil yang lebih baik.

Jika sebuah organisasi memilih untuk meningkatkan Scrum, ia memperoleh arsitektur bebas skala yang dapat berhasil ditambah lebih lanjut. Namun, setiap augmentasi disertai dengan peningkatan tingkat kerumitan yang harus dihadapi oleh Tim Pemilik Produk, Kepala Pemilik Produk, dan Scrum dari Scrum Master.

Jika Anda menyukai konten kami, bergabunglah dengan komunitas lebah sibuk kami di Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 16. Scaling Scrum caroline becker avatar 1background

Pengarang: Caroline Becker

Sebagai Manajer Proyek, Caroline ahli dalam menemukan metode baru untuk merancang alur kerja terbaik dan mengoptimalkan proses. Keterampilan organisasi dan kemampuannya untuk bekerja di bawah tekanan waktu menjadikannya orang terbaik untuk mengubah proyek rumit menjadi kenyataan.

Lihat semua posting

Panduan Scrum:

  1. Daftar istilah dasar, peran dan pengertian
  2. Apa itu Scrum?
  3. Nilai scrum
  4. Bagaimana menerapkan Scrum di perusahaan Anda?
  5. Tim Scrum - apa itu dan bagaimana cara kerjanya?
  6. Siapa Pemilik Produk?
  7. Kesalahan paling umum dari Pemilik Produk
  8. Siapa Scrum Masternya?
  9. Karakteristik Scrum Master yang baik
  10. Kesalahan paling umum dari Scrum Master
  11. Statistik dan metrik apa yang harus dilacak oleh Scrum Master?
  12. Kerjasama antara Pemilik Produk dan Scrum Master
  13. Tim Pengembang di Scrum
  14. Kesalahan paling umum dari Pengembang
  15. Artefak scrum
  16. Scaling Scrum
  17. Sprint Backlog
  18. Apa itu Product Backlog?
  19. Apa itu Cerita Pengguna?
  20. Membuat Kisah Pengguna terbaik dengan INVEST
  21. Kesalahan Cerita Pengguna yang paling umum
  22. Kriteria Penerimaan Cerita Pengguna
  23. Estimasi dan Poin Cerita di Scrum
  24. Perencanaan Poker
  25. Game Estimasi Tim
  26. Mendefinisikan Kenaikan
  27. Acara Scrum
  28. Apa itu Sprint di Scrum?
  29. Komitmen Tim Scrum - Sasaran Produk, Sasaran Sprint, dan Definisi Penyelesaian
  30. Apa itu Grafik Burndown?
  31. Bagaimana cara membuat dan menafsirkan grafik burndown?
  32. Keuntungan dan kerugian dari grafik burndown
  33. Papan Kanban di Scrum dan Scrumban
  34. Kecepatan dalam Scrum - Kecepatan Tim Pengembang
  35. Scrum Harian
  36. Perencanaan Sprint
  37. Ulasan Sprint
  38. Apa itu Retrospektif Sprint?
  39. Kesalahan umum selama Sprint Retrospective
  40. Pemeliharaan Backlog Produk