از یک داستان باید شروع کرد
در سال 2001، 17 نفر از صاحب نظران صنعت نرم‌افزار و صاحبان تجربه‌های فنی و مدیریتی دور هم جمع شدند تا وضعیت آن زمان این صنعت را بررسی کنند و شاید بتوانند برای بهبود آینده این صنعت پیشنهادهایی ارایه دهند. آن زمان آمار شکست پروژه‌های نرم‌افزاری به‌شدت بالا بود و شاید این بهانه خوبی برای دور هم جمع شدن این افراد بود. ماحصل این کارگاه سه روزه بیانیه نمادین «چابک» بود .



این بیانیه همانند یک چتر بود که تجربه‌هایی مانند اسکرام، کانبان، XP ، کریستال و ... را در بر می گرفت .

چه نیازی بود که ما چابک شویم؟  
گزارش سال 2007 موسسه استندیش گروپ نشان می‌داد که قبل از ظهور روش‌های چابک فقط 16% پروژه‌های نرم‌افزاری موفق بودند ولی بعد از آن، گزارش گارتنر نشان ‌داد که 77% پروژه‌ها موفق بودند. [1][2 ][ 3 [
تحقیقات سال 2004 فارستر [4] نشان می‌داد که بعد از چابک شدن :

• 93% افزایش بهره‌وری
• 88% افزایش کیفیت
• 83% افزایش رضایت ذی نفعان
• 49% کاهش هزینه
• 66% کاهش ریسک در برگشت سرمایه

صورت گرفته است.
شروع بسیار خوبی داشتیم ولی بعد از مدتی :

• روش مدیریتی فرمان و کنترل توسط اسکرام مستر اجرا می‌شد
• جلسات روزانه سرپایی اسکرام حالت گزارشی داشت
• فقط جلسه برگزار می‌کردیم
• تعهد یا احترامی در کار نبود
• نرم‌افزار کارکننده داشتیم ولی همراه با اشکال‌های متعدد
• زمانی برای آزمایش نداشتیم

کن شوئبر مبدع اسکرام در یکی از مصاحبه‌های خود گفته است ] 5 [ :
من تخمین می‌زنم 75% از سازمان‌هایی که از اسکرام استفاده می‌کنند، در دست‌یابی به منافعی که از استفاده از اسکرام دنبال آن بودند ناموفق خواهند بود .
شاید اگر در گوگل دنبال کلمه «چابک» بگردید به مطالبی مانند «اجایل برده‌داری نوین» هم بر بخورید. در عصر چابک شدن، درست است که تعداد پروژه‌های موفق بالا رفته بود، ولی همچنان آمار نارضایتی‌ها و شکست‌ها هم کم نبود. سازمان‌ها در پیاده‌سازی به شیوۀ چابک با چالش‌های بزرگی مواجه شده بودند.
اگر مقالاتی در مورد «موانع چابک سازی» خوانده باشید یا حتی خودتان تحقیقی روی آن داشته باشید، حتما با موارد زیادی مواجه شدید مانند «فرهنگ سازمان» «مهارت‌های فنی» و ... ولی در این مقاله سعی شده است از منظر جدیدی این مشکل بررسی شود .
نظریۀ پنجره شکسته و چابک شدن
فرض کنید روزی از محله خلوتی رد می‌شوید. در آنجا ساختمانی است که یکی از شیشه‌های آن شکسته است. روز دوم می‌بینید که علاوه بر این‌که شیشه شکسته تعویض نشده یکی دیگر از شیشه‌ها هم شکسته است. روز سوم می‌بینید شیشه‌های بیشتری شکسته است. روز چهارم در می‌یابید که این ساختمان به حال خود رها شده است. در این صورت، احتمال دارد که شیشه بعدی را شما بشکنید. با این‌که شما انسان به شدت با شخصیتی بودید ولی درگیر یک عارضه اجتماعی شدید که با عنوان نظریۀ پنجره شکسته شناخته می‌شود .
نظریۀ پنجره شکسته زمانی اتفاق می‌افتد که «خراب‌کاری» در سیستم (شهر، محصول، پروژه یا ...) اتفاق می‌افتد و «کسی اهمیت نمی‌دهد» و آن تبدیل به یک رفتار اجتماعی می‌شود.  فلیپ زیمباردو روان‌شناس استنفورد، در یک آزمایش، ماشین بدون پلاکی را با کاپوت باز در جایی از شهر رها کرد. در طی چند روز کسی با ماشین کاری نداشت. بعد از چند روز خود او با میله‌ای شیشه‌های ماشین را خرد کرد، کمتر از 24 ساعت مردان و زنان شیک‌پوشی که از آنجا رد می‌شدند ماشین را تخریب کردند .
نظریۀ پنجره شکسته را می‌توان در جاهای مختلف و در سیستم‌های مختلف مشاهده کرد ولی به طور تخصصی می‌خواهیم در پیاده‌سازی چابک بررسی کنیم .
کیفیتی که می‌شکند
شاید اگر درگیر پروژه‌های نرم‌افزاری شوید، می‌بینید که در ابتدای پروژه کیفیت محصول تولیدی به‌شدت بالا است ولی در گذر زمان این کیفیت به‌شدت پایین می‌آید. بعد از مدتی می‌توان به وضوح نظریۀ پنجره شکسته را در آن جا دید .
در خیلی از پروژه‌ها «سرعت» یا «فشار»، بهانه برنامه‌نویسان برای تولید محصول بی‌کیفیت می‌باشد، «این گناه من نبود، مدیر فشار می‌آورد که باید سریع این قابلیت را ارایه کنید». بعد از مدتی که کدها به اصطلاح «اسپاگتی» شد، برنامه‌نویس‌های حتی خوب هم شروع خواهند کرد به «اسپاگتی» نوشتن. و اینجا هست که رژه مرگ شروع می‌شود .
وقتی برنامه‌نویس‌خوب که تا دیروز سعی می‌کرد «بهترین کدهای خود را بنویسد، همیشه بهسازی کند و ...» با دیدن پنجره‌های شکسته (کدهای کثیف) به عارضه پنجره شکسته دچار خواهد شد .
در اینجا شاهد چنین گفتگوهایی خواهیم بود «حالا این را هم اینطوری بزن بره بعداً درستش می‌کنم» یا «حالا کی می‌فهمه» یا «فعلا وقت نداریم برای بهسازی» و ....

عارضۀ پروژۀ بعدی
در آغاز فرآیند چابک شدن همه فکر می‌کنند که از روز اول باید همه چیز بهترین باشد و زمانی که پنجره‌های شکسته را می‌بینند (کد کثیف، نتیجه بد در یک اسپرینت، مشکل در ارتباطات تیمی و ... ) به جای تعمیر آن‌ها، شروع می‌کنند به شکستن پنجره‌های بیشتر .
اگر ما در اسپرینت‌های نخستین آزمایش نکردیم، دیگر آزمایش نخواهیم کرد تا شاید در پروژه بعدی .
اگر کد کثیف می‌نویسیم، کد تمیز را در پروژه بعدی خواهیم نوشت .
و فرمول«... را در  پروژه بعدی انجام خواهیم داد» و پروژه‌ای که هیچ وقت از راه فرا نخواهد رسید، مثل همان شنبه‌ای که می‌خواهیم تغییر کنیم و هیچ وقت نمی‌آید .

چابک و دنیای مداومت
ما در فرآیند چابک چندین چیز مداوم داریم :

• یکپارچه‌سازی مداوم
• راه‌اندازی مداوم
• حمل مداوم
• بهبود بخشی مداوم

موتور تحول چابک، تفکر بهبود مداوم می‌باشد. یعنی هر تیم یا سازمان قبل از استفاده از هر تجربۀ چابک مانند اسکرام باید تلاش کند تا تفکر بهبود مداوم را در سازمان جا بیندازد .
باید این تفکر به وجود بیاید که دفعه بعدی یا فردایی در کار نیست و امروز و همین الان باید (کمی) بهتر شد.

اما امروزه بهبود مداوم در تیم‌های چابک چگونه انجام می‌شود؟
جلسات بازنگری می‌تواند تبدیل شود به جایی برای :

• پیدا کردن پنجره‌های شکسته
• سرزنش کردن همدیگر
• نشان دادن این‌که روش چابک به درد ما نمی‌خورد
• ما تیم یا سازمان بدی هستیم

و تصمیم بگیریم تا پنجره‌های بیشتری بشکنیم .
به جای تمرکز بر روی کاستی‌ها و پیدا کردن پنجره‌های شکسته ابتدا باید بر روی نقاط مثبت یا نقاط قوت تمرکز کنیم. (چه کاری را خوب انجام دادیم؟ چه چیزهایی کار کرد؟)
کشف موردی برای  قدردانی
AI  یک روش با رویکردی تازه برای بهبود سیستم‌ها و تصمیم‌گیری‌های اثربخش می‌باشد که در سال 1980 توسط دیوید کوپرایدر و همکارانش توسعه داده شده است. این متد با یک سری پرسش و مصاحبه شروع می‌شود که به‌‌آن فرآیند کشف می‌گویند ] 7 [ .
AI  در جستجوی بهترین‌ها و نقاط قوت افراد، سازمان و محیط می‌باشد. چیزهایی که امروز کار می‌کنند و نقاط قوت ما می‌باشند و باید قدردان آن‌ها باشیم. برای قدردان بودن از چیزی باید ابتدا کشف کنیم که ما در چیزی خوب هستم. انسان بخاطر ماهیت فراموش کاری یا به‌خاطر عارضه پنجره شکسته فراموش می‌کند که چه نقاط مثبتی دارد و باید قدردانش باشد .
AI  بر پایه تفکر مثبت و روان‌شناسی مثبت بنا شده است که در آن با پرسیدن سوالاتی سعی می‌شود نفرات بر پایه نقاط قوت خود و سازمان، آینده‌ای برای خود ترسیم کنند تا بتوانند  در عکسی که تجسم کرده‌اند توانایی های بالقوه خود را بالفعل نمایند. در این روش تاکید بر روی شناسایی نقاط قوت و برنامه ریزی آینده بر اساس همین نقاط قوت می‌باشد .
مقایسه رویکرد AI  با رویکرد حل مشکل:

فرآیند کشف موردی برای قدردانی شامل چهار چیز می‌باشد که همه با حرف D شروع می‌شوند:

• Discover یا کشف: کشف بهترین‌ها و چه چیزهایی امروز کار می‌کند .
• Dream یا رویا: ترسیم و دیدن آینده‌ای که می‌تواند اتفاق بیفتد .
• Design یا طراحی: برنامه‌ریزی این‌که آینده چگونه باید باشد .
• Delivery یا حمل: پیاده‌سازی آنچه باید می‌شد .

بازنگری قدردانی
یکی از بهترین کارها برای بهبود عارضه پنجره شکسته برگزاری جلسات بازنگری به شیوه AI می‌باشد ] 8 [ .

• هدف گذاری

جلسه بازنگری به روش AI با هدف‌گذاری مثبت شروع می‌شود. هدفی که به سوالات بعدی و فرآیند مصاحبه و کشف جهت خواهد داد .
برای مثال: «در طول این جلسه بازنگری، ما راه‌هایی برای تقویت نقاط قوتمان در کارتیمی پیدا خواهیم کرد»

•  جمع آوری داده

همه اعضای تیم سوال می‌پرسند و مورد پرسش قرار می‌گیرند تا تک تک نفرات در مورد موفقیت‌ها و نقاط قوت آگاهی داشته باشند و بتوانند بر روی آن‌ها تمرکز نمایند. معمولا این پرسش‌ها در راستای همان هدف تعیین شده می‌باشد .
برای مثال «چه کار ما به‌عنوان یک تیم در اسپرینت گذشته برای تو با ارزش بود؟»

•  ایجاد نگرش

داده‌های جمع‌آوری شده، با پرسشی برای ایجاد چشم اندازی برای آینده ادامه می‌یابد .
«فرض کنید ما سوار ماشین زمان شده‌ایم و یک سال به جلو رفته‌ایم، الان به عنوان بهترین تیم دنیا از ما یاد می‌کنند. الان در این شرایط چگونه هستیم؟ چه شکلی عمل می کنیم و  ... »

• تصمیم بگیرید چه کاری می‌خواهید انجام دهید

در این مرحله چشم‌انداز ترسیم شده را به مراحل قابل پیاده‌سازی می‌شکنید و تصمیم می‌گیرید که کدامیک از آن‌ها را چه زمانی پیاده‌سازی کنید .

خلاصه
در سال‌های اخیر شرکت‌ها و سازمان‌های مختلف به‌دلایل زیادی تمایل به استفاده از تفکر چابک داشته‌اند ولی با وجود آمارهای موفقیت زیاد، شاهد شکست‌هایی هم بوده‌ایم. شاید یکی از بزرگ‌ترین موانع موفقیت، ماهیت انسانی سازمان‌ها است. انسان‌هایی که تمایل دارند از روز اول همه چیز عالی و کامل باشد و در صورت مواجهه با نارسایی‌ها، ناامید می‌شوند و تصمیم می‌گیرند در دفعه بعدی و نه الان بهتر عمل کنند .
تفکر بهبود مداوم می‌تواند موتور چابک‌سازی هر تیم یا سازمانی باشد به صورتی که درک کنیم ما همین الان باید بهتر شویم و دفعه بعدی در کار نیست. برای این کار لازم است هر زمان که خودمان را بررسی می‌نماییم، بیشتر بر روی نقاط قوتمان تمرکز نماییم و آینده را بر اساس همین نقاط قوت بنا نماییم .
روش کشف موردی برای قدردانی یک روش نوین با رویکردی مثبت است که سعی می‌نماید نقاط قوت را شناسایی و براساس آن برنامه‌ریزی نماید. تیم‌های چابک می‌توانند از این روش برای جلسات بازنگری خود استفاده نمایند.

منابع

1 Standish Group Report: There’s Less Development Chaos Today, by David Rubinstein SD Times March 1, 2007,
2 “Agile Has Crossed the Chasm,” Dr. Dobb’s Journal, July 2, 2007. 3QSMA and Cutter Consortium ROI case study on BMC Software, 2008. 4 Gartner, Inc. 2005 
3 Why agile - Rally software development corp
4 “Agile Methodologies: Survey Results,” by Shine Technologies, 2003; 2 Forrester Research, 2004;
5 http://www.agilecollab.com/interview-with-ken-schwaber
6 en.wikipedia.org/wiki/Broken_windows_theory
7 http://en.wikipedia.org/wiki/Appreciative_inquiry
8 Diana Larsen, FutureWorks Consulting - An Appreciative Retrospective