فصل ۹ — Kanban: Flow، Metrics و Emergent Behavior | Learning Agile

فصل ۹ — Kanban: اندازه‌گیری Flow، Little’s Law و رفتار Emergent

این بخش ادامهٔ Core Practiceهای Kanban است. Team با Visualize کردن Workflow و Limit کردن WIP فقط شروع کار را انجام داده است؛ اکنون باید Flow را Measure و Manage کند، Process Policyها را Explicit سازد و از Feedback Loopها برای Evolution System استفاده کند.

Measure and Manage Flow

Flow نرخ حرکت Work Itemها در System است. وقتی Team Delivery Pace مناسب و مقدار Feedback قابل‌مدیریت پیدا می‌کند، Flow افزایش می‌یابد. کاهش Unevenness و Overburdening باعث می‌شود افراد Task را تمام کنند و به بعدی بروند. برعکس، وقتی Work پشت Stage خاصی جمع می‌شود، Flow قطع یا کند می‌شود.

تجربهٔ Flow برای اعضا آشناست: هر روز حس می‌کنید Work ارزشمند انجام می‌دهید، Waiting کم است و Blockerها زود برطرف می‌شوند. نبود Flow نیز آشناست: انگار در گل گیر کرده‌اید؛ برای Decision، Approval، Ticket یا Dependency مدام منتظرید. Project شاید روی Plan «۹۰٪ کامل» باشد اما احساس می‌شود هنوز «۹۰٪ باقی مانده» است. User نیز نتیجه را در Lead Time بالا می‌بیند.

هدف Kanban افزایش Flow و درگیرکردن کل Team در این Improvement است.

CFD و WIP Area Chart برای Measure/Manage Flow

Kanban Board Problem امروز را Visible می‌کند؛ WIP Limit کمک می‌کند همان لحظه Work را به Stage مناسب Redirect کنید. اما برای فهم اینکه در طول زمان Flow واقعاً بهتر شده یا نه، Lean Thinking دوباره Measurement را وارد می‌کند.

Cumulative Flow Diagram (CFD)

CFD شبیه WIP Area Chart است، با یک تفاوت مهم: Work Itemهای Done از نمودار خارج نمی‌شوند؛ در آخرین Stripe تجمع پیدا می‌کنند. بنابراین تمام Stripeها در طول زمان به سمت بالا رشد می‌کنند.

در Chapter 8، Stripeهای WIP Area Chart با Value Stream Stageها متناظر بودند. در این فصل، Stripeهای CFD و WIP Chart با Columnهای Kanban Board متناظرند.

CFD می‌تواند سه Measurement مهم را نشان دهد:

• Arrival Rate (λ): تعداد Work Itemهایی که در واحد زمان وارد Workflow می‌شوند.
• Inventory (L): تعداد کل Work Itemهای حاضر در System.
• Lead Time (W): متوسط زمانی که یک Work Item در System باقی می‌ماند.

همهٔ CFDها الزاماً Lineهای Arrival/Inventory ندارند، اما این Lineها برای درک Stability بسیار مفیدند.

ساخت CFD

1. تعداد Work Itemهای هر Column را هر روز ثبت کنید.
2. تعداد Itemهایی که وارد Column اول شده‌اند = Arrival Rate روزانه.
3. مجموع Itemهای همه Columnها = Inventory روزانه.
4. برای هر روز نقطه‌ای برای Arrival و Inventory ثبت و Line Chart بسازید.
5. ابزارهایی مثل Spreadsheet می‌توانند Linear Trendline اضافه کنند.

اگر Long-Term Trendlineهای Arrival و Inventory صاف و افقی باشند، System Stable است. اگر یکی Tilt داشته باشد، Value در حال تغییر است و System هنوز Stable نیست.

در Figure 9-10 منبع، Inventory نزولی و Arrival Rate صعودی است؛ بنابراین نمی‌توان Average Lead Time بلندمدت را معتبر محاسبه کرد. اگر Arrival بیشتر از خروجی شود، Inventory بعداً دوباره رشد می‌کند و Team همان حس «فرو رفتن در گل» را تجربه خواهد کرد.

راه Stabilize کردن System همان ابزار آشناست: WIP Limit را Experiment کنید تا Rate ورود و Rate Completion در بلندمدت Balance شوند.

Little’s Law

وقتی System Stable شد، رابطه‌ای ساده و اثبات‌شده میان سه Variable وجود دارد. این قانون از Queueing Theory می‌آید و به نام John Little، که آن را در دههٔ ۱۹۵۰ مطرح کرد، شناخته می‌شود:

L = W × λ

که در آن:

• L = Average Long-Term Inventory
• λ = Average Arrival Rate
• W = Average Lead Time

برای محاسبه Lead Time:

W = L ÷ λ

این فقط Heuristic نیست؛ در Stable System قانون ریاضی برقرار است. بنابراین اگر Inventory و Arrival Rate را Measure کنید، می‌توانید Average Lead Time را محاسبه کنید.

Lead Time Measurement مهم است چون به Experience User نزدیک است: Delivery سریع رضایت می‌آورد، Delay طولانی Frustration ایجاد می‌کند. David Anderson همچنین رابطهٔ Lead Time طولانی با Quality بدتر را گزارش می‌کند: در نمونه‌ای که در کتاب او نقل شده، افزایش حدود ۶٫۵ برابر Average Lead Time با افزایش بیش از ۳۰ برابر Initial Defect همراه بوده است. Longer Lead Time معمولاً از WIP بیشتر می‌آید؛ بنابراین Reduction WIP یک Leverage Point برای Quality نیز هست.

نتیجهٔ عملی Little’s Law برای Kanban مهم است: اگر System Stable باشد، با محدودکردن Work جدید و کنترل Inventory می‌توان Lead Time Customer را کاهش داد.

Experiment با WIP Limit: مثال مطب پزشک

برای ملموس‌کردن CFD، کتاب یک Doctor’s Office را مثال می‌زند. Appointment صبح نزدیک Opening Time Wait کمی دارد، اما هرچه روز جلو می‌رود Waiting Room شلوغ‌تر می‌شود. این نشانهٔ Unstable System است.

Workflow:

1. Patient وارد Waiting Room می‌شود.
2. Nurse او را به Exam Room می‌برد، Weight/Blood Pressure/Temperature را می‌گیرد.
3. Patient در Exam Room برای Doctor منتظر می‌ماند.
4. Doctor Patient را می‌بیند و سپس Item از System خارج می‌شود.

Office پنج Exam Room و دو Doctor دارد. این‌ها Natural WIP Limit هستند: بیش از ۵ Patient نمی‌تواند در Exam Room و بیش از ۲ Patient هم‌زمان نزد Doctor باشد.

Staff هر ۱۵ دقیقه تعداد Patientهای Arrival و Inventory را ثبت می‌کند. Kanban Board سه Column اصلی دارد: Waiting Room، Exam Room و With Doctor. Sticky هر Patient با حرکت واقعی او جابه‌جا می‌شود.

CFD نشان می‌دهد Arrival Rate تقریباً Stable است چون Appointmentها با Rate ثابت Schedule شده‌اند و Booking ساعت ۴ عصر متوقف می‌شود؛ اما Inventory Trend رو به بالا است، چون Waiting Room در طول روز پرتر می‌شود.

Team باید System را Stabilize کند. به‌جای اینکه Doctorها را مجبور کند «سریع‌تر» کار کنند، Staff با Schedule Rate و WIP Experiment می‌کند.

مثال عددی Little’s Law

اگر:

λ = 11 بیمار در ساعت
L = 7 بیمار

آنگاه:

W = 7 ÷ 11 = 0.63 ساعت ≈ 37 دقیقه

اگر با Experiment، Arrival به ۱۰ Patient/hour برسد و Inventory متوسط به ۴ Patient کاهش یابد:

W = 4 ÷ 10 = 0.4 ساعت = 24 دقیقه

فقط با Schedule کردن یک Patient کمتر در ساعت، Average Waiting تقریباً ۱۵ دقیقه کاهش پیدا می‌کند. نکته این است که Little’s Law حتی اگر Staff آن را محاسبه نکند باز بر Stable System حاکم است.

Little’s Law و Software Flow

کتاب سپس به Teamی برمی‌گردد که هر سه هفته برای Production Release با Support Work سنگین روبه‌رو می‌شود. در ظاهر همه Workها در نهایت Done می‌شوند، اما هر ماه Stress بیشتر می‌شود. Kanban Board روزمره شاید اغلب Healthy به نظر برسد، چون Spike Support بعداً ناپدید می‌شود؛ اما Team احساس می‌کند System در Quicksand فرو می‌رود.

WIP Area Chart Problem را نشان می‌دهد: پس از هر Release، Stripe یک Column کمی ضخیم‌تر باقی می‌ماند. یعنی Work با Rate بیشتری وارد آن Stage می‌شود تا خارج شود. Long-Term Inventory بالا می‌رود و System Stable نیست.

WIP Limit مناسب اجازه نمی‌دهد Work اضافه بی‌حد وارد Stage Overburdened شود. Spikeهای Release هنوز وجود دارند، اما Inventory بعد از هر Spike بیشتر نمی‌شود. وقتی Column به Limit می‌رسد، Team Focus را به Work Itemهای Stageهای دیگر منتقل می‌کند.

Kanban Team Limit را یک بار تعیین و رها نمی‌کند. یک Hypothesis می‌سازد، WIP Limit را تغییر می‌دهد، Measurement می‌گیرد و تا رسیدن به Flow بهتر Experiment را ادامه می‌دهد. این اجرای واقعی Improve Collaboratively, Evolve Experimentally است.

Support Work را First-Class Work Item کنید

وقتی Support Task روی Board به Work Item واقعی تبدیل می‌شود، دیگر «کار اضافه‌ای که باید somehow کنار Development جا شود» نیست. Team آن را درست Prioritize می‌کند. این کار ممکن است در بلندمدت Support Issue را هم کم کند، چون برخی Issueها محصول Technical Debtی هستند که قبلاً برای رسیدن به Unrealistic Backlog ساخته شده بود.

اگر Support همه Slotهای Queue را پر کند، معنایش این است که Organization عملاً Support را بالاتر از Development Prioritize کرده است. این شاید برای Developer خوشایند نباشد، اما از وضعی بهتر است که Team هم‌زمان مسئول تمام Support و تمام Development باشد و برای Failure هر دو Blame شود.

Visible کردن این Choice Magical Thinking Boss را سخت‌تر می‌کند. اگر Software کمتری Deliver می‌شود، Progress Measurement واقعی‌تر است. Boss برای Software بیشتر باید یا Priority را تغییر دهد یا Capacity اضافه کند؛ نمی‌تواند Pretend کند همان Team بدون Cost هر دو Workload را کامل انجام می‌دهد.

Managing Flow با WIP Limit به‌طور طبیعی Slack می‌سازد

Developer به Slack یا Wiggle Room نیاز دارد تا Design خوب، Testing و فکرکردن ممکن باشد. Atmosphere «همیشه عقبیم، همیشه عجله داریم» Creativity و Quality Practice را نابود می‌کند و Technical Debt می‌سازد. XP به همین دلیل Slack را Practice مهم می‌داند.

Kanban نیز Slack را ارزشمند می‌داند، اما آن را با WIP Limit و Delivery Cadence به‌صورت Systemic ایجاد می‌کند.

Team Kanban ممکن است به‌جای Strict Timebox، Delivery Cadence داشته باشد؛ مثلاً هر شش هفته Release کند، اما به Set مشخصی از Work Itemها Commitment ندهد. اگر Flow سالم باشد، در هر Cadence مجموعه‌ای از Done Work Itemها به‌طور طبیعی آمادهٔ Release می‌شود.

قبل از WIP Limit، Emergency Requestها و Last-Minute Changeها دائماً به Team نفوذ می‌کنند و Slack برنامه‌ریزی‌شده را می‌خورند. بعد از WIP Limit و Agreement واقعی Stakeholderها، Request جدید هنوز می‌آید اما وارد Queue می‌شود؛ Team مجبور نیست Impact آن را همان لحظه Absorb کند.

به همین دلیل بعضی Teamهای Kanban روی تقریباً همهٔ Columnها WIP Limit می‌گذارند، حتی Ready for Release. اگر Done Work زیادی پشت Release جمع شود، شاید Signal دهد Delivery Cadence باید کوتاه‌تر شود.

WIP Limitها همچنین یک احساس مهم ایجاد می‌کنند: Relief. اعضا می‌دانند Work بی‌نهایت پشت سرشان جمع نخواهد شد. اگر Chaos دوباره وارد System شود، Measurement آن را Visible می‌کند و Limit/Cadence دوباره تنظیم می‌شود.

Make Process Policies Explicit

Effective Scrum Team معمولاً توضیح نسبتاً مشترکی از «چطور Software می‌سازیم» دارد، چون Ruleهای Scrum ساده، مشترک و Practiceشده‌اند. Team Waterfall نامؤثر ممکن است Fractured Perspective داشته باشد: Developer فقط Coding را توضیح دهد، Tester فقط Testing را، BA فقط Requirement را و Project Manager فقط Planning/Tracking را.

Process پیچیده گاهی Necessary است و گاهی Wasteful Bureaucracy. مثلاً Policy نانوشته‌ای که هر تغییر Specification را با تعداد زیادی Email و Approval همراه می‌کند ممکن است Regulatory Requirement باشد، یا فقط CYA Habit قدیمی.

Kanban Practice Make Process Policies Explicit می‌گوید Rule واقعی را بنویسید و به همهٔ افراد تحت‌تأثیر نشان دهید. همین Visibility اغلب باعث می‌شود Policy بی‌منطق فوراً Question شود.

Explicit Policy لازم نیست Wiki عظیم باشد:

• WIP Limit بالای Column.
• Definition of Done در پایین Column.
• Exit Criteria برای Move به Stage بعد.
• Rule مربوط به Urgent Item یا Backward Move.

وقتی Policyها Collaboratively ساخته و Experimentally Evolution شده باشند، Team می‌فهمد چرا Rule وجود دارد.

بسیاری از Bureaucracyها دفاعی شکل می‌گیرند. Business Analystی که به خاطر Last-Minute Change دائماً Blame می‌شود ممکن است Change-Control Process سنگینی بسازد تا Paper Trail و CYA داشته باشد. هدف Kanban سرزنش او نیست؛ Visible کردن System است تا Root Cause دفاعی آن Rule فهمیده شود.

WIP Limit نیز Policy است و فقط وقتی کار می‌کند که همه Agreement را Honor کنند. Written Policy روی Board به Team Ground محکمی می‌دهد: اگر Manager Urgent Request دارد و Queue Full است، باید Item دیگری خارج یا Reprioritize شود. چون Manager از قبل Policy را پذیرفته، Discussion Objectiveتر است.

Emergent Behavior with Kanban

«هرچه Grip خود را محکم‌تر کنی، Tarkin، Star Systemهای بیشتری از میان انگشتانت فرار خواهند کرد.» — Princess Leia

Command-and-Control برای Doctor’s Office احتمالاً از Doctorها Estimate دقیق Duration هر Patient می‌خواهد و Schedule کاملاً Micromanaged برای Room، Nurse و Doctor می‌سازد. این ممکن است ظاهراً Control بدهد، اما Doctor در Estimation تخصص ندارد و Patientها نیز Variation طبیعی دارند. Kanban به‌جای Control جزئی، System Aggregate را Measure می‌کند، Variability Work Item را می‌پذیرد و muda/mura/muri را کاهش می‌دهد.

وقتی Team Process را تدریجی Improve می‌کند، رفتار Company نیز می‌تواند بدون دستور مستقیم تغییر کند؛ این همان Emergent Behavior است.

مثال درخواست‌های چند Manager

Team از چند Manager Request می‌گیرد و هر Manager Request خودش را مهم‌ترین می‌داند. قبل از Kanban، Team میان Priorityهای متضاد گرفتار و در صورت Delay Blame می‌شود.

با Visualize، همه Requestها Sticky در Column اول می‌شوند. اگر Demand از Capacity بیشتر باشد، Pile Up برای همه Visible است. Managerها روی WIP Limit آن Column Agreement می‌کنند.

تا وقتی Limit پر نشده، رفتار قدیم ادامه دارد. اما وقتی Limit پر شد، Manager جدید دیگر نمی‌تواند Sticky اضافه کند. باید Item دیگری را خارج کند؛ اگر نمی‌خواهد Item خودش را حذف کند، باید با Managerهای دیگر مذاکره کند.

این تغییر مهم است: Manager به‌جای Blame Team، با Constraint System روبه‌رو می‌شود و با Managerهای دیگر Solution پیدا می‌کند. Overburdening دیگر «Problem Team» نیست؛ Problem مشترک System است. شاید Managerها Prioritization Meeting یا Horse Trading راه بیندازند. اما Team دیگر Expected نیست Work بیشتر از Capacity انسانی را انجام دهد.

قبل از WIP Limit، Magical Thinking اجازه می‌داد Work نامحدود Push شود و Promiseهای غیرواقعی ساخته شود. Explicit Policy این Magical Thinking را محدود می‌کند و Behavior جدید بدون دستور مستقیم Emerges. Slack Team افزایش می‌یابد و Energy‌ای که قبلاً صرف Negotiation فردی می‌شد روی Work اصلی قرار می‌گیرد.

پرسش‌های متداول

آیا WIP Limit و Explicit Policy واقعاً می‌توانند رفتار Organization را تغییر دهند؟

بله. ریشهٔ Kanban در Toyota است؛ واژهٔ Japanese آن به معنی Signal Card/Signboard است. Station اسمبلی تعداد مشخصی Card برای Part داشت. وقتی Part کم می‌شد، Card در Cart خالی قرار می‌گرفت و برای هر Card یک Part جدید Replenish می‌شد. تعداد Cardها خود WIP Limit بود و Pull Signal تولید می‌کرد.

هدف مقایسهٔ Developer با Assembly Worker نیست؛ Parallel اصلی Signal است: Sticky روی Board مثل Kanban Card نشان می‌دهد چه Workی Ready است.

کتاب مثال Minnesota State Fair را می‌آورد. Vendor Grilled Corn دو Station دارد: Station اول Money را می‌گیرد و Ticket می‌دهد؛ Station دوم Ticket را گرفته Corn می‌دهد. Ticket ظاهراً Step اضافی است، اما در واقع Kanban است. Grill Station فقط تعداد مشخصی Ticket در Circulation نگه می‌دارد، بنابراین Line نزد Grill Overload نمی‌شود. در Peak Time Ticket و Corn روی Grill افزایش می‌یابد؛ پس از Peak کاهش پیدا می‌کند. WIP Limit با Variability تنظیم می‌شود.

Vendor Deep-Fried Olive با Line بلند Push System دارد: Demand مستقیم به Worker Push می‌شود. Corn Vendor Pull System دارد: Grill Station با Ticket تعداد Customerهایی را که به Step بعد Pull می‌شوند کنترل می‌کند. Little’s Law توضیح می‌دهد چرا محدودکردن Arrival پس از Payment، Waiting Time را کاهش می‌دهد.

Software همیشه Problem متفاوت دارد؛ این Pull System چطور به Development مربوط است؟

Software به‌شدت Changeable است و بنابراین Variability حتی بیشتر از Manufacturing دارد. WIP Limit، Queue Size، Blocker Clustering و Root-Cause Improvement راه‌های کاهش Variability مضرند.

Waterfall معمولاً با Change Control Process Variability را مهار می‌کند: Change کند، Analyze و Approve می‌شود. این Risk را کم می‌کند اما می‌تواند Team را مجبور کند چیزی را بسازد که ابتدا Plan شده حتی اگر User Value تغییر کرده باشد.

Traditional Project Manager خوب نیز Slack ایجاد می‌کند، اما اغلب با Schedule Buffer/Padding. Kanban ترجیح می‌دهد Variability را Hide نکند، چون See the Whole نیازمند Information آشکار است. به‌جای Buffer پنهان، Root Cause Unevenness آشکار و Flow با Policy/WIP کنترل می‌شود.

اگر Manager WIP Limit را نپذیرد چه؟

بدون Agreement Stakeholder، Limit قابل اتکا نیست. Manager ممکن است آن را «Underallocation» ببیند، از Slack بترسد یا به دلیل Pressure واقعی Business پذیرش نداشته باشد. حذف Limit می‌تواند Kanban Effort را از پایه ضعیف کند.

در چنین Contextی Scrum ممکن است مناسب‌تر باشد: Timebox Predictable و Scope توسط Product Owner مدیریت می‌شود. Backlog داخل Project است و Product Owner Authority برای جذب Variability دارد. Kanban Queue/Buffer بیرون Project را هم درگیر می‌کند و Customer/Manager باید WIP Limit را مستقیماً قبول کند؛ در مقابل Control بیشتری روی ترتیب Work در Just-in-Time Delivery دارد.

اگر Kanban Exploration در نهایت Team را به Scrum برساند، این Failure نیست؛ یک Stable System با Improvement Culture نتیجهٔ خوبی است.

Kanban Board شبیه Project Management Tool است؛ چرا Kanban Project Management نیست؟

Board برای Understand و Visualize Workflow است، نه برای شکستن Work Item به Task و Assign کردن Actionها. Board در Work-Item Level می‌ماند. اگر Team Task Board، Gantt Chart یا Tool Project Management دیگری دارد، همچنان می‌تواند آن را استفاده کند.

مزیت Kanban این است که Board دائماً با Reality Update می‌شود؛ برخلاف Survey/Interviewهای Process Improvement سنتی که افراد ناخودآگاه Successها را بهتر به یاد می‌آورند و Failureها را کم‌رنگ می‌کنند. CFD نیز Flow را به‌صورت Objective Measure می‌کند.

کارهایی که امروز می‌توانید انجام دهید

• اگر امروز Kanban Board بسازید، Columnهای واقعی Workflow چه هستند؟ Value Stream Map می‌تواند کمک کند.
• Candidate مناسب WIP Limit را پیدا کنید؛ فقط Stickyهای همان Column را بشمارید و Starting Limit احتمالی را تخمین بزنید.
• مشخص کنید برای Agreement روی WIP Limit باید با چه Stakeholderهایی صحبت شود.
• یک Board ساده یک هفته Track کنید و CFD بسازید؛ آیا Inventory Stable است؟ Arrival Rate چطور؟

منابع معرفی‌شده

• Kanban: Successful Evolutionary Change for Your Technology Business — David J. Anderson، Blue Hole Press، 2010.
• Lean Software Development: An Agile Toolkit — Mary و Tom Poppendieck، Addison-Wesley، 2003؛ برای Systems Thinking.

Coaching Tips

• Kanban با Lean Mindset شروع می‌شود؛ Coaching Lean فصل ۸ مقدم است.
• بزرگ‌ترین مانع Adoption این است که Team Kanban را Project Management System بداند. Coach باید تفاوت «Understand System» و «Manage Task» را روشن کند.
• Early Commitment و Waste ناشی از آن را Visible کنید؛ Team را به Options و Last Responsible Moment هدایت کنید.
• Managerهای نگران یا گرفتار Magical Thinking ممکن است Date Commitment زودهنگام بخواهند؛ کمک کنید فقط Commitment واقعاً لازم ساخته شود.
• Systems Thinking پایهٔ Kanban است. Kanban Board نخستین ابزار خوب برای جداکردن ذهنی «Cogهای Process» از انسان‌هایی است که در System کار می‌کنند.

شکل‌ها و تصاویر منبع

تصاویر زیر از صفحات مربوط به همین مقاله در PDF اصلی استخراج و به‌صورت دادهٔ داخلی Base64 جاسازی شده‌اند.