12.6 اپنانے کا روڈ میپ

یہ ضمیمہ اس کتاب کے عمل کو بتدریج رول آؤٹ کرنے کی عملی رہنما ہے۔ پوری گائیڈ بک کی سب سے اہم واحد ہدایت، جو ہر باب میں دہرائی گئی ہے، یہ ہے: بتدریج اپنائیں؛ big-bang نہ کریں۔ جو تبدیلی ایک ساتھ سب کچھ بدلنے کی کوشش کرے وہ پائیداری سے کچھ نہیں بدلتی: وہ خیر سگالی تھکاتی ہے، ٹیموں کو مغلوب کرتی ہے، اور پہلے بحران پر ڈھ جاتی ہے۔ جو تبدیلی حقیقی درد سے شروع ہو، نظر آنے والی جیت دے، اور وہاں سے مرکب ہو، وہ چند سالوں میں ہزاروں کے ادارے کو حرکت دے سکتی ہے۔

یہ روڈ میپ آپ کو اپنانے کے اصول، پہلے 90 دن سے دو سے زیادہ سالوں تک پختگی پر مبنی ترتیب، حل شدہ مثال کے ساتھ ترجیح کا فریم ورک، شعبہ بہ شعبہ فوری جیتیں، انٹرپرائز اور حکومت کے لیے خاص رہنمائی، کامیابی ناپنے کے طریقے، اور بچنے کے ناکامی کے طریقے دیتا ہے۔

اپنانے کے اصول

یہ اصول آپ کے سائز، شعبے، یا ابتدائی پختگی سے قطع نظر لاگو ہیں۔

درد سے شروع کریں، فریم ورک سے نہیں۔ وہ چیز ڈھونڈیں جو سب سے زیادہ تکلیف دے، چاہے سست ریلیزز، بار بار outages، ناکام آڈٹ، یا چھوڑ کر جانے والے لوگ، اور اسے پہلے ٹھیک کریں۔ درد وہ طلب اور سیاسی آڑ پیدا کرتا ہے جو اوپر سے مینڈیٹ کبھی نہیں دے سکتا۔ آرام کی کوئی مزاحمت نہیں کرتا۔
مینڈیٹ کی بجائے پکی سڑکیں۔ سفارش کردہ طریقے کو آسان ترین طریقہ بنائیں۔ golden path جو تیز، محفوظ، اور بہتر دستاویزی ہو اپنی خوبیوں پر اپنانا جیتتی ہے؛ وہ پالیسی جو متبادل راستے سے سست ہو اس کے گرد راستہ نکالا جائے گا۔ کچی پگڈنڈی کو deprecate کرنے سے پہلے پکی سڑک میں سرمایہ کاری کریں۔
سرگرمی نہیں، نتائج ناپیں۔ ٹریک کریں کہ تبدیلی نے ترسیل، قابل اعتمادی، سیکیورٹی کی کیفیت، یا صارف کے نتائج بہتر کیے، نہ کہ کتنی ٹیموں نے تربیت میں شرکت کی یا خانہ پُر کیا۔ بدلنے سے پہلے instrument کریں تاکہ اثر ثابت کر سکیں۔
ایگزیکٹو سرپرستی محفوظ کریں، اور برقرار رکھیں۔ پائیدار تبدیلی کو جوابدہ ایگزیکٹو چاہیے جو فنڈنگ کی حفاظت کرے، رکاوٹیں ہٹائے، اور جب تبدیلی ناگوار ہو تو ڈٹا رہے۔ سرپرستی launch کی تقریب نہیں؛ یہ جاری تعلق ہے جسے آپ کو نتائج سے دوبارہ کمانا ہوگا۔
بھرتی شدہ سے پہلے رضاکار۔ ان ٹیموں سے شروع کریں جو بدلنا چاہتی ہیں۔ ان کی کامیابی حوالہ کی کہانی بنتی ہے جو ہچکچاتی اکثریت کو کھینچتی ہے۔ مزاحمت کرنے والوں کو پہلے مجبور کرنا بدنیتی کی تعمیل اور تنبیہی کہانیاں پیدا کرتا ہے۔
جہاں ممکن ہو الٹنے کے قابل بنائیں۔ ایسی تبدیلیوں کو ترجیح دیں جنہیں آپ pilot، ناپ، اور rollback کر سکیں۔ الٹنے کے قابل “دو طرفہ دروازے” کے فیصلے تیزی سے چل سکتے ہیں؛ بھاری عمل کو واقعی ناقابل واپسی کے لیے رکھیں۔
جلد اور اکثر جیتیں دکھائیں۔ سہ ماہیوں میں نہیں، ہفتوں میں کچھ نظر آنے والا ship کریں۔ رفتار وسیلہ ہے؛ پہلی جیت اگلی کو فنڈ کرنے پر خرچ کریں۔
ٹیموں کو وہاں ملیں جہاں وہ ہیں۔ سب پر یکساں لاگو واحد پختگی کی حد غیر منصفانہ اور حوصلہ شکن ہے۔ ہر ٹیم کی تیاری اور درد کے مطابق ترتیب دیں۔

پختگی پر مبنی ترتیب

نیچے کے افق جمع ہوتے ہیں: ہر ایک پچھلے پر بنتا ہے۔ تاریخیں رہنمائی ہیں، ڈیڈ لائنیں نہیں؛ بڑا یا بھاری ضابطے والا ادارہ ہر مرحلہ زیادہ دیر چلا سکتا ہے۔ نمونہ (مستحکم کریں، پھر معیاری بنائیں، پھر پھیلائیں، پھر برقرار رکھیں) رفتار سے قطع نظر قائم رہتا ہے۔

پہلے 90 دن: مستحکم کریں اور ثابت کریں

ہدف: بنیادی لکیر قائم کریں، ایک یا دو نمایاں مسائل چنیں، اور آمادہ ٹیم کے ساتھ معتبر پہلی جیت دیں۔

جوابدہ ایگزیکٹو سرپرست اور چھوٹے رہنما اتحاد کا نام لیں۔
چار DORA میٹرکس (ڈیپلائے کی تعدد، lead time، تبدیلی کی ناکامی کی شرح، بحالی کا وقت) کی بنیادی لکیر بنائیں چاہے اعداد موٹے ہوں۔
سب سے بڑے خلا ڈھونڈنے کو باب 12.4 کے پختگی کے ماڈلز کے مقابل ہلکی تشخیص چلائیں۔
ایک یا دو pilot ٹیمیں چنیں جو رضاکار ہوں اور حقیقی درد رکھتی ہوں۔
ایک نمایاں مسئلہ شروع سے آخر تک ٹھیک کریں (مثلاً ایک ٹیم کی ڈیپلائے خودکار کریں، یا ایک نازک سروس میں SLOs جوڑیں)۔
فیصلوں کا مشترک ریکارڈ (ADRs) اور نتائج شائع کرنے کی جگہ کھڑی کریں۔
کچھ بدلنے سے پہلے اتفاق کریں کہ کامیابی کیسے ناپیں گے۔

6 مہینے تک: جیتنے والے نمونے کو معیاری بنائیں

ہدف: pilot کی کامیابی کو دہرائے جانے کے قابل، دستاویزی نمونے میں بدلیں اور اسے ٹیموں کے اگلے گروہ کو پکی سڑک کے طور پر پیش کریں۔

pilot سے golden path کو دوبارہ قابل استعمال سانچوں، پائپ لائنز، اور دستاویزات کے طور پر شائع کریں۔
پکی سڑک کی مالک اور سہارا دینے کو پلیٹ فارم یا enabling ٹیم (حتیٰ کہ مجازی) قائم کریں۔
نمونہ تین سے پانچ مزید ٹیموں کو رول آؤٹ کریں، اثر اور تیاری سے ترجیح دیتے ہوئے۔
خودکار معیار اور سیکیورٹی کے دروازے (linting، ٹیسٹ، SAST/SCA) مشترک پائپ لائن میں ڈیفالٹ کے طور پر شامل کریں، اضافے کے طور پر نہیں۔
بلا الزام واقعے کے ریویو کا عمل شروع کریں اور postmortems اندرونی طور پر شائع کریں۔
ہلکا نظم و نسق کا فورم (فن تعمیر کا ریویو، پکی سڑک کی نگرانی داری) قائم کریں جو دروازے پر پہرہ دینے کی بجائے رکاوٹیں ہٹائے۔

12 مہینے تک: ادارے بھر پھیلائیں

ہدف: پکی سڑک کو زیادہ تر نئے کام کے لیے ڈیفالٹ بنائیں اور بدترین پرانے عمل ریٹائر کرنا شروع کریں۔

پلیٹ فارم ٹیم کا دائرہ بڑھائیں؛ سروس کیٹلاگ اور اسکور کارڈ شائع کریں۔
ادارہ گیر بنیادی لکیریں طے کریں: tier-1 سروسز کے SLOs، ہر پائپ لائن میں سیکیورٹی کنٹرولز، front-end builds میں رسائی کی جانچیں۔
ٹیم کے لحاظ سے اپنانے کی شرحیں ٹریک کریں اور ڈیٹا نظر آنے والا بنائیں۔
strangler-fig اور branch-by-abstraction نمونوں سے سب سے زیادہ خطرے والے نظاموں پر دانستہ پرانے نظام کی جدت کاری شروع کریں۔
پیمائش کو منصوبہ بندی میں بُنیں: ٹیمیں اپنی DORA اور قابل اعتمادی کے رجحانات معمول کی آپریٹنگ تال میں ریویو کرتی ہیں۔
اہلیت سازی (اندرونی تربیت، رہنمائی، عمل کی برادریاں) میں سرمایہ کاری کریں تاکہ صلاحیت مینڈیٹ سے تیز پھیلے۔

2+ سال: برقرار رکھیں اور مسلسل بہتر کریں

ہدف: عمل “ہم کیسے کام کرتے ہیں” ہیں، پروگرام نہیں، اور ادارہ مرکزی دھکے کے بغیر انہیں بہتر کرتا ہے۔

تبدیلی کے پروگرام کو نام زد اقدام کے طور پر ریٹائر کریں؛ اس کا کام معمول کے نظم و نسق اور پلیٹ فارم آپریشنز میں پیوست کریں۔
پکی سڑک کو اپنے روڈ میپ، صارفین، اور اطمینان کے میٹرکس (ڈویلپر کے تجربے کے سروے) والی پروڈکٹ سمجھیں۔
تکنیکی قرض اور جدت کاری کو ایک بار کے دھکے کی بجائے کھڑے پورٹ فولیو کے طور پر منظم کریں۔
وقتاً فوقتاً پختگی کی دوبارہ تشخیص چلائیں اور جیسے بنیادی حد بلند ہو معیارات اوپر ایڈجسٹ کریں۔
پسپائی سے بچیں: سرپرستی رکھیں، ناپتے رہیں، اور ٹیکنالوجی اور خطرات کے ارتقا پر عمل تازہ کریں۔

ترجیح کا فریم ورک

آپ کے پاس ہمیشہ بہتریاں کرنے کی صلاحیت سے زیادہ بہتریاں ہوں گی۔ کمرے میں سب سے بلند آواز کی بجائے سادہ، قابل دفاع ماڈل سے ترجیح دیں۔

ہر امیدوار اقدام کو تین جہتوں پر سکور دیں:

اثر (1–5): یہ کتنا حقیقی نتیجہ (ترسیل کی رفتار، قابل اعتمادی، سیکیورٹی، لاگت، یا صارف کی قدر) بہتر کرے گا، اور کتنی ٹیموں یا صارفین کے لیے؟
کوشش (1–5): اسے ڈیلیور کرنے میں کتنا کام، ہم آہنگی، اور خلل؟ (اونچا = زیادہ کوشش۔)
خطرے کا وزن (0.5–2.0): فوری پن اور نمائش کا ضرب کنندہ۔ سیکیورٹی، تعمیل، اور حفاظت کے مسائل اونچا وزن رکھتے ہیں؛ اچھے-ہونے-والے کم۔

مفید درجہ بندی کا سکور ہے:

Priority = (Impact × Risk weight) ÷ Effort

نزولی ترجیح سے رینک کریں۔ اوپر کی اشیا کو ترتیب دیں، مگر رفتار قائم رکھنے کو ہمیشہ کم از کم ایک تیز، کم کوشش والی “فوری جیت” جاری رکھیں، اور حالات بدلنے پر ہر سہ ماہی اسکور پر نظر ثانی کریں۔

حل شدہ مثال

اقدام	اثر	کوشش	خطرے کا وزن	ترجیح	ترتیب
سب سے اونچی آمدنی والی سروس کی ڈیپلائے خودکار کریں	5	2	1.5	3.75	ابھی
tier-1 سروسز میں SLOs اور alerting جوڑیں	4	2	1.5	3.00	ابھی
مشترک پائپ لائن میں SAST/SCA لائیں	4	2	2.0	4.00	ابھی
تمام front ends کو ڈیزائن سسٹم رول آؤٹ کریں	4	5	1.0	0.80	بعد میں
mainframe batch کو کلاؤڈ میں منتقل کریں	5	5	1.5	1.50	مرحلہ وار
ٹیموں میں ADRs معیاری کریں	3	1	1.0	3.00	ابھی (فوری جیت)
ادارے بھر نئی پروگرامنگ زبان اپنائیں	2	5	0.5	0.20	موخر کریں

اس مثال میں، سیکیورٹی پائپ لائن کا کام اپنے اونچے خطرے کے وزن اور معمولی کوشش کی وجہ سے فہرست میں اوپر ہے، جبکہ ادارہ گیر زبان کی تبدیلی جوش کے باوجود نیچے گرتی ہے، کیونکہ اس کا اثر کم اور کوشش اور خلل زیادہ ہے۔ فریم ورک اس سمجھوتے کو واضح اور قابل بحث بناتا ہے، جو اس کی حقیقی قدر ہے۔

شعبہ بہ شعبہ فوری جیتیں

کتاب کے ہر حصے کا کم لاگت، اونچے اشارے کا پہلا قدم ہے۔ یہاں سے شروع کریں۔

حصہ	“یہاں سے شروع کریں” فوری جیت
بنیادیں (ثقافت، ٹیمیں، عمل)	ہلکے ADRs اپنائیں اور ایک بلا الزام retrospective چلائیں؛ فیصلے اور سیکھنا نظر آنے والا بنائیں۔
پروگرامنگ کا فن	CI میں نافذ ڈیفالٹس کے طور پر auto-formatter اور linter چالو کریں، تاکہ انداز ریویو کا موضوع نہ رہے۔
فن تعمیر	اپنے سب سے اہم نظام کے لیے ایک صفحے کا فن تعمیراتی فیصلہ اور C4 context خاکہ لکھیں۔
سیکیورٹی	پائپ لائن میں انحصار کی اسکیننگ (SCA) اور secret scanning جوڑیں؛ پہلے ایک نازک ریپو کے لیے چالو کریں۔
UX / ڈیزائن	اپنے سب سے زیادہ ٹریفک والے بہاؤ پر تین سستے usability ٹیسٹ چلائیں؛ جو سب سے بڑا مسئلہ دیکھیں اسے ٹھیک کریں۔
AI / ML	کسی بھی ماڈل کے کام سے پہلے ایک صفحے کی مسئلے کی تشکیل اور ڈیٹا کی تیاری کی جانچ لکھیں؛ متعین کریں کہ کامیابی کیسے جانچیں گے۔
ڈیٹا / analytics	ایک متفقہ “north-star” میٹرک اور ایک قابل اعتماد ڈیش بورڈ متعین کریں؛ ایک متضاد کو ریٹائر کریں۔
DevOps / پلیٹ فارم	ایک ٹیم کو مکمل خودکار build-test-deploy پائپ لائن تک پہنچائیں اور اسے سانچے کے طور پر دستاویزی کریں۔
آپریشنز / قابل اعتمادی	اپنے سب سے نازک صارف کے سفر کے لیے SLIs اور ایک SLO متعین کریں؛ وجوہات پر نہیں، علامات پر alert کریں۔
انٹرپرائز / حکومت	اپنے موجودہ کنٹرولز کو ایک فریم ورک (NIST CSF، ISO 27001، یا SOC 2) سے نقشہ بند کریں اور ایک کنٹرول کی شہادت خودکار کریں۔

انٹرپرائز کے لیے خاص رہنمائی

بڑے قائم شدہ ادارے پیمانہ، بہت سی ٹیمیں، گہرا پرانا نظام، اور بھاری تبدیلی کے انتظام کا اوور ہیڈ اٹھاتے ہیں۔ روڈ میپ کو اسی کے مطابق ڈھالیں۔

وفاقی بنائیں، سب کچھ مرکزی نہ کریں۔ واحد مرکزی ٹیم سینکڑوں پروڈکٹ ٹیموں کی خدمت نہیں کر سکتی۔ پلیٹ فارم ٹیم سے پکی سڑکیں اور enabling ٹیموں سے کوچنگ دلوائیں، جبکہ پروڈکٹ ٹیمیں ملکیت رکھیں۔ (Team Topologies دیکھیں۔)
Conway کے قانون کا احترام کریں۔ آپ کا فن تعمیر آپ کے org chart کی عکاسی کرے گا۔ اگر آپ الگ سروسز چاہتے ہیں تو آپ کو الگ، بااختیار ٹیمیں چاہییں؛ فطرت کے خلاف لڑنے کی بجائے دانستہ تنظیم نو کریں۔
پرانے نظام کو پورٹ فولیو سمجھیں۔ آپ سب کچھ جدید نہیں کر سکتے۔ پرانے نظاموں کو خطرے اور کاروباری قدر سے رینک کریں، اور جو چند اہم ہیں ان پر strangler-fig migration لگائیں؛ باقی کو دانستہ منجمد یا ختم کریں۔
تبدیلی کا انتظام حقیقی کام ہے۔ پیمانے پر ابلاغ، تربیت، اور ترغیبات کی ہم آہنگی اوور ہیڈ نہیں: وہی تبدیلی ہیں۔ اہلیت سازی، عمل کی برادریوں، اور اندرونی تبلیغ کا واضح بجٹ بنائیں۔
مینڈیٹ کے ردعمل سے خبردار رہیں۔ بڑے ادارے پالیسی میمو پر ڈیفالٹ کرتے ہیں۔ مزاحمت کریں۔ پکی سڑک کے بغیر مینڈیٹ خانہ پُری پیدا کرتا ہے؛ مینڈیٹ کے بغیر پکی سڑک حقیقی اپنانا پیدا کرتی ہے۔
ترغیبات اور فنڈنگ ہم آہنگ کریں۔ پراجیکٹ فنڈنگ سے پائیدار پروڈکٹ ٹیموں کی طرف جائیں تاکہ بہتریاں پراجیکٹ کی آخری تاریخ سے آگے بچیں۔ آؤٹ پٹ کو نہیں، نتائج کو انعام دیں۔

حکومت کے لیے خاص رہنمائی

عوامی شعبے کے ادارے خریداری کے چکر، تعمیل کے دروازے، ٹھیکیداروں کا انتظام، کئی سالہ فنڈنگ، اور شفافیت کی ذمہ داریاں جوڑتے ہیں۔ یہ ڈیزائن کے ان پٹس ہیں، بہانے نہیں۔

پہلے دن سے ATO کے لیے ڈیزائن کریں۔ Authorisation to operate اور مسلسل نگرانی کے دروازے (NIST RMF / 800-37 کے مطابق) ٹائم لائنز پر غالب ہو سکتے ہیں۔ سیکیورٹی کنٹرولز اور شہادت جمع کرنا جلد پائپ لائن میں بنائیں تاکہ تعمیل دیر کی، روکنے والی بھاگ دوڑ کی بجائے مسلسل ہو۔
بتدریج خریدیں۔ کئی سالہ، big-bang خریداریاں اسی big-bang ناکامی کو ادارہ جاتی بناتی ہیں جس سے یہ کتاب خبردار کرتی ہے۔ ماڈیولر معاہدوں، چھوٹے ایوارڈز، اور نتیجے پر مبنی کام کے بیانات کو ترجیح دیں جو iteration کی اجازت دیں۔
فروخت کنندگان اور integrators کو ٹیم کا حصہ سمجھ کر منظم کریں۔ سرکاری انجینئرنگ کا بڑا حصہ ٹھیکیداروں سے ڈیلیور ہوتا ہے۔ پکی سڑکیں، معیار کے دروازے، اور شفافیت کے تقاضے معاہدوں میں لکھیں، اور یقینی بنائیں کہ lock-in اور bus-factor کے خطرے سے بچنے کو علم اور کوڈ حکومت کو منتقل ہو۔
فنڈنگ کے چکروں کے گرد منصوبہ بنائیں۔ کئی سالہ اور سالانہ تخصیصات محدود کرتی ہیں کہ آپ کس پر commit کر سکتے ہیں۔ کام کو یوں ترتیب دیں کہ ہر فنڈ شدہ اضافہ خود مختار قدر دے اور فنڈنگ بدلنے پر آپ کو تبدیلی کے بیچ میں بے سہارا نہ چھوڑے۔
رسائی اور سادہ زبان قانونی ذمہ داریاں ہیں۔ Section 508، ADA، WCAG، اور سادہ زبان کے مینڈیٹ تقاضے ہیں، اضافے نہیں۔ رسائی کی جانچیں پائپ لائنز میں اور مواد کا ریویو ورک فلو میں بنائیں۔
شفافیت فیچر ہے۔ FOIA، اوپن سورس کے مینڈیٹ (“عوامی پیسہ، عوامی کوڈ”)، اور شائع شدہ سروس کے معیارات کا مطلب ہے کہ آپ کا کام عوامی جانچ کے تابع ہے۔ اس کے لیے ڈیزائن کریں: واضح ریکارڈ، جہاں مناسب ہو کھلا، اور ایماندار شائع شدہ کارکردگی کا ڈیٹا۔
آزمودہ عوامی شعبے کے نمونوں کی پیروی کریں۔ U.S. Digital Services Playbook، GOV.UK Service Standard، اور USWDS محنت سے کمائے سبق انکوڈ کرتے ہیں؛ انہیں دوبارہ ایجاد کرنے کی بجائے اپنائیں۔

اپنانے کی کامیابی ناپنا

پیشگی اشاریے (ابتدائی اشارے کہ تبدیلی جم رہی ہے) اور بعد کے اشاریے (وہ نتائج جن کی آپ کو آخرکار فکر ہے) دونوں ناپیں۔ ایک ریڈنگ نہیں، رجحان دیکھیں، اور میٹرک کو کبھی ایسا ہدف نہ بننے دیں جسے گیم کیا جائے۔

قسم	اشاریہ	یہ آپ کو کیا بتاتا ہے
پیشگی	پکی سڑک پر ٹیموں کی تعداد	اپنانا کتنی تیزی سے پھیل رہا ہے
پیشگی	پائپ لائن کے دروازوں کا coverage (ٹیسٹ، SAST، a11y)	معیار/سیکیورٹی کتنی پیوست ہو چکی ہے
پیشگی	ڈویلپر کے تجربے کے سروے کے سکور	کیا پکی سڑک واقعی مدد کرتی ہے
پیشگی	ADRs کے طور پر پکڑے فیصلوں کی فیصد	کیا تحریر/سیکھنے کی ثقافت حقیقی ہے
بعد کا	ڈیپلائے کی تعدد (DORA)	ترسیلی throughput
بعد کا	تبدیلیوں کا lead time (DORA)	commit سے production تک رفتار
بعد کا	تبدیلی کی ناکامی کی شرح (DORA)	ترسیلی عمل کا معیار
بعد کا	سروس بحال کرنے کا وقت (DORA)	آپریشنل لچک
بعد کا	واقعے کی تعدد اور شدت کا رجحان	وقت کے ساتھ قابل اعتمادی کی بہتری
بعد کا	آڈٹ کے نتائج / کنٹرول کی ناکامیاں	تعمیل کی کیفیت
بعد کا	برقراری اور چھوڑ کر جانا	کیا ثقافت بہتر ہو رہی ہے

چار DORA میٹرکس ترسیل کے لیے سب سے زیادہ توثیق شدہ صنعتوں کے پار نتیجے کی پیمائشیں ہیں؛ چاروں میں مجموعی بہتری کو سرخی کا اشارہ سمجھیں، اور ایک بہتر کرتے ہوئے دوسرے کی قربانی سے خبردار رہیں۔

ناکامی کے عام طریقے اور ان سے کیسے بچیں

ناکامی کا طریقہ	یہ کیسا دکھتا ہے	اس سے کیسے بچیں
Big-bang rollout	سب کے لیے ایک ساتھ سب کچھ بدلنا؛ پروگرام اپنے ہی وزن تلے ڈھ جاتا ہے۔	درد اور تیاری سے ترتیب دیں؛ pilot کریں، ثابت کریں، پھر پھیلائیں۔
پکی سڑک کے بغیر مینڈیٹ	پالیسی نیا طریقہ لازم کرتی ہے، مگر نیا طریقہ سست ہے؛ ٹیمیں کاغذ پر تعمیل اور اس کے گرد کام کرتی ہیں۔	آسان، بہتر راستہ پہلے بنائیں؛ خوبیوں پر اپنانا کمائیں۔
فریم ورک کی اندھی نقل	SAFe، Spotify ماڈل، یا کسی اور ادارے کا ڈھانچہ ان کے سیاق کے بغیر کاپی کرنا۔	اپنے درد اور اصولوں سے شروع کریں؛ ڈھالیں، پیوند نہ لگائیں۔
نتائج نہیں، سرگرمی ناپنا	مکمل تربیت اور خانہ پُری کا جشن جبکہ ترسیل اور قابل اعتمادی نہیں ہلتے۔	نتائج (DORA، واقعات، صارف کی قدر) کو شروع سے instrument کریں۔
ٹول-پہلے تبدیلی	پلیٹ فارم خرید کر توقع کرنا کہ ثقافت پیچھے آئے گی۔	عمل اور پکی سڑکوں سے آگے بڑھیں؛ ٹولز ان کی خدمت کرتے ہیں، الٹ نہیں۔
سرپرستی کھونا	ایگزیکٹو چیمپیئن چھوڑ جاتا ہے یا الگ ہو جاتا ہے؛ پروگرام رک جاتا ہے۔	تبدیلی کو معمول کے نظم و نسق میں ادارہ جاتی بنائیں؛ اتحاد بنائیں، واحد ناکامی کا نقطہ نہیں۔
دکھاوے کے میٹرکس اور گیمنگ	coverage یا velocity کے اعداد بڑھتے ہیں جبکہ معیار گرتا ہے۔	میٹرکس کو متوازن پیمائشوں کے ساتھ اشاروں کے طور پر استعمال کریں؛ کبھی واحد اہداف کے طور پر نہیں۔
پرانے نظام پر سمندر ابالنا	سب کچھ جدید کرنے کی کوشش، کچھ ڈیلیور نہیں۔	خطرے اور قدر سے رینک کریں؛ نازک چند کو strangle کریں، باقی کو منجمد کریں۔
تبدیلی کی تھکن	نظر آنے والی ادائیگی کے بغیر نہ ختم ہونے والی تبدیلی؛ ٹیمیں دلچسپی کھو دیتی ہیں۔	جلد کی جیتیں ship کریں؛ پائیدار رفتار کی حفاظت کریں؛ پروگرام کو ختم ہو کر معمول کا کام بننے دیں۔
org chart کو نظر انداز کرنا	نیا فن تعمیر موجودہ ٹیم کے ڈھانچے سے لڑتا ہے۔	inverse Conway manoeuvre لگائیں: ٹیموں کو اس فن تعمیر کے مطابق شکل دیں جو آپ چاہتے ہیں۔

مختصر ترین ممکنہ ورژن

اگر آپ اس ضمیمے سے اور کچھ یاد نہ رکھیں:

سب سے بڑا درد ڈھونڈیں اور اسے آمادہ ٹیم کے ساتھ ٹھیک کریں۔
اس اصلاح کو ایسی پکی سڑک میں بدلیں جو پرانے طریقے سے واقعی آسان ہو۔
نتیجہ ناپیں، جیت دکھائیں، اور اسے اگلے قدم کو فنڈ کرنے میں استعمال کریں۔
دہرائیں، دائرہ وسیع کرتے ہوئے، یہاں تک کہ پکی سڑک محض یہی ہو کہ آپ کیسے کام کرتے ہیں۔
سرپرستی رکھیں، ناپتے رہیں، اور کبھی big-bang نہ کریں۔

ان تشخیصوں کو لنگر دینے والے پختگی کے ماڈلز کے لیے باب 12.4 دیکھیں، اور ہر قدم کو عملی بنانے والی launch، ریویو، اور آڈٹ کی چیک لسٹوں کے لیے باب 12.2 دیکھیں۔