https://virgool.ir/feed/@m_31778496fa2026-11-10 21:54:08https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@m_31778496https://virgool.ir/@m_31778496/فراتر-از-اسپرینتچرا-scrum-را-کنار-گذاشتیم-و-به-سمت-end-to-end-delivery-رفتیم-jodgevnlgtnwاز Scrum Master تا Technical Delivery Managementیک زمانی فکر می‌کردیم اگر تیم‌ها Sprint داشته باشند، Daily برگزار کنند، Backlog مرتب باشد و Retrospective انجام شود، Delivery هم باید بهتر شود.و تا حد زیادی هم درست بود.Scrum برای خیلی از تیم‌ها نقطه‌ی شروع خوبی است؛ یک ریتم مشخص ایجاد می‌کند، مسئولیت‌ها را شفاف‌تر می‌کند و کمک می‌کند تیمی که هنوز روش کار خودش را پیدا نکرده، ساختار داشته باشد.اما مسئله از جایی شروع می‌شود که سازمان رشد می‌کند.تعداد تیم‌ها بیشتر می‌شود، Dependencyها زیاد می‌شوند، پروژه‌ها دیگر داخل یک تیم تمام نمی‌شوند، تعداد Stakeholderها افزایش پیدا می‌کند و ارتباط بین Product، Engineering و Business پیچیده‌تر می‌شود.در این نقطه، گاهی Frameworkی که قرار بود به تیم کمک کند، خودش تبدیل به بخشی از مسئله می‌شود.و این دقیقاً جایی بود که ما در Snapp Pay به آن رسیدیم.یک تصمیم یک‌شبه نبودتصمیم به کنار گذاشتن Scrum در Snapp Pay یک تصمیم ناگهانی یا نتیجه‌ی یک جلسه نبود.از سال گذشته به‌تدریج داشتیم با یک سؤال اساسی درگیر می‌شدیم:آیا مدل فعلی ما واقعاً به تیم‌ها کمک می‌کند سریع‌تر و با تمرکز بیشتری Deliver کنند، یا بخش قابل‌توجهی از ظرفیت سازمان صرف مدیریت خود Process شده است؟پاسخ این سؤال ساده نبود.چون Scrum سال‌ها بخشی از روش کار ما بود و طبیعتاً تغییر آن فقط تغییر چند جلسه یا چند عنوان شغلی نبود. باید می‌فهمیدیم چه چیزی واقعاً ارزش ایجاد می‌کند، چه چیزی باید حفظ شود و چه چیزهایی دیگر با Scale و نیازهای امروز سازمان هم‌خوانی ندارند.اما مسئله فقط به اندازه تیم‌ها یا بزرگ‌تر شدن سازمان محدود نمی‌شد. مسئله مهم‌تر، ماهیت Dependencyهایی بود که با رشد کسب‌وکار ایجاد شده بود.Scrum در سطح تیم می‌تواند ساختار و ریتم مشخصی برای Delivery ایجاد کند. اما با رشد Snapp Pay، بسیاری از مسئله‌هایی که باید حل می‌کردیم دیگر در مرز یک تیم باقی نمی‌ماندند. Delivery یک قابلیت می‌توانست به چند تیم، چند Domain، Product، Business و Stakeholder مختلف وابسته باشد.به عبارت دیگر، ما به‌تدریج از نقطه‌ای عبور کرده بودیم که می‌توانستیم Delivery را صرفاً با بهینه‌سازی در سطح هر تیم مدیریت کنیم. مسئله ما دیگر فقط این نبود که هر تیم چقدر خوب کار می‌کند؛ مسئله این بود که آیا کل مسیر End-to-End از تصمیم تا Delivery به‌درستی در حال حرکت است یا نه.همین تغییر، نیاز به مدلی را ایجاد کرد که به‌جای تمرکز صرف بر عملکرد محلی هر تیم، بتواند Delivery را در سطح End-to-End ببیند و جریان آن را بین تیم‌ها و Domainهای مختلف هم‌راستا کند.این مسیر با تغییرات ساختاری، بازتعریف نقش‌ها، فراز و نشیب‌های متعدد و حتی شرایط غیرعادی که در ایران تجربه کردیم ادامه پیدا کرد.تا اینکه در ۱۰ تیر، به نقطه‌ای رسیدیم که مدل جدید را Roll Out کردیم:Scrum به‌عنوان Operating Model تیم‌های Engineering کنار رفت و نقش Scrum Master به Technical Delivery Manager تغییر کرد.اما این فقط تغییر یک عنوان نبود.در واقع داشتیم مسئله‌ی Delivery را از نو تعریف می‌کردیم.وقتی Ceremony تبدیل به Overhead می‌شودScrum قرار نیست پر از جلسه باشد؛ اما در سازمان‌های بزرگ، خیلی راحت می‌تواند به یک مدل Ceremony-heavy تبدیل شود.Daily، Planning، Refinement، Review، Retrospective و جلسات مختلف Coordination، هرکدام به‌تنهایی منطقی هستند.مسئله زمانی ایجاد می‌شود که این جلسات روی هم جمع می‌شوند.اگر هر Engineer روزانه فقط ۴۵ دقیقه از زمانش را صرف Ceremonyهای تکرارشونده Scrum کند، در سازمانی با ده‌ها تیم، سالانه هزاران ساعت از ظرفیت Engineering صرف جلسات و هماهنگی‌های فرآیندی می‌شود؛ زمانی که می‌توانست صرف حل مسئله، توسعه نرم‌افزار و رساندن سریع‌تر ارزش به مشتری شود. اما مسئله فقط تعداد جلسات نیست.یک مشکل مهم‌تر هم وجود دارد:وابستگی Process به آدم‌ها.اگر برای جلو رفتن بخشی از کار، حتماً باید Scrum Master در جلسه باشد، Blocker را پیگیری کند، وضعیت را جمع کند، افراد را هماهنگ کند و فرآیند را جلو ببرد، در واقع بخشی از سیستم Delivery هنوز به یک نقش وابسته است.ما می‌خواستیم از این مدل فاصله بگیریم.نه با حذف Coordination، بلکه با بازطراحی آن.اما بازطراحی Coordination به این معنی نیست که ارتباط و Alignment را حذف کنیم. مسئله این است که بخشی از هماهنگی‌هایی که قبلاً از طریق Ceremonyهای ثابت انجام می‌شد، باید به شکل Async، مکتوب و مبتنی بر Ownership انجام شود.به جای اینکه برای پیش رفتن کار، افراد دائماً در جلسات مختلف دور هم جمع شوند، اطلاعات، تصمیم‌ها، Blockerها و Dependencyها باید تا حد ممکن در جریان کاری خودشان قابل مشاهده باشند. در این مدل، Meeting زمانی ارزشمند است که واقعاً به Discussion، Decision یا Problem Solving نیاز داشته باشیم؛ نه صرفاً برای اینکه همه در جریان وضعیت کار قرار بگیرند.به بیان ساده، جلسات با سکوت جایگزین نشدند؛ بلکه جای خود را به جریان‌های کاری ساختاریافته و Async دادند.از «اجرای Scrum» به «مدیریت Delivery»اینجا بود که مفهوم TDM برای ما شکل گرفت.Technical Delivery Manager قرار نیست Scrum Master با یک Job Title جدید باشد.اگر قرار بود فقط Ceremonyهای Scrum را حذف کنیم و همان مسئولیت‌ها را با نام دیگری ادامه دهیم، عملاً هیچ اتفاقی نیفتاده بود.این تغییر به معنی ایجاد یک لایه جدید از Ownership نبود؛ بلکه نیاز داشتیم مرز مسئولیت‌ها را شفاف‌تر کنیم.در مدل جدید، Product Manager مالک Why و What است؛ یعنی جهت محصول، مسئله کسب‌وکار، Scope و اولویت‌بندی.Tech Lead و Engineering Manager مالک How و Quality هستند؛ یعنی راهکار فنی، کیفیت Engineering، ظرفیت تیم و اجرای فنی.و Technical Delivery Manager مسئول When و Orchestration در سطح End-to-End است؛ یعنی کمک به حرکت Delivery، مدیریت Dependencyهای بین تیم‌ها، باز کردن مسیرهای Block شده، پیگیری Milestoneها و افزایش قابلیت پیش‌بینی Delivery.بنابراین TDM قرار نیست جایگزین PM، TL یا EM شود. مسئولیت TDM این است که بین این Ownershipها در سطح Delivery اتصال ایجاد کند و مطمئن شود تصمیم‌های محصول و راهکارهای فنی، در نهایت در یک مسیر منسجم به Delivery منجر می‌شوند.تغییر اصلی این بود که سؤال TDM با سؤال Scrum Master متفاوت است.سؤال اصلی دیگر این نیست:«آیا تیم Sprint را درست اجرا می‌کند؟»بلکه:«چه چیزی جلوی Delivery این حوزه را گرفته و چه کاری باید انجام دهیم تا آن را برطرف کنیم؟»این تفاوت کوچک در ظاهر، در عمل تفاوت بزرگی ایجاد می‌کند.TDM باید بتواند Dependencyها را ببیند، Bottleneckها را زود تشخیص دهد، Trade-offها را دنبال کند، Timeline و Milestoneها را مدیریت کند و بین Product، Engineering، Business و سایر Stakeholderها ارتباط ایجاد کند.در واقع تمرکز از Team Process به End-to-End Delivery منتقل می‌شود.پس با جلسات چه کردیم؟یک سوءتفاهم رایج درباره این تغییر می‌تواند این باشد که:«Scrum را جمع کردید، پس دیگر جلسه ندارید؟»اتفاقاً نه.ما قرار نیست ارتباط را حذف کنیم؛ قرار است ارتباط غیرضروری را حذف کنیم.یکی از تغییرات مهم برای ما حرکت به سمت Async-first بود.به جای اینکه برای هر موضوع جلسه برگزار کنیم تا همه در جریان قرار بگیرند، تلاش می‌کنیم اطلاعات، تصمیم‌ها و Context تا جای ممکن مکتوب باشند.در این مدل، حذف Scrum به معنی حذف Check-in و Alignment هم نیست. بخشی از این هماهنگی در قالب Execution Pod انجام می‌شود؛ یک Check-in روتین با Shared Ownership بین PM، EM و TL که هدف آن این است که این نقش‌ها بتوانند در سطح Vertical درباره اولویت‌ها، تصمیمات مهم و جهت‌گیری‌های استراتژیک خود مستقیماً با یکدیگر هم‌راستا شوند و کار را پیش ببرند.نکته مهم این است که Execution Pod یک متد اجباری برای اجرای کار نیست. تیم‌ها قرار نیست برای اینکه بدانند «چطور» کار کنند، به یک Scrum Master، TDM یا نقش واسطه دیگری وابسته باشند. هر تیم می‌تواند با توجه به Context خود، روش و متدی را انتخاب کند که برایش بهتر جواب می‌دهد؛ از Kanban گرفته تا هر روش دیگری که به Delivery بهتر کمک کند.هدف Execution Pod این است که Ownership تصمیم‌گیری را به خود تیم برگرداند و نیاز به یک واسطه دائمی برای هماهنگی و پیش بردن کار را از بین ببرد.RFC (Request For Comment)، PRD، Confluence و سایر ابزارهای مستندسازی در این مدل نقش مهم‌تری پیدا می‌کنند.در لایه اجرای واقعی، هم‌راستایی بین PM، PX و TL اهمیت بیشتری پیدا می‌کند. در این مرحله، موضوع از صرفاً تصمیم‌گیری درباره اولویت‌ها عبور کرده و وارد اجرای واقعی و تجربه کاربر می‌شود؛ بنابراین PX مسئولیت بیشتری در مسیر Execution بر عهده می‌گیرد و TL نیز به‌دلیل درگیری مستقیم با Technical Execution، در این جریان حضور دارد.به این ترتیب، Execution Alignment در سطح تیم و در نزدیک‌ترین نقطه به اجرای واقعی اتفاق می‌افتد، بدون اینکه برای پیش بردن کار نیاز به یک واسطه دائمی بین تیم و سایر نقش‌ها وجود داشته باشد.الگوی مطلوب ما بیشتر شبیه این است:Write → Review → Comment → Decideو جلسه زمانی برگزار می‌شود که واقعاً به Discussion، Decision یا Problem Solving نیاز داریم.این تغییر فقط برای کم کردن Calendar افراد نیست.هدف اصلی این است که Attention افراد را از Process به Problem برگردانیم.چرا این تغییر برای Engineering مهم بود؟یکی از اهداف اصلی این Transformation، افزایش Efficiency بود؛ اما Efficiency برای ما فقط به معنی «جلسه کمتر» نیست.ما سه هدف بزرگ‌تر داشتیم.۱. Efficiencyمی‌خواستیم Overhead ناشی از Coordination و Process را کاهش دهیم و زمان بیشتری برای حل مسئله و Delivery آزاد کنیم.۲. Capacityنمی‌خواستیم هرچه سازمان بزرگ‌تر می‌شود، برای مدیریت پیچیدگی مجبور باشیم به همان نسبت لایه‌های Coordination بیشتری ایجاد کنیم.بخشی از این ظرفیت باید از طریق بهتر شدن سیستم کار کردن ایجاد شود، نه فقط با اضافه کردن آدم‌های بیشتر.۳. Focusو شاید مهم‌تر از همه، تمرکز.Engineer باید بیشتر روی Engineering تمرکز کند.Tech Lead باید روی Technical Direction تمرکز کند.Engineering Manager باید روی Engineering Organization و Release تمرکز کند.Product Manager باید روی Product و Business Outcome تمرکز کند.و TDM باید مطمئن شود که بین این Ownershipها، مسیر End-to-End Delivery دچار اصطکاک و Blocker نمی‌شود.Agile را حذف نکردیم؛ یک Framework را از هدف بودن خارج کردیماین شاید مهم‌ترین بخش این تغییر باشد.Scrum را کنار گذاشتن، به معنی کنار گذاشتن Agile نیست.ما همچنان به Feedback، Collaboration، Transparency، Iteration و Continuous Improvement نیاز داریم.اما دیگر نمی‌خواهیم یک Ceremony را صرفاً به این دلیل برگزار کنیم که در یک Framework تعریف شده است.اگر Daily برای تیمی ارزش ایجاد می‌کند، انجام شود.اگر Retrospective واقعاً باعث بهبود تیم می‌شود، انجام شود.اگر Planning به تصمیم‌گیری بهتر کمک می‌کند، انجام شود.اما این‌ها دیگر نباید هدف باشند.هدف، Delivery است.به زبان ساده:Process باید در خدمت Delivery باشد، نه Delivery در خدمت Process.TDM قرار نیست «Follow-up Person» باشدبا تعریف TDM یک خطر دیگر هم وجود دارد.اینکه نقش جدید دوباره تبدیل شود به کسی که همه چیز را Follow Up می‌کند:«این Task چی شد؟»«فلان تیم جواب داد؟»«این Ticket چرا Done نشده؟»«Timeline آپدیت شد؟»اگر به این نقطه برسیم، فقط Scrum Master را با یک اسم جدید بازتولید کرده‌ایم.به همین دلیل، TDM نباید به یک Administrative Monitor یا Status Aggregator تبدیل شود. اگر TDM صرفاً دنبال‌کننده Ticketها باشد و مرتب بپرسد «این Task به کجا رسید؟»، «این Ticket چرا Done نشده؟» یا «Status این مورد چیست؟»، در واقع فقط نام نقش را تغییر داده‌ایم، نه مدل کار را.TDM باید به‌جای Taskها، سیستم Delivery را ببیند؛ ریسک‌ها را زود تشخیص دهد، Bottleneckها را برطرف کند، Dependencyها را به هم متصل کند و Trade-offهای ساختاری را شفاف کند.TDM لازم نیست Status تک‌تک Taskها را بداند؛ باید بداند آیا سیستم در مسیر رسیدن به Outcome مورد انتظار قرار دارد یا نه، و اگر نیست، دلیل آن چیست.TDM باید یک لایه بالاتر بایستد.باید بتواند بگوید:کدام مسئله واقعاً Delivery را تهدید می‌کند؟کدام Dependency باید الان حل شود؟کدام Trade-off باید تصمیم‌گیری شود؟کجا داریم ظرفیت را اشتباه مصرف می‌کنیم؟چرا این Delivery در حال کند شدن است؟و مهم‌تر از همه:چطور می‌توانیم قبل از اینکه یک مشکل به Delay تبدیل شود، آن را ببینیم؟از TDM چه انتظاری داریم؟TDM برای ما یک نقش جدید در یک نمودار سازمانی نیست؛ بخشی از مدل جدید Delivery است.انتظار داریم TDM:Bottleneckها را قبل از تبدیل شدن به Blocker شناسایی کند.Dependencyهای Cross-domain را مدیریت کند.Trade-offها را شفاف کند و تا رسیدن به تصمیم دنبال کند.Roadmap و Timeline را در سطح Milestone زنده نگه دارد.بین Business، Product و Engineering ارتباط مؤثر ایجاد کند.با Metrics درباره Delivery صحبت کند، نه صرفاً با Status (مثل Lead Time to Production، Cycle Time، Milestone Predictability و Blocker Resolution Time). Proactively مسئله پیدا کند، نه اینکه فقط منتظر Escalation بماند.و در نهایت، روی Outcome و Time to Market تمرکز کند.TDM قرار نیست کسی باشد که همه چیز را Follow Up می‌کند.TDM باید کسی باشد که می‌فهمد چه چیزی باید Follow Up شود، چرا باید Follow Up شود و چه Outcomeای باید از آن حاصل شود.پایان Scrum یا شروع یک مدل جدید؟شاید «Sunsetting» واژه‌ی دقیق‌تری از «حذف» باشد.ما یک مدل را کنار نگذاشتیم چون ذاتاً بد بود.آن مدل در یک مقطع زمانی برای ما ارزش ایجاد کرده بود.اما سازمان تغییر کرده بود.Scale تغییر کرده بود.مسائل ما تغییر کرده بود.و وقتی مسئله تغییر می‌کند، روش حل مسئله هم باید تغییر کند.مسیر ما از سال گذشته شروع شد و در ۱۰ تیر ۱۴۰۵ با Roll Out نقش‌های جدید وارد مرحله‌ی تازه‌ای شد.هنوز هم این مدل در حال تکامل است و احتمالاً TDM هم در ماه‌ها و سال‌های آینده تغییر خواهد کرد.چون هدف ما ساختن یک Process جدید و ثابت برای همیشه نیست.هدف این است که سازمانی داشته باشیم که بتواند:سریع‌تر تصمیم بگیرد،با Overhead کمتر هماهنگ شود،ظرفیت بیشتری برای اجرای واقعی داشته باشد،و در نهایت،چیزهایی را که برای مشتری و کسب‌وکار ارزش دارند، سریع‌تر و با کیفیت بیشتری به Production برساند.شاید این، در نهایت، معنای واقعی Scrum Sunsetting برای ما باشد:نه اینکه Agile تمام شده است؛بلکه اینکه دیگر Framework را با Delivery اشتباه نمی‌گیریم.در نهایت، Scrum Sunsetting به معنی حذف Structure، Discipline یا Accountability نبود. ما نمی‌خواستیم ساختار را از سازمان حذف کنیم؛ می‌خواستیم وابستگی سازمان به Processهای اجباری و دست‌وپاگیر را کمتر کنیم و در مقابل، Ownership، اعتماد و مسئولیت‌پذیری بیشتری به تیم‌های Engineering بدهیم.هر سازمانی در یک مرحله از رشد خود به Structureهایی نیاز دارد که کمک کنند یاد بگیرد چگونه حرکت کند. اما همان Structureها نباید برای همیشه به چرخ‌های کمکی تبدیل شوند.ما چرخ‌های کمکی را برداشتیم تا سازمان Engineering بتواند با Ownership و اعتماد بیشتر، با تمام سرعت حرکت کند.سامان قاسمیسامان قاسمیSat, 17 Oct 2026 17:40:48 +0330