فصل ۵ — Scrum: دور پیروزی، ارزشها و فرهنگ سازمانی
روایت
تیمی در یک شرکت کوچک روی اپلیکیشن تلفن همراه کار میکند:
- Roger — رهبر تیم که میخواهد Agile شود.
- Avi — Product Owner.
- Eric — Scrum Master در تیمی دیگر.
پردهٔ ششم: دور پیروزی
ساعت 11:30 شب بود و همه هنوز در دفتر بودند، اما نه برای کار. تیم اوایل همان هفته Lolleaderz.com را Live کرده بود و Reviewهای عالی و تعداد روبهرشدی از کاربران داشت. مدیرعامل از Release Party کوچکی که Roger و Avi در نظر داشتند خبردار شد و اجازه نداد کوچک بماند؛ Catering، DJ و Open Bar آورد. Roger و Avi هم تا آن لحظه حسابی نوشیده بودند.
Roger تلوتلوخوران نزد Eric رفت که با چند نفر از اعضای تیم حرف میزد و گفت: «بدون تو نمیتوانستیم این کار را انجام دهیم!»
Eric لحظهای فکر کرد: «خیلی لطف داری، اما به کاری که من انجام دادم فکر کن. در واقع هیچکدام از کارهای پروژه را من انجام ندادم، درست است؟ فقط چند مشکل را نشان دادم، راهحلهایی را که برای خودم جواب داده بود پیشنهاد کردم، و گاهی اجازه دادم وارد بعضی مشکلها شوید تا خودتان ببینید چه چیزی اشتباه است.»
Avi هم رسید: «اتفاقاً دربارهٔ همین! چند جای مسیر واقعاً سخت شد. چرا نمیتوانستیم از آنها دوری کنیم؟ البته شکایتی ندارم؛ نتیجه خودش حرف میزند.»
حالا بیشتر تیم و چند Account Manager جمع شده بودند. Eric گفت: «اگر آن جلسهٔ افتضاح با Account Managerهای دیگر اتفاق نمیافتاد، آیا اصلاً User Storyها را میساختید؟ آیا Project Velocity خودتان را میشناختید و میتوانستید Sprintها را برنامهریزی کنید؟»
Roger فکر کرد: «یعنی میگویی تنها راه یادگرفتن، افتادن در دردسر است؟»
Eric گفت: «من برعکس به آن نگاه میکنم و مثبت فکر میکنم. قسمتهای سختی که به آنها میخورید دلیل خوبی میشوند که با هم کار کنید و دربارهٔ مؤثرترشدن فکر کنید. راه بهبود را پیدا میکنید و بهعنوان تیم رشد میکنید.»
صفحهٔ PDF 179
سرهای زیادی با تأیید تکان خورد. ناگهان صدایی از پشت آمد: «این همان چیزی است که میخواهم بشنوم!» مدیرعامل بود، کاملاً راضی: «من برای آیندهٔ این تیم چیزهای بزرگی میبینم. کارتان عالی بود!»
بازگشت به ارزشهای Scrum
Roger، Avi و تیم در پروژهٔ Lolleaderz.com با مشکلهای زیادی روبهرو شدند. برای بسیاری از تیمها همین مسائل میتوانست کل پروژه را غرق کند و شکستی شبیه CHAOS Report بسازد. چرا این تیم توانست مشکلات را به فرصت تبدیل کند، از آنها یاد بگیرد و موفق شود؟
یکی از تفاوتهای بزرگ، سلاح پنهان Roger و Avi بود: Mentor مؤثری به نام Eric که میتوانست آنها را از موانع عبور دهد. نخستین کار Eric این بود که به Roger، Avi و تیم کمک کند ارزشهای Scrum را بفهمند: Commitment، Respect، Focus، Openness و Courage. با داستان Pig و Chicken معنای Commitment را روشن کرد. به آنها کمک کرد Daily Scrum مؤثرتری اجرا کنند و از طریق آن Focus را بالا برد. نشان داد با گوشدادن به یکدیگر میتوان Mutual Respect ساخت. با بهترکردن Sprint Planning و Review و Backlog از طریق User Story و Velocity، پروژه برای Account Managerها و CEO شفافتر شد و Openness رشد کرد. وقتی شرایط سخت شد نیز Eric نشان داد تیم Courage دارد به حقیقت پایبند بماند، حتی اگر کوتاهمدت برخی افراد ناراحت شوند.
هر پروژه Challenge و Problem دارد. وقتی Methodology یا Practice تازهای را برای اولین بار امتحان میکنید، کمبود تجربه، سوءبرداشت و اشتباههای عادی میتوانند مشکلها را بزرگتر کنند. Mentor خوب این را میداند. بهجای تلاش برای جلوگیری از همهٔ اشتباهها، از آنها برای ساخت تجربهٔ یادگیری استفاده میکند. این کار letting the team fail یا «اجازهدادن به تیم برای شکست» نام دارد و یکی از عناصر پایهٔ Coaching است.
Lyssa Adkins در Coaching Agile Teams میگوید مضمون این اصل چنین است: اجازه دهید تیم شکست بخورد؛ نه اینکه بیتفاوت بایستید و ببینید تیم از صخره سقوط میکند، بلکه از دهها فرصتی که در هر Sprint پدید میآید استفاده کنید تا تیم بعضی خطاها را تجربه کند. تیمی که با هم شکست میخورد و با هم Recover میکند قویتر و سریعتر از تیمی است که دائماً از هر خطا محافظت میشود. حتی ممکن است تیم شما را غافلگیر کند و چیزی که تصور میکردید آسیبزاست واقعاً برایش کار کند.⁸
⁸ Lyssa Adkins, Coaching Agile Teams, Addison-Wesley, 2010.
صفحهٔ PDF 180
خواندن واژههایی مثل Courage، Openness، Commitment، Focus و Respect و موافقت با اینکه «ایدههای خوبی هستند» یک چیز است؛ رفتن به دفتر رئیس و گفتن اینکه تیم بهدلیل کمبود زمان Sprint نمیتواند Feature وعدهدادهشده را تحویل دهد چیز دیگری. وقتی شغل انسان در خطر است Courage دشوار میشود.
بدون پایبندی به این ارزشها Scrum موفق ندارید. حقیقت این است که شرکتهای زیادی فرهنگ سازگار با Scrum دارند، اما بعضی ندارند. حتی ممکن است برای مدیری کار کنید که Project Management فرماندهی و کنترل را مطالبه میکند و اگر سعی کنید تیم خودسازمانده بسازید اخراجتان کند.
تیم Scrum از اشتباهها یاد میگیرد؛ همینطور بهعنوان تیم رشد میکند. پس به فرهنگی نیاز دارد که خطا در آن قابل تحمل باشد. این یکی از دلایل اهمیت Collaboration و Respect در Scrum است. اما حتی اگر خود تیم ظرفیت یادگیری از خطا را داشته باشد، شاید در شرکتی باشد که اشتباه را نمیپذیرد.
Grady Booch، نوآور Software Engineering، در Beautiful Teams توضیح میدهد یکی از نشانههای سلامت سازمان این است که نسبت به شکست بیش از حد هراسان نباشد. سازمانهایی که اصلاً شکست را تحمل نمیکنند معمولاً کمنوآورتریناند و فضای لذتبخشی هم ندارند، چون افراد از ترس شکست محافظهکارترین اقدام را انتخاب میکنند. در مقابل، سازمانی که تا حدی آزادی شکست دارد ــ نه در حد نابودکردن کسبوکار ــ معمولاً مولدتر است، چون افراد هنگام نوشتن هر Line of Code از جان خود نمیترسند.
پس اگر در سازمانی هستید که Failure مساوی Firedشدن است، چه میکنید؟ آیا Scrum اصلاً ممکن است؟
Practiceها بدون ارزشها هم کار میکنند — فقط اسمش را Scrum نگذارید
هر تیم در هر شرکتی از روز اول نمیتواند Self-organize شود و این اشکالی ندارد. اگر فرهنگ شرکت با Scrum Values هماهنگ نیست، وظیفهٔ فردی که Scrum را وارد میکند کمک به اطرافیان برای درک ارزشهاست. بهترین روش lead by example است: در کار خود Openness نشان دهید، به دیگران Respect بگذارید و هنگام مشکل Courage داشته باشید. یافتن Mentor خوب نیز میتواند نشان دهد این رویکرد واقعاً عملی است و نگرشها را تغییر دهد. به همین دلیل بسیاری از تیمها Consultant بیرونی را بهعنوان Mentor میآورند، چون گاهی مدیران راحتتر حرف کسی خارج از شرکت را دربارهٔ نیاز به تغییر میشنوند.
اما گاهی با وجود انجام همهٔ کارهای درست، فرهنگ غالب شرکت بسیار دور از Scrum Values است. در آن صورت Self-organization و Collective Commitment ممکن است فعلاً برای تیم دستنیافتنی باشد.
صفحهٔ PDF 181
و همانطور که Ken Schwaber نشان میدهد، بدون Self-organization و Collective Commitment، Scrum واقعی ندارید.
و این هم اشکالی ندارد.
حتی بدون «قلب و روح» ارزشها و بدون Self-organization و Collective Commitment، Scrum Practiceهای بسیار خوبی دارد. سادهاند، پیادهسازیشان آسان است و اغلب میتوان آنها را درون تیم، بدون گرفتن اجازه انجام داد.
اگر میدانید در محیطی هستید که میتوانید Practiceها را اجرا کنید اما Values را نه، باز هم میتوانید به نتایج «better-than-not-doing-it» برسید؛ یعنی بهتر از این است که هیچکدام را انجام ندهید. پس انجامشان دهید، اما دقیقاً بدانید چه چیزی را اجرا میکنید و مرزها کجاست.
فقط Practiceها را اجرا نکنید و بعد نگویید Scrum را کامل Adopt کردهاید. این ادعا بعداً دردسر میسازد. کسانی که دربارهٔ «hyper-productive teams» و «astonishing results» خواندهاند خواهند پرسید چرا شما چنین نتیجهای ندارید و پاسخ خوبی نخواهید داشت. بدتر، تیم با هیجان وارد Scrum میشود و بعد میبیند زندگی کاری فقط کمی تغییر کرده است. ممکن است نتیجه بگیرد همین سقف توان تیم است؛ و اگر تفاوت چندانی با گذشته ندارد، ناامید و Demotivated میشود. این تجربه حتی تلاشهای بعدی برای بهبود را مسموم میکند، چون تیم محدودیتها را خارج از کنترل خود تصور میکند.
اگر به همه بگویید «Scrum را انجام دادید، تبریک!» ممکن است این تصور ایجاد شود که Scrum چیزی بیش از تغییر نام Status Meeting به Daily Scrum و Requirements به Backlog نیست. این برای Agile Adopter خطرناک است، چون مشکلات بنیادی که قرار بود با Scrum حل شوند هنوز باقیاند. مردم نتیجه میگیرند Scrum قادر به حلشان نیست، یا حتی بدتر: مشکلهایی مانند «Developers can’t estimate»، «Software is always buggy» و «Projects always run late» را واقعیتهای تغییرناپذیر زندگی میپندارند.
اگر مرتب ادعا کنید Scrum قرار است مشکلاتی را حل کند که آشکارا حل نشدهاند، به چشم Agile Zealot مزاحم دیده میشوید. مردم از شنیدن دربارهٔ Scrum بدون دیدن نتیجه خسته میشوند؛ هم به حرفهٔ شما آسیب میزند و هم تصور افراد از Scrum را خراب میکند.
راه دیگری وجود دارد: Practiceهایی بدهید که تیم امروز انجام دهد، اما Visionی هم از چیزی که فردا میتواند به آن برسد ارائه کنید. آنگاه صرفاً بهخاطر چند Practice ساده تصور نمیکنند Scrum کامل انجام شده است.
صفحهٔ PDF 182
اگر صادقانه بگویید Practiceهای Scrum را گذاشتهاید، اما هنوز روی Self-organization و Collective Commitment کار نکردهاید چه؟ بهجای ادعای «Scrum کامل»، روشن میگویید Practiceها اجرا شدهاند اما برای Values، Self-organization و تعهد واقعی به Value هنوز مسیر زیادی مانده است.
مزیت نخست این است که وعدهای ندادهاید که نتوانید نگه دارید. گفتهاید شرایط کمی بهتر میشود. پس وقتی نتیجهٔ بهتر از «هیچکاری نکردن» ظاهر میشود، مردم بهجای ناراحتی از اینکه تمام مشکلات شرکت حل نشده، خوشحالاند نرمافزار بهتر، سریعتر و آسانتر ساخته میشود. وقتی سابقهٔ Improvement، حتی کوچک، دارید صحبتکردن دربارهٔ ارزشهای تازه برای شرکت آسانتر است. از دید Boss هم بهجای متهمکردنش به «Scrum کافی نبودن»، امروز نتیجهٔ خوب میدهید و فردا نتیجهٔ بهتر وعده میدهید، به شرط اینکه اجازه دهد تیم این Values تازه را امتحان کند.
آیا فرهنگ شرکت شما با Scrum Values سازگار است؟
همهٔ شرکتها آمادهٔ کنارگذاشتن Command-and-control و آغاز Self-organization نیستند و همهٔ تیمها هم آمادهٔ Collective Commitment نیستند. برای فهم آمادگی، بررسی کنید آیا Culture با Scrum Values سازگار است. سؤالهای زیر را صادقانه از خودتان، تیم و Manager بپرسید.
آمادگی برای Commitment
آیا شما، تیم و Boss با این موارد راحت هستید؟
- کنترل Project را رها کنید و به تیم اعتماد کنید که دربارهٔ چیزی که تحویل میشود تصمیم بگیرد؟
- تنها نروید چیزی بسازید و فقط در پایان آن را بدون گفتوگو با تیم Integrate نکنید؟
- یک «single, wringable neck» نداشته باشید؟⁹
- Comment و Feedback را بشنوید و به دیگران نگویید «به کار خودت برس»؟
- واقعاً مسئولیت بپذیرید؟ آیا همهٔ اعضا همین احساس را دارند؟
آمادگی برای Respect
- به تیم اعتماد کنید کار درست را انجام دهد و هر Feature را در بهترین زمان ممکن بر اساس Relative Value و روند واقعی Project تحویل دهد، حتی اگر پروژه بیشتر از انتظار طول بکشد؟
- به تیم زمان کافی بدهید و Overtime اجباری مطالبه نکنید؟
- به تیم اعتماد کنید Task مناسب خود و Project را انتخاب کند، بهجای اتکا به Roleهای سخت، RACI Matrix و مانند آن؟
- دیگر نتوانید بگویید نمیدانم چرا تیم چنین تصمیمی گرفت، چون تصمیمها شفافاند؟
آمادگی برای Focus
- هرگز از فردی نخواهید کاری خارج از Sprint جاری انجام دهد؟
- هرگز از کسی نخواهید کاری را انجام دهد که کل تیم قبول نکرده است، صرفاً چون «الان لازم دارم»؟
- ارزشمندترین موضوع برای Company را بالاتر از دیگر دغدغهها بگذارید؟
- از قبل نتوانید اعضا را مجبور کنید Taskهای خاص را با ترتیب تحمیلی انجام دهند؟
آمادگی برای Openness
- واقعاً حرف دیگران را بشنوید و دربارهاش فکر کنید؟
- اگر قبلاً به Planning یا User فکر نمیکردید، حالا فکر کنید؟
- اگر قبلاً Technical Detail حوزهٔ شما نبود، دربارهاش فکر کنید؟
- ببینید Programmer کنار شما روی چه چیزی کار میکند و آیا با Overall Goal سازگار است؟
- اجازه دهید همان Programmer دربارهٔ Work شما نیز همینطور فکر کند؟
آمادگی برای Courage
- نتوانید نبود Planning را گردن Project Manager بیندازید؟
- نتوانید Requirements نامناسب را گردن Product Owner یا Senior Manager بیندازید؟
- زمان واقعی برای فهم Users صرف کنید؟
- چیزی بسازید که Perfect نیست، چون چیزی که User الآن بیش از همه نیاز دارد «به اندازهٔ کافی خوب» است؟
اگر پاسخ بیشتر این سؤالها «بله» است، Culture تیم، Manager و Company احتمالاً با Scrum Values سازگار است. اگر برای هر Value بیش از یکی دو «نه» دارید، همانها نقطهٔ شروع گفتوگوی واقعبینانه و Open با تیم و Boss هستند. اگر حتی تصور چنین گفتوگویی غیرواقعی به نظر میرسد، برای گرفتن حداکثر ارزش Scrum قطعاً باید روی Openness کار کنید.
⁹ عبارت «single, wringable neck» در بعضی شرکتها لقب Product Owner است؛ تیم شاید Self-organization و Collective Commitment را بفهمد، اما بیرون تیم هنوز Product Owner را تنها فرد پاسخگو ببیند.
پرسشهای متداول
مگر Backlog و Task Board اساساً همان Project Schedule نیستند؟ آیا Scrum همان کار قبلی را با اسم جدید انجام نمیدهد؟
میتوان ابزارهای Scrum را طوری استفاده کرد که بسیار شبیه Project سنتی باشند؛ مثلاً بعضی تیمها User Storyهایی مینویسند که شبیه Use Case است. اما تیمی که شیوهٔ عملش را تغییر ندهد نتیجهاش هم تغییر نمیکند. چنین تیمی Mindset لازم برای Scrum را نمیپذیرد و فقط به Improvement محدود میرسد.
تفاوت کلیدی این است که Plan تیم Scrum بعد از ساختهشدن روی قفسه نمیرود تا فقط هنگام انحراف Update شود. تیم هر روز در Daily Scrum آن را Inspect میکند. بسیاری از تیمهای مؤثر علاوه بر آن حداقل یک ساعت در هفته همراه Product Owner Backlog را Update یا «Groom» میکنند. Product Owner دائماً Feature احتمالی تازه کشف میکند. در جلسهٔ هفتگی، Storyهای تازه با Conditions of Satisfaction ساخته، Story Point داده و بر اساس Value در Product Backlog Prioritize میشوند.
این کار دو ابزار مهم میدهد. نخست، تمرین دائمی Estimation؛ در نتیجه وقتی Change رخ میدهد تیم میداند اثر آن را چگونه تخمین بزند. دوم، گفتوگوی مداوم با Product Owner دربارهٔ اینکه کدام Story ارزشمندتر است. برای این گفتوگو تیم باید Goalهای Project را واقعاً بفهمد. Elevating Goal کمک میکند؛ وقتی Product Owner مرتب توضیح میدهد چرا User به نرمافزار نیاز دارد، انتخاب Story باارزش آسانتر میشود.
این همان Planning در Last Responsible Moment است: تیمی که همیشه در حال Planning است و زمان مشخصی برای آن کنار گذاشته، بنابراین Planning رفتار طبیعی اوست.
مگر Programmerها در Planning بد نیستند، بهخصوص در Software Projectهای ذاتاً غیرقابل پیشبینی؟
این یکی از رایجترین سوءبرداشتها و گاهی Self-fulfilling Prophecy است. واقعیت این نیست که فقط Programmerها در Planning بدند؛ تقریباً همه ابتدا در Planning بدند. اگر انسانها همیشه عالی برنامهریزی میکردند، همهٔ Businessها موفق میشدند، Marketها همیشه بالا میرفتند و هیچ ازدواجی به Divorce نمیرسید.
Planning با پیشبینی آینده یکی نیست. بعضی شرکتها به افسانهٔ Perfect Project Plan باور دارند: Developer Estimate کاملاً دقیق میدهد و Project Manager هر Risk را پیشبینی میکند و Contingency دقیق میگذارد. Plan آنها هم تغییر میکند ــ گاهی بیشتر ــ چون در ابتدای Project Detail بسیار زیادی گذاشتهاند و Detailهای کوچک بیشترین احتمال خطا را دارند.
Scrum از بالا به پایین مؤثرتر Plan میکند. ابتدا Broad Strokeها در Product Backlog قرار میگیرند؛ فقط به اندازهای Detail که Product Owner و Users بتوانند Value را مقایسه کنند. Detailed Planning در ابتدای Sprint و فقط برای Backlog Itemهایی انجام میشود که انتظار میرود وارد Sprint شوند. بیشتر Planning روزبهروز و ساعتبهساعت به Daily Scrum واگذار میشود. اگر Detail خاصی لازم باشد همان ابتدا انجام میشود، اما استثناست و در Daily Scrum قابل بازبینی است.
آیا بهتر نیست همهچیز را از ابتدا Plan کنیم و بعداً Plan را بازبینی کنیم؟
در عمل بسیاری از تیمها دیدهاند تصمیمگیری در Last Responsible Moment انعطاف بیشتری میدهد و Planning را مؤثرتر میکند. تصمیم به کسانی واگذار میشود که بهترین توان تصمیم دارند و تا زمانی که مسئله بهتر فهمیده نشده مجبور نیستند تصمیم را قطعی کنند.
یکی از علتهای Failure برنامههای بزرگ این است که Planning سطح پایین از ابتدای Project غیرواقعی است و از Developer اطلاعاتی میخواهد که هنوز ندارد. این وضعیت چرخهٔ CYA ایجاد میکند: Project Manager Developer را بابت Estimate ضعیف سرزنش میکند و Developer Manager را بابت Plan بد. افراد Blame میشوند اما قربانی واقعی Quality نرمافزار است.
Scrum با مطالبهٔ Planning فقط در سطح Detailی که امروز میدانیم، و بهتعویقانداختن Detailهای ناشناخته تا Last Responsible Moment، ما را از این چرخه آزاد میکند. Plan هر روز Review، Inspect و Adapt میشود تا وقتی ــ نه اگر ــ اشتباه بود سریع واکنش نشان دهیم. در مقابل Scrum از همه Genuine Commitment برای تحویل ارزشمندترین Software ممکن میخواهد.
آیا قول Working Software در پایان هر Sprint غیرواقعی نیست؟ Featureهایی که Demoشدنی نیستند چه؟
بعضی Featureها مثل صفحهٔ جدید Web یا Button یا Behavior تازه بهسادگی Demo میشوند: User Story را بردارید، Software را اجرا کنید و Conditions of Satisfaction را قدمبهقدم نشان دهید. اما بهینهسازی Database، تغییر Service یا Nonfunctional Change چطور؟
هر Software Change به شکلی قابل Demonstrate است و یافتن آن Demo برای Programmer مفید است. اگر Sprint روی Database Change متمرکز بوده، Developerها برای Verify کردن Change حتماً Code یا Scriptهایی برای Insert، Update، Delete و سنجش نتیجه نوشتهاند. بهجای Throwaway Code، میتوان آن را در برنامهٔ کوچک Console یا Scriptهای Version-controlled قرار داد، کمی Polish کرد و در Sprint Review نشان داد. حالا همان چیزی که Demo است بعداً Test قابل استفادهٔ مجدد نیز میشود.
برای Performance Change میتوان Before/After Test نشان داد. برای Service Architecture میتوان برنامهٔ کوچکی نمایش داد که Data retrieved از API جدید را نشان دهد. Demo نهفقط Visibility میدهد، بلکه ابزار Test قابل تکرار تولید میکند.
در Demoهای Nonfunctional باید با زبانی حرف زد که Users بفهمند. معمولاً Userها بسیار بیشتر از چیزی که Developer تصور میکند Technical Detail را میفهمند. مهمتر اینکه Stakeholder واقعاً میبیند تیم چه ساخته است. بدون Demo ممکن است از بیرون Sprint «هیچ چیز ساخته نشد» به نظر برسد. این Visibility کمک میکند Deadlineهای آینده واقعبینانهتر باشند و Pressure برای کوتاهکردنشان کمتر شود.
Bug بحرانی Production را نمیتوان تا پایان Sprint منتظر گذاشت. Scrum دربارهٔ Support غیرواقعی نیست؟
همهٔ Software Teamها با کار غیرمنتظره مواجهاند. اگر Bug سایت باید فوراً Fix و Push شود، تنها گزینه انجام همین حالاست. Scrum در واقع برای این وضعیت بهتر از بسیاری از روشهای command-and-control آماده است، چون تیم هر روز برای کشف Change و Adaptکردن Plan جلسه دارد.
اگر مسئله واقعاً تا Sprint بعد صبر نمیکند و Product Owner از طرف Company موافق است، آیتم به Sprint Backlog اضافه و احتمالاً اولویت اول میشود. سپس Daily Scrum، Task Board، Burndown، User Story، Story Point و Velocity کمک میکنند همه از اثر Change آگاه بمانند.
تفاوت مهم این است که Scrum اجازه نمیدهد وانمود کنیم Work اضافه هزینه ندارد. Burndown یک جهش نشان میدهد و همه میبینند احتمالاً Work دیگری باید از Sprint خارج شود. چون تیم Scrum به Value متعهد است و مرتب Working Software نشان داده، Userها معمولاً Trust و Visibility بیشتری دارند و دربارهٔ ظرفیت Sprint واقعبینانهتر میشوند.
Product Owner با این همه Authority، ارتباط با Customer و زمان روزانه برای Team غیرواقعی به نظر میرسد. یعنی Scrum عملاً شدنی نیست؟
برعکس، تیمهای Scrum مؤثر زیادی در Industryهای مختلف دقیقاً همینگونه کار میکنند. Company میفهمد قراردادن فردی با این میزان Authority و Seniority بهصورت Full-time در تیم مزیت بزرگی ایجاد و در بلندمدت Development Work را کم میکند. این اتصال مستقیم به Value واقعی Software کلید بسیاری از «astonishing results» است.
البته Cost واقعی دارد: Product Owner خوب باید از Work قبلیاش جدا شود و معمولاً Salary همان است. Companyای که به Scrum اعتماد کرده میبیند این Cost در برابر تیمی که با Needهای متغیر Business همگام است ارزش دارد.
اگر چنین چیزی در شرکت شما غیرواقعی است، این بیشتر از اینکه نقد Scrum باشد، نشان میدهد Company چه مقدار برای Software تیم Value قائل است. بعضی شرکتها صریحاً میگویند Executive و Business Person مهم را با سؤالهای روزمرهٔ Software «مزاحم نشوید». این یکی از رایجترین نقاط Clash بین Scrum Values و Company Values است.
به همین دلیل برخی Companyها BRUF یا Big Requirements Up Front و Waterfall کماثرتر را انتخاب میکنند. هزینهٔ Document، Business Analyst، QA و Tester بیشتر را میپذیرند تا زمان Executive کمتر صرف Team شود. ممکن است باز هم Software خوب ساخته شود، اما Risk Featureهای بلااستفاده بالا میرود.
اگر Time تیم بسیار کمارزشتر از Time Business Person دیده شود، BRUF از دید Cost-benefit ممکن است منطقی باشد. راه پیش رو میتواند آموزش Scrum و Agile Values به Managerها باشد. اگر نتیجه نداد، حداقل Practiceهای Scrum را بگذارید و Track Recordی از نتیجهٔ بهتر ــ نه لزوماً شگفتانگیز ــ بسازید.
Estimateهای Task از کجا میآیند؟ Planning Poker چیست؟
یکی از محبوبترین روشها Planning Poker است، یکی از GASPها که James Grenning، از سازندگان Agile Manifesto، ابداع کرد و Mike Cohn در Agile Estimating and Planning مشهورش کرد.¹⁰
روند اصلی:
- به هر Estimator یک Deck کارت داده میشود که روی هر کارت یکی از Estimateهای معتبر نوشته شده؛ مثلاً
0, 1, 2, 3, 5, 8, 13, 20, 40, 100. کارتها از قبل آماده میشوند و عددها باید از آنطرف میز خوانا باشند. - Moderator توضیح User Story یا Theme را میخواند. معمولاً Product Owner یا Analyst است، اما Role امتیاز ویژهای ندارد. Product Owner به سؤالها پاسخ میدهد.
- پس از پاسخ همهٔ سؤالها، هر Estimator بهطور خصوصی کارت Estimate خود را انتخاب میکند. تا انتخاب همه کارتها نشان داده نمیشوند؛ سپس همزمان برگردانده میشوند.
- تفاوت زیاد میان Estimateها خبر خوبی است. Estimatorهای High و Low توضیح میدهند چه چیزی در ذهن داشتهاند. هدف Attack نیست؛ هدف فهمیدن Reasoning و کشف اختلاف در برداشت یا Risk است.
- گفتوگو و دورهای بعدی تا رسیدن به درک مشترک ادامه مییابد.
Planning Poker مؤثر است چون Expertise، Opinion و Idea افراد را در یک عدد قابلارتباط جمع میکند. عددهای روی کارت جادویی نیستند؛ بعضی تیمها Fibonacci 1,2,3,5,8,13,21,34,55,89 استفاده میکنند. فاصلهٔ عددها کمک میکند تفاوت معنادار Effort بهتر دیده شود.
¹⁰ برای مطالعهٔ بیشتر، PDF مربوط به Planning Poker از James Grenning پیشنهاد شده است.
تیمهای Global را چگونه مدیریت کنیم؟
پراکندهبودن تیم در Officeهای سراسر دنیا Challenge بزرگی است، اما ناممکن نیست. تیمهای Agile غیر Collocated هم میتوانند Software عالی بسازند، ولی هرچه Face-to-face Communication کم و Channel کماعتمادتر شود، Risk خطاهای «game of telephone» بیشتر میشود.
یک راه Scrum این است که Global Team به Scrum Teamهای کوچک Collocated شکسته شود. علاوه بر Daily Scrum، جلسهٔ روزانهٔ دیگری به نام Scrum of Scrums تشکیل میشود؛ نمایندگان تیمها سه سؤال را پاسخ میدهند، پیرامون Backlog بزرگتر Global Project Self-organize میشوند و Taskهای خودتخصیصیافته را به تیمهای خود برمیگردانند. این روش Plan بزرگتری میدهد که هر روز Inspect میشود.
Scrum of Scrums Silver Bullet نیست و همهٔ مسئلههای Global Team را حل نمیکند. دشوارترین بخش، حفظ Motivation تکتک اعضا با Shared Elevating Goal است. Product Owner باید Vision را در Time Zoneهای مختلف و Channelهایی مثل Teleconference و Email منتقل کند که از گفتوگوی حضوری ضعیفترند.
حتی Developer خوشنیت هم ممکن است روی کار جذاب ولی کمارزش منحرف شود. Scrum جلوی Sidetrack را میگیرد؟
نه همیشه. Jeff Sutherland و Scott Downey در مقالهٔ «Scrum Metrics for Hyperproductive Teams»¹¹ دقیقاً این مسئله را بررسی کردند. آنها با سنجش تیمهای Scrum گزارش کردند تیم مؤثر ممکن است Project را تا 400% سریعتر از تیم کماثر تحویل دهد و Focus روی Work ارزشمند در این نتیجه نقش مهمی دارد.
یکی از تغییرهای پیشنهادی آنها برای Daily Scrum این است که بهجای حرکت Person-by-person، Sprint Backlog را از بالاترین Value به پایین بررسی کنید و برای هر Priority بپرسید:
- دیروز ما روی Priority 1 چه چیزی به دست آوردیم؟
- Contribution ما روی Priority 1 چند Story Point ارزش داشت؟
- Plan ما برای تکمیل Priority 1 امروز چیست؟
- چه چیزی ما را Block کرده یا ممکن است امروز کند کند؟
کل تیم پاسخ میدهد و سپس سراغ Item بعدی در Value Order میرود تا Itemها یا Timebox تمام شوند.
این تغییر جلوی Disconnectشدن افراد از Daily Scrum را میگیرد؛ مثلاً «دیروز روی Code خودم بودم، امروز هم همان، Roadblock ندارم، بعدی...» و همه را روی Highest-value Item متمرکز میکند. حتی تیم Agile مؤثر اگر Developerها روی Taskهای شخصی و جذابتر تمرکز کنند میتواند وارد قلمرو CHAOS Report شود.
Daily Scrum در اصل نوعی Formal Inspection Meeting است که هدفش بالابردن Quality برنامهریزی و Communication است، با این تفاوت که برای Team جذاب و Engaging طراحی شده است. یکی از بهترین ویژگیهای Scrum همین Evolving بودن دائمی آن و مشارکت Practitionerهای برتر در بهبود روش است.
¹¹ Scott Downey & Jeff Sutherland, “Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft,” 2013.
کارهایی که همین امروز میتوانید انجام دهید
- اگر User Story ندارید، برای یکی از Featureهای فعلی یک Story بنویسید و با تیم Review کنید.
- امروز Planning Poker را امتحان کنید و با تیم چند Task فعلی را Estimate کنید؛ کارت چاپی، خریداریشده یا Online قابل استفاده است.
- بعد از ساخت Estimate، روی Whiteboard یا کاغذ بزرگ Burndown Chart بسازید و ببینید تا پایان Project یا Iteration چه رفتاری دارد.
- بررسی کنید آیا از Project یا Iteration قبلی میتوانید Project Velocity به دست آورید.
برای مطالعهٔ بیشتر
- Agile Project Management with Scrum — Ken Schwaber، Microsoft Press، 2004.
- User Stories Applied — Mike Cohn، Addison-Wesley، 2004.
- Agile Estimating and Planning — Mike Cohn، Addison-Wesley، 2005.
- Retrospectives: Making Good Teams Great — Esther Derby و Diana Larsen، Pragmatic Bookshelf، 2006.
نکتههایی برای مربیان Agile
- یکی از بزرگترین Challengeهای Coaching، کمک به تیم برای فهم واقعی Collective Commitment است. به اعضایی توجه کنید که از Estimate دادن یا Planning مشارکتی دوری میکنند یا میخواهند Scrum Master همهٔ Planning را انجام دهد.
- با افراد دربارهٔ Project Goal حرف بزنید و Tunnel Vision را پیدا کنید؛ کسی که فقط Feature یا Story «خودش» را میبیند. تشویقش کنید Task از Story دیگری بردارد و اجازه دهد دیگران هم روی Story او کار کنند.
- Scrum Master را Coach کنید تا همهٔ Data را Visible کند: Burndown و Task Board روی دیوار و Daily Scrum در Area قابل مشاهده.
- Political Dynamic را بشناسید. شاید تیم از Publicکردن Progress واقعی ناراحت باشد چون در گذشته Senior Manager با کوچکترین انحراف شدیداً عصبانی میشده است. وظیفهٔ Coach حل مستقیم این مشکل نیست؛ کمک کنید تیم آن را ببیند و بفهمد Culture شرکت برای پذیرش مؤثرتر Scrum باید بهآرامی تغییر کند.
صفحهٔ PDF 194