عزيزي رشيق ، أنا سئم من التظاهر

"رشيقة ميتة." يقول الناس أنه في كل وقت. لكنهم يضيفون بالضرورة: "نحن فقط أمزح". لقد كان نوعًا من هذا يعني أنك مارست هذه الممارسات الخاطئة والغبية التي ماتت بها Agile. لكن "الحقيقي" رشيق لم يمت. انها مجرد أن الجميع يفعل الخطأ. لذلك أدركت: أجيل الحقيقي هو ، كما تعلمون ، أجيل من الناحية النظرية . حتى أنا تنفيذها. وانت تعرف ماذا؟ أنا سئمت منه.

لقد رأيت مؤخرًا نفس الدفاع القديم في مقالاتي: "لكن ، لكن ، ولكن المشكلة هي الشلال ، والسكوت والتنفيذ الخاطئ لأجيل ، وعدم مراعاة البيان ... بلاه بلاه بلاه". ثم أخبرني بوب مارشال بالحقيقة. قال ، "اسكت يا تشارلز. البيان الرشيق هو الإبريق الذي نملؤه ". لقد أدلى ببعض التعليقات التي كان علي الاتفاق عليها. فكرت في ذلك. وكانت النتيجة هذا المقال.

هنا اختبار لك. كيف يبدأ السطر الأول من بيان Agile؟ لا زقزقة. لا تعرف؟ كل شيء على ما يرام. لا يهم تقول: "نحن نكتشف طرق تطوير برامج أكثر تقدمًا ..." توقف. لاحظ ، تقول: "تطوير البرمجيات". إنه لا يقول: "سحب مؤسستك" ، "سداد الديون للتحويل" ، "الاستغناء عن هذا القرف والسيطرة" ، "التركيز على النتائج وتحسين العمل الافتتاحي" ، "إصلاح نظام موازنة القرون الوسطى ،" أو أيًا كان المزيد من القيمة المضافة المتقدمة التي حاول الناس الاستثمار فيها. ولكن الحقيقة هي أنه عندما يقول الناس أن أجيل يشير إلى المنظمة بأكملها ، فهي تحريفية. هذا ليس عدلا.

لاحظ أيضًا أنه يبدأ " نكتشف ..." ولا يقول: "لقد تلقينا من أعلى ..." ألا تعتقد أننا تعلمنا شيئًا من عام 2001؟ أقصد ، نعم ، لا تزال معظم المنظمات الكبيرة عالقة في عام 1987 ، لكن حسنًا ، أنت. على عكس الاعتقاد الشائع ، فإن الصورة أدناه ليست في الحقيقة من فعل توقيع البيان. هل يمكننا في النهاية التوقف عن التظاهر؟



عرض البيان غرضًا محددًا ، لكنه لن يقودك إلى المكان الذي تحتاج إليه. لذا ابدأ دراستك. معرفتنا لها تاريخ انتهاء الصلاحية ، وليس طالما نفكر. كل شخص لديه زملاء (عادة رؤساء) يدعون أنهم "ليس لديهم وقت للتعلم". أنت نفسك تعرف أنها واثقة من نفسها في معرفتها. حتى تجد قائمة جيدة من الكتب. مواكبة بلوق جيدة. هذه بداية: إذا لم تكن قد قرأت Sense & Respond ، و Lean Enterprise ، ومقعد على الطاولة ، وكل شخص عامل تغيير ، أقترح عليك القيام بذلك على الفور. وإلى رؤسائك.

ابدأ في قراءة مشاركات John Cutler و Melissa Perry و Bob Marshall و Allen Holub و Laura Klein و Erica Hall و Neil Killick وأولئك الذين يشيرون إليهم. هل يتفقون جميعا مع بعضهم البعض (أو معي)؟ لا ، لكنها ذكية وستجعلك أكثر ذكاءً. ابدأ القراءة وشجع الآخرين. تقول شركة فاست إن المدير التنفيذي المتوسط ​​يقرأ 60 كتابًا سنويًا. كم عدد الكتب التي يقرأها قادتك؟ وماذا يقرأون؟ (لا تعد مقالات HBR وتقارير Gartner وروايات Maeve Binchi). لأننا نواجه الأمر: إذا كان قادتك هم سادة سكروم ، فأنت عالق بقوة في الثمانينيات والتسعينيات.



دعنا ننتقل إلى التعلم المستمر ونتوقف عن التظاهر بأن أجيل هو نوع من العلاج. يجب أن يقال هذا: Agile دائمًا ما يكون تحسينًا محليًا لزيادة طفيفة في كفاءة النظام . فقط رشيق وضعت بشكل غير عادل تحت المجهر فريق من مطوري البرمجيات. هذا لا يزيد من المرونة التنظيمية. NO. ومن المثير للاهتمام ، وفقًا لما قاله كين شوابر (راجع كتابه "غير آمن في أي سرعة") ، كان Agile محاولة "للتعويض عن الضرر الناجم عن الشلال" ، لكنه لم يعط المنظمات أبدًا بديلاً كليًا وقابل للتطبيق للشلال. لأن هناك فرق بين النظرية والتطبيق. العمل على منتج هو أكثر من ممارسة. عندما نشكو من AINO (Agile In Name Only) ، فإننا لسنا صادقين مع أنفسنا.

النظرية مقابل الممارسة ، تذكر؟ يجب أن نكون عمليين. رشيقة في الممارسة العملية هو دائما تقريبا AINO. يبدو وكأنه مشكلة في الحركة نفسها ، أليس كذلك؟ في أي حال ، هناك أشياء أكثر أهمية يجب معرفتها ، بما في ذلك (على سبيل المثال لا الحصر) Lean UX و Lean Enterprise و Beyond Budget و Theory of Restrict و Accounting Overput و Thinkingps و DevOps و Marshall Organizational Therapy وغيرها.

قد تسأل لماذا يتصدر Lean UX القائمة؟ نظرًا لحقيقة أن Lean UX في جوهره يشيع مفهوم اتجاه النتائج. فكر: إذا كنت لا تعرف نوع التغيير الذي تحاول إنشاءه ، فلن تفهم تصرفاتك. إذا لم يكن لديك إشارة محورية واضحة ، فلن تتمكن بعد ذلك من المرونة. هذا ما هو Agile ، بعد كل شيء ، هو محور. قد يعترض البعض: "لا ، لا ، تحقق والتكيف!" بالطبع النظرية مقابل الممارسة ، تذكر؟ لا أرى فرقًا مرنة تختبر وتتكيف. أرى فرق Agile تحاول اللحاق بالركب ، والتعب مع جيرا ورالي والعمل كما لو كانت تقوم ببناء جدار من الطوب بناءً على الطلبات.



يميل Agile في الواقع إلى إخفاء المشكلة الرئيسية - وهذا هو الافتقار إلى الثقة الرأسية في النظامين. يغادر Agile Coachis ، مما يؤدي إلى تفاقم الموقف: يتركون وراءهم مدراء يتحدثون الخنازير وفريق تطوير تحولوا إلى الإسبرانتو. تعتقد الفرق أن الإدارة مقطوعة ، وتعتقد الإدارة أن التركيز الرئيسي يجب أن يكون على الحجم والتوقيت والكفاءة ، متجاهلاً أن الجداول الزمنية تعسفية وأن تقديرات الوقت هي شكل من أشكال الهدر . (هل تعرف ما هي نقاط القصة التي تم اختراعها فعليًا لإخفاء الوقت والمساعدة في حل المشكلة نفسها؟ كانت هناك عواقب غير سارة هنا ، أيضًا ، نظرية وممارسة).

خمن من سيفوز؟ معسكرين لهما منظوران مختلفان تمامًا ، من أين يحصل أحد المعسكرات على تصنيفات من الآخر؟ إذا كانت الفرق مثل المكفوفين الذين يشعرون بالفيل ولا يتفقون مع ما هو عليه ، فإن القيادة تشبه الأفيال العمياء التي تهاجم الناس وتوافق على أنهم جميعًا مسطحون. الحل هو أن ندرك أن النظام هو فريق. انتهى بالفعل من التحسينات المحلية وأدرك أن الثقة هي المشكلة الأولى. التوقف عن وضع المطورين تحت المجهر بشكل غير عادل ، والسماح للآخرين للاختباء في صندوق أسود. (لماذا لا نهتم بكيفية عمل فرق التطوير الإستراتيجية؟ أو كيف قيود نظام المهندسين المعماريين القديمة؟)

وبينما نفعل هذا ، يجب أن نتوقف عن معاملة فرق التطوير كما لو كانوا يعملون في مصنع. نحن لا ختم الأطباق البلاستيكية. نخلق البرمجيات. تحتاج إلى التوقف عن التصرف مثل أننا نقدم بيتزا . هنا هي القواعد الأخرى. نحن لا نستخدم نفس الوصفة المثبتة. نحن نطور الوصفات . إذا لم تكن قد فهمت حتى الآن ، فهذا فتح عمل وليس مجرد تسليم. يؤدي إهمال الاكتشاف إلى خسائر فادحة: الوظائف غير المستخدمة وغيرها من الأعمال التي لا تحقق نتائج. هذا يكشف عن عيب عميق آخر من رشيق. يقترح أنه يمكن اعتبار المستخدمين خنازير غينيا: "مهلا ، فقط استخدم هذا المنتج الغامق ، ثم سنقوم بتحسينه." باستثناء المنتج الغامق يبقى عادة هكذا ، أليس كذلك؟ تصبح التحسينات المستقبلية "تكاليف" غير ضرورية.

لكن-لكن-لكن ، Agile يركز حقًا على الأبحاث! حقا؟ سنكون صادقين. النظرية مقابل الممارسة ، تذكر؟ إذا ربحت من خلال تصميم أو إجراء بحث ، فقم بالإجابة على هذا السؤال. كيف تشعر عادة حول العمل مع فرق مرنة؟ هل يُنظر إليك في البداية على أنها قيمة وتُطلب منك المساعدة في "الاختبار والتكيف"؟ أو هل يطلب منك "إثبات قيمتها"؟ كما قال آلان كوبر ، عندما يُطلب منك "إثبات قيمتك" ، فأوضح لك أنك في نظام لا يقدرك. يرجى ملاحظة أنهم يطلبون من مشارك فردي إثبات قيمته - لا يسألون عن مدى تحيز الكود الخاص بهم للمؤشرات في الاتجاه الصحيح. بمعنى آخر ، ما زالوا يركزون على الناس ، وليس على العمل نفسه . ربما لا تزال تركز على العظام ، وليس القيمة ، وتجاهل المناطق التي يتدفق فيها جزء كبير من القيمة بالفعل.

إذا كنت تعمل مع فرق مرنة ، في المرة القادمة التي يُطلب منك فيها "إظهار القيمة" ، جرب ذلك. ابدأ بطرح الأسئلة عليهم . هل يعرفون سعر التأخير؟ ما هي التمارين التي يستخدمونها لتقييم هذه المعلمة؟ ما هي النتائج المحددة التي يحاولون تحقيقها؟ ما هي نسبة منتجاتها التي تصل بالفعل إلى أدائها؟ ألا يعرفون؟ إذا كانت هناك طرق أسرع وأرخص لمعرفة ما يجب تطويره ، بخلاف إصدار الكود ، فهل هم مهتمون بالتعلم؟ ما هي كفاءة التدفق؟ كم هو سيء؟ كم من الوقت يقضون في الاجتماعات؟ إذا كانت هناك ألعاب مصممة وإجراءات مبسطة ستؤدي إلى حلول أفضل في وقت أقل بكثير ، فهل هم مهتمون بالتعلم؟ لأنني لن أعرض عليك القيمة فقط - سأعلمك أن تنشئ قيمة أكبر في كل ما تفعله .

هذه طريقة مختلفة للتفكير. هذا هو الفوقية. هذه استراتيجية. كما يلاحظ أوستن غويللا ، يركز كل من أجيل والشلال على التنمية . التصميم هو اختبار . إذا لم تكن مهتمة ، يمكنك المغادرة. إذا قاموا ببساطة بتخفيض رؤوسهم للإفراج عن منتج ما ، مع التركيز على التكاليف ، فلن يعرفون أبدًا ما يكفي لفهم أنك تحصل عادة على أكثر مما تركز عليه (أم ، عظام). هذا هو مصنع الميزة. المسؤولية المتبادلة. يتظاهرون بصنع أطباق بلاستيكية. لديك أشياء أكثر أهمية للقيام بها. لأن القيمة الحقيقية يتم توفيرها من خلال الخيارات التي يتم إنشاؤها من خلال البحث . لمزيد من الخيارات التي تنشئها وأكثر مرونة في النهج الخاص بك ، والمزيد من المسارات الممكنة ونتائج أفضل. ما الذي يحاولون تحقيقه؟ هل استكشفوا ثلاث إلى خمس طرق لتحقيق ذلك؟ سيؤدي ذلك إلى اتخاذ قرارات أفضل للمستقبل. خيار واحد ليس خيارا. اثنان هو معضلة. ثلاثة - الآن لقد حققت شيئا.

هل سمعت عن قانون التنوع الضروري؟ المكون مع معظم الخيارات يتحكم في النظام . قم بتطبيقه على صراع السلطة الغبي بين Agile و Waterfall. كان لديك مديرين تنفيذيين حاولوا الحفاظ على السيطرة على النظام من الأعلى وفرق مرنة حاولت تقريب القيمة من المصدر (المستخدمون الحقيقيون والعملاء). المخرج من حرب أهلية لا معنى لها هو تعليم الناس كيفية إنشاء خيارات على جميع المستويات . الطريق إلى الأمام ليس رشيقًا ضد الشلال. هذا هو العمل الاستراتيجي الذكي من أعلى إلى أسفل (الشلال) مع تكتيكات من أسفل إلى أعلى الموجهة تجريبيا. تصميم واكتشاف المساعدة في كلتا الحالتين.

إذن ... ما هو الحل؟ هذا هو التركيز المعقول على النتائج الواضحة ، وليس التسليم ، مع النتائج المخططة بدلاً من العلامات المخططة ، وليس مع المشروع ، ولكن مع فرق المنتجات الموثوقة المصرح لها بمراجعة الافتراضات والعثور على أقصر الطرق للقيمة.

الآن للتدريب (مقتبس من الرسم البياني جون Cutler).



لذلك ... هل هذا يعني رشيق يغادر؟ بالطبع لا. هذا هو مجرد بلوق وظيفة غبية. ليس لدي قوة. وحتى لو كان الأمر كذلك ، فإن Agile ما زالت غير تختفي. جعلت حركة رشيق العديد من هذه المفاهيم ممكن . بالإضافة إلى ذلك ، خلافًا للاعتقاد السائد ، لم يتم اختراع الممارسات الرشيقة من قبل حركة Agile. ظهرت قبل عقود.

لذلك لا ، لا أريد أن تغادر أجيل.

أريد فقط أن نكون أكثر صدقًا.