در قسمت شانزدهم که با اُرُد سمسارزاده عزیز در مورد SAFe صحبت کردیم، موضوعی مطرح شد که حتی خود مرا هم شوکه کرد؛ کانبان فریم‌ورک اجایل نیست اما به افزایش چابکی کمک می‌کند. این بار به صورت حضوری با اُرُد به عنوان مدرس رسمی کانبان همراه شدیم و درباره‌ی این سوال گفتگو کردیم:
اگر کانبان فریم‌ورک اجایل نیست پس واقعاً چیست و چطور عمل می‌کند؟
مهمان: اُرُد سمسارزاده، مدرس رسمی کانبان از استرالیا
اجرا: پدرام کشاورزی، اجایل کوچ و اسکرام مستر
تدوین: پانته‌آ شهریاری
طراح کاور: سید محمدحسین بطحایی
سلام به همه شنونده‌های عزیز. من پدرام کشاورزی هستم و شما به پادکست «اجایل گپ» گوش می‌دهید.
اگر یادتان باشد، در اپیزود شانزدهم با حضور آقای اورود سمسار درباره‌ی موضوعات مختلف صحبت کردیم و در میانه‌ی بحث، اشاره‌ای هم به «کانبان (Kanban)» شد. ایشان تأکید کردند که کانبان را نباید جزو «فریم‌ورک‌های اجایل (Agile Frameworks)» به حساب آورد. همین شد که تصمیم گرفتیم دوباره اورود را دعوت کنیم تا توضیح بیشتری درباره‌ی این نکته بدهد. خوشبختانه این بار ایشان در ایران حضور دارند و توانستیم گفت‌وگو را در استودیو ضبط کنیم؛ به همین دلیل کیفیت صدا هم بهتر از اپیزودهای قبلی است.
اورود جان، خیلی خوش آمدید.
– مرسی پدرام، من هم خوشحالم که اینجا هستم. فقط لازم است همان ابتدا روشن کنم: جمله‌ای که قبلاً گفتم این بود که «کانبان یک فریم‌ورک اجایل نیست». امروز هم به‌عنوان «Accredited Kanban Trainer» صحبت می‌کنم؛ یعنی کسی که طبق استانداردهای «Kanban University» آموزش می‌دهد. پس هر چه می‌گویم مبتنی بر همان مراجع رسمی است.
بسیار عالی. اجازه دهید بحث را از همین‌جا ادامه بدهیم.
در اپیزود قبل وقتی از «SAFe» صحبت می‌کردیم، برای مقدمه اشاره کردم که «Agile» در اصل چیست و بعد سراغ فریم‌ورک‌ها رفتم. همان‌طور که می‌دانید، فریم‌ورک‌ها مانند «Scrum» یا «SAFe» برای ما یک چارچوب مشخص تعریف می‌کنند: تعداد اعضای تیم، نقش‌ها، اندازه‌ی اسپرینت، و بسیاری از قواعد دیگر. این چارچوب‌ها به‌طور مستقیم بر مبنای ارزش‌ها و اصول «Agile Manifesto» طراحی شده‌اند.
اما کانبان رویکرد متفاوتی دارد. کانبان یک «روش کاری (Method)» است نه فریم‌ورک. یعنی شما را مجبور به تغییر ساختار سازمان یا تعریف نقش‌های جدید نمی‌کند. تمرکز کانبان روی بهبود «جریان کار» است: اینکه نیاز مشتری چه‌طور وارد سیستم می‌شود، چه مسیری را طی می‌کند و ما چطور می‌توانیم این مسیر را بهینه کنیم. مهم‌تر اینکه، کانبان خودش را محدود به مانیفست اجایل نمی‌داند؛ یعنی الزاماً قرار نیست همه‌چیز را با همان چارچوب‌ها تعریف کند.
در بسیاری از منابع معتبر، گاهی کانبان را اشتباهاً یک فریم‌ورک اجایل معرفی کرده‌اند. من هم باید اعتراف کنم که در اپیزود قبلی پادکست، همین اشتباه رخ داد. بنابراین اینجا اصلاح می‌کنم: کانبان یک فریم‌ورک نیست؛ یک روش است. خوشحالم که با این گفت‌وگو، فرصت یادگیری دوباره برای من و شنونده‌ها فراهم شد.
از صحبت‌های شما یک نکته مهم هم برداشت کردم: «Agility» یا «چابکی» یعنی توانایی سازمان در پاسخ‌دادن به نیاز مشتری در زمان درست. به زبان ساده:
Deliver the right work to the right customer at the right time
نکته‌ای که باید در تعریف «چابکی (Agility)» در نظر داشته باشیم این است که صرفاً «زودتر تحویل دادن» به‌معنای بهتر بودن نیست. اگر مشتری خدمتی را برای هفته‌ی آینده می‌خواهد، تحویل آن دو روز زودتر لزوماً ارزشی ایجاد نمی‌کند. بنابراین مهم‌ترین معیار این است که «نیاز مشتری دقیقاً در زمان مورد انتظارش» برآورده شود.
از این‌رو، نخستین کاری که باید در هر سیستم انجام دهیم، اندازه‌گیری مدت‌زمانی است که از لحظه‌ی طرح درخواست مشتری تا تحویل آن سپری می‌شود. این همان «زمان تحویل (Lead Time)» است. هرچه بتوانیم این زمان را کاهش دهیم، سطح چابکی بالاتر خواهد رفت. اما کافی نیست که صرفاً زمان کوتاه شود؛ سیستم باید «قابل پیش‌بینی (Predictable)» و «پایدار (Sustainable)» هم باشد.
یک سیستم پایدار یعنی سیستمی که اعضای آن مجبور نباشند به‌طور مداوم ۱۲ یا ۱۵ ساعت در روز کار کنند. زیرا چنین فشاری تنها در کوتاه‌مدت ممکن است نتیجه بدهد، اما به‌سرعت فرسودگی ایجاد می‌کند و افراد سازمان را از بین می‌برد. درحالی‌که هدف، ایجاد سیستمی است که همواره بتواند در بازه‌های زمانی قابل پیش‌بینی، نتایج مورد انتظار مشتری را تحویل دهد.
اینجا باید توجه داشت که بحث ما درباره‌ی «کار دانش‌محور (Knowledge Work)» است، نه کار دستی یا مکانیکی. در کار دستی، خروجی تا حد زیادی قابل تخمین است: مثلاً یک کارگر می‌تواند در هر ساعت ۱۰ پیچ ببندد یا یک ماشین می‌تواند هزار پیچ را در همان زمان محکم کند. اما در کار دانش‌محور، خروجی همواره با عدم قطعیت همراه است.
چرا؟ چون دانش هر فرد یکتا است. دانش من با دانش شما—even درباره‌ی موضوع واحد—متفاوت است. افزون بر این، عوامل انسانی هم دخیل هستند: یک روز حال فرد خوب است و بهره‌وری بالاتری دارد، روز دیگر به‌دلیل فشارهای شخصی یا محیطی تمرکز کافی ندارد. بنابراین کار دانش‌محور به‌طور ذاتی «غیرقابل پیش‌بینی» است.
حال چالش این است: چگونه می‌توان در محیطی که پر از ابهام و غیرقابل پیش‌بینی است، سیستمی طراحی کرد که «پایدار و قابل پیش‌بینی» باشد؟ این همان چیزی است که کانبان (Kanban) به آن می‌پردازد. کانبان به ما کمک می‌کند تا با طراحی جریان کار، کاری که وارد سیستم می‌شود به شکلی روان حرکت کند، به انجام برسد و در زمان مناسب به مشتری تحویل داده شود. در این مسیر، می‌توانیم سیستم را بهینه‌سازی کنیم تا «زمان تحویل (Lead Time)» کاهش یابد و در نتیجه چابکی سازمان بالاتر برود.
برای ورود به بحث کانبان، لازم است ابتدا مفهوم «دانش (Knowledge)» را روشن کنیم. ما سه سطح داده‌ای داریم.
فرض کنید کسی بگوید: «من ۲۰ سالم است.» منِ اورود به‌عنوان فردی بزرگسال، این را نشانه‌ی جوانی می‌دانم و می‌گویم: «چه خوب، تو جوان هستی.» اما اگر همین فرد نزد یک کودک پنج‌ساله چنین حرفی بزند، آن کودک می‌گوید: «تو خیلی پیر هستی!» درواقع، «۲۰ سال» نه پیر است و نه جوان. تفاوت در «تجربه» و «برداشت» ما از این داده است.
به همین دلیل، میان «دیتا (Data)» و «اینفورمیشن (Information)» و «نالج (Knowledge)» تفاوت وجود دارد. داده‌ها خام و بدون معنا هستند؛ وقتی آنها را در یک «بافت (Context)» قرار می‌دهیم، به «اطلاعات» تبدیل می‌شوند؛ و زمانی که این اطلاعات با تجربه و درک شخصی آمیخته می‌شود، «دانش» شکل می‌گیرد.
دانش هر فرد منحصربه‌فرد است. تجربه‌ی من اورود تنها متعلق به من است و هیچ‌کس دیگر دقیقاً همان تجربه را ندارد. به همین دلیل است که «کار دانش‌محور (Knowledge Work)» ارزشمند می‌شود. اگر فردی از یک سیستم خارج شود، فقط یک نفر را از دست نداده‌ایم؛ بلکه دانش او نیز همراهش از دست می‌رود. بنابراین، سیستم آسیب می‌بیند.
از همین رو، کانبان (Kanban) به‌دنبال ساخت سیستمی پایدار (Sustainable) است؛ سیستمی که افراد در آن باقی بمانند، احساس فرسودگی نکنند و صرفاً به‌دلیل نادیده‌گرفته‌شدن یا فشار بیش از حد، سازمان را ترک نکنند.
هدف دوم کانبان این است که بدون محدود کردن خود به «مانیفست اجایل (Agile Manifesto)»، امکان افزایش چابکی را فراهم آورد. این نکته را من بارها تأکید کرده‌ام؛ حتی چند هفته پیش در یک گفت‌وگوی زنده‌ی انگلیسی در یوتیوب نیز همین موضوع را بیان کردم. در همان‌جا هم گفتم که احتمالاً چنین سخنانی برایم مخالفان زیادی ایجاد می‌کند. در لینکدین نیز وقتی این بحث را منتشر کردم، عمداً می‌خواستم توجه برانگیزم؛ همان‌طور که در فارسی می‌گوییم «آب بریزیم تا مورچه‌ها بیرون بریزند».
به باور من، یکی از بزرگ‌ترین ضعف‌های کانبان همین است که پیام خود را به‌خوبی منتقل نکرده است. در نتیجه، امروز در سراسر دنیا نوعی «برداشت اشتباه همه‌گیر» (Pandemic of Misunderstanding) درباره‌ی کانبان وجود دارد. بسیاری آن را با اسکرام مقایسه می‌کنند، درحالی‌که این مقایسه دقیق نیست. چرا؟ چون اسکرام یک فریم‌ورک است، اما کانبان یک روش کاری (Method) است.
آنچه می‌توان مقایسه کرد، این است که:
اسکرام چگونه می‌کوشد چابکی را افزایش دهد.
کانبان چگونه در پی افزایش چابکی است.
یا اینکه می‌توان مقایسه‌ای میان «روش مدیریت تغییر (Change Management)» در اسکرام و کانبان انجام داد.
در اسکرام، مدیریت تغییر بیشتر «انقلابی (Revolutionary)» است. یعنی باید ساختار موجود کنار گذاشته شود تا ساختاری جدید ایجاد گردد؛ وگرنه اسکرام امکان اجرا ندارد. در مقابل، کانبان رویکردی «تکاملی (Evolutionary)» دارد. یعنی از وضعیت موجود آغاز می‌کند، بدون آنکه نقش‌ها تغییر یابند؛ و با ایجاد تغییرات کوچک و تدریجی، سازمان را به سطحی بالاتر از بلوغ می‌رساند.
چارچوب‌هایی مانند «اسکرام» یا «SAFe» اغلب از اصطلاح «ترنسفورمیشن (Transformation)» استفاده می‌کنند. این اصطلاح به معنای یک دگرگونی بنیادین است؛ تغییری که گاهی به‌صورت انقلابی همه‌چیز را دگرگون می‌سازد. در ایران نیز این اصطلاح رایج شده و حتی وارد زبان روزمره‌ی حرفه‌ای‌ها شده است. به همین دلیل، بد نیست کمی دقیق‌تر به تفاوت «رویکرد انقلابی» و «رویکرد تدریجی» در پیاده‌سازی چارچوب‌ها بپردازیم.
در اسکرام، معمولاً چنین رویکردی مشاهده می‌شود: تیمی تشکیل می‌شود، نقش‌ها مشخص می‌گردد، و یک اسکرام‌مستر مأمور می‌شود که شرایط را برای اجرای کامل اسکرام فراهم کند. حتی اگر در ابتدا تنها بخشی از رویدادها یا تمرین‌ها اجرا شوند، هدف نهایی این است که تیم به «اسکرام کامل» برسد. به بیان دیگر، از همان آغاز، یک «فرآیند درست» تعریف شده است و سازمان باید خود را با آن منطبق کند.
اما کانبان (Kanban) اساساً چنین رویکردی ندارد. در کانبان، هیچ «فرآیند صحیح و از پیش تعریف‌شده‌ای» وجود ندارد. اصل بر این است که سازمان از وضعیت موجود آغاز کند و بدون تغییر فوری نقش‌ها یا ساختار، به‌تدریج و بر اساس ظرفیت و بلوغ خود تکامل یابد.
به همین دلیل، «مدل بلوغ کانبان (Kanban Maturity Model)» معرفی شده است که شش یا هفت سطح بلوغ را توصیف می‌کند. یک سازمان می‌تواند در سطحی بسیار ابتدایی باشد؛ سطحی که حتی «بصری‌سازی (Visualization)» ساده‌ی کارها انجام نمی‌شود و کسی نمی‌داند همکارش دقیقاً بر روی چه کاری مشغول است. از این سطح نیز می‌توان با کانبان آغاز کرد و به‌تدریج ارتقا یافت.
در مقابل، اسکرام معمولاً برای سازمان‌های کوچک‌تر یا تیم‌هایی که آمادگی بیشتری برای تغییر ساختار دارند مناسب‌تر است. در اسکرام، همه باید حول یک هدف مشترک فعالیت کنند؛ همان‌طور که در ریشه‌ی اصطلاح «اسکرام» در ورزش راگبی نیز آمده است: گروهی از بازیکنان با هم، به‌مثابه یک واحد واحد، حرکت می‌کنند. اما در سازمان‌های بزرگ، که افراد معمولاً در «سیلوها» کار می‌کنند (مثلاً توسعه‌دهنده تنها کدنویسی می‌کند، یا تستر تنها تست می‌نویسد)، تحقق چنین هم‌راستایی بسیار دشوار است.
به همین دلیل است که اسکرام به‌تنهایی نمی‌تواند همیشه در سازمان‌های بزرگ یا سنتی موفق باشد. هرچند تلاش‌هایی همچون SAFe برای گسترش اسکرام در مقیاس وسیع انجام شده است، اما همچنان بسیاری از سازمان‌ها با چالش‌های بنیادی مواجه‌اند؛ زیرا تغییر ناگهانی نقش‌ها و ساختارها برای افراد باسابقه‌ای که سال‌ها در جایگاه‌های خاصی فعالیت کرده‌اند، به‌سادگی امکان‌پذیر نیست.
در مقابل، کانبان با رویکرد تکاملی خود، این امکان را می‌دهد که افراد در همان نقش‌های فعلی خود باقی بمانند و به‌تدریج تغییرات را تجربه کنند. در این مسیر، سازمان می‌تواند مرحله به مرحله به بلوغ بالاتری برسد، بدون آنکه نیازمند یک انقلاب سازمانی باشد.
با تغییر عنوان شغلی، ذهنیت و دانش افراد تغییر نمی‌کند. دانش (Knowledge) با گذراندن یک دوره‌ی دو یا سه‌روزه به‌دست نمی‌آید؛ بلکه حاصل تجربه و تمرین مداوم است. از همین‌رو تأکید می‌شود که «دانش» ارزشمندترین دارایی هر فرد است و باید آن را جدی گرفت.
کانبان بر این اصل بنا شده است که هیچ‌چیز را به اجبار تحمیل نکند. افراد می‌توانند در همان نقشی که دارند باقی بمانند، اما به‌تدریج رفتارها و روش‌های کاری خود را اصلاح کنند. اگر سازمان یا تیم به سطحی از بلوغ برسد که خود تشخیص دهد لازم است تغییر ایجاد کند، آن‌گاه تغییر به‌صورت طبیعی اتفاق خواهد افتاد، نه با اجبار بیرونی.
معنای لغوی واژه‌ی «Kanban» نیز ریشه در همین نگاه دارد. در زبان چینی، «Kanban» به معنای «تابلوی بزرگ» یا «برد تصویری» است که همه‌ی کارها روی آن نمایش داده می‌شوند. اما در زبان ژاپنی، معنای اصلی آن «سیگنال» است؛ سیگنالی که نشان می‌دهد فرد یا تیم ظرفیت (Capacity) برداشتن کار جدید را دارد. این همان معنایی است که کانبان در مدیریت کار دنبال می‌کند.
ریشه‌ی تاریخی این مفهوم نیز به دهه‌ی ۱۹۴۰ و توسعه‌ی «سیستم تولید تویوتا» بازمی‌گردد. در آن زمان، مهندسان ژاپنی مشاهده کردند که در فروشگاه‌های زنجیره‌ای آمریکا، قفسه‌ها به‌محض خالی‌شدن دوباره پر می‌شوند؛ به این صورت که وقتی مشتری یک محصول را برمی‌دارد، بلافاصله محصول دیگری جایگزین آن می‌شود. این ایده بعدها به‌صورت «سیگنال کشش (Pull Signal)» وارد نظام تولید شد و سرانجام به مدیریت کار دانشی (Knowledge Work) نیز تعمیم یافت.
بنابراین، در کانبان اگر بردی دارید که صرفاً پر از کارت و فعالیت است، هنوز سیستم کانبان ایجاد نکرده‌اید. سیستم زمانی واقعی است که «سیگنال» وجود داشته باشد؛ یعنی مشخص باشد چه کسی ظرفیت دارد که یک کار جدید را «بکشد» و آغاز کند.
از این نقطه، گام‌های بعدی آغاز می‌شود:
شناخت مشتری و نیازهای او: ابتدا باید بدانیم مشتری چه می‌خواهد و خروجی مطلوب چیست.
طراحی جریان کار (Workflow): مسیر حرکت کار از نقطه‌ی آغاز تا تحویل به مشتری باید به‌روشنی مشخص و نمایش داده شود.
اندازه‌گیری (Measurement): بررسی شود که هر کار چقدر زمان می‌برد، چه مدت در صف انتظار می‌ماند، و چه میزان زمان صرف انجام آن می‌شود.
شناسایی گلوگاه‌ها (Constraints): در هر جریان کاری، همواره یک نقطه وجود دارد که سرعت کل سیستم را کاهش می‌دهد. این الزاماً ناشی از تنبلی نیست، بلکه گاه به دلیل ماهیت کار است. برای نمونه، توسعه‌دهندگان کد را سریع‌تر تولید می‌کنند اما تست دستی ده‌ها یا صدها سناریو زمان‌بر است؛ بنابراین، «تست» به گلوگاه سیستم بدل می‌شود.
در روش‌های سنتی، توسعه‌دهندگان حجم زیادی از کار را تولید کرده و به‌صورت یکجا به تیم تست منتقل می‌کنند. در نتیجه، صفی طولانی از کارهای نیمه‌تمام ایجاد می‌شود و باگ‌هایی که پس از مدت‌ها کشف می‌شوند، دوباره فرآیند را مختل می‌کنند. این همان «باتلنک (Bottleneck)» است که سیستم را کند و پرهزینه می‌سازد.
کانبان برای رفع این مشکل از WIP Limit یا محدودیت کار در جریان استفاده می‌کند؛ یعنی میزان کاری که در هر مرحله می‌تواند هم‌زمان انجام شود محدود می‌شود تا جریان پایدار و قابل پیش‌بینی گردد.
وقتی در جریان کار مشخص می‌شود که بخش «تست» به‌عنوان گلوگاه (Constraint) عمل می‌کند، نخستین اقدام این است که کل سیستم خود را با این گلوگاه هماهنگ سازد. به عبارت دیگر، توسعه‌دهندگان به جای آنکه صرفاً با سرعت بالا کد تولید کرده و مسئولیت پیامدهای آن را متوجه بخش تست بدانند، باید سرعت کار خود را با ظرفیت تست منطبق کنند تا از ایجاد «باتلنک» و انباشته‌شدن کارهای نیمه‌تمام جلوگیری شود.
در چنین شرایطی، بهتر است توسعه‌دهنده زمانی را به استراحت، تفکر یا بررسی روش‌های بهبود اختصاص دهد تا اینکه بدون توجه به ظرفیت سیستم، کار جدیدی به جریان تزریق کند. هدف نهایی، تحویل به‌موقع کار به مشتری است و این امر تنها با حرکت هماهنگ تمامی اجزای سیستم محقق می‌شود.
مرحله‌ی بعدی آن است که توسعه‌دهندگان بیندیشند چگونه می‌توانند به کاهش فشار گلوگاه کمک کنند. قرار نیست گلوگاه به‌طور کامل حذف شود، چرا که این امر غالباً هزینه‌های زیادی دارد. اما می‌توان با اقداماتی مانند نوشتن تست‌های خودکار (Automation) یا صرف زمان بیشتر برای کیفیت در همان مرحله‌ی توسعه، بار کاری بخش تست را کاهش داد.
اینجاست که مفهوم Slack Time یا «زمان آزاد» اهمیت می‌یابد. این زمان به توسعه‌دهندگان فرصت می‌دهد تا فراتر از وظایف روزمره بیندیشند و راه‌هایی برای بهبود سیستم بیابند. در کار دانش‌محور (Knowledge Work)، افراد تنها زمانی می‌توانند خلاقانه فکر کرده و فرآیندها را بهبود دهند که فشار کاری بی‌وقفه نداشته باشند. بدون Slack Time، تیم‌ها صرفاً به اجرای تکراری وظایف مشغول می‌شوند و فرصتی برای یادگیری و بهینه‌سازی باقی نمی‌ماند.
این نگاه، در نهایت به بهینه‌سازی جریان کار (Flow Optimization) می‌انجامد. برخلاف تصور رایج، افزایش بهره‌وری همواره به معنای «بیشتر کار کردن» نیست. در بسیاری موارد، کاهش اتلاف (Waste) و جلوگیری از دوباره‌کاری خود به سودآوری (Profit) منجر می‌شود.
از این منظر، تفاوتی بنیادین میان کانبان و اسکرام نیز دیده می‌شود. اسکرام زمان مشخصی را برای بازاندیشی و یادگیری تیم در قالب رویداد «Retrospective» در نظر می‌گیرد. در حالی‌که کانبان این فرآیند را به‌صورت پیوسته و لحظه‌ای دنبال می‌کند. هر زمان که سیگنالی نشان دهد بخشی از کار دچار اختلال است، محدودیت‌ها (WIP Limit) اعمال شده و اعضای تیم به‌طور طبیعی به سمت بهبود سیستم هدایت می‌شوند.
وقتی سازمانی سال‌ها بر اساس نقش‌ها و ساختارهای سنتی خود عمل کرده است، تغییر ناگهانی و تحمیلی نه تنها دشوار بلکه از نظر روان‌شناختی نیز بسیار پرهزینه است. برای مثال، فردی که ۲۰ یا ۳۰ سال در جایگاه «مدیر پروژه» یا «تحلیل‌گر کسب‌وکار» فعالیت کرده است، هویت حرفه‌ای خود را بر اساس همین نقش‌ها تعریف کرده است. اگر در یک شب اعلام شود که تمام آنچه تاکنون انجام داده «اتلاف» بوده و اکنون باید نقش کاملاً متفاوتی بپذیرد، این نه یک تغییر ساده در «عنوان شغلی» بلکه نوعی تهدید برای هویت و ارزش شخصی اوست.
در چنین شرایطی، رویکردهای انقلابی مانند برخی مدل‌های پیاده‌سازی اسکرام که تغییرات فوری و بنیادین را مطالبه می‌کنند، به‌ویژه در سازمان‌های بزرگ، با مقاومت شدیدی روبه‌رو می‌شوند. زیرا این رویکردها مستلزم بازسازی کامل ساختارها، روابط و نقش‌ها هستند؛ امری که هم از منظر روانی و هم از منظر عملیاتی دشوار است.
در مقابل، رویکردهایی مانند کانبان با فلسفه‌ی «شروع از وضعیت موجود» فشار کمتری وارد می‌کنند. این روش به جای بی‌اعتبار کردن گذشته، می‌پذیرد که دستاوردها و تجربه‌های پیشین ارزشمندند و صرفاً نیازمند اصلاحات تدریجی‌اند. در این نگاه، افراد نقش‌ها و هویت‌های خود را حفظ می‌کنند، اما گام‌به‌گام شیوه‌ی کارشان را بهبود می‌بخشند. این امر سبب می‌شود پذیرش تغییر آسان‌تر گردد و سازمان‌ها بدون تجربه‌ی شوک یا گسست شدید، به بلوغ بیشتری دست یابند.
بنابراین، می‌توان گفت نقطه‌ی قوت اصلی کانبان در مقایسه با برخی چارچوب‌های انقلابی این است که تغییر را یک «فرآیند تکاملی» می‌بیند، نه یک «انقلاب ناگهانی». این تکامل نه تنها باعث ماندگاری افراد کلیدی در سازمان می‌شود، بلکه امکان می‌دهد که دانش ضمنی و تجربیات آنها نیز حفظ و در مسیر جدید به کار گرفته شود.
دخترم وقتی به تابلوی شخصی من نگاه کرد، دید که کارها را با رنگ‌های مختلف دسته‌بندی کرده‌ام. رنگ سبز مربوط به فعالیت‌های شخصی و سرگرمی‌های خودم بود؛ مانند ورزش، مطالعه یا دیگر کارهایی که برای خودم ارزشمند بودند. او با کنجکاوی پرسید: «این‌ها چیست؟» و وقتی توضیح دادم، گفت: «پس تو حتی برای کارهای تفریحی و شخصی هم برنامه‌ریزی کرده‌ای!»
این بازخورد ساده نشان داد که حتی در زندگی شخصی نیز می‌توان از رویکرد کانبان بهره گرفت. هنگامی که فعالیت‌ها شفاف‌سازی و به‌صورت بصری‌سازی (Visualization) ارائه می‌شوند، نه تنها خود فرد بهتر می‌تواند میزان بار کاری‌اش را درک کند، بلکه اطرافیان نیز متوجه می‌شوند که چگونه اولویت‌ها تعریف شده‌اند و کدام بخش‌ها مربوط به خود فرد، خانواده یا سازمان‌های بیرونی است.
در این روش، تنها کافی است ورودی‌های سیستم ــ یعنی کارهایی که از سوی مشتریان مختلف (اعم از خود فرد، خانواده، نهادهای بیرونی یا همکاران) درخواست می‌شوند ــ روی برد مشخص شوند. به این ترتیب، ظرفیت و محدودیت‌ها (WIP Limits) بهتر دیده می‌شوند و فرد می‌تواند در لحظه تصمیم بگیرد که چه کاری را باید آغاز یا متوقف کند.
نکته‌ی کلیدی اینجاست که حتی کوچک‌ترین «پیروزی‌های سریع» (Quick Wins) ــ مانند انجام یک کار ساده و مشخص ــ باعث ایجاد انگیزه و پذیرش بیشتر می‌شود. زیرا فرد یا تیم فوراً نتیجه را مشاهده می‌کند و این تجربه‌ی موفق، زمینه‌ساز اعتماد به روش و تمایل به ادامه‌ی بهبودهای تدریجی خواهد شد.
دوستم پرسید اگر بخواهی به یک کودک توضیح دهی «اجایل» چیست، چه خواهی گفت؟ پاسخ دادن به چنین پرسشی ساده نیست، زیرا ارزش‌ها و اصول اجایل (Agile) برای یک کودک معنا و کاربرد مستقیمی ندارد. اما وقتی به «کانبان (Kanban)» نگاه می‌کنیم، موضوع بسیار ساده‌تر می‌شود. به کودک می‌توان نشان داد که مشق‌های مدرسه‌اش را در یک ستون قرار دهد، و وقتی یکی از آنها تمام شد، آن را به ستون دیگری منتقل کند. او به سرعت متوجه می‌شود که چند کار در جریان دارد، چه چیزی تمام شده و چه چیزی باقی مانده است. همین سادگی باعث می‌شود که حتی یک کودک هم بتواند مفهوم پایه‌ای کانبان را درک و اجرا کند.
برای کسانی که می‌خواهند به‌صورت حرفه‌ای وارد این حوزه شوند، دوره‌های آموزشی رسمی در دسترس است. در حال حاضر سه دوره‌ی اصلی توسط Kanban University ارائه می‌شود:
Kanban for Practitioners: ویژه‌ی کسانی که با کانبان کار می‌کنند و می‌خواهند اصول اجرایی (Practices)، اصول تغییر (Change Management Principles)، و مبانی تحویل خدمات (Service Delivery) را عمیق‌تر بیاموزند.
Kanban System Design: مناسب افرادی که می‌خواهند یک سیستم کانبان طراحی کنند. این دوره به‌طور خاص بر طراحی جریان کار (Workflow Design) و ایجاد یک سیستم قابل‌اعتماد تمرکز دارد.
Kanban System Improvement: دوره‌ای برای ارتقاء و گسترش سیستم کانبان. در این دوره شرکت‌کنندگان می‌آموزند چگونه یک سیستم موجود را بهبود دهند، آن را در سطح سازمانی گسترش دهند (Scaling)، و بلوغ (Maturity) سیستم را افزایش دهند. این دوره پیش‌نیاز دارد و معمولاً پس از گذراندن System Design توصیه می‌شود.
معمولاً نخستین دوره‌ای که پیشنهاد می‌شود، همان System Design است. برگزاری آن در ماه می یا نهایتاً ماه بعد از آن برنامه‌ریزی شده است و پس از آن نیز سایر دوره‌ها با فرکانس بالاتری ارائه خواهند شد. البته افراد می‌توانند Practitioner و System Design را مستقل از یکدیگر بگذرانند، اما برای شرکت در System Improvement گذراندن System Design ضروری است.
برای پیگیری این دوره‌ها، علاقه‌مندان می‌توانند مستقیماً از طریق لینکدین با مدرس در تماس باشند.
همچنین، برای کسانی که می‌خواهند مطالعه‌ی فردی داشته باشند، نقطه‌ی شروع مناسب کتاب Blue Book نوشته‌ی David J. Anderson است. در این کتاب چندین مطالعه‌ی موردی (Case Study) ارزشمند وجود دارد، از جمله درباره‌ی «اسکرام‌بان (Scrumban)». این منبع معتبرتر از جستجوهای پراکنده در اینترنت است؛ زیرا متأسفانه مقالات اینترنتی درباره‌ی کانبان فراوان‌اند و بسیاری از آنها حاوی برداشت‌های نادرست یا تعریف‌های ناقص‌اند که می‌تواند باعث سردرگمی شود.
چارچوبی تازه‌ای طراحی شده است که Scrumban نام دارد. به زبان ساده، این چارچوب برای زمانی به کار می‌رود که تیمی در حال کار با اسکرام (Scrum) است، اما احساس می‌کند اسکرام دیگر پاسخ‌گوی نیازهایش نیست و مایل است به تدریج به سمت کانبان (Kanban) حرکت کند. فاصله‌ی میان «اسکرام کامل» و «کانبان کامل» را اسکرام‌بان می‌نامند.
از آن‌جا که کانبان هیچ‌گاه تیم را مجبور نمی‌کند که ناگهان اسکرام را کنار بگذارد، این تغییر به‌صورت تدریجی و مرحله‌به‌مرحله رخ می‌دهد. برای مثال، ممکن است تیم تصمیم بگیرد جلسات روزانه (Daily) یا اسپرینت‌های دو هفته‌ای را کاهش دهد و به مرور تغییرات دیگری اعمال کند. این رویکرد باعث می‌شود که تیم‌ها بتوانند بدون ایجاد شوک سازمانی، به سمت استفاده‌ی کامل از کانبان حرکت کنند.
در کتاب Blue Book نوشته‌ی David J. Anderson، چندین مطالعه‌ی موردی (Case Study) جذاب در این زمینه ارائه شده است. نویسنده نشان می‌دهد که چگونه سازمان‌ها، پس از عادت کردن به اسکرام و رویدادهای آن، می‌توانند به تدریج به سمت روش‌های کانبانی حرکت کنند، بدون آنکه ناچار باشند یک‌باره همه چیز را متوقف کنند. به همین دلیل، این کتاب منبعی بسیار مناسب برای شروع یادگیری کانبان محسوب می‌شود.
هدف اصلی از این گفت‌وگو و همچنین برگزاری چنین پادکست‌هایی، آن است که پیام اصلی کانبان ــ یعنی اینکه کانبان یک فریم‌ورک (Framework) نیست بلکه یک روش کاری (Method) است ــ به‌درستی منتقل شود. زمانی که افراد با این مفهوم آشنا شوند و ذهنیت‌های تازه در برابر ذهنیت‌های قدیمی آشکار گردد، می‌توان انتظار داشت که تغییرات مثبت و پایدار در سازمان‌ها ایجاد شود.
بنیان‌گذاران جنبش اجایل بارها تأکید کرده‌اند که هدف اولیه‌ی آنان Agility (چابکی واقعی) بوده است، نه صرفاً «Agile بودن» به‌عنوان یک برچسب. امروزه، در بسیاری از سازمان‌ها، اجرای اسکرام یا سایر فریم‌ورک‌ها صرفاً به‌عنوان یک نماد «لاکچری» یا نشانه‌ی «پیشرفته بودن» تلقی می‌شود، در حالی که مقصود اصلی ــ یعنی رساندن سریع و پایدار ارزش به مشتری ــ به فراموشی سپرده می‌شود.
بنابراین، مهم آن است که دوباره به اصل ماجرا بازگردیم: رضایت مشتری و افزایش سطح اجیلیتی سازمان. خواه این مسیر از طریق اسکرام طی شود یا کانبان یا هر روش دیگری، معیار واقعی موفقیت، توانایی سازمان در پاسخ‌گویی سریع، پایدار و ارزش‌محور به نیازهای مشتری است.
در پایان، از تمامی شنوندگان پادکست سپاسگزاریم. لطفاً دیدگاه‌ها، پرسش‌ها و نقدهای خود را در بسترهایی که امکان گفت‌وگو فراهم است (مانند Apple Podcasts، لینکدین، اینستاگرام یا توییتر) با ما در میان بگذارید. همچنین از مدرسه‌ی اسکرام بابت حمایت‌های مالی و معنوی‌اش قدردانی می‌کنیم. امیدواریم این گفت‌وگو برایتان مفید بوده باشد.
اجایل گپ را می‌توانید از طریق شبکه‌های اجتماعی لینکدین، اینستاگرام و تلگرام دنبال کنید
