AI এবং Scrum Events: ডেভেলপমেন্ট টিমের মিটিংয়ে আসলে কী বদলায়
সিরিজের সারসংক্ষেপ: AI কীভাবে Scrum Events বদলায়, কোথায় টিমকে সাহায্য করে, কোন ঝুঁকিগুলো বাড়ায় এবং কেন দায়িত্ব মানুষেরই থাকে।
এই ছবিটি লোড করা যায়নি।এটি ক্রস-ফাংশনাল ডেভেলপমেন্ট টিমের ক্লাসিক মিটিং কীভাবে AI বদলায় সে বিষয়ে সিরিজের চূড়ান্ত নিবন্ধ। পূর্ববর্তী অংশগুলোতে আমি আলাদাভাবে বিশ্লেষণ করেছি Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review এবং Sprint Retrospective। এগুলো একসাথে মিলিয়ে দেখলে সামগ্রিক সিদ্ধান্তটি বেশ বাস্তববাদী হয়: AI Scrum events-এর প্রস্তুতি সস্তা ও সমৃদ্ধ করে, কিন্তু পরিদর্শন, অভিযোজন, আলোচনা এবং প্রকৃত পরিবর্তনের দায়িত্ব টিমের কাছ থেকে কেড়ে নেয় না।
যখন আমি এই সিরিজ শুরু করেছিলাম, তখন দুটি চরম পরিস্থিতির একটিতে চলে যাওয়া সহজ ছিল। প্রথমটি: AI শীঘ্রই প্রায় সব টিম মিটিং প্রতিস্থাপন করবে, কারণ মডেল ইতিমধ্যে সারসংক্ষেপ তৈরি, টাস্ক লেখা, পরিকল্পনা তৈরি, স্ট্যাটাস সংগ্রহ, ডেমো প্রস্তুত এবং action items প্রস্তাব করতে পারে। দ্বিতীয়টি: Scrum events প্রকৃতিগতভাবে এতটাই মানবিক যে সেখানে AI-এর প্রায় প্রয়োজনই নেই।
পাঁচটি পৃথক বিশ্লেষণের পর আমার মনে হয় দুটি পরিস্থিতিই অতিরিক্ত সরল।
AI সত্যিই টিমের মিটিং বদলায়। কিন্তু বিজ্ঞাপনী প্রতিশ্রুতিতে যেভাবে শোনায় সেভাবে নয়। এটি Scrum events-এর মূল অংশ নয়, বরং তাদের চারপাশের স্তর বদলায়: প্রস্তুতি, অনুসন্ধান, সারসংক্ষেপ, প্রাথমিক কাঠামোবদ্ধকরণ, সংকেত শনাক্তকরণ, সিদ্ধান্ত নথিভুক্তকরণ এবং follow-up। আর এই স্তর যত সস্তা হয়, ততই স্পষ্ট হয় যা অর্থ হারানো ছাড়া স্বয়ংক্রিয় করা যায় না: টিমের বিচার, দায়িত্ব, মূল্য নিয়ে বিতর্ক, বাস্তবতা যাচাই, মনস্তাত্ত্বিক নিরাপত্তা এবং পরিকল্পনা, backlog বা কাজের পদ্ধতি পরিবর্তনের সক্ষমতা।
“AI প্রস্তুতি সস্তা করে, কিন্তু মানবিক দায়িত্বকে আরও দৃশ্যমান করে।”
এটাই সিরিজের মূল প্রশ্নের প্রধান উত্তর। AI ক্রস-ফাংশনাল ডেভেলপমেন্ট টিমের ক্লাসিক মিটিং বাতিল করে না। এটি তাদের মনোযোগের অর্থনীতি বদলায়। রুটিন তথ্য সংগ্রহ সস্তা হয়। যত্নশীল খসড়া তৈরি সস্তা হয়। স্ট্যাটাস যোগাযোগ সস্তা হয়। কিন্তু Scrum ইভেন্টের প্রকৃত মূল্য তখনও তৈরি হয় যেখানে টিম তথ্য দেখে, অর্থ নিয়ে বিতর্ক করে, সমঝোতা করে এবং পরবর্তী পদক্ষেপ বদলায়।
প্রথমে মিটিংয়ের উদ্দেশ্যে ফিরে যাওয়া উপকারী
এতে Scrum Guide 2020 -এ Scrum ইভেন্টগুলোকে আচার-অনুষ্ঠানের সমষ্টি নয়, বরং স্বচ্ছতা, পরিদর্শন ও অভিযোজনের অন্তর্নির্মিত সুযোগ হিসেবে বর্ণনা করা হয়েছে। Sprint Planning স্প্রিন্ট শুরু করে এবং টিমকে মূল্য, কাজের পরিমাণ ও সম্পাদনের পদ্ধতি নিয়ে সম্মত হতে সাহায্য করে। Daily Scrum ডেভেলপারদের Sprint Goal-এর দিকে অগ্রগতি যাচাই এবং Sprint Backlog অভিযোজনের জন্য প্রয়োজন। Sprint Review ফলাফল পরিদর্শন এবং Product Backlog-এর পরবর্তী অভিযোজনের জন্য প্রয়োজন। Sprint Retrospective টিমের কাজের গুণমান ও কার্যকারিতা বাড়ানোর জন্য প্রয়োজন।
Backlog Refinement আলাদাভাবে অবস্থান করে: এটি Scrum Guide 2020-এ অফিসিয়াল Scrum-ইভেন্ট নয়, বরং Product Backlog স্পষ্ট করার একটি চলমান কার্যক্রম। কিন্তু বাস্তব জীবনে ক্রস-ফাংশনাল টিমের refinement প্রায়ই একটি গুরুত্বপূর্ণ নিয়মিত মিটিং বা কর্মসেশন系列的 মতো কাজ করে। তাই এই সিরিজে আমি এটি ক্লাসিক ইভেন্টগুলোর পাশে বিশ্লেষণ করেছি: ঠিক সেখানেই টিম প্রথমে বিপুল পরিমাণ ম্যানুয়াল বৌদ্ধিক প্রস্তুতির সম্মুখীন হয়, যা AI সবচেয়ে আগে ত্বরান্বিত করতে শুরু করে।
এই কাঠামো গুরুত্বপূর্ণ, কারণ এটি ভুল প্রশ্ন থেকে রক্ষা করে। খারাপ প্রশ্ন হলো: “AI কোন মিটিং প্রতিস্থাপন করতে পারে?”। আরও সঠিক প্রশ্ন: “AI ম্যানুয়াল প্রস্তুতির কোন অংশ নিতে পারে, যাতে মিটিংটি নিজেই আরও সৎ পরিদর্শন ও অভিযোজন হয়?”।
সিরিজের শেষ নিবন্ধগুলোতে অতিরিক্ত নির্দেশিকা হিসেবে আমি ব্যবহার করেছি Scrum Guide Expanded v2026.1। এটি Scrum Guide 2020-এর ভিত্তিতে companion-উৎস হিসেবে পড়া উচিত, নতুন প্রামাণিক Scrum Guide সংস্করণ হিসেবে নয়। AI বিষয়ের জন্য সেখানে মডেলকে supervised decision-making partner হিসেবে উল্লেখ করা উপকারী: AI transparency, inspection ও adaptation বাড়াতে পারে, কিন্তু human accountability প্রতিস্থাপন করে না এবং empirical process control বাতিল করা উচিত নয়। চূড়ান্ত নিবন্ধের জন্য এটি প্রায় আদর্শ সীমারেখা।
পাঁচটি অংশে যা বারবার ফিরে আসে
নিবন্ধে Backlog Refinement প্রধান সিদ্ধান্ত ছিল: AI টিমের সমঝোতা নয়, বরং তার জন্য উপাদান প্রস্তুত করা ত্বরান্বিত করে। এটি প্রসঙ্গ, ব্যবহারকারী গল্পের খসড়া, গ্রহণযোগ্যতার মানদণ্ড, ঝুঁকি, খোলা প্রশ্ন এবং সমাধানের প্রাথমিক বিকল্প সংগ্রহ করতে সাহায্য করে। কিন্তু এটি মিথ্যা স্পষ্টতার ঝুঁকিও তৈরি করে: কাজটি সহজবোধ্য মনে হয়, কারণ এটি সুন্দরভাবে সাজানো।
নিবন্ধে Sprint Planning অনুরূপ প্যাটার্ন অন্য স্তরে প্রকাশ পায়। AI দ্রুত Sprint Goal-এর বিকল্প, কাজের পরিমাণ, নির্ভরতা, বিভাজন এবং ঝুঁকি সংগ্রহ করতে সাহায্য করে। কিন্তু মিথ্যা বাস্তববাদ দেখা দেয়: পরিকল্পনা সুসংগত, সম্পূর্ণ ও সম্পাদনযোগ্য মনে হয়, যদিও টিম এখনও capacity, Definition of Done, পরীক্ষণযোগ্যতা এবং প্রকৃত সীমাবদ্ধতার ভিত্তিতে এটি যাচাই করেনি।
এতে Daily Scrum AI আর ভবিষ্যতের কাজ প্রস্তুত করে না, বরং স্প্রিন্টের অগ্রগতি সম্পর্কে সংকেত সংগ্রহ করে। এটি ব্লকার, রিভিউ বটলনেক, অস্থির টেস্ট, Jira-status ও বাস্তবতার মধ্যে অমিল, নির্ভরতা এবং অ্যাসিঙ্ক্রোনাসভাবে নেওয়া সিদ্ধান্ত তুলে ধরতে পারে। কিন্তু যদি ফোকাস Sprint Goal থেকে সরে গিয়ে "কে কী কাজে ব্যস্ত ছিল"-এ চলে যায়, তাহলে Daily Scrum AI-generated status reporting-এ পরিণত হয়।
В Sprint Review AI স্প্রিন্টের ফলাফল, মেট্রিক, release notes, প্রতিক্রিয়া এবং খোলা পণ্যসংক্রান্ত প্রশ্নের জন্য প্রস্তুতিমূলক স্তর হিসেবে উপযোগী। কিন্তু ঠিক সেখানেই demo theater-এর ঝুঁকি বিশেষভাবে লক্ষণীয়: মডেল পর্যালোচনাটি সুন্দর করে তোলে, দল একটি পালিশ করা গল্প দেখায়, স্টেকহোল্ডাররা মাথা নাড়ে, আর Product Backlog বদলায় না।
В Sprint Retrospective AI আলোচনায় hard evidence আনতে পারে: পুনরাবৃত্ত impediments, review-এর অপেক্ষা, অসম্পূর্ণ action items, Definition of Done-এর সঙ্গে অমিল, recurring patterns। কিন্তু সুপারিশের তালিকা থেকে উন্নয়ন আসে না। এটি আসে কেবল তখনই, যখন দল সমস্যা স্বীকার করে, একটি পরিবর্তন বেছে নেয়, owner নির্ধারণ করে এবং পরবর্তী স্প্রিন্ট পর্যন্ত সেটি এগিয়ে নিয়ে যায়।
এই সিদ্ধান্তগুলো পাশাপাশি রাখলে একটি সাধারণ চিত্র emerges: AI প্রায় সর্বত্র মিটিংয়ের ইনপুটকে সমৃদ্ধ করে। আর প্রায় সর্বত্রই সমৃদ্ধ ইনপুটকে ইতিমধ্যে নেওয়া সিদ্ধান্তের সঙ্গে গুলিয়ে ফেলার প্রলোভন তৈরি করে।
Scrum events অনুযায়ী পরিবর্তনের মানচিত্র
| মিটিং / অনুশীলন | AI কী সস্তা করে | людей-এর কাছে কী থাকে | প্রধান ঝুঁকি |
|---|---|---|---|
| Backlog Refinement | প্রসঙ্গ সংগ্রহ, স্টেটমেন্টের খসড়া, গ্রহণযোগ্যতার মানদণ্ড, প্রান্তিক ঘটনা, খোলা প্রশ্ন। | অর্থ, ডোমেইন নিয়ম, প্রযুক্তিগত সীমাবদ্ধতা এবং কাজটি নিয়ে আলোচনার প্রস্তুতি যাচাই। | মিথ্যা স্পষ্টতা: কাজটি প্রস্তুত মনে হয়, কারণ এটি ভালোভাবে লেখা হয়েছে। |
| Sprint Planning | Sprint Goal, scope, নির্ভরতা, ঝুঁকি, ডিকম্পোজিশন, টেস্ট সিনারিওর варианты। | লক্ষ্য, পরিধি, বাস্তববাদিতা, Definition of Done এবং স্প্রিন্টের প্রতিশ্রুতি নিয়ে দলের সিদ্ধান্ত। | মিথ্যা বাস্তববাদিতা: পরিকল্পনাটি সম্পাদনযোগ্য মনে হয়, কারণ এটি মসৃণভাবে সাজানো হয়েছে। |
| Daily Scrum | স্প্রিন্টের অগ্রগতি, ব্লকার, PR, টেস্ট, সিদ্ধান্ত এবং নির্ভরতা সম্পর্কে প্রাথমিক সংকেত। | Shared awareness, Sprint Backlog-এর অভিযোজন এবং নিকটবর্তী কাজে কী পরিবর্তন হবে সে সম্পর্কে সিদ্ধান্ত। | স্ট্যাটাস-বট: মিটিংটি Sprint Goal নিয়ে আলোচনার বদলে মানুষ সম্পর্কে রিপোর্টে পরিণত হয়। |
| Sprint Review | Release notes, ফলাফলের চিত্র, পণ্যের মেট্রিক, প্রতিক্রিয়া এবং খোলা প্রশ্ন। | ইনক্রিমেন্টের সৎ পরিদর্শন, স্টেকহোল্ডারদের সঙ্গে আলোচনা এবং Product Backlog-এর অভিযোজন। | ডেমো-থিয়েটার: সুন্দরভাবে দেখানো হলো, কিন্তু পণ্যসংক্রান্ত সিদ্ধান্ত নেওয়া হলো না। |
| Sprint Retrospective | প্রক্রিয়া সম্পর্কে তথ্য, recurring patterns, পুরোনো action items, আলোচনার জন্য evidence। | মনস্তাত্ত্বিক নিরাপত্তা, সমস্যা স্বীকার, উন্নয়ন বেছে নেওয়া এবং follow-through। | দলের আচরণ পরিবর্তনের বদলে AI-সুপারিশের তালিকা। |
এই সারণি বলে না যে AI "Scrum উন্নত করে"। এটি খুবই জোরালো দাবি হবে। AI-assisted Scrum events নিয়ে সরাসরি স্বাধীন প্রমাণভিত্তিক ভিত্তি এখনো কম, এবং সিরিজের отдельных research briefs-এ আমি সচেতনভাবে এই ঘাটতি উল্লেখ করেছি। আরও সতর্ক বাক্যটি ভিন্ন: AI একটি পরিপক্ব পরিদর্শন ও অভিযোজন অনুশীলনকে শক্তিশালী করতে পারে, কিন্তু দলে আগে থেকেই কোনো পুরোনো anti-pattern বেঁচে থাকলে সেটিকেও সহজেই শক্তিশালী করে তুলবে।
এটি সতর্ক কাঠামোর সঙ্গে ভালোভাবে মেলে DORA State of AI-assisted Software Development 2025: AI-কে আরও ভালো delivery-এর স্বতন্ত্র নিশ্চয়তা হিসেবে নয়, বরং বিদ্যমান সাংগঠনিক ব্যবস্থার amplifier হিসেবে বিবেচনা করা উচিত। দল যদি মূল্য, ঝুঁকি, গুণমান ও প্রক্রিয়া নিয়ে আলোচনা করতে জানে, AI ইনপুটকে সমৃদ্ধ করে। দল যদি পরিদর্শনকে স্ট্যাটাস দিয়ে প্রতিস্থাপন করতে অভ্যস্ত হয়, AI স্ট্যাটাসকে আরও দ্রুত ও সুন্দর করে তুলবে।
এন্ড-টু-এন্ড কেস: B2B LMS এবং email-রিমাইন্ডার
সিরিজের সব লেখায় আমি একটি উদাহরণ ধরে রেখেছি: একটি B2B LMS প্ল্যাটফর্ম, যেখানে বড় ক্লায়েন্টরা কর্মীদের জন্য বাধ্যতামূলক কোর্স নির্ধারণ করে, আর দল ডেডলাইনের আগে বাধ্যতামূলক কোর্স সম্পূর্ণ না করা ব্যক্তিদের জন্য email-রিমাইন্ডার যোগ করে। এই কেসটি ভালোভাবে দেখায় যে AI একটি নির্দিষ্ট মিটিং নয়, বরং দলের মনোযোগের পুরো শৃঙ্খল বদলে দেয়।
Refinement-এ AI ক্লায়েন্ট প্রসঙ্গ, অনুরূপ অনুরোধ, অ্যাসাইনমেন্টের স্ট্যাটাস, নোটিফিকেশনের আর্কিটেকচার, টাইম জোন, ডিডুপ্লিকেশন, ভাষা কনফিগারেশন এবং হিস্ট্রি লগ নিয়ে প্রশ্ন সংগ্রহ করতে সাহায্য করে। দল দ্রুত অর্থবহ backlog item-এ পৌঁছায়। কিন্তু কোনটিকে অসম্পূর্ণ কোর্স ধরা হবে, কীভাবে expired-এর সঙ্গে আচরণ করা হবে, প্রথম সংস্করণের সীমা কোথায় এবং কোন ডেটা মডেলকে দেওয়া যাবে না—এসব দলকেই সিদ্ধান্ত নিতে হবে।
Planning-এ AI Sprint Goal ও কাজের পরিধির কয়েকটি варианты সংগ্রহ করতে সাহায্য করে: ন্যূনতম, বর্ধিত, উচ্চাভিলাষী, পরিধির বাইরে। দল দ্রুত সমঝোতাগুলো দেখতে পায়। কিন্তু স্প্রিন্টে আসলে কী ধরবে, কী Sprint Goal-কে সমর্থন করে, কোনটি প্রথমে বাদ দেওয়া যায় এবং Definition of Done-এ ঝুঁকি কোথায় লুকিয়ে আছে—এসবের সৎ উত্তর দলকেই দিতে হবে।
Daily Scrum-এ AI সংকেত তোলে: scheduler-এর PR রিভিউ ছাড়া খোলা, QA টেস্ট ডেটার জন্য অপেক্ষা করছে, চ্যাটে ডুপ্লিকেটের ঝুঁকি নিয়ে আলোচনা হয়েছে, টাইম জোন নিয়ে অনিশ্চয়তা দেখা দিয়েছে, সাপোর্ট ক্লায়েন্টের নতুন প্রশ্ন এনেছে। এটি ভালো ইনপুট। কিন্তু Daily-র পরে কাকে সিঙ্ক্রোনাইজ করতে হবে, কোন ঝুঁকি escalate করতে হবে এবং নিকটবর্তী পরিকল্পনা কীভাবে অভিযোজিত হবে—তা দলই সিদ্ধান্ত নেয়।
Sprint Review-এ AI ফলাফল এবং প্রতিক্রিয়া সংগ্রহ করে: কাকে অনুস্মারক পাঠানো হয়েছে, open/click rates কী ছিল, সাপোর্টে কী কী টিকিট এসেছে, পাইলট ক্লায়েন্টরা কী বলেছে, কোন backlog items এই Sprint Goal-এর সাথে সম্পর্কিত। কিন্তু পণ্যের মূল্য তখনই তৈরি হয় যখন Scrum Team এবং স্টেকহোল্ডাররা সিদ্ধান্ত নেয় পরবর্তীতে কী করতে হবে: eligibility স্পষ্ট করা, backlog পরিবর্তন করা, সাপোর্টের জন্য ডায়াগনস্টিকস যোগ করা বা অগ্রাধিকার পুনর্বিবেচনা করা expired.
Sprint Retrospective-এ AI দেখতে সাহায্য করে যে দল আবার দেরিতে টেস্ট ডেটা পেয়েছে, review একই ধরনের জায়গায় আটকে গেছে, Definition of Done ভূমিকার মধ্যে স্পষ্টভাবে ভিন্ন ছিল, এবং গত স্প্রিন্টের action item সম্পন্ন হয়নি। কিন্তু উন্নতি শুরু হয় শুধুমাত্র যখন দল পরবর্তী স্প্রিন্টের জন্য একটি নির্দিষ্ট পরীক্ষা বেছে নেয়: উদাহরণস্বরূপ, টেস্ট ডেটার owner আগে থেকে নির্ধারণ করা, PR-এর আকার কমানো বা email-প্রেরণের কাজের জন্য DoD স্পষ্ট করা।
একই কেস মূল বিষয়টি দেখায়: AI পুরো স্প্রিন্ট জুড়ে তথ্যের সূত্র টেনে নিতে পারে। কিন্তু যে সিদ্ধান্তগুলি এই তথ্যগুলিকে উপযোগী করে তোলে, তা সে প্রতিস্থাপন করতে পারে না।
পাঁচটি অ্যান্টি-প্যাটার্ন যা AI ত্বরান্বিত করে
AI-তে সবচেয়ে অপ্রিয় বিষয় এই নয় যে এটি মাঝে মাঝে ভুল করে। ভুল ধরা যায়। সবচেয়ে অপ্রিয় বিষয় এই যে এটি একটি খারাপ প্রক্রিয়াকে খুব বিশ্বাসযোগ্য করে তুলতে পারে।
মিথ্যা স্পষ্টতা। refinement-এ দল একটি পরিচ্ছন্ন user story, বিস্তারিত acceptance criteria এবং edge cases-এর তালিকা দেখে। মনে হয় কাজটি বোঝা গেছে। কিন্তু যদি তথ্যগুলি উৎসের সাথে ট্রেস না হয়, এবং খোলা প্রশ্নগুলি মসৃণ পাঠ্যের নিচে লুকানো থাকে, তাহলে দল শুধু দ্রুত প্রস্তুতির একটি বিভ্রম তৈরি করেছে।
মিথ্যা বাস্তবতা। planning-এ মডেল একটি সুন্দর Sprint Plan তৈরি করে: লক্ষ্য, scope, নির্ভরতা, risks, steps, estimates। কিন্তু যদি ডেভেলপাররা capacity, DoD, অসম্পূর্ণ কাজ এবং প্রকৃত সীমাবদ্ধতা যাচাই না করে, এটি পরিকল্পনা নয়। এটি সুন্দরভাবে সাজানো একটি আশা।
স্ট্যাটাস-বট। Daily Scrum-এ AI প্রতিদিন লিখে কে কী করেছে, Jira-তে কী পরিবর্তন হয়েছে এবং কোন PR খোলা আছে। এটি সুবিধাজনক। কিন্তু যদি দল Sprint Goal এবং পরিকল্পনার নিকটতম অভিযোজন নিয়ে কথা বলা বন্ধ করে দেয়, তাহলে Daily Scrum রিপোর্টিংয়ে পরিণত হয়েছে।
ডেমো-থিয়েটার। Sprint Review-এ AI স্লাইড, release notes এবং প্রতিক্রিয়ার সারাংশ প্রস্তুত করে। সবকিছু পেশাদার দেখায়। কিন্তু যদি স্টেকহোল্ডাররা বিতর্ক না করে, Product Backlog পরিবর্তিত না হয়, এবং অস্বস্তিকর সংকেতগুলি গড়ে যায়, তাহলে দল একটি উপস্থাপনা করেছে, Review নয়।
পরিবর্তনহীন রেট্রো। Retrospective-এ AI root causes এবং action items প্রস্তাব করে। কিন্তু যদি মানুষ সৎভাবে কথা বলতে প্রস্তুত না হয়, যদি owner, প্রভাবের যাচাই এবং পরবর্তী Sprint Backlog-এ স্থান না থাকে, এটি improvement নয়। এটি উন্নতি ছাড়া উন্নতির প্রোটোকল।
পাঁচটি অ্যান্টি-প্যাটার্নেরই একই প্রকৃতি: AI ফর্মের খরচ কমায়, কিন্তু ফর্ম বিষয়বস্তু বলে অভিনয় করতে শুরু করে। এজন্যই সিরিজের নিবন্ধগুলিতে overreliance, confabulation, misinformation, information integrity, privacy এবং human oversight সম্পর্কিত উৎসগুলি এতবার পুনরাবৃত্তি হয়েছে: NIST AI Risk Management Framework 1.0, NIST Generative AI Profile এবং OWASP Top 10 for LLM Applications 2025 AI-সিস্টেমের স্তরে এই ঝুঁকির শ্রেণিগুলি ভালভাবে বর্ণনা করে। Scrum দলে তারা খুব নির্দিষ্টভাবে প্রকাশ পায়: সুন্দর খসড়ার প্রতি অতিরিক্ত আস্থা হিসেবে।
দলে কী শক্তিশালী হওয়া উচিত
যদি AI প্রস্তুতি ত্বরান্বিত করে, তাহলে দল ভুলভাবে সিদ্ধান্ত নিতে পারে যে তাদের কম শৃঙ্খলা প্রয়োজন। বাস্তবে উল্টোটা। যত দ্রুত খসড়া তৈরি হয়, তত বেশি যাচাইয়ের শৃঙ্খলা গুরুত্বপূর্ণ।
আমি পাঁচটি দলীয় দক্ষতা তুলে ধরব যা কম গুরুত্বপূর্ণ নয়, বরং আরও গুরুত্বপূর্ণ হয়ে ওঠে।
প্রথমত: তথ্য থেকে অনুমান আলাদা করা। যেকোনো AI-ইনপুটে দৃশ্যমান হওয়া উচিত কী উৎস থেকে এসেছে, কী মডেলের ব্যাখ্যা, এবং কী কার্যকরী অনুমান। এটি refinement, planning এবং Review-তে বিশেষভাবে গুরুত্বপূর্ণ, যেখানে একটি ত্রুটি সহজেই backlog item বা পণ্য সিদ্ধান্তে পরিণত হতে পারে।
দ্বিতীয়ত: সম্পূর্ণতাだけでなく, বিশ্বাসযোগ্য মসৃণতাও যাচাই করা। একজন ভালো reviewer AI-খসড়াকে জিজ্ঞাসা করে না “আর কী যোগ করা যায়?”, বরং “এখানে কী অসত্য হতে পারে?”, “সারাংশ থেকে কোন নির্ভরতা হারিয়ে যেতে পারে?”, “মডেল কোন অপ্রিয় সংকেত গড়ে দিয়েছে?”।
তৃতীয়ত: AI-সংকেতগুলি মানুষের মূল্যায়ন হিসেবে ব্যবহার না করা। Daily Scrum এবং Retrospective এই সীমার প্রতি বিশেষভাবে সংবেদনশীল। যদি মডেল Jira, Git, PR comments এবং চ্যাট পড়ে, তাহলে কাজের বিশ্লেষণ থেকে গোপন monitoring-এ যাওয়া খুব সহজ। এটি আস্থা নষ্ট করে এবং কথোপকথনকে আরও সতর্ক করে তোলে। বাস্তবে এর অর্থ: work and system বিশ্লেষণ করা, not people।
চতুর্থত: যাচাইয়ের মালিক নিয়োগ করা। ব্যবসায়িক অর্থ যাচাই করেন প্রোডাক্ট ওনার। প্রয়োজনীয়তার সংগতি — বিশ্লেষক। আর্কিটেকচারাল সীমাবদ্ধতা — ডেভেলপাররা। Testability এবং failure modes — QA। UX-সীমা — ডিজাইনার। মিটিং এবং দলীয় চুক্তির গুণমান — স্ক্রাম মাস্টার। AI একটি সাধারণ খসড়া প্রস্তুত করতে পারে, কিন্তু যাচাইয়ের মালিক হতে পারে না।
পঞ্চমত: সিদ্ধান্তগুলিকে কাজের পরিবর্তন পর্যন্ত নিয়ে যাওয়া। যদি Sprint Review-এর ফলাফলে Product Backlog পরিবর্তিত না হয়, এবং Sprint Retrospective-এর ফলাফলে একটি যাচাইযোগ্য next-sprint experiment না আসে, তাহলে AI একটি নথিতে সাহায্য করেছে, কিন্তু Scrum-এ সাহায্য করেছে কি না তা নিশ্চিত নয়।
মুক্ত হওয়া সময় কোথায় ব্যবহার করবেন
সিরিজের সবচেয়ে গুরুত্বপূর্ণ প্রশ্নগুলোর একটি আসলে প্রযুক্তিগত নয়। যদি AI দলকে প্রস্তুতিতে সময় বাঁচায়, সেই সময় কোথায় যায়?
খারাপ উত্তর: সাথে সাথে আরও বেশি কাজ দিয়ে সেই সময় ভরে ফেলা। তখন AI শুধু প্রবাহের ঘনত্ব বাড়ায় এবং অতিরিক্ত বোঝা ঢেকে দেয়। দল দ্রুত কাজ প্রস্তুত করে, দ্রুত পরিকল্পনা সাজায়, দ্রুত স্ট্যাটাস লেখে এবং দ্রুত প্রোটোকল প্রকাশ করে, কিন্তু সিদ্ধান্তের গুণমানের প্রতি আরও মনোযোগী হয় না।
আরও পরিপক্ব উত্তর: মুক্ত হওয়া সময়ের一部分 এমন কিছুতে বিনিয়োগ করা, যা আগে সবসময় জরুরির কাছে হেরে যেত। বিতর্কিত ক্লায়েন্ট প্রসঙ্গ যাচাই করা। Definition of Done স্পষ্ট করা। টেস্ট ডেটা সম্পূর্ণ করা। বারবার আসা review সমস্যা বিশ্লেষণ করা। ডকুমেন্টেশন উন্নত করা। টেকনিক্যাল ঋণ কমানো। একেবারে সৎভাবে বললে, কঠিন planning-এর আগে ভালো ঘুমানো।
AI তখন উপকারী, যখন দল শুধু বেশি কাজ করে না। এটি তখন উপকারী, যখন দল স্পষ্ট বিষয় পুনরাবৃত্তি করতে কম মনোযোগ এবং আগে শোরগোলের কারণে পিছিয়ে পড়া সিদ্ধান্তে বেশি মনোযোগ দিতে শুরু করে।
Scrum events-এ AI প্রবর্তনের ব্যবহারিক উপায়
দল যদি আমাকে জিজ্ঞেস করে কোথা থেকে শুরু করবে, আমি বড় “AI-transformation of Scrum” দিয়ে শুরু করব না। আমি ইভেন্টের প্রস্তুতির একটি ছোট মানচিত্র দিয়ে শুরু করব।
প্রতিটি মিটিংয়ে AI প্রবর্তনের আগে সাতটি প্রশ্নের উত্তর দেওয়া উচিত:
- এই মিটিংয়ে কোন ইনপুট আসলে পরিদর্শন ও অভিযোজনে সাহায্য করে;
- কোন উৎস ব্যবহার করা যায় এবং কোনটি যায় না;
- কীভাবে তথ্য, অনুমান এবং মডেলের ব্যাখ্যা আলাদা করা হয়;
- কে ব্যবসা, আর্কিটেকচার, টেস্টিং, UX, ডেটা এবং ঝুঁকি যাচাই করে;
- এই মিটিংয়ের কোন অ্যান্টি-প্যাটার্নটি AI বাড়িয়ে তুলতে পারে;
- AI-সুপারিশের উপরে কী human override হিসেবে গণ্য হবে;
- দল কীভাবে বুঝবে যে ইভেন্টটি আরও উপকারী হয়েছে, শুধু ছোট হয়নি।
শেষ প্রশ্নটি বিশেষভাবে গুরুত্বপূর্ণ। মিটিংয়ের দৈর্ঘ্য কমানো নিজেই উন্নতির প্রমাণ নয়। Daily Scrum ছোট এবং খারাপ হতে পারে, যদি দল পরিকল্পনা অভিযোজিত করা বন্ধ করে দেয়। Sprint Review আরও সুন্দর এবং দুর্বল হতে পারে, যদি ফিডব্যাক হারিয়ে যায়। Retrospective আরও পরিচ্ছন্ন এবং অকেজো হতে পারে, যদি action items কেউ সম্পন্ন না করে।
তাই আমি “কত মিনিট বাঁচল” তা নয়, বরং আরও জীবন্ত লক্ষণ দেখব: দল আগে ঝুঁকি দেখে, তথ্য নিয়ে কম তর্ক করে, অজানাগুলো ভালোভাবে আলাদা করে, Review-এর পরে প্রায়ই Product Backlog পরিবর্তন করে, স্প্রিন্টের ভেতরে Sprint Backlog আরও সৎভাবে অভিযোজিত করে, Retrospective-এর পরে কম কিন্তু আরও নির্দিষ্ট improvement experiments বেছে নেয়।
তাহলে আসলে কী বদলায়
AI ক্লাসিক Scrum মিটিংগুলোকে প্রস্তুতি ও বিশ্লেষণমূলক স্তরের পরিবর্ধক হিসেবে বদলে দেয়। এটি দ্রুত refinement-এর জন্য উপাদান, planning-এর জন্য পরিকল্পনার বিকল্প, Daily Scrum-এর জন্য সংকেত, Sprint Review-এর জন্য ফলাফল ও ফিডব্যাক, Retrospective-এর জন্য তথ্য ও প্যাটার্ন সংগ্রহ করে।
কিন্তু এটি মূল নীতিটি বদলায় না: Scrum events ডকুমেন্ট, স্ট্যাটাস, ডেমো এবং প্রোটোকল তৈরির জন্য নয়। এগুলো inspection এবং adaptation-এর জন্য। যদি AI দলকে বাস্তবতা আরও ভালোভাবে দেখতে এবং দ্রুত সচেতন সিদ্ধান্তে পৌঁছাতে সাহায্য করে, তবে এটি উপকারী। যদি AI পুরোনো আচারকে আরও মসৃণ করে তোলে, দল Scrum-এর উন্নতি পায় না, বরং পুরোনো সমস্যার একটি ত্বরান্বিত সংস্করণ পায়।
তাই আমার চূড়ান্ত উপসংহার এই: Scrum events-এ AI চালু করা উচিত মিটিং প্রতিস্থাপন হিসেবে নয়, বরং মানব inspection-এর অধীনে প্রস্তুতির একটি স্তর হিসেবে। AI তথ্য সংগ্রহ করুক, বিকল্প প্রস্তাব করুক, ঝুঁকি চিহ্নিত করুক, সিদ্ধান্তের কথা মনে করিয়ে দিক এবং follow-up নথিভুক্ত করতে সাহায্য করুক। কিন্তু দলকে নিজের কাছে সেটাই রাখতে হবে যার জন্য Scrum আদৌ বিদ্যমান: transparency, পরীক্ষা, adaptation, দায়বদ্ধতা এবং পরবর্তী কাজ সৎভাবে পরিবর্তন করার ক্ষমতা।
পরিপক্ব দল জিজ্ঞেস করে না: “এখন আমরা কোন মিটিংগুলো বাদ দিতে পারি?”। এটি ভিন্নভাবে জিজ্ঞেস করে: “AI কোন অংশের শব্দ সরিয়ে নিতে পারে, যাতে আমাদের কাছে অর্থ, মূল্য, গুণমান এবং আচরণ পরিবর্তনের জন্য বেশি মনোযোগ থাকে?”। এটি কম চমকপ্রদ প্রশ্ন। তবে এটি ক্রস-ফাংশনাল ডেভেলপমেন্ট দলের প্রকৃত কাজের অনেক বেশি কাছাকাছি।
উৎস এবং নির্দেশিকা
- Backlog Refinement এবং AI: আসলে কী বদলায় — সিরিজের প্রথম নিবন্ধ: AI আলোচনার জন্য উপাদান প্রস্তুত করা দ্রুত করে, কিন্তু মিথ্যা স্পষ্টতার ঝুঁকি তৈরি করে।
- AI-assisted Sprint Planning: দায়বদ্ধতা না হারিয়ে প্রস্তুতি কীভাবে দ্রুত করা যায় — সিরিজের দ্বিতীয় নিবন্ধ: AI পরিকল্পনার বিকল্প দ্রুত করে, কিন্তু দলের যাচাই ছাড়া পরিকল্পনাকে বাস্তবসম্মত করে না।
- Daily Scrum এবং AI: কেন স্ট্যান্ডআপ স্ট্যাটাস-বট হওয়া উচিত নয় — সিরিজের তৃতীয় নিবন্ধ: AI সংকেতের জন্য উপকারী, কিন্তু দৈনিক প্রতিবেদন তৈরির যন্ত্র হিসেবে বিপজ্জনক।
- Sprint Review এবং AI: কেন ডেমো মূল্য নিয়ে কথোপকথনের বিকল্প নয় — সিরিজের চতুর্থ নিবন্ধ: AI ফলাফল এবং feedback সংগ্রহ করতে সাহায্য করে, কিন্তু Product Backlog-এর adaptation-এর বিকল্প নয়।
- Sprint Retrospective এবং AI: কেন উন্নয়ন মডেলকে অর্পণ করা যায় না — সিরিজের পঞ্চম নিবন্ধ: AI evidence আনে, কিন্তু psychological safety এবং follow-through তৈরি করে না।
- Scrum Guide 2020 — Scrum events, transparency, inspection, adaptation, Sprint Goal, Product Goal, Sprint Backlog, Product Backlog এবং accountabilities-এর প্রামাণ্য কাঠামো।
- Scrum Guide Expanded v2026.1 — Scrum Guide 2020-ভিত্তিক companion-উৎস; AI-কে supervised decision-making partner হিসেবে ব্যবহারিক কাঠামোর জন্য উপকারী, কিন্তু Scrum Guide-এর বিকল্প নয়।
- NIST AI Risk Management Framework 1.0 — AI ঝুঁকি ব্যবস্থাপনা, জবাবদিহিতা, সুশাসন এবং মানুষ ও AI-এর মিথস্ক্রিয়ার কনফিগারেশন।
- NIST Generative AI Profile — জেনারেটিভ AI-এর জন্য কনফাবুলেশন, অতিরিক্ত নির্ভরতা, তথ্যের অখণ্ডতা, গোপনীয়তা এবং মানব তত্ত্বাবধান।
- OWASP Top 10 for LLM Applications 2025 — সংবেদনশীল তথ্য প্রকাশ, ভুল তথ্য, অতিরিক্ত এজেন্সি এবং LLM-অ্যাপ্লিকেশনের পরিচালনগত ঝুঁকি।
- DORA State of AI-assisted Software Development 2025 — একটি সতর্ক কাঠামো: AI বিদ্যমান সাংগঠনিক অনুশীলনগুলোকে শক্তিশালী করে, তবে নিজে থেকে ডেলিভারি উন্নতির নিশ্চয়তা দেয় না।
- Lehtinen, Itkonen & Lassenius: Recurring opinions or productive improvements? — রেট্রোস্পেকটিভ, অংশগ্রহণকারী পক্ষপাত, কঠিন প্রমাণ এবং পুনরাবৃত্ত বিষয় নিয়ে একটি অভিজ্ঞতাভিত্তিক গবেষণা।
- Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams — দলগত শিক্ষার শর্ত হিসেবে সাইকোলজিক্যাল সেফটি সম্পর্কে একটি চিরায়ত উৎস।
- EDPB Opinion 28/2024 এবং ICO monitoring at work guidance impact assessment — ব্যক্তিগত তথ্য, স্বচ্ছতা, আনুপাতিকতা এবং কর্মক্ষেত্রে নজরদারির সীমা সম্পর্কিত নির্দেশনা।