স্প্রিন্ট রেট্রোস্পেক্টিভ এবং AI: কেন উন্নতিগুলো মডেলের কাছে অর্পণ করা যায় না

এটি ক্রস-ফাংশনাল ডেভেলপমেন্ট দলের ক্লাসিক মিটিংগুলোতে AI কীভাবে পরিবর্তন আনছে সে বিষয়ে সিরিজের পঞ্চম নিবন্ধ। আগের অংশগুলোতে আমি বিশ্লেষণ করেছি ব্যাকলগ রিফাইনমেন্ট, স্প্রিন্ট প্ল্যানিং, ডেইলি স্ক্রাম এবং স্প্রিন্ট রিভিউ. সামগ্রিক সিদ্ধান্ত ধীরে ধীরে আরও কঠোর হচ্ছে: AI কথোপকথনের জন্য ইনপুট সংগ্রহে ভালো, কিন্তু কথোপকথনের বিকল্প হওয়া উচিত নয়। স্প্রিন্ট রেট্রোস্পেক্টিভে এই সীমারেখা বিশেষভাবে গুরুত্বপূর্ণ, কারণ এখানে দল শুধু কাজ ও পণ্য নিয়ে আলোচনা করে না, বরং নিজেদের অভ্যাস, পারস্পরিক ক্রিয়া, গুণমান এবং পরিবর্তনের সক্ষমতা নিয়েও আলোচনা করে।

স্প্রিন্ট রেট্রোস্পেক্টিভকে AI-এর জন্য খুবই সুবিধাজনক প্রার্থী মনে হয়। স্প্রিন্টের শেষে ইতিমধ্যেই Jira, Git, pull request, CI/CD, ইনসিডেন্ট, চ্যাট, ক্যালেন্ডার, Daily Scrum-এর নোট, Sprint Review-এর সিদ্ধান্ত, মাঝে মাঝে দলের ছোট সার্ভেও থাকে। মডেল দ্রুত সংগ্রহ করতে পারে: কী সবচেয়ে বেশি কাজ আটকে রেখেছিল, কোথায় review bottleneck ঝুলছিল, কোন কাজগুলো দিনের পর দিন স্থানান্তরিত হচ্ছিল, কোথায় Definition of Done অস্পষ্ট হয়ে গিয়েছিল, কোন সিদ্ধান্তগুলো পুনরাবৃত্তি হচ্ছিল, কোন বিষয়গুলো আগের রেট্রোতে শোনা গিয়েছিল এবং এখনও হারিয়ে যায়নি।

প্রথম নজরে এটি প্রায় নিখুঁত অটোমেশন। পুরো স্প্রিন্ট আবার মনে করার দরকার নেই। review-এর অপেক্ষা সত্যিকারের সমস্যা ছিল নাকি কারও অনুভূতি মাত্র, তা নিয়ে বিতর্ক করার দরকার নেই। ডজন ডজন টিকিট ও আলোচনার শাখা হাতে দেখার দরকার নেই। AI তথ্য প্রস্তুত করতে, প্যাটার্ন গোষ্ঠীভুক্ত করতে, root cause analysis প্রস্তাব করতে এবং এমনকি পরবর্তী স্প্রিন্টের জন্য action item তৈরি করতে পারে।

কিন্তু ঠিক এখানেই মূল ঝুঁকি শুরু হয়।

স্প্রিন্ট রেট্রোস্পেক্টিভের উদ্দেশ্য সুন্দরভাবে সাজানো উন্নতির তালিকা পাওয়া নয়। এর অর্থ হলো দল সৎভাবে দেখবে তারা কীভাবে কাজ করছে, কী পরিবর্তন করা উচিত তা নিয়ে একমত হবে এবং সেই পরিবর্তনের দায়িত্ব নেবে। যদি AI রেট্রোকে সুপারিশের তালিকায় পরিণত করে, দল একটি সুন্দর নথি পেতে পারে কিন্তু সবচেয়ে গুরুত্বপূর্ণ জিনিসটি হারাতে পারে: মনস্তাত্ত্বিক নিরাপত্তা, সমস্যা সম্পর্কে যৌথ বোঝাপড়া এবং প্রকৃত follow-through।

“AI প্যাটার্নগুলো হাইলাইট করতে পারে, কিন্তু উন্নতি তখনই শুরু হয় যখন দল সমস্যাটি স্বীকার করে এবং নিজেদের আচরণ পরিবর্তন করে।”

Sprint Retrospective কেন প্রয়োজন

এতে Scrum Guide 2020 Sprint Retrospective খুব বাস্তবসম্মতভাবে বর্ণনা করা হয়েছে: দল গুণমান ও কার্যকারিতা বাড়ানোর উপায় পরিকল্পনা করে। এর জন্য Scrum Team পর্যালোচনা করে স্প্রিন্টটি মানুষ, পারস্পরিক ক্রিয়া, প্রক্রিয়া, সরঞ্জাম এবং Definition of Done-এর দৃষ্টিকোণ থেকে কেমন গেল। দল আলোচনা করে কী ভালো হয়েছে, কী সমস্যা দেখা দিয়েছে এবং সেই সমস্যাগুলো সমাধান হয়েছে কি হয়নি। তারপর এটি সবচেয়ে উপকারী পরিবর্তনগুলো নির্ধারণ করে, এবং সবচেয়ে গুরুত্বপূর্ণ উন্নতিগুলো যত তাড়া সম্ভব সম্বোধন করতে হবে এবং সেগুলো পরবর্তী স্প্রিন্টের Sprint Backlog-এ যেতে পারে।

অর্থাৎ, রেট্রোস্পেক্টিভ স্প্রিন্টের শেষে একটি আবেগময় বিশ্রাম নয়। এবং এটি একটি আনুষ্ঠানিক অনুষ্ঠানও নয় যেখানে তিনটি কলাম পূরণ করতে হয়: কী ভালো ছিল, কী খারাপ ছিল, কী উন্নত করব। এই ইভেন্টটি কাজের পদ্ধতি অভিযোজনের বিষয়ে। এই অর্থে এটি Scrum-এর সাধারণ যুক্তির সাথে সরাসরি সম্পর্কিত: স্বচ্ছতা পর্যালোচনার জন্য প্রয়োজন, পর্যালোচনা অভিযোজনের জন্য প্রয়োজন, এবং অভিযোজন ছাড়া পর্যালোচনা অর্থহীন হয়ে যায়। Scrum Guide সরাসরি জোর দেয়: Scrum ইভেন্টগুলো এমনভাবে ডিজাইন করা হয়েছে যাতে পরিবর্তনকে উৎসাহিত করা যায়, শুধু প্রোটোকল তৈরি করা নয়।

অতিরিক্ত নির্দেশিকা হিসেবে উপকারী Scrum Guide Expanded v2026.1, কিন্তু এটি Scrum Guide 2020-এর ভিত্তিতে একটি companion-উৎস হিসেবে, নতুন ক্যানোনিক্যাল Scrum Guide সংস্করণ হিসেবে নয়। এই নিবন্ধের জন্য এটি দুটি বিষয়ে গুরুত্বপূর্ণ। প্রথমত, এটি বলে যে প্রতিফলন মনস্তাত্ত্বিকভাবে নিরাপদ পরিবেশে আরও কার্যকর। দ্বিতীয়ত, AI-এর বিভাগে এটি মডেলটিকে supervised decision-making partner হিসেবে বর্ণনা করে: AI স্বচ্ছতা, পর্যালোচনা এবং অভিযোজন বাড়াতে পারে, কিন্তু মানব দায়িত্ব প্রতিস্থাপন করে না এবং প্রক্রিয়ার অভিজ্ঞতাভিত্তিক নিয়ন্ত্রণ বাতিল করে না।

তাই আমি Sprint Retrospective-এর উদ্দেশ্য পাঁচটি কার্যাবলীর মাধ্যমে বর্ণনা করব:

• দলের কাজের প্রকৃত প্যাটার্নগুলো দেখা, শুধু সবচেয়ে জোরালো মতামত নয়;
• শাস্তির ভয় ছাড়াই পারস্পরিক ক্রিয়া, প্রক্রিয়া, সরঞ্জাম এবং Definition of Done নিয়ে আলোচনা করা;
• তথ্যকে ব্যাখ্যা ও অনুমান থেকে আলাদা করা;
• অল্প সংখ্যক উন্নতি বেছে নেওয়া যা দল সত্যিই চেষ্টা করতে প্রস্তুত;
• এই উন্নতিগুলো পরবর্তী স্প্রিন্টে এমনভাবে স্থানান্তর করা যাতে তাদের owner, যাচাইয়ের মানদণ্ড এবং কাজের মধ্যে স্থান থাকে।

এটি AI নিয়ে কথোপকথনের একটি কাঠামো। যদি সরঞ্জামটি দলকে এই কার্যাবলী আরও ভালোভাবে সম্পাদন করতে সহায়তা করে, তবে এটি উপকারী। যদি এটি কেবল আরও সুন্দর action items-এর তালিকা তৈরি করে, তবে এটি সুবিধাজনক হতে পারে, কিন্তু এটি অগত্যা দলকে আরও কার্যকর করে না।

সাধারণত কী ভুল হয়

রেট্রোস্পেক্টিভের সমস্যা খুব কমই এই যে দল সমস্যাগুলোর নাম বলতে পারে না। সাধারণত সমস্যাগুলো ভিন্ন। দল আবার একই বিষয় নিয়ে আলোচনা করে। অ্যাকশন আইটেমগুলো স্প্রিন্ট থেকে স্প্রিন্টে চলে যায়। মানুষ সতর্কভাবে কথা বলে, কারণ তারা দোষী দেখতে চায় না। সবচেয়ে বেদনাদায়ক বিষয়গুলো এড়িয়ে যায়। স্ক্রাম মাস্টার ফরম্যাট বের করে, কিন্তু পরিবর্তন বের করে না। শেষে সবাই "চলো আরও ভালো যোগাযোগ করি"-এর মতো কিছুতে একমত হয়, এবং তা পরের সপ্তাহেই মিলিয়ে যায়।

Lehtinen, Itkonen এবং Lassenius-এর গবেষণা এমপিরিক্যাল সফটওয়্যার ইঞ্জিনিয়ারিং রেট্রোস্পেক্টিভের এই দিকটি ভালোভাবে তুলে ধরে। লেখকরা প্রায় তিন বছরে 37টি দল-স্তরের রেট্রোস্পেক্টিভ অধ্যয়ন করেছেন এবং কয়েকটি গুরুত্বপূর্ণ বিষয় দেখিয়েছেন: আলোচনাগুলো প্রায়ই দলের কাছাকাছি ও নিয়ন্ত্রণযোগ্য বিষয় নিয়ে হয়, কিন্তু অংশগ্রহণকারী পক্ষপাত (participant bias) ভুগতে পারে; কঠিন প্রমাণ ছাড়া তারা সবসময় বাস্তবতা প্রতিফলিত করে না; কিছু বিষয় দীর্ঘ সময় ধরে পুনরাবৃত্তি হয়, কারণ হয় সেগুলো স্বাভাবিকভাবে ফিরে আসে, অথবা জটিলতা বা নিয়ন্ত্রণের অভাবের কারণে দল তাদের নিজেদের স্তরে সমাধান করতে পারে না।

এটি AI-এর জন্য খুবই উপকারী একটি কাঠামো। মডেল সত্যিই যেখানে আগে শুধু অনুভূতি ছিল সেখানে কঠিন প্রমাণ আনতে সাহায্য করতে পারে। উদাহরণস্বরূপ, দল বলে: "রিভিউ স্প্রিন্টকে ধীর করে দেয়"। AI তথ্য তুলে আনতে পারে: কত PR একদিনের বেশি অপেক্ষা করেছে, কোনগুলো আটকে ছিল, কোন মন্তব্যগুলো পুনরাবৃত্তি হয়েছে, merge-এর পরে কোথায় সংশোধনী হয়েছে। স্মৃতির ভিত্তিতে তর্ক করার চেয়ে এটি বেশি উপকারী।

কিন্তু এই একই কাঠামোর একটি বিপরীত দিকও আছে। যদি দল অস্বস্তিকর কারণ নিয়ে কথা বলতে না চায়, AI তাদের আরও সৎ করবে না। যদি সমস্যাটি দলের প্রভাবের বাইরে থাকে, মডেল সুন্দরভাবে একটি অ্যাকশন আইটেম তৈরি করতে পারে যা তবুও কেউ সম্পাদন করবে না। যদি মানুষ কনটেক্সটে বিশ্বাস না করে, তারা আর প্রক্রিয়া নিয়ে নয়, বরং AI তাদের কাজ সঠিকভাবে বর্ণনা করেছে কিনা তা নিয়ে তর্ক করবে।

যেখানে AI সত্যিই সাহায্য করে

স্প্রিন্ট রেট্রোস্পেক্টিভে AI-এর একটি শক্তিশালী উপকারী ক্ষেত্র আছে, যদি উন্নতিটির কাজটি তার উপর ছেড়ে না দেওয়া হয়। আমি এটি রেট্রোর আগে এবং পরে ব্যবহার করব, রেট্রোর পরিবর্তে নয়।

কিন্তু এখানে অতিরিক্ত প্রতিশ্রুতি দেওয়া গুরুত্বপূর্ণ নয়। DORA State of AI-assisted Software Development 2025 সংগঠনিক সিস্টেমের বিদ্যমান শক্তি ও দুর্বলতাগুলোর পরিবর্ধক হিসেবে AI-কে বর্ণনা করে। রেট্রোস্পেক্টিভের জন্য এটি প্রায় নিখুঁত সূত্র: যদি দল ইতিমধ্যে প্রক্রিয়া নিয়ে সৎভাবে আলোচনা করতে এবং উন্নতিগুলোকে কর্মে পরিণত করতে জানে, AI ইনপুটকে আরও সমৃদ্ধ করবে। যদি রেট্রো অনেক আগেই ফলো-থ্রু ছাড়া একটি নিরাপদ আচার হয়ে থাকে, AI শুধু এই আচারটিকে আরও দ্রুত ও পরিচ্ছন্ন করবে।

মিটিংয়ের আগে AI পরিদর্শনের জন্য ইনপুট প্রস্তুত করতে পারে:

• ডেইলি স্ক্রাম, টিকিট, পুল রিকোয়েস্ট এবং ইনসিডেন্ট নোট থেকে পুনরাবৃত্ত impediments সংগ্রহ করা;
• যেখানে ওয়ার্ক আইটেমগুলো দীর্ঘ সময় রিভিউ, টেস্ট ডেটা, প্রোডাক্ট ওনার-এর সিদ্ধান্ত বা বাহ্যিক নির্ভরতার জন্য অপেক্ষা করেছে এমন জায়গা খুঁজে বের করা;
• স্প্রিন্ট প্ল্যানিং-এর পরিকল্পনা, স্প্রিন্ট চলাকালীন প্রকৃত সিদ্ধান্ত এবং স্প্রিন্ট রিভিউ-তে আলোচিত ফলাফলের তুলনা করা;
• ডেফিনিশন অফ ডান এবং দল আসলে কীভাবে কাজগুলো সম্পন্ন করেছে তার মধ্যে অসঙ্গতি চিহ্নিত করা;
• পুরনো অ্যাকশন আইটেমগুলো সংগ্রহ করা এবং দেখানো কোনগুলো সম্পন্ন হয়েছে, ভুলে গেছে বা পুনরাবৃত্তি হয়েছে;
• আলোচনার জন্য প্রার্থী প্রশ্ন তৈরি করা: কী তথ্য ছিল, কী ব্যাখ্যা ছিল এবং কী যাচাই প্রয়োজন।

মিটিংয়ের পরে AI ফলো-থ্রু-তে সাহায্য করতে পারে: নির্বাচিত অ্যাকশন আইটেমগুলো সতর্কভাবে লিপিবদ্ধ করা, owner, যাচাইয়ের মানদণ্ড, স্প্রিন্ট ব্যাকলগের সাথে সংযোগ এবং পরবর্তী রেট্রোস্পেক্টিভের জন্য অনুস্মারক যোগ করা। এটি বিশেষভাবে মূল্যবান, কারণ অনেক রেট্রোর দুর্বল দিক আলোচনায় নয়, বরং উন্নতিগুলো পরবর্তী স্প্রিন্ট পর্যন্ত টিকে থাকে না।

কিন্তু এই সব পরিস্থিতিতে AI প্রস্তুতিমূলক এবং সহায়ক স্তরেই থাকে। কোন সমস্যাটি প্রধান তা এটি নির্ধারণ করবে না। এটি দোষী ব্যক্তি নির্ধারণ করবে না। এটি root cause-কে তথ্য হিসেবে নির্ধারণ করবে না। এবং এটি অবশ্যই জীবন্ত যাচাই ছাড়া স্বয়ংক্রিয়ভাবে "দলের উন্নয়ন পরিকল্পনা" লিখবে না।

কেন AI দলের হয়ে রেট্রোস্পেক্টিভ পরিচালনা করা উচিত নয়

AI-সহায়ক রেট্রোস্পেক্টিভের সবচেয়ে বিপজ্জনক সংস্করণটি পরিপক্ব দেখায়। মডেল সব ডেটা সংগ্রহ করে, দলের মেজাজ বিশ্লেষণ করে, "সমস্যার তিনটি প্রধান কারণ" খুঁজে বের করে, অ্যাকশন আইটেম প্রস্তাব করে এবং সারাংশ Slack বা Confluence-এ পাঠায়। সবাই পড়ে, মাথা নাড়ে, প্রতিক্রিয়া দেয়, এবং রেট্রো ছোট হয়ে যায়। কখনও কখনও দল ভাবতেও শুরু করে: যদি AI ইতিমধ্যে সবকিছু বিশ্লেষণ করে ফেলে, তবে কথাবার্তায় এক ঘণ্টা নষ্ট করার দরকার কী?

সমস্যা হলো, রেট্রোস্পেক্টিভ শুধু উপসংহারের জন্যই মূল্যবান নয়। এটি যৌথ বোঝাপড়ার প্রক্রিয়ার জন্যও মূল্যবান। দলের জন্য শুধু "রিভিউ অনেক সময় নেয়" এই বিবৃতিটি পাওয়া গুরুত্বপূর্ণ নয়। তাদের একমত হতে হবে কেন এটি ঘটছে, দল কী পরিবর্তন করতে প্রস্তুত, কী সমঝোতা গ্রহণ করছে এবং কে দায়িত্ব নিচ্ছে। কখনও কখনও এই আলোচনায় এমন কিছু উঠে আসে যা ডেটা থেকে দেখা যায় না: শক্তিশালী ডেভেলপারের সাথে তর্ক করার ভয়, অস্পষ্ট প্রোডাক্ট কনটেক্সট নিয়ে বিরক্তি, ক্রমাগত জরুরি কাজের ক্লান্তি, বর্তমান ডেফিনিশন অফ ডান-এর সাথে নীরব অসহমতি।

Amy Edmondson-এর ক্লাসিক কাজ মানসিক নিরাপত্তা এবং শেখার আচরণ এখানে একটি ফ্যাশনেবল রেফারেন্স হিসেবে নয়, বরং একটি ব্যবহারিক দিকনির্দেশনা হিসেবে গুরুত্বপূর্ণ। যদি মানুষ মনে না করে যে তারা আন্তঃব্যক্তিক ঝুঁকি ছাড়াই সমস্যাগুলো নিয়ে কথা বলতে পারে, তাহলে রেট্রোস্পেকটিভ নিরাপদ ভাষায় পরিণত হয়। এই পরিস্থিতিতে AI প্রোটোকলকে আরও মসৃণ করতে পারে, কিন্তু দলকে আরও সৎ করতে পারে না।

তদুপরি, AI সততা আরও খারাপ করতে পারে যদি দল এটিকে পর্যবেক্ষণ হিসেবে воспринимает। যদি মডেল Slack, Jira, PR-মন্তব্য এবং ক্যালেন্ডার পড়ে, তারপর লেখে «আলেক্সির review-এ প্রতিক্রিয়ার গতি কম» বা «QA প্রায়ই ডেটা প্রস্তুতিতে দেরি করে», এটি আর রেট্রোস্পেকটিভের সমর্থন নয়। এটি প্রক্রিয়া উন্নতির ছদ্মবেশে performance management। এমন পরিবেশে মানুষ দৃশ্যমান কার্যকলাপ অপ্টিমাইজ করতে শুরু করে, মডেলের সাথে তর্ক করে এবং প্রকৃত প্রক্রিয়া নিয়ে আলোচনার পরিবর্তে খ্যাতি রক্ষা করে।

এই কারণেই NIST Generative AI Profile, OWASP Top 10 for LLM Applications 2025, EDPB Opinion 28/2024 এবং ICO-র কর্মক্ষেত্রে পর্যবেক্ষণ এখানে প্রাসঙ্গিক। নিবন্ধের আইনি বিভাগ হিসেবে নয়, বরং একটি স্মারক হিসেবে: রেট্রোস্পেকটিভ ডেটা সহজেই সংবেদনশীল হয়ে ওঠে। সেগুলো মানুষ, আচরণ, দ্বন্দ্ব, ভুল, বিলম্ব, চিঠিপত্র এবং কখনও কখনও ব্যবস্থাপনার দুর্বল স্থানগুলোর সাথে সম্পর্কিত।

ব্যবহারিক সীমা সহজ: রেট্রোতে AI-কে কাজ এবং সিস্টেম বিশ্লেষণ করতে হবে, মানুষ নয়। অর্থাৎ আটকে থাকা কাজ, পুনরাবৃত্ত প্রত্যাশা, অস্পষ্ট নিয়ম, Definition of Done-এ ফাঁক, খারাপ handoff, অতিরিক্ত বোঝাই প্রক্রিয়া পয়েন্ট। «কে খারাপ কাজ করেছে» নয়, বরং «সিস্টেমে কী আমাদের আবার একই ফলাফলে আসতে বাধ্য করে»।

“রেট্রোর জন্য ভালো AI-input আটকে থাকা কাজ এবং পুনরাবৃত্ত প্যাটার্নের দিকে তাকায়। খারাপ AI-input মানুষকে রিপোর্টের সারিতে পরিণত করে।”

কেসটি চালিয়ে যাই: B2B LMS এবং email-রিমাইন্ডার

আগের নিবন্ধগুলোর একই কেসটি নিই: B2B LMS প্ল্যাটফর্ম, বাধ্যতামূলক কোর্স, ডেডলাইনের আগে বাধ্যতামূলক কোর্স সম্পূর্ণ না করা কর্মচারীদের email-রিমাইন্ডার। Sprint Planning-এ দল একটি সংকীর্ণ Sprint Goal বেছে নিয়েছিল: সিস্টেম ডেডলাইনের আগে অসম্পূর্ণ বাধ্যতামূলক কোর্সসহ সক্রিয় কর্মচারীদের একটি সঠিক রিমাইন্ডার পাঠায় এবং যাচাইযোগ্য পাঠানোর ইতিহাস সংরক্ষণ করে। Daily Scrum-এ দল ডিডুপ্লিকেশন, টাইম জোন এবং টেস্ট ডেটার ঝুঁকি ট্র্যাক করেছিল। Sprint Review-এ দল আলোচনা করেছিল এটি পণ্য এবং Product Backlog-এর জন্য কী পরিবর্তন করে।

এখন Sprint Retrospective আসে। AI ছাড়া কথোপকথন দ্রুত স্বাভাবিক অনুভূতিতে চলে যেতে পারে। ব্যাকএন্ড বলে: «eligibility-র স্পষ্টীকরণ আমাদের ধীর করে দিয়েছিল»। QA বলে: «টেস্ট ডেটা দেরিতে এসেছিল»। ফ্রন্টএন্ড বলে: «স্প্রিন্টের মাঝখানে API পরিবর্তিত হয়েছিল»। প্রোডাক্ট ওনার বলে: «আমরা expiredনিয়ে এত প্রশ্ন আশা করিনি»। স্ক্রাম মাস্টার লিখে: «যোগাযোগ উন্নত করুন», «আগে ডেটা প্রস্তুত করুন», «প্রয়োজন কম পরিবর্তন করুন»। মনে হয় রেট্রো সম্পন্ন হয়েছে।

AI ইনপুটকে আরও নির্দিষ্ট করতে পারে। এটি স্প্রিন্টের ইতিহাস তুলে আনে এবং দেখায়:

• চারটি PR এক দিনের বেশি review-এর জন্য অপেক্ষা করেছিল, এবং সবগুলো retry logic এবং idempotency-র সাথে সম্পর্কিত ছিল;
• নিষ্ক্রিয় ব্যবহারকারীদের জন্য eligibility-র ব্যাখ্যা তিনবার পরিবর্তিত হয়েছে;
• QA ডেটা planning-এ দলের প্রত্যাশার চেয়ে তিন দিন পরে এসেছে;
• Definition of Done নেতিবাচক পরিস্থিতির জন্য যাচাইযোগ্য পাঠানোর ইতিহাস প্রয়োজন করেনি;
• পুরনো action item «PR-এর আকার কমান» সম্পন্ন হয়নি এবং সমস্যা হিসেবে পুনরাবৃত্ত হয়েছে;
• Slack-এ আলোচনার কিছু অংশ বাস্তবায়ন নিয়ে নয়, বরং expired.

উপকরণ

এটি একটি ভালো ইনপুট। কিন্তু এটি এখনও রেট্রোস্পেকটিভ নয়।

রেট্রোস্পেকটিভ শুরু হয় যখন দল আলোচনা করে এর মধ্যে আসলে কী পরিবর্তন করতে হবে। উদাহরণস্বরূপ, তারা সিদ্ধান্ত নিতে পারে: «আগে যোগাযোগ করুন» নয়, বরং «planning-এ বিতর্কিত eligibility অবস্থা এবং তাদের product owner decision স্পষ্টভাবে রেকর্ড করুন»। «QA দ্রুত ডেটা প্রস্তুত করে» নয়, বরং «Sprint Backlog-এ গুরুত্বপূর্ণ পরিস্থিতি বাস্তবায়ন শুরুর আগে টেস্ট ডেটার জন্য আলাদা work item যোগ করা হয়»। «কম PR করুন» নয়, বরং «notification architecture-এ পরিবর্তনের জন্য PR একটি review-পরিস্থিতিতে ফিট হতে হবে এবং কাজ শুরুর আগে review-এর জন্য owner থাকতে হবে»। «DoD উন্নত করুন» নয়, বরং «Definition of Done এখন রিমাইন্ডারের নেতিবাচক পরিস্থিতির জন্য যাচাইযোগ্য পাঠানোর ইতিহাস অন্তর্ভুক্ত করে»।

Anti-patterns

নিচে কয়েকটি anti-pattern রয়েছে যা আমি Sprint Retrospective-এ AI প্রবর্তনের সময় আলাদাভাবে ট্র্যাক করব।

1. AI-সারাংশ জীবন্ত কথোপকথন প্রতিস্থাপন করে

যদি দল শুধু তৈরি করা সারাংশ পড়ে এবং এতে সম্মত হয়, রেট্রো তার মূল জিনিস হারায়। ভালো প্রশ্ন «AI কি স্প্রিন্ট সঠিকভাবে বর্ণনা করেছে?» নয়, বরং «এর মধ্যে আমরা আমাদের কাজে কী পরিবর্তন করতে প্রস্তুত?»।

2. Sentiment analysis দল সম্পর্কে সত্যে পরিণত হয়

টোন বিশ্লেষণ একটি দরকারি দুর্বল সংকেত হতে পারে, কিন্তু এটি প্রসঙ্গ জানে না। ব্যঙ্গ, ক্লান্তি, স্থানীয় দ্বন্দ্ব, রসিকতা, নীরবতা এবং সতর্ক ভাষা খারাপভাবে মেট্রিকে পরিণত হয়। দলের মেজাজকে গ্রাফে সীমাবদ্ধ করা যায় না।

3. AI সিস্টেমিক প্যাটার্নের পরিবর্তে দোষী খোঁজে

যখনই মডেল মানুষকে গতি, সক্রিয়তা বা «তৈরি করা ব্লকারের» সংখ্যা দিয়ে র‍্যাংক করতে শুরু করে, রেট্রোস্পেকটিভ মনিটরিংয়ে পরিণত হয়। এটি মনস্তাত্ত্বিক নিরাপত্তা নষ্ট করে এবং মানুষ যে তথ্য দিতে প্রস্তুত তার গুণমান খারাপ করে।

৪. Root cause যাচাই ছাড়াই গ্রহণ করা হয়

মডেল আত্মবিশ্বাসের সাথে লিখতে পারে: «বিলম্বের প্রধান কারণ হলো অস্পষ্ট প্রয়োজনীয়তা»। কিন্তু এটি কেবল দৃশ্যমান অংশ হতে পারে। প্রকৃত কারণ হতে পারে আর্কিটেকচারাল ঋণ, অগ্রাধিকারের দ্বন্দ্ব, টেস্ট ডেটার অভাব বা সমস্যা এস্কেলেট করার ভয়। AI-এর root cause একটি অনুমান, সত্য নয়।

৫. Action items অতিরিক্ত সাধারণ হয়ে যায়

«যোগাযোগ উন্নত করা», «দ্রুত রিভিউ», «ভালোভাবে প্রস্তুতি নেওয়া» প্রায় কখনোই আচরণ বদলায় না। একটি ভালো action item-কে এই প্রশ্নগুলোর উত্তর দিতে হবে: কে করে, ঠিক কী বদলায়, পরবর্তী স্প্রিন্টে এটি কোথায় দৃশ্যমান এবং দল কীভাবে প্রভাব যাচাই করবে।

৬. উন্নতিগুলো Sprint Backlog-এ পৌঁছায় না

Scrum Guide সবচেয়ে গুরুত্বপূর্ণ উন্নতিগুলোকে পরবর্তী স্প্রিন্টের Sprint Backlog-এ যাওয়ার অনুমতি দেয়। যদি দল একটি উন্নতি বেছে নেয় কিন্তু তার জন্য মনোযোগ, owner ও কাজের মধ্যে স্থান নির্ধারণ না করে, এটি improvement নয়। এটি একটি ইচ্ছা।

ভূমিকাগুলো কীভাবে বদলায়

AI Scrum Team-এর দায়িত্বের ক্ষেত্র বাতিল করে না, কিন্তু কথোপকথনের প্রস্তুতি বদলায়। স্প্রিন্টের ইতিহাস ম্যানুয়ালি পুনর্গঠনের মূল্য কমে। সৎ ব্যাখ্যা, ছোট পরীক্ষা বেছে নেওয়া এবং উন্নতিকে ফলাফল পর্যন্ত নিয়ে যাওয়ার মূল্য বাড়ে।

ভূমিকা	খারাপ AI-পরিস্থিতিতে ঝুঁকি	AI-এর পরিপক্ব ব্যবহার
ডেভেলপাররা	তাদের সক্রিয়তা নিয়ে AI-মূল্যায়নের সাথে তর্ক করে এবং প্রক্রিয়া নিয়ে আলোচনার বদলে খ্যাতি রক্ষা করে।	তথ্য ও প্যাটার্নকে ইনপুট হিসেবে ব্যবহার করে, কিন্তু ইঞ্জিনিয়ারিং প্র্যাকটিস, রিভিউ, DoD ও handoffs-এ কী বদলাবে তা নিজেরাই বেছে নেয়।
প্রোডাক্ট ওনার	AI-রেট্রোকে দলের পারফরম্যান্স রিপোর্ট হিসেবে পড়ে এবং গতির উপর চাপ দেয়।	প্রোডাক্টের অস্পষ্টতা দূর করতে, দলকে যে সিদ্ধান্তগুলো আটকে রেখেছিল তা স্পষ্ট করতে এবং পরবর্তী Sprint Backlog-এ উন্নতি সমর্থন করতে সাহায্য করে।
স্ক্রাম মাস্টার	ফ্যাসিলিটেশন মডেলকে দিয়ে দেয় এবং সৎ কথোপকথনের বদলে একটি পরিপাটি প্রোটোকল পায়।	প্রস্তুতির জন্য AI-ইনপুট ব্যবহার করে, কিন্তু মনস্তাত্ত্বিক নিরাপত্তা, সিস্টেমের উপর ফোকাস এবং নির্বাচিত action items-এর follow-through রক্ষা করে।
কোয়ালিটি ইঞ্জিনিয়ার / QA ইঞ্জিনিয়ার	«বিলম্বের উৎস» ভূমিকা পায়, যদি মডেল সমস্যাগুলোকে ভাসাভাসি টেস্টিংয়ের সাথে যুক্ত করে।	কোয়ালিটি সিগন্যালকে Definition of Done, test-data ownership ও পর্যবেক্ষণযোগ্যতার পরিবর্তনে অনুবাদ করতে সাহায্য করে।
UX/UI ডিজাইনার	রেট্রো থেকে বাদ পড়ে, কারণ AI মূলত কোড, PR ও ডেভেলপমেন্ট টাস্ক বিশ্লেষণ করে।	মিথস্ক্রিয়া, সিদ্ধান্ত ও ব্যবহারকারী-প্রসঙ্গ তুলে ধরে, যা দলের কাজ ও পণ্যের গুণমানে প্রভাব ফেলেছিল।
Engineering Lead / Tech Lead	AI-রেট্রোকে ইঞ্জিনিয়ারদের নিয়ন্ত্রণের ড্যাশবোর্ড হিসেবে ব্যবহার করে।	সিস্টেমিক engineering bottlenecks-কে ব্যক্তিগত সক্রিয়তা থেকে আলাদা করতে এবং এমন একটি প্রযুক্তিগত উন্নতি বেছে নিতে সাহায্য করে যা সত্যিই পরবর্তী স্প্রিন্টে ধরবে।

AI-assisted Retrospective-এর জন্য ব্যবহারিক ফিল্টার

আমি «AI রেট্রো পরিচালনা করুক» এই ধারণা দিয়ে শুরু করতাম না। আমি আরও সংকীর্ণ প্রশ্ন দিয়ে শুরু করতাম: কোন ইনপুট দলকে আরও সৎভাবে কাজের পদ্ধতি পরিদর্শন করতে এবং এক-দুটি উন্নতি বেছে নিতে সাহায্য করবে যা তারা সত্যিই সম্পন্ন করবে?

Sprint Retrospective-এ AI-ইনপুট উপকারী, যদি এটি এই প্রশ্নগুলোর উত্তর দিতে সাহায্য করে:

• কোন সমস্যাগুলো বারবার ঘটেছে আর কোনগুলো একবারের ছিল;
• কোন তথ্য বিষয়টি নিশ্চিত করে আর কোনটি মতামত বা আবেগভিত্তিক মূল্যায়ন;
• কী দলের প্রভাবের পরিধিতে আছে আর কী Supporters, ম্যানেজমেন্ট বা অন্য দলের সাহায্য প্রয়োজন;
• কোন পুরনো action items সম্পন্ন হয়নি এবং কেন;
• পরবর্তী স্প্রিন্টে কোন একটি প্রক্রিয়া, টুল, working agreement বা Definition of Done বদলানো উচিত;
• দল কীভাবে যাচাই করবে যে পরিবর্তনটি কাজ করেছে।

আর বিপরীতভাবে: যদি AI-ইনপুট মূলত «কে 병목 ছিল» এই প্রশ্নের উত্তর দেয়, এটি একটি বিপজ্জনক সংকেত। রেট্রোস্পেকটিভ দলকে কাজের সিস্টেম উন্নত করতে সাহায্য করবে, অংশগ্রহণকারীদের গোপন রেটিং তৈরি করা নয়।

ডেটা ও সীমানা

Sprint Retrospective বিশেষভাবে ডেটার প্রতি সংবেদনশীল, কারণ AI সহজেই এমন জিনিস সংগ্রহ করতে শুরু করে যা মানুষ ব্যক্তিগত হিসেবে воспринимает: চ্যাট বার্তা, উত্তর দেওয়ার গতি, মন্তব্যের সুর, PR-এ প্রতিক্রিয়ার সময়, মিটিংয়ে অংশগ্রহণ, পুনরাবৃত্ত ভুল, আলোচনায় দ্বন্দ্ব। অ্যাক্সেস যত 넓, বিশ্লেষণ তত বিশ্বাসযোগ্য। কিন্তু সংবেদনশীল প্রসঙ্গ ফাঁস হওয়ার, মডেলের আউটপুটের উপর অতিরিক্ত নির্ভরতার এবং রেট্রোকে employee monitoring-এ পরিণত করার ঝুঁকি তত বেশি।

ব্যবহারিকভাবে আমি রেট্রোতে AI প্রবর্তনের আগে কয়েকটি নিয়ম নির্ধারণ করতাম:

• রেট্রোর প্রশ্নের জন্য প্রয়োজনীয় ন্যূনতম সোর্স সেট ব্যবহার করা;
• স্পষ্ট সমঝোতা ও প্রয়োজন ছাড়া ব্যক্তিগত বার্তা বিশ্লেষণ না করা;
• ব্যক্তিগত রেটিং, স্কোর ও performance management নিয়ে সিদ্ধান্ত তৈরি না করা;
• দলকে দেখানো কোন ডেটা ব্যবহার হয়েছে এবং কোনটি বাদ দেওয়া হয়েছে;
• তথ্যকে উৎপন্ন ব্যাখ্যা থেকে আলাদা করা;
• গুরুত্বপূর্ণ সিদ্ধান্ত মূল সোর্স থেকে যাচাই করা;
• AI-সারাংশ সংবেদনশীল দলীয় প্রসঙ্গ ধারণ করলে তা মুছে ফেলা বা সংরক্ষণ সীমিত করা।

এটি আমলাতন্ত্র নয়। এটি সৎ কথোপকথনের একটি শর্ত। যদি মানুষ বুঝতে না পারে যে মডেলটি ঠিক কী পড়ছে এবং পরে তার আউটপুট কীভাবে ব্যবহার করা হয়, তাহলে তারা আরও সতর্কভাবে কথা বলবে। আর সতর্ক রেট্রোস্পেক্টিভ প্রায় সবসময়ই নিরাপদ কিন্তু দুর্বল উন্নতি তৈরি করে।

তাহলে আসলে কী বদলায়

AI সত্যিই Sprint Retrospective-কে আরও উপকারী করতে পারে। এটি প্রস্তুতির খরচ কমাতে পারে, কথোপকথনে তথ্য আনতে পারে, পুনরাবৃত্ত প্যাটার্ন দেখাতে পারে, অসম্পূর্ণ action items-এর কথা মনে করাতে পারে, Definition of Done-এর সঙ্গে অমিল তুলে ধরতে পারে এবং অস্পষ্ট «উন্নতি দরকার»-কে একটি নির্দিষ্ট next-sprint experiment-এ রূপান্তরিত করতে সাহায্য করতে পারে।

কিন্তু এটি কেবল তখনই কাজ করে যদি দল সীমাটি বোঝে: AI পরিদর্শনের জন্য উপাদান প্রস্তুত করে, দলের হয়ে অভিযোজন করে না। এটি তথ্য দেখতে সাহায্য করে, কিন্তু মনস্তাত্ত্বিক নিরাপত্তা তৈরি করে না। এটি root cause প্রস্তাব করতে পারে, কিন্তু মানুষ কী নিয়ে কথা বলতে ভয় পায় তা জানে না। এটি action item লিখতে পারে, কিন্তু owner নেয় না এবং পরের স্প্রিন্টে আচরণ বদলায় না।

তাই মূল বক্তব্যটি আমি এভাবে বলব: AI-কে তথ্য পুনরুদ্ধারের খরচ কমাতে হবে, যাতে দলের সৎ কথোপকথন এবং একটি ছোট উন্নতি বেছে নেওয়ার জন্য বেশি মনোযোগ থাকে। যদি উল্টোটা ঘটে এবং Sprint Retrospective স্বয়ংক্রিয়ভাবে তৈরি সুপারিশের তালিকায় পরিণত হয়, তাহলে দল ঠিক সেই জিনিসটিই হারায় যার জন্য এই ইভেন্টটির অস্তিত্ব: যৌথ শেখা, পরিবর্তনের দায়িত্ব এবং কাজের গুণমান বাড়ানোর সক্ষমতা।

একটি পরিণত দল জিজ্ঞেস করে না: «আমরা কি AI-কে রেট্রোস্পেক্টিভ পরিচালনার দায়িত্ব দিতে পারি?»। এটি অন্যভাবে জিজ্ঞেস করে: «প্রস্তুতির কোন অংশটি AI নিতে পারে, যাতে আমাদের রেট্রোস্পেক্টিভ আরও সৎ, আরও নির্দিষ্ট হয় এবং আরও ভালোভাবে কাজে পৌঁছায়?»। এটি কম চমকপ্রদ প্রশ্ন। তবে ঠিক এটিই বাস্তব continuous improvement-এর বেশি কাছাকাছি।

উৎস ও দিকনির্দেশনা

• Scrum Guide 2020 — Sprint Retrospective, গুণমান ও কার্যকারিতা, মানুষ / মিথস্ক্রিয়া / প্রক্রিয়া / সরঞ্জাম / Definition of Done, সবচেয়ে উপকারী উন্নতি এবং Sprint Backlog-এর সঙ্গে সংযোগ।
• Scrum Guide Expanded v2026.1 — Scrum Guide 2020-ভিত্তিক companion-উৎস: psychological safety, অর্থবহ ধারাবাহিক উন্নতির অনুসরণ এবং AI একটি supervised decision-making partner হিসেবে।
• Scrum.org: Introduction to the Sprint Retrospective — দলের কাজের প্র্যাকটিসের inspection and adaptation-এর ইভেন্ট হিসেবে Sprint Retrospective-এর ব্যবহারিক ব্যাখ্যা।
• Lehtinen, Itkonen ও Lassenius: Recurring opinions or productive improvements — প্রায় তিন বছরের 37টি রেট্রোস্পেক্টিভের অভিজ্ঞতাভিত্তিক গবেষণা: participant bias, hard evidence, recurring topics এবং corrective actions।
• Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams — team learning-এর শর্ত হিসেবে মনস্তাত্ত্বিক নিরাপত্তা সম্পর্কে একটি চিরায়ত উৎস।
• NIST Generative AI Profile — confabulation, data privacy, human-AI configuration, overreliance, information integrity এবং জেনারেটিভ AI-এর অন্যান্য ঝুঁকি।
• OWASP Top 10 for LLM Applications 2025 — sensitive information disclosure, excessive agency, misinformation এবং LLM-অ্যাপ্লিকেশনের পরিচালনগত ঝুঁকি।
• DORA State of AI-assisted Software Development 2025 — সাংগঠনিক ব্যবস্থার বিদ্যমান শক্তি ও দুর্বলতার amplifier হিসেবে AI।
• EDPB Opinion 28/2024 এবং ICO monitoring at work guidance impact assessment — ব্যক্তিগত তথ্য, স্বচ্ছতা, আনুপাতিকতা এবং কর্মক্ষেত্রে নজরদারির সীমা সম্পর্কে দিকনির্দেশনা।