10.7 অ্যাজাইল

পরিচিতি ও প্রেরণা

অ্যাজাইল হলো পুনরাবৃত্তিমূলকভাবে, ক্রমিকভাবে এবং যাঁরা এটি ব্যবহার করবেন তাঁদের সঙ্গে ঘনিষ্ঠ সহযোগিতায় সফটওয়্যার (এবং মূল্য) ডেলিভারির একটি মানসিকতা। 2001 সালের Manifesto for Agile Software Development-এ সংহিতাবদ্ধ, এটি প্রক্রিয়া হিসেবে নয়, মূল্যবোধ ও নীতির একটি সেট হিসেবে সবচেয়ে ভালো বোঝা যায়: আগের পরিকল্পনা-ভারী, চুক্তি-ভারী, নথি-ভারী ডিফল্টের ওপরে মানুষ ও মিথস্ক্রিয়া, কাজ করা সফটওয়্যার, গ্রাহক সহযোগিতা এবং পরিবর্তনে সাড়া দেওয়াকে অগ্রাধিকার। স্ক্রাম, কানবান এবং এক্সট্রিম প্রোগ্রামিং (XP)-এর মতো কাঠামো সেই মানসিকতার বাস্তবায়ন। এগুলো দরকারি শুরুর বিন্দু, কিন্তু মানসিকতা নিজে নয়। এই অধ্যায় অধ্যায় 1.4 (কাজের উপায়, যা পদ্ধতিগুলো বিস্তৃতভাবে সমীক্ষা করে) পরিপূরক করে বিশেষভাবে অ্যাজাইলে গভীরে গিয়ে।

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

বড় দল, এন্টারপ্রাইজ ও সরকারের জন্য অ্যাজাইল একই সঙ্গে শক্তিশালী এবং প্রায়ই বিকৃত। এন্টারপ্রাইজ এটি শত শত দল জুড়ে গ্রহণ করে এবং প্রায়ই সিদ্ধান্ত কীভাবে নেওয়া হয় বা মূল্য কীভাবে মাপা হয় না বদলে আচারে নামিয়ে আনে (“আমরা এখন স্ট্যান্ড-আপ করি”)। সরকার সুচিন্তিতভাবে অ্যাজাইল আলিঙ্গন করেছে, কারণ পুনরাবৃত্তিমূলক, ব্যবহারকারী-কেন্দ্রিক ডেলিভারি প্রমাণিতভাবে বড় সরকারি কর্মসূচির ঝুঁকি কমায়: U.S. Digital Service ও তার Digital Services Playbook, UK-র Government Digital Service ও Service Standard, এবং অ্যাজাইল ক্রয় সংস্কার সবই আংশিকভাবে উচ্চ-প্রোফাইল ওয়াটারফল ব্যর্থতার প্রতিক্রিয়ায় উঠে এসেছে। পুরস্কার প্রকৃত। “কেবল নামে অ্যাজাইল”-এর ব্যর্থতার ধরনও তাই।

মূল নীতিসমূহ

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

সুপারিশ

আচারের বদলে মূল্যবোধ ও নীতিতে নোঙর করুন

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

কাঠামোকে শুরুর বিন্দু হিসেবে বাছুন, ধর্ম হিসেবে নয়

কাজের সঙ্গে মেলে এমন একটি কাঠামো বাছুন এবং তা মানিয়ে নিন:

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

কাঠামো মাচা। যা সাহায্য করে রাখুন, যা করে না ফেলুন, এবং কখনো “কাঠামো বলছে” কে “নীতি কেন বলছে”-র ওপর প্রাধান্য পেতে দেবেন না।

প্রযুক্তিগত উৎকর্ষে জোর দিন

প্রকৌশল শৃঙ্খলা ছাড়া অ্যাজাইল দ্রুত অরক্ষণীয় কোডের দ্রুত উৎপাদনে অবনত হয়, “ডার্ক স্ক্রাম,” যেখানে দলগুলো নিজেদের ত্রুটি ও প্রযুক্তিগত ঋণ-এর আলকাতরা গর্তে স্প্রিন্ট করে ঢোকায়। XP চর্চা ঐচ্ছিক অতিরিক্ত নয়। কন্টিনিউয়াস ইন্টিগ্রেশন (অধ্যায় 8.1), স্বয়ংক্রিয় টেস্টিং (অধ্যায় 2.4), রিফ্যাক্টরিং, ট্রাঙ্ক-ভিত্তিক ডেভেলপমেন্ট (অধ্যায় 2.6) এবং পরিচ্ছন্ন নকশা (অধ্যায় 2.2) একটি দলকে সফটওয়্যার সস্তায় বদলাতে দেয়, যা অ্যাজিলিটির পুরো ভিত্তি। টেকসই গতি একই কারণে গুরুত্বপূর্ণ: পুড়ে যাওয়া দল মান বা সাড়াশীলতা টেকসই করতে পারে না।

সতর্কতার সঙ্গে স্কেল করুন, এবং ডিস্কেলিং পছন্দ করুন

SAFe (স্কেলড অ্যাজাইল ফ্রেমওয়ার্ক), LeSS, Nexus ও Scrum@Scale-এর মতো স্কেলিং কাঠামো অনেক দলকে ভাগ করা লক্ষ্যের দিকে সমন্বয় করে। এগুলো সাহায্য করতে পারে, কিন্তু একটি সতর্কতা বহন করে (অধ্যায় 1.4-এর প্রতিধ্বনি): ভারী স্কেলিং কাঠামো প্রায়ই ঠিক সেই কমান্ড-অ্যান্ড-কন্ট্রোল, পরিকল্পনা-ভারী ওভারহেড ফিরিয়ে আনে যা অ্যাজাইল সরাতে চেয়েছিল। একটি বড় কাঠামো গ্রহণের আগে ডিস্কেলিং চেষ্টা করুন। স্পষ্ট মালিকানা ও ন্যূনতম আন্তঃদল নির্ভরতাসহ স্বাধীন, স্ট্রিম-সারিবদ্ধ দলের চারপাশে সংগঠিত হোন (অধ্যায় 1.2), যাতে প্রথমেই কম সমন্বয় যন্ত্র লাগে। যেখানে সমন্বয় সত্যিই দরকার, কাজ করে এমন সবচেয়ে হালকা কাঠামো যোগ করুন, এবং আউটপুট নয়, ফলাফলের (OKR, উদ্দেশ্য ও মূল ফলাফল, অধ্যায় 11.1) সঙ্গে যুক্ত করুন।

এন্টারপ্রাইজ ও সরকারে অ্যাজিলিটি বাস্তব করুন

খাপখাইয়ে ডেলিভারি ও প্রাতিষ্ঠানিক সীমাবদ্ধতা সহাবস্থান করতে পারে, কিন্তু তাতে সুচিন্তিত নকশা লাগে:

• হাইব্রিড শাসন: একটি ভবিষ্যদ্বাণীমূলক অর্থায়ন/সম্মতি খোলসের ভেতরে একটি খাপখাইয়ে ডেলিভারি কোর (অধ্যায় 10.6), যাতে পুনরাবৃত্তি তদারকির সঙ্গে লড়ার বদলে তা সন্তুষ্ট করে।
• অ্যাজাইল ক্রয়: একটি স্থির-পরিসর মেগাচুক্তির বদলে মডুলার, ফলাফল-ভিত্তিক চুক্তি ও ছোট বর্ধিতাংশ; এখানেই সরকারি-খাতের অ্যাজাইল সবচেয়ে প্রায়ই সফল বা ব্যর্থ হয়।
• চলার পথে সম্মতি: নিরীক্ষা, প্রবেশগম্যতা (অধ্যায় 5.3) ও নিরাপত্তা (অধ্যায় 4.1) বর্ধিতাংশে স্বয়ংক্রিয়তা ও ফিটনেস ফাংশনের (স্থাপত্য ও মানের বৈশিষ্ট্য নিরন্তর যাচাই করা স্বয়ংক্রিয় পরীক্ষা; অধ্যায় 8.5, 1.6) মাধ্যমে গাঁথুন, দেরির গেট হিসেবে নয়।
• প্রকৃত ব্যবহারকারী প্রবেশাধিকার: সবচেয়ে কঠিন ও সবচেয়ে গুরুত্বপূর্ণ। দলগুলোর নাগরিক বা গ্রাহকের সঙ্গে প্রকৃত যোগাযোগ দরকার, যা ক্রয় ও নিরাপত্তা নিয়ম প্রায়ই বাধা দেয়।

নিরন্তর উন্নতি করুন, এবং তা মন থেকে করুন

রেট্রোস্পেক্টিভ অ্যাজাইলের উন্নতির ইঞ্জিন, এবং কোনো পরিবর্তন না ঘটালে তা মূল্যহীন। অল্প সংখ্যক সুনির্দিষ্ট, মালিকানাযুক্ত কর্ম তৈরি করা রেট্রোস্পেক্টিভ চালান, এবং পরেরটির আগে আসলে সেগুলো সম্পূর্ণ করুন। ফলাফল মাপুন (পরিবর্তন কি একটি মূল ফলাফল নড়িয়েছে? দেখুন অধ্যায় 11.1) এবং প্রবাহ মাপুন (লিড টাইম কি ছোট হচ্ছে? দেখুন অধ্যায় 11.2, 11.3)। বেগ মাপবেন না: এটি একটি সামর্থ্য সংকেত যা উৎপাদনশীলতা লক্ষ্য হিসেবে ব্যবহার করার মুহূর্তে মিথ্যা হয়ে যায়।

ট্রেড-অফ: সুবিধা ও অসুবিধা

সিদ্ধান্ত	সুবিধা	অসুবিধা
অ্যাজাইল (খাপখাইয়ে)	দ্রুত ফিডব্যাক; পরিবর্তন শোষণ করে; প্রাথমিক, নিরন্তর মূল্য	আগে পরিসর/খরচ স্থির করা কঠিনতর; সম্পৃক্ত গ্রাহক ও শৃঙ্খলা দাবি করে
ওয়াটারফল (ভবিষ্যদ্বাণীমূলক)	পূর্বাভাসযোগ্য পরিসর; চুক্তি/নিরীক্ষা-বান্ধব	দেরিতে ফিডব্যাক; বিগ-ব্যাং ঝুঁকি; অনিশ্চিত প্রয়োজনীয়তায় খারাপ মানানসই
স্ক্রাম	ছন্দ, ভূমিকা, মনোযোগ; ব্যাপকভাবে বোঝা	আনুষ্ঠানিকতা ওভারহেড; ব্যাঘাত-চালিত কাজে সংগ্রাম
কানবান	প্রবাহ, WIP সীমা, নমনীয়; পরিচালনার জন্য দারুণ	কম কাঠামো; সীমা ধরে রাখতে শৃঙ্খলা লাগে
ভারী স্কেলিং (SAFe)	অনেক দল সমন্বয় করে; বড় প্রতিষ্ঠানের পরিচিত	কমান্ড-অ্যান্ড-কন্ট্রোল ফিরিয়ে আনতে পারে; আনুষ্ঠানিকতা-ভারী
ডিস্কেলিং / দলের স্বায়ত্তশাসন	কম সমন্বয় ওভারহেড; দ্রুততর দল	নিম্ন সংযুক্তি এবং শক্তিশালী প্ল্যাটফর্ম/মালিকানা লাগে

সংজ্ঞায়ক টানাপোড়েন খাপখাওয়ানো বনাম পূর্বাভাসযোগ্যতা, এবং ক্লাসিক ভুল পাঠ হলো অ্যাজাইল মানে “কোনো পরিকল্পনা নেই।” তা নয়। এর অর্থ নিরন্তর পরিকল্পনা করা এবং পরিসর নমনীয় রেখে ফলাফল ও ছন্দে অঙ্গীকার করা। অন্য পুনরাবৃত্ত ফাঁদ হলো অ্যাজাইলকে কেবল প্রক্রিয়া (আচার) বা কেবল প্রকৌশল (XP) গণ্য করা। এর দুটিই দরকার।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

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

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

3. আপনার দল প্রযুক্তিগত ঋণে স্প্রিন্ট করছে কি না আপনি কীভাবে জানবেন, এবং লঞ্চ চাপের মধ্যে টেকসই গতি কী রক্ষা করে? প্রকৌশল শৃঙ্খলা ছাড়া অ্যাজাইল ডার্ক স্ক্রামে অবনত হয়, যেখানে দলগুলো ত্রুটি ও অরক্ষণীয় কোডের আলকাতরা গর্তে দ্রুত স্প্রিন্ট করে, এবং পুড়ে যাওয়া দল মান বা সাড়াশীলতা টেকসই করতে পারে না। XP চর্চা (কন্টিনিউয়াস ইন্টিগ্রেশন, স্বয়ংক্রিয় টেস্টিং, রিফ্যাক্টরিং, ট্রাঙ্ক-ভিত্তিক ডেভেলপমেন্ট) একটি দলকে সফটওয়্যার সস্তায় বদলাতে দেয়, যা অ্যাজিলিটির পুরো ভিত্তি, তাই একটি তারিখ ঘনালে বিনিময় করার ঐচ্ছিক অতিরিক্ত নয়। প্রমাণ আনুন: লিড টাইম ছোট হচ্ছে না বাড়ছে, ত্রুটি হার উঠছে কি না, এবং দল প্রতিটি স্প্রিন্ট ধরতে নীরবে বেশি ঘণ্টা কাজ করছে কি না অনুসরণ করুন। উত্তর প্রযুক্তিগত উৎকর্ষ ও মানবিক গতিকে অনমনীয় করা উচিত, কারণ কারুশিল্প বিসর্জন দিয়ে কেনা গতি কয়েকটি পুনরাবৃত্তির মধ্যে ভেঙে পড়ে। প্রবাহ ও ফলাফল মাপুন, কখনো বেগ লক্ষ্য হিসেবে নয়, কারণ একটি সামর্থ্য সংকেতকে উৎপাদনশীলতা লক্ষ্য করার মুহূর্তে তা মিথ্যা হয়।

4. একটি ভারী স্কেলিং কাঠামোর দিকে হাত বাড়ানোর আগে, আপনি কি প্রথমেই সমন্বয়ের প্রয়োজন তৈরি করা আন্তঃদল নির্ভরতা কমানোর চেষ্টা করেছেন? এটি একটি বড় প্রতিষ্ঠানের জন্য সবচেয়ে গুরুত্বপূর্ণ, কারণ অনেক দলকে একসঙ্গে পাঠাতে হলে প্রতিক্রিয়া হলো SAFe, LeSS বা Scrum@Scale-এর মতো একটি কাঠামো কেনা, এবং ভারী স্কেলিং যন্ত্র প্রায়ই অ্যাজাইল যা সরাতে আছে সেই কমান্ড-অ্যান্ড-কন্ট্রোল, পরিকল্পনা-ভারী ওভারহেড পাচার করে ফিরিয়ে আনে। প্রতিদ্বন্দ্বী বিবেচনা প্রকৃত: কিছু সমন্বয় সত্যিই দরকার, এবং স্বাধীন, স্ট্রিম-সারিবদ্ধ দলে ডিস্কেলিং নিম্ন সংযুক্তি, স্পষ্ট মালিকানা এবং দলগুলোকে স্ব-সেবা করতে দেওয়ার মতো পরিণত একটি প্ল্যাটফর্ম দাবি করে, যা আপনার এখনো না থাকতে পারে। আলোচনায় প্রমাণ আনুন: দলগুলোকে একে অপরের জন্য অপেক্ষা করতে বাধ্য করা প্রকৃত নির্ভরতা মানচিত্র করুন, এবং জিজ্ঞাসা করুন দলের সীমানা ও সেবা মালিকানার একটি সুচিন্তিত পুনর্নকশায় কতগুলো টিকে থাকবে। এন্টারপ্রাইজ ও সরকারি কর্মসূচিতে, যেখানে ডজন খানেক দলের একটি সংগঠন চার্ট সাধারণ, সৎ প্রশ্ন হলো আপনি কি এমন একটি স্থাপত্য ও দল নকশার ক্ষতিপূরণে সমন্বয় কাঠামো যোগ করছেন যা আপনি সরলীকরণ করতে পারতেন, যাতে আপনার আদৌ কম সমন্বয় লাগে।

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

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

খাতভেদে দৃষ্টিভঙ্গি

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

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

এন্টারপ্রাইজ। সমস্যা কমান্ড-অ্যান্ড-কন্ট্রোল ফিরিয়ে না এনে অনেক দল সমন্বয় করা। একটি ভারী স্কেলিং কাঠামো গ্রহণের আগে ডিস্কেলিং পছন্দ করুন, অর্থাৎ স্ট্রিম-সারিবদ্ধ দল নকশা ও একটি দৃঢ় প্ল্যাটফর্মের মাধ্যমে আন্তঃদল নির্ভরতা কমানো। নির্ধারিত বার্ষিক পরিসর ও স্টোরি পয়েন্টের বদলে ফলাফল (OKR) ও ছন্দের চারপাশে অর্থায়ন ও শাসন করুন, দল জুড়ে XP-ধাঁচের প্রকৌশল চর্চা অনমনীয় করুন, এবং প্রবাহ মেট্রিক ও ফলাফল পরিমাপসহ ডেলিভারি পোর্টফোলিও হিসেবে পরিচালনা করুন যাতে গোষ্ঠীগুলো আচারের বদলে প্রমাণে উন্নতি করে।

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

উদাহরণ

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

এন্টারপ্রাইজ। একটি টেলিকমের 60-দলের রূপান্তর প্রথমে “স্ক্রাম করে” কিন্তু কোনো উন্নতি দেখে না। দলগুলো এখনো নির্ধারিত বার্ষিক পরিসর পায় এবং বেগ নিয়ে প্রতিবেদন করে। একটি রিসেট নীতিতে পুনঃকেন্দ্রীভূত হয়: ত্রৈমাসিক OKR ফিচার আদেশ প্রতিস্থাপন করে, আন্তঃদল নির্ভরতা কমাতে দলগুলো পুনর্গঠিত হয় (ডিস্কেলিং), এবং XP চর্চা (CI, TDD, ট্রাঙ্ক-ভিত্তিক ডেভেলপমেন্ট) অনমনীয় করা হয়। লিড টাইম কমে, ত্রুটি কমে, এবং, গুরুত্বপূর্ণভাবে, ব্যবসা স্টোরি পয়েন্টের বদলে ফলাফল মাপতে শুরু করে, অ্যাজাইল ডেলিভারিকে আবিষ্কার পাইপলাইনের সঙ্গে যুক্ত করে (অধ্যায় 11.1)।

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

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

অ্যাজাইলের প্রতিদান আসে ঝুঁকি হ্রাস ও দ্রুততর মূল্য উপলব্ধি থেকে। কাজ করা সফটওয়্যার আগে ও ঘন ঘন ডেলিভার করে দলগুলো অনিশ্চয়তাকে নিরন্তর প্রমাণে রূপান্তর করে, ভুল-জিনিস ও কাজ-করবে-না ব্যর্থতা সস্তা থাকতেই ধরে, একটি দূরের, ব্যয়বহুল গো-লাইভে নয়। আধুনিক ডেলিভারির পিছনের গবেষণা (DORA, DevOps Research and Assessment, অধ্যায় 11.2-এর ফলাফল) দেখায় অ্যাজাইল যে চর্চা প্রচার করে (ছোট ব্যাচ, ঘন ঘন রিলিজ, দ্রুত ফিডব্যাক, প্রযুক্তিগত উৎকর্ষ) তা ভালো ডেলিভারি এবং স্থিতিশীলতা এবং সাংগঠনিক কর্মক্ষমতার সঙ্গে সম্পর্কযুক্ত। প্রাথমিক বর্ধিতাংশও আগে মূল্য ফেরত দেওয়া শুরু করে, যা একটি বিগ-ব্যাং রিলিজের তুলনায় ROI-এর সময় ও মোট আকার উন্নত করে, যে রিলিজ শেষ পর্যন্ত কিছুই ফেরত দেয় না।

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

অ্যান্টি-প্যাটার্ন ও ফাঁদ

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

পরিপক্বতা মডেল

• স্তর 1, সূচনা। ওয়াটারফল বা অ্যাড হক ডেলিভারি; বিগ-ব্যাং রিলিজ; কাজ প্রতিক্রিয়াশীল ও পরিকল্পনা-ভারী, কোনো পুনরাবৃত্তিমূলক ফিডব্যাক ও অ্যাজাইল কেন সাহায্য করতে পারে তার কোনো ভাগ করা ধারণা নেই।
• স্তর 2, বিকাশ। কয়েকটি দল অ্যাজাইল আচার (স্ট্যান্ড-আপ, স্প্রিন্ট, রেট্রোস্পেক্টিভ) গ্রহণ করে, কিন্তু সংগঠন জুড়ে চর্চা অসামঞ্জস্যপূর্ণ: মানসিকতা ও প্রকৌশল শৃঙ্খলা আচারের পিছনে পড়ে, বেগকে আউটপুট গণ্য করা হয়, এবং পরিসর এখনো আগে স্থির।
• স্তর 3, মানসম্মতকরণ। মূল্যবোধ ও নীতি প্রকৃতপক্ষে প্রতিষ্ঠান-ব্যাপী কাজ পরিচালনা করে, প্রতিটি দলের জন্য নথিবদ্ধ ও প্রত্যাশিত: XP-ধাঁচের প্রযুক্তিগত উৎকর্ষ (CI, স্বয়ংক্রিয় টেস্টিং, রিফ্যাক্টরিং, ট্রাঙ্ক-ভিত্তিক ডেভেলপমেন্ট) মান চর্চা, দল স্ব-সংগঠিত, প্রতিটি পুনরাবৃত্তিতে গ্রাহকরা সম্পৃক্ত, এবং রেট্রোস্পেক্টিভ সুনির্দিষ্ট, সম্পূর্ণ পরিবর্তন তৈরি করে।
• স্তর 4, ব্যবস্থাপনা। ডেলিভারি ভিত্তিরেখার বিপরীতে মাপা ও নিয়ন্ত্রিত: দলগুলো লিড টাইম, ডিপ্লয়মেন্ট ফ্রিকোয়েন্সি, পরিবর্তন-ব্যর্থতা হার ও ত্রুটি পলায়ন হার (DORA-ধাঁচের প্রবাহ ও স্থিতিশীলতা মেট্রিক) অনুসরণ করে, মূল ফলাফলের সঙ্গে বাঁধা ফলাফল পরিমাপের পাশাপাশি, এবং প্রতিটি একটি জানা ভিত্তিরেখার বিপরীতে তুলনা করে। রেট্রোস্পেক্টিভ কর্ম সমাপ্তি পর্যন্ত অনুসরণ করা হয়, ওভারটাইম ও বার্নআউটের মতো টেকসই-গতি সংকেত পর্যবেক্ষিত, এবং বেগ কখনো উৎপাদনশীলতা লক্ষ্য হিসেবে ব্যবহৃত হয় না। যাওয়া-না-যাওয়া সিদ্ধান্ত মতামতের বদলে এই প্রমাণের ওপর দাঁড়ায়।
• স্তর 5, সমন্বয়। খাপখাইয়ে ডেলিভারি প্রতিষ্ঠান জুড়ে ব্যবসা ও ঝুঁকি পরিকল্পনার সঙ্গে একীভূত: ফলাফল (OKR) অর্থায়ন ও ছন্দ চালায়, নিম্ন-নির্ভরতা দল নকশা (ডিস্কেলিং) সমন্বয় ওভারহেড ন্যূনতম করে, এবং হাইব্রিড শাসন ডেলিভারি ধীর না করে তদারকি সন্তুষ্ট করে। নিরন্তর উন্নতি আনুষ্ঠানিকতার বদলে সাংস্কৃতিক, এবং প্রমাণ ও ঝুঁকি চিত্র সরলে প্রতিষ্ঠান নিয়মিত তার পোর্টফোলিও পুনঃপরিসর, পুনঃদলবদ্ধ ও পুনঃভারসাম্য করে।

আলোচনার ভাবনা

1. বারোটি অ্যাজাইল নীতির বিপরীতে আপনার দলকে স্কোর করুন: আপনি কোথায় আচারে অ্যাজাইল কিন্তু সারবস্তুতে নন?
2. আপনার দলে বেগ কি পূর্বাভাস হিসেবে ব্যবহৃত হয় নাকি লক্ষ্য হিসেবে, এবং তা আচরণের ওপর কী করেছে?
3. কোন XP প্রযুক্তিগত চর্চা অনুপস্থিত, এবং এর অনুপস্থিতি ত্রুটি বা ধীর পরিবর্তন হিসেবে কীভাবে দেখা দিচ্ছে?
4. একটি স্কেলিং কাঠামো গ্রহণের আগে, আপনি কি এর বদলে আন্তঃদল নির্ভরতা কমাতে পারেন?
5. আপনার প্রেক্ষাপটে ঠিক কী প্রতি পুনরাবৃত্তিতে প্রকৃত ব্যবহারকারী প্রবেশাধিকার আটকায়, এবং আপনি কীভাবে তা সরাতে পারেন?
6. একটি রেট্রোস্পেক্টিভ শেষবার আসলে কোন সুনির্দিষ্ট পরিবর্তন ঘটিয়েছে?

প্রধান শিক্ষা

• অ্যাজাইল আচারের সেট নয়, মূল্যবোধ ও নীতির একটি মানসিকতা; কাঠামো শুরুর বিন্দু, লক্ষ্য নয়।
• ঘন ঘন কাজ করা সফটওয়্যার ডেলিভার করুন, পরিবর্তনকে স্বাগত জানান, এবং স্ব-সংগঠিত দল ক্ষমতায়ন করুন।
• প্রযুক্তিগত উৎকর্ষ (XP চর্চা) অনমনীয়। এটি ছাড়া অ্যাজিলিটি দ্রুত ক্ষয়ে পরিণত হয়।
• সতর্কতার সঙ্গে স্কেল করুন; ডিস্কেলিং পছন্দ করুন। সমন্বয় কাঠামো যোগ করার আগে নির্ভরতা কমান।
• এন্টারপ্রাইজ/সরকারে খাপখাইয়ে ডেলিভারিকে হাইব্রিড শাসন ও অ্যাজাইল ক্রয়ের সঙ্গে মেলান, এবং প্রকৃত ব্যবহারকারী প্রবেশাধিকারের জন্য লড়ুন।
• ROI হলো নিরন্তর ঝুঁকি হ্রাস ও আগের মূল্য, কিন্তু কেবল যখন অ্যাজাইল প্রকৃত, আচার নয়। দেখুন অধ্যায় 1.4, 11.1, 11.2, 10.6 এবং 11.3।

তথ্যসূত্র ও আরও পড়ার জন্য

• Kent Beck et al., Manifesto for Agile Software Development and its twelve principles (agilemanifesto.org, 2001).
• Ken Schwaber and Jeff Sutherland, The Scrum Guide.
• Kent Beck, Extreme Programming Explained: Embrace Change.
• David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business.
• Mike Cohn, User Stories Applied and Succeeding with Agile.
• Jeff Patton, User Story Mapping.
• Stephen Denning, The Age of Agile.
• Matthew Skelton and Manuel Pais, Team Topologies (team design and descaling).
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (evidence for agile/DevOps practices).
• U.S. Digital Service, Digital Services Playbook; UK Government, Government Service Standard.