فصل ۱۰ — Agile Coach
در فصلهای قبل Scrum، XP، Lean و Kanban را دیدیم، شباهتها و تفاوتهایشان را شناختیم و Practiceها، Valueها، Principleها و Mindsetهایشان را بررسی کردیم. اما میان خواندن دربارهٔ Agile و تغییر واقعی روش کار یک Team فاصلهٔ بزرگی وجود دارد.
بعضی Teamها یک کتاب Scrum یا XP میخوانند، Practiceها را اجرا میکنند و فوراً Result خوب میگیرند. علت معمولاً این است که Mindset آنها از قبل با Agile Manifesto و Methodology انتخابی سازگار است؛ Adoption برایشان آسانتر است چون لازم نیست روش فکرکردنشان دربارهٔ Work را از پایه عوض کنند.
اما اگر Environment با Agile Valueها ناسازگار باشد چه؟ اگر Individual Contribution بسیار بیشتر از Team Effort Reward شود، Mistake بهشدت Punish شود، Innovation خفه شود یا Team هیچ Access واقعی به Customer/User نداشته باشد؟ اینها Barrierهای Adoption هستند.
اینجاست که Agile Coach وارد میشود: فردی که Team را در Adoption Agile کمک میکند، اعضا را از Barrierهای Mental، Emotional و Technical عبور میدهد و فقط «چطور» Practice را نمیگوید، بلکه «چرا»ی آن را روشن میکند. Coach همچنین با Discomfort و Fear طبیعی ناشی از Change کار میکند.
در طول کتاب بارها Better-than-not-doing-it Result دیدیم: Team اسم Practice را Adopt میکند، اما Mindset و Attitude همکاری تغییر نمیکند؛ Improvement حاشیهای میگیرد و بعد تصور میکند Agile همین بوده است. Team برای Result واقعی به Mindset سازگار با Value/Principleهای Agile و Methodology خاص نیاز دارد.
هدف Coach کمک به Team برای رسیدن به Mindset Agileتر است: Methodology متناسبتر را انتخاب کند، Practiceها را به شکلی Introduce کند که Team بتواند آنها را یاد بگیرد، و از خود Practiceها بهعنوان مسیر Internalize کردن Valueها و Principleها استفاده کند.
روایت: پردهٔ سوم — Just One More Thing، دوباره!
Dan دوباره Catherine را صدا میزند: «خبر عالی دارم.» Catherine به تجربه میداند این جمله معمولاً Request اضطراری جدیدی است که Project را از مسیر خارج میکند.
اما این بار Dan از موفقیت Agile Team تعریف میکند. Catherine به هشت ماه گذشته فکر میکند که همراه Timothy با Kanban Process را بهتر کردهاند. Bottleneckهای مختلف را پیدا کردهاند، مخصوصاً نقطهای که Dan و Managerهای دیگر Featureهای جدید را ظاهراً Random روی Team میریختند. با ایجاد Queue اتفاق مهمی افتاد: Managerها بهجای انتظار Capacity نامحدود از Team، برای Position در Queue با هم مذاکره کردند و بهتدریج Requestهای غیرممکن کمتر شد.
Dan میگوید Parent Company این Success را دیده و میخواهد آنها Teamهای دیگر را آموزش دهند. Catherine میپرسد: «یعنی میخواهی Coachشان کنم؟» Dan میگوید دقیقاً. Catherine جواب میدهد هیچ ایدهای ندارد چطور Coach باشد. Dan با همان سبک قدیمی میگوید: «اختیاری نیست؛ فقط Buck Up and Do It.»
Coachها میفهمند چرا مردم همیشه Change نمیخواهند
بیشتر افراد Organization میخواهند کارشان را خوب انجام دهند و Peers و Supervisorها آنها را Competent ببینند. وقتی فرد در Job خودش Comfort و Familiarity پیدا کرده، آخرین چیزی که میخواهد این است که کسی بیاید و مجبورش کند روش کاملاً جدیدی Adopt کند. — Andrew Stellman و Jennifer Greene، Applied Software Project Management
Agile Coach بخش زیادی از وقتش را صرف کمک به افراد برای Change روش کار میکند. مشکل این است که Coach Big Picture را میبیند، ولی Team اغلب فقط Ruleهای جدیدی را میبیند که از آنها خواسته شده رعایت کنند.
Practice آشنا میشود، ولی Purpose از بین میرود
Team خوشنیت ممکن است Practice را طوری تغییر دهد که دیگر Function اصلیاش را انجام ندهد:
- Daily Scrum به Daily Status Meeting تبدیل میشود؛ Scrum Master عملاً Project Manager میشود و Work Assign میکند. در حالی که هدف Daily Scrum تقویت Self-Organization و Control Team بر Plan است.
- User Story به Business Requirements Document اضافه میشود، ولی BRUF همانطور باقی میماند؛ فقط Label جدیدی روی Waterfall Spec آمده است.
- در XP، Team بهجای TDD فقط بعد از Coding Test زیاد مینویسد تا Code Coverage بالا باشد. چون Test بعد از Design نوشته شده، هیچ تأثیری بر Design ندارد.
افراد واقعاً قصد Adoption دارند، اما Ecosystem بزرگتر Methodology را نمیفهمند. بنابراین Practice را به چیزی تبدیل میکنند که Familiar است. Teamی که فقط Command-and-Control دیده Contextی برای فهم Self-Organization ندارد؛ طبیعی است Daily Scrum را با Status Meeting مقایسه کند.
بیشتر Teamهایی که Agile را Adopt میکنند از قبل Software میسازند و مقداری Success دارند. آنها نمیخواهند چیزی که «کار میکند» را خراب کنند، پس Small Changeهای آشنا را ترجیح میدهند. Roadblock بزرگ زمانی شکل میگیرد که فرد میگوید: «Practiceهای آشنا را Adopt کردم، Team کمی بهتر شد، همین کافی است.» این همان Better-than-not-doing-it Result است که بعدها Hype Agile را ناامیدکننده جلوه میدهد.
Change در Work واکنش Emotional کاملاً منطقی ایجاد میکند
هر Practice جدید Change است و Change ممکن است Fail شود. در محیط Work، Failure میتواند Job را تهدید کند. بنابراین Resistance همیشه Irrational نیست؛ Work منبع درآمد و امنیت خانواده است.
وقتی از فرد میخواهند Skill یا روش جدیدی را سریع Master کند، ذهن ممکن است به شکل ابتدایی چنین ترجمه کند: «دیروز مطمئن بودم میتوانم Jobم را انجام دهم و زندگیام را تأمین کنم؛ امروز دیگر مطمئن نیستم.» این Anxiety توضیح میدهد چرا Change Response گاهی شدید است.
عامل دیگر کمبود Time برای فهم Why است. Agile Adoption اغلب با Pilot Project شروع میشود؛ یک نفر کتاب خوانده و همزمان باید Team را Guide کند، در حالی که Deadline، Bug، Conflict و Changing Requirement نیز وجود دارند. وقتی چیزی کاملاً فهمیده نمیشود، Label Agile باقی میماند ولی Method کار قدیمی میماند: Milestone قدیمی نام Sprint میگیرد، Task Board نصب میشود اما Decision واقعی را تغییر نمیدهد، و Team در Deadline به Habit قبلی برمیگردد.
سپس اعضا نتیجه میگیرند Agile کار نمیکند، در حالی که هرگز Agile واقعی را تجربه نکردهاند.
Coach Context میدهد: Daily Scrum چگونه Self-Organization را تقویت میکند؛ TDD چگونه Functional Thinking و Incremental Design را شکل میدهد؛ User Story چگونه Perspective User را وارد Discussion میکند. هدف عبور از Rule جدید به درک مقصد است.
Warning Signهای مشکل Team با Change
Coach باید جملههایی را که نشاندهندهٔ Discomfort هستند بشنود و Root Concern را بفهمد.
«ما همین الان Software را خوب میسازیم؛ چرا باید عوض شویم؟»
Success را نمیتوان نادیده گرفت. Teamی که Software Deliver کرده حق دارد بداند چرا Change لازم است. «Boss گفته» Morale را خراب میکند. Coach باید Success گذشته را Respect کند و در عین حال Problemهای واقعی تکرارشونده را نشان دهد. Practice Agile برای Problem مشخص Solution دارد؛ وقتی Team Problem و Mechanism Solution را بفهمد، Adoption منطقیتر میشود.
«این خیلی Risky است.»
برای فرد عادتکرده به Command-and-Control، Agile ممکن است Buffers، Risk Register و Bureaucracy محافظ را حذفشده نشان دهد. Project Plan Opaque میتواند Comfort بدهد؛ Milestone مبهم و Buffer اجازه میدهد Status Message کنترل شود.
Agile Principle میگوید Working Software معیار اصلی Progress است. اگر Problem وجود داشته باشد، Visible است. Coach باید Manager، User و Customer را با این Measurement مستقیم Comfortable کند و Environmentی بسازد که Team اجازه داشته باشد امروز Fail کند، اگر فردا از آن Learn میکند. اگر فعلاً Safe Environment ممکن نیست، تغییر Climate باید Goal Evolutionary باشد.
«Pair Programming/TDD برای من کار نمیکند.»
Developer عادتکرده به کار تنها ممکن است واقعاً Pairing را کندکننده احساس کند. اگر Culture Mistake را نابخشودنی میداند، داشتن نفر دیگری کنار Keyboard میتواند اضطراب واقعی ایجاد کند. Senior Developer هم شاید از دادن Keyboard به Junior بترسد.
Coach ابتدا Practiceهایی را انتخاب میکند که با Mindset فعلی Compatibility بیشتری دارند. با تجربهٔ Benefit، Team میتواند Mindset را Shift دهد و Practiceهای دشوارتر را بعداً بپذیرد.
«Agile برای Business ما مناسب نیست.»
این جمله اغلب از Comfort با Up-Front Planning/Design میآید. Manager با Scope و Plan کامل احساس Control میکند؛ Architect با Design کامل پیش از نخستین خط Code همین احساس را دارد. Last Responsible Moment یعنی بخشی از این Control زودهنگام واگذار شود.
هر Business پیچیده است و هر Project Analysis/Planning نیاز دارد؛ Agile Complexity را انکار نمیکند. Coach نشان میدهد Team با شکستن Project به Pieceهای کوچک و تصمیمگیری دیرتر، Complexity را با Information واقعی بهتر Capture میکند.
«این دقیقاً همان کاری است که قبلاً میکردیم، فقط اسمش فرق کرده.»
این یکی از رایجترین Rejectهاست. افراد Practice قدیمی را Rename میکنند و نتیجه میگیرند Agile صرفاً Hype یا Obfuscation Common Sense است. Coach نباید آن را Bad Faith بداند؛ فرد احتمالاً Agile واقعی ندیده ولی فکر میکند دیده است. وظیفه Coach آشکارکردن Difference واقعی است.
Coachها میفهمند مردم چگونه Learn میکنند
Lyssa Adkins مدل Shu-Ha-Ri را از Martial Arts برای یادگیری توضیح میدهد:
- Shu: Rule را Follow کن.
- Ha: Rule را Break/Detach کن و Principle پشت آن را بفهم.
- Ri: خودت Rule باش؛ Ideas آنقدر Internalized شدهاند که Methodology Label دیگر مهم نیست.
Kent Beck نیز برای XP سه Level مشابه بیان کرده بود: ابتدا همهچیز را همانطور که نوشته شده انجام بده؛ سپس بعد از تجربه، Variation Ruleها را Experiment کن؛ در نهایت مهم نباشد که اسم کار XP هست یا نه.
چرا افراد اول Practice ملموس میخواهند؟
کتاب صدها صفحه برای Mindset، Value، Principle و Practice صرف کرده، اما بیشتر افراد Agile را با Reading عمیق یاد نمیگیرند؛ با Doing یاد میگیرند. آنها در ابتدا List ساده Rule میخواهند که بتوانند امروز Follow کنند.
Coach تازهکار ممکن است فوراً دربارهٔ Self-Organization، Collective Commitment و Valueهای انتزاعی توضیح دهد، در حالی که Team فقط میخواهد بداند Story چیست و Task Board چطور کار میکند. اصل Teaching میگوید: افراد را جایی ملاقات کن که هستند، نه جایی که دوست داری باشند.
Shu — ابتدا Rule
Shu به معنی Obey/Observe است. Learner تازه Rule واضح میخواهد. Practiceهایی مثل Sprint، Pair Programming، Task Board و Daily Scrum برای Shu مناسباند، چون میتوان دید Follow شدهاند یا نه.
برای Adult Learner در Work، Rule نقطهٔ شروع امن میدهد. مثلاً:
«هر روز ساعت ۱۰:۳۰ Daily Scrum داریم و هر فرد سه سؤال را پاسخ میدهد.»
این Rule میتواند بعداً Principle را یاد بدهد:
«ما با Self-Organization Plan را دائماً Review و Adjust میکنیم.»
اما Coach نباید Agile Zealot شود: کسی که فکر میکند یک روش دقیق برای همه Teamها درست است و هر Problem را با Rule آماده حل میکند. Zealot در Shu گیر کرده و Context Learner را نمیبیند.
Ha — از Rule به Principle
در Ha، فرد Practice کافی با Rule دارد و میتواند Principle پشت آن را Internalize کند. Adoption Practice + Discussion تیمی Mindset را Shift میدهد. Team در Ha از Better-than-not-doing-it به Benefit واقعی Agile نزدیک میشود.
Ri — Fluency
در Ri، Idea/Value/Principle Fluent شده است. Team اگر Problem با Practice Scrum حل شود همان Practice را انجام میدهد، اگر XP یا Kanban بهتر باشد همان را؛ Label Methodology مهم نیست. این Chaos نیست؛ Team Smooth و Well-Functioning است و افراد میدانند چه چیزی Right است.
Alistair Cockburn اشاره میکند Ri ممکن است برای Learner Shu «بهطرز آزاردهندهای Zen» به نظر برسد: «هرچه کار میکند انجام بده»، «وقتی واقعاً انجامش میدهی، دیگر آگاه نیستی که داری انجامش میدهی»، «Technique را تا وقتی Benefit دارد استفاده کن.» برای Fluent درست است، برای Learner Rule-Seeking تقریباً بیاستفاده است.
Coach باید Stage افراد را تشخیص دهد. فرد Shu ممکن است حتی بپرسد Sticky بهتر است یا Index Card؛ Coach میداند هر دو ممکناند ولی Learner هنوز Critical/Trivial بودن Decision را نمیداند، پس Rule مشخص میدهد. بعداً Similarity/Difference را برای Principle توضیح میدهد.
Shuhari برای یاددادن Valueهای Methodology
Task Board و Story Shu-Level Concept هستند؛ Rule ملموس. Valueهایی مثل Openness و Commitment بیشتر Ha-Level هستند؛ Conceptهای Abstractی که نحوهٔ استفاده از Rule را Governing میکنند. Self-Organization و Collective Commitment زمانی واقعیاند که Valueها Internalize شوند.
بنابراین Practiceهای Scrum شروع خوبی برای آموزش Valueها هستند. Coach Patient است و در طول Sprint منتظر Teaching Opportunity میماند.
مثال Feature نیمهتمام در Sprint
Developer در نیمهٔ Sprint میفهمد Feature تمام نمیشود و در Daily Scrum از Product Owner میخواهد آن را به Sprint بعد ببرد. Product Owner عصبانی میشود و از Reaction Customer میترسد؛ میگوید «هر کاری لازم است انجام دهید»، حتی اگر Corner Cutting و Incomplete Code لازم باشد.
پاسخ Shu-Level: Rule Scrum میگوید فقط Feature «Done Done» در Sprint Review Demo میشود؛ Work ناقص باید به Sprint بعد برود.
Opportunity Ha-Level: Coach Fractured Perspective را Unfracture میکند.
- Product Owner باید Perspective Developer را ببیند: Poor Work Technical Debt میسازد، Maintainability را بدتر میکند و Sprintهای آینده را کند میکند. Focus روی Completion با Quality در بلندمدت Value بیشتری Deliver میکند.
- Developer نیز باید Importance Feature برای Customer را بفهمد و در آینده با Product Owner Feature را کوچکتر Break کند تا Value زودتر Deliver شود. این Lesson دربارهٔ Commitment به Value است.
Coach با Rule Conflict را حل میکند و از همان Conflict برای آموزش Value استفاده میکند.
Coach میفهمد Methodology چرا کار میکند
Problem روزانه همیشه Teaching Opportunity نیست. Coach خوب میداند چه چیزی Supporting Beam Methodology است.
در مثال Sprint، Coach میداند Timeboxed Iteration بدون Rule «Done Done» بیاثر میشود؛ Iteration به Milestone ساده تبدیل میشود، Scope Variable میشود و Working Software در پایان Iteration دیگر Primary Measure of Progress نیست.
Customer Collaboration نیز به معنی «Customer همیشه درست میگوید» نیست؛ یعنی Team و Customer وقتی Plan Problem دارد با هم Solution با Value بیشتر پیدا میکنند. اگر Product Owner بتواند Developer را مجبور کند Software ناقص Demo کند، Team بهتدریج True Progress را پنهان میکند و Collaboration دوباره به Contract Negotiation تبدیل میشود.
Coach Scrum Collective Commitment و Self-Organization را میفهمد. Coach XP Embracing Change و Incremental Design را میفهمد. Coach Kanban میداند WIP Limit برای Control Flow Structural است؛ حذف آن میتواند Method را از پایه بیاثر کند.
اجازه دهید Team گاهی Fail کند
Lyssa Adkins توصیه میکند Team را از هر Failure محافظت نکنید. اجازه ندهید از Cliff سقوط کند، اما دهها Opportunity کوچک Sprint برای Fail و Recover وجود دارند. Teamهایی که با هم Fail و Recover میکنند Stronger میشوند. Coach باید Watch and Wait کند.
این پادزهر Command-and-control-ism خود Coach است. Retrospective فرصت مهم Learning از Failure است. اگر Failure ناشی از Skill Practice باشد، Skill را Improve کنید. اگر ناشی از Mindset باشد، Value/Principle مرتبط را آشکار کنید.
اما برخی Supporting Beamها نباید برداشته شوند. مثل دیوار باربر خانه در Renovation. Coach با Ha-Level Understanding میداند چه چیز Context-Specific و Changeable است و چه چیز Structural. در Kanban Columnهای Board قابل تغییرند، اما WIP Limit ممکن است Lynchpin سیستم باشد.
قسمت دشوار Coaching تعیین مقدار Explanation است: Shu-Level Rule برای شروع کافی است، اما Mindset کامل نمیسازد؛ Ha-Level Why لازم است، ولی اگر خیلی Abstract گفته شود Learner را Lost میکند. Coach Pace یادگیری را تنظیم میکند.
Principles of Coaching
Agile به Mindset درست نیاز دارد و Value/Principle مسیر رسیدن به آن هستند. Coaching نیز Principleهایی دارد. John Wooden، Coach مشهور Basketball تیم UCLA، در Practical Modern Basketball پنج Principle را مطرح میکند که برای Agile Coach نیز معنادارند:
1. Industriousness — سختکوشی
تغییر روش ساخت Software یعنی کار جدی روی Skillهای جدید. Developer باید علاوه بر Coding به Planning و Testing فکر کند؛ Product Owner باید Work Team را بفهمد نه اینکه Feature را «از روی دیوار» Throw کند؛ Scrum Master باید Control را به Team بدهد ولی از Project جدا نشود. Skill جدید Practice میخواهد.
2. Enthusiasm — اشتیاق
وقتی فرد واقعاً به روش جدید Excited باشد، Energy او منتقل میشود. Agile قرار است Problemهای مزمن را حل کند؛ Enthusiasm میتواند نه فقط Software بهتر، بلکه Team خلاقتر، شادتر و مشتاقتر برای Collaboration بسازد.
3. Condition — آمادگی
Agile فرض میکند اعضا Pride of Workmanship دارند، Best Software ممکن را میخواهند و Skill خود را دائماً Improve میکنند. هر عضو باید Condition حرفهای خودش را حفظ و بهتر کند تا بهترین توانش را وارد Project کند.
4. Fundamentals — اصول پایه
Wooden میگوید بهترین System نمیتواند Execution ضعیف Fundamentals را جبران کند و Coach نباید با System پیچیده «از خود بیخود» شود. این برای Agile بسیار مرتبط است: Valueها سادهاند و Practiceها قرار نیست Complexity مصنوعی بسازند. Coach Team را روی Fundamentals و Simplicity نگه میدارد.
5. Development of Team Spirit — توسعهٔ روحیهٔ تیمی
Self-Organization، Whole Team، Energized Work و Empowerment همگی Team Spirit را تقویت میکنند. Coach باید مراقب فردی باشد که Personal Performance، Career Goal، Résumé یا Promotion را بالاتر از Team Welfare قرار میدهد.
Wooden بر Teamwork و Unselfishness تأکید میکند؛ هر عضو باید نه فقط «حاضر»، بلکه مشتاق باشد Personal Glory را برای Welfare Team کنار بگذارد. Selfishness، Envy، Egotism و Criticism متقابل Team Spirit را نابود میکنند و Coach باید آنها را پیش از رشد Problem شناسایی کند.
این پنج Principle Foundation خوبی برای Mindset Agile Coach هستند، همانطور که Valueهای Agile Manifesto و Methodologyها Foundation Mindset Teamاند.
نکات کلیدی
- Agile Coach به Team برای Adoption Agile و Shift Mindset هر فرد کمک میکند.
- Resistance به Change اغلب Rational است و به Risk حرفهای، Familiarity و Safety مربوط میشود.
- Coach Warning Signهای Discomfort را میشنود و Why را توضیح میدهد.
- Shuhari سه Stage یادگیری دارد: Shu = Follow Rule، Ha = Understand/Break Rule با Principle، Ri = Fluency beyond Label.
- Practiceهای ملموس برای Shu مناسباند؛ Valueها اغلب در Ha Internalize میشوند.
- Coach مؤثر فقط Rule را نمیداند؛ چرا Methodology کار میکند را میفهمد.
- Failure کنترلشده میتواند ابزار Learning باشد، اما Supporting Beam Methodology نباید شکسته شود.
- Coaching به Industriousness، Enthusiasm، Condition، Fundamentals و Team Spirit نیاز دارد.
منابع معرفیشده
- Coaching Agile Teams — Lyssa Adkins، Addison-Wesley، 2010.
- Agile Software Development: The Cooperative Game, 2nd Edition — Alistair Cockburn، Addison-Wesley، 2006؛ دربارهٔ Shuhari.
- Practical Modern Basketball, 3rd Edition — John Wooden، Benjamin Cummings، 1998؛ Fundamentals Coaching.
- Applied Software Project Management — Andrew Stellman و Jennifer Greene، O’Reilly، 2005؛ Resistance to Change.