My first blog
I dont know man
Read articleWriting
Notes from building software, learning in public, and the work behind the finished product.
All writing, newest first.
9 articles · 3 sources
I dont know man
Read article“Men don't cry” sounds like a small sentence. It is not. Repeated often enough, it teaches boys to...
Read articleI have tried complicated productivity systems before. Most of them lasted a week. The problem was not...
Read articleI first tried Elysia because I wanted to know whether Bun could make a small TypeScript API feel...
Read articleThe first useful thing Docker gave me was not “cloud-native architecture.” It was a boring promise:...
Read articleThe SSR/ISR/CSR comparison is useful, but the usual explanation often turns it into three competing...
Read articleI used to see the Software Development Life Cycle as a diagram for reports: requirements, design,...
Read articleMBKM Batch 6 gave me something coursework could not: six months of working inside a software team...
Read article*kanban ilustration Before joining BIGIO, I knew Kanban and Scrum mostly as definitions. During onboarding, the useful lesson was seeing how these ideas shape ordinary decisions: what to start, what to finish, when to ask for help, and how a team learns from work that did not go as planned. The board is a conversation, not decoration A Kanban board is useful when it shows the real state of work. If everything is “in progress,” the board is only reporting that the team has started too much. The most important habit is limiting work in progress. Finishing one task creates more value than opening five tasks and leaving all of them halfway done. A visible blocker is also better than a task that quietly stops moving. Scrum provides a rhythm Scrum adds a time boundary. A sprint gives the team a short planning horizon and regular moments to inspect the product and the way the team works. The ceremonies only help when each one answers a real question: • Sprint planning: what outcome can we realistically deliver? • Daily stand-up: what changed, and what is blocking progress? • Sprint review: does the result solve the stakeholder’s problem? • Retrospective: what should we change in the next cycle? When a meeting becomes a status performance for a manager, it has lost the point. Kanban and Scrum are not enemies Teams often borrow from both. They may plan in sprints while visualizing flow and limiting work in progress. The name “Scrumban” matters less than whether the combination solves a real coordination problem. Process should serve the team. The team should not spend its energy proving loyalty to a process. Where OKRs fit OKRs operate at a different level. Kanban and Scrum help organize delivery; an Objective and its Key Results explain the outcome the organization wants. A useful Key Result measures a change, not an activity. “Release four features” describes output. “Reduce the time required to complete onboarding from five days to two” describes an outcome the team can evaluate. What makes an Agile team An Agile team is not defined by sticky notes or a daily meeting. It is a group that can deliver a meaningful slice of work, receive feedback, and adapt without waiting for a long chain of handoffs. That requires more than developers. Product context, design, testing, operations, and stakeholder feedback all need a place in the loop. What I carried into my own work My practical version is simple: 1. Make work and blockers visible. 2. Finish before starting more. 3. Plan around an outcome, not a pile of tickets. 4. Keep feedback cycles short. 5. Change the process when it stops helping. Onboarding at BIGIO made these ideas less abstract. Agile is not about moving cards faster. It is about helping a team notice reality early enough to respond to it.What Onboarding at BIGIO Taught Me About Kanban, Scrum, and Agile Teams Before joining BIGIO, I knew Kanban and Scrum mostly as definitions. During onboarding, the useful lesson was seeing how these ideas shape ordinary decisions: what to start, what to finish, when to ask for help, and how a team learns from work that did not go as planned. The board is a conversation, not decoration A Kanban board is useful when it shows the real state of work. If everything is “in progress,” the board is only reporting that the team has started too much. The most important habit is limiting work in progress. Finishing one task creates more value than opening five tasks and leaving all of them halfway done. A visible blocker is also better than a task that quietly stops moving. Scrum provides a rhythm Scrum adds a time boundary. A sprint gives the team a short planning horizon and regular moments to inspect the product and the way the team works. The ceremonies only help when each one answers a real question: • Sprint planning: what outcome can we realistically deliver? • Daily stand-up: what changed, and what is blocking progress? • Sprint review: does the result solve the stakeholder’s problem? • Retrospective: what should we change in the next cycle? When a meeting becomes a status performance for a manager, it has lost the point. Kanban and Scrum are not enemies Teams often borrow from both. They may plan in sprints while visualizing flow and limiting work in progress. The name “Scrumban” matters less than whether the combination solves a real coordination problem. Process should serve the team. The team should not spend its energy proving loyalty to a process. Where OKRs fit OKRs operate at a different level. Kanban and Scrum help organize delivery; an Objective and its Key Results explain the outcome the organization wants. A useful Key Result measures a change, not an activity. “Release four features” describes output. “Reduce the time required to complete onboarding from five days to two” describes an outcome the team can evaluate. What makes an Agile team An Agile team is not defined by sticky notes or a daily meeting. It is a group that can deliver a meaningful slice of work, receive feedback, and adapt without waiting for a long chain of handoffs. That requires more than developers. Product context, design, testing, operations, and stakeholder feedback all need a place in the loop. What I carried into my own work My practical version is simple: 1. Make work and blockers visible. 2. Finish before starting more. 3. Plan around an outcome, not a pile of tickets. 4. Keep feedback cycles short. 5. Change the process when it stops helping. Onboarding at BIGIO made these ideas less abstract. Agile is not about moving cards faster. It is about helping a team notice reality early enough to respond to it. Optimizing Project Management with Kanban, Scrum, and Agile Teams Dalam lingkup manajemen proyek yang dinamis, organisasi selalu mencari metode untuk meningkatkan efisiensi, kolaborasi, dan mencapai tujuan. Dua pendekatan yang populer, yakni Kanban dan Scrum, bersama dengan penerapan tim Agile, telah terbukti efektif dalam mencapai sasaran-sasaran tersebut. Lebih lanjut, integrasi Objectives and Key Results (OKR) memberikan fokus tambahan pada usaha proyek. Kanban: Visualisasi Alur Kerja Dalam dunia manajemen proyek yang dinamis, terdapat dua pendekatan utama yang menjadi pilihan umum untuk meningkatkan efisiensi dan mencapai tujuan, yaitu Kanban dan Scrum. Kanban, dengan prinsip utama visualisasi alur kerja, mengelola pekerjaan dengan cara yang meminimalkan waktu siklus dan meningkatkan efisiensi. Kanban, baik fisik maupun digital, digunakan untuk memvisualisasikan tugas dan menggeser kartu tugas melalui kolom yang mewakili tahapan berbeda dalam alur kerja. Fleksibilitas waktu adalah salah satu ciri khas Kanban, di mana tugas dapat ditambahkan atau diambil kapan saja tanpa batasan siklus tertentu. Di sisi lain, Scrum menekankan pembagian pekerjaan menjadi iterasi waktu yang disebut sprint, biasanya berlangsung selama 2–4 minggu. Dalam pendekatan ini, pertemuan rutin seperti daily standup, sprint planning, sprint review, dan sprint retrospective menjadi kunci untuk memastikan transparansi dan adaptasi selama proyek. Scrum juga menciptakan struktur dengan menggunakan artefak proyek seperti Product Backlog, Sprint Backlog, dan increment. Seringkali, organisasi memilih untuk menggabungkan elemen-elemen dari Kanban dan Scrum, menciptakan pendekatan yang dikenal sebagai “Scrumban,” untuk memanfaatkan kelebihan dari kedua metode dan mencapai keseimbangan yang optimal antara fleksibilitas dan struktur waktu. Scrum: Pembagian Pekerjaan Menjadi Beberapa Waktu Scrum adalah suatu kerangka kerja manajemen proyek yang berbasis pada pendekatan Agile. Pendekatan ini dirancang untuk memungkinkan tim pengembangan mengatasi kompleksitas dan menghasilkan produk secara efektif sambil merespons perubahan kebutuhan pelanggan yang mungkin terjadi selama pengembangan. Contoh Implementasi Scrum: Tim Scrum: Sebuah tim Scrum terdiri dari anggota yang berdedikasi, termasuk Product Owner (pemilik produk), Scrum Master (pemimpin tim), dan anggota pengembangan. Product Backlog: Sebuah daftar prioritas yang berisi semua fitur, perubahan, dan pekerjaan yang harus dilakukan pada produk. Product Owner bertanggung jawab untuk memprioritaskan backlog. Sprint Planning: Pada awal setiap sprint, tim Scrum melakukan pertemuan sprint planning. Mereka merinci pekerjaan yang akan dilakukan selama sprint dan menentukan tujuan sprint. Daily Standup: Pertemuan harian yang singkat di mana anggota tim berbicara tentang kemajuan mereka, menyoroti hambatan, dan merencanakan pekerjaan selanjutnya. Sprint Review: Pertemuan setelah berakhirnya sprint untuk meninjau pekerjaan yang telah selesai, mendemonstrasikan produk yang dihasilkan, dan menerima umpan balik dari stakeholder. Sprint Retrospective: Pertemuan untuk mengevaluasi kinerja tim selama sprint, mengidentifikasi peluang perbaikan, dan membuat rencana untuk implementasi perubahan pada sprint berikutnya. Implementasi Scrum dapat berbeda-beda tergantung pada kebutuhan dan konteks proyek, namun, intinya adalah memberikan kerangka kerja yang fleksibel dan responsif untuk mengelola proyek pengembangan produk dengan cara yang efisien dan adaptif. Objectives and Key Results (OKR): Menetapkan Tujuan Ambisius dengan Hasil yang Terukur OKR, atau Objectives and Key Results, mewakili metodologi yang mengintegrasikan tujuan tim dan individu dengan tujuan yang menantang dan ambisius, diukur dengan hasil yang spesifik. Mari kita lihat contoh praktis: Tujuan: Mencapai dampak karbon terendah dalam industri. Hasil Kunci 1: Membentuk rantai pasokan dan infrastruktur pengiriman tanpa limbah. Hasil Kunci 2: Mengganti 100% kerugian karbon untuk emisi karbon dioksida yang dihitung. Hasil Kunci 3: 25% dari material dapat dijadikan kompos. Hasil Kunci 4: 75% bahan dapat terurai secara hayati. Hasil yang terukur ini membimbing tim untuk mencapai tujuan mereka, memberikan arah yang jelas untuk keberhasilan. Tim Agile: Keahlian Multiguna Mendorong Keberhasilan Tim Agile, terdiri dari individu dengan berbagai keahlian dan berdedikasi untuk kesuksesan proyek, memainkan peran kunci dalam fase pengembangan, pengujian, dan pengiriman. Biasanya terdiri dari 5 hingga 10 anggota yang dipilih karena keahlian mereka di bidang bisnis tertentu, tim Agile disusun untuk mencapai tujuan perusahaan atau tujuan bisnis tertentu. Struktur organisasinya dan tanggung jawabnya dirancang dengan cermat, memfasilitasi kolaborasi lintas fungsi untuk mencapai tujuan bersama. Contoh Skenario: Stakeholder internal bertindak sebagai pihak yang meminta proyek, tetap terinformasi tentang kemajuan saat mereka berkoordinasi dengan tim lain untuk peluncuran atau pembaruan. Umpan balik mereka yang berharga memengaruhi arah tugas, memastikan keselarasan dengan tujuan proyek secara keseluruhan. Secara keseluruhan, kombinasi Kanban, Scrum, OKR, dan tim Agile membentuk suatu pendekatan yang menyeluruh dalam manajemen proyek. Pendekatan ini membawa adaptabilitas, transparansi, dan fokus pada tujuan, memberikan organisasi alat yang dibutuhkan untuk berhasil menghadapi tantangan kompleks dalam pengembangan proyek modern.
Read on Medium